Opened 7 years ago

Closed 2 years ago

# Enabling DataSaverPlugin breaks 0.13dev-r0

Reported by: Owned by: Benjamin Lau Steffen Hoffmann normal DataSaverPlugin normal 1.0

### Description

Traceback (most recent call last):
File "build/bdist.macosx-10.6-universal/egg/trac/web/api.py", line 497, in send_error
data, 'text/html')
File "build/bdist.macosx-10.6-universal/egg/trac/web/chrome.py", line 982, in render_template
File "build/bdist.macosx-10.6-universal/egg/trac/web/chrome.py", line 942, in load_template
File "build/bdist.macosx-10.6-universal/egg/trac/web/chrome.py", line 653, in get_all_templates_dirs
for provider in self.template_providers:
File "build/bdist.macosx-10.6-universal/egg/trac/core.py", line 78, in extensions
components = [component.compmgr[cls] for cls in classes]
File "build/bdist.macosx-10.6-universal/egg/trac/core.py", line 199, in __getitem__
component = cls(self)
File "build/bdist.macosx-10.6-universal/egg/trac/core.py", line 138, in __call__
self.__init__()
File "build/bdist.macosx-10.6-universal/egg/datasaver/datasaver.py", line 21, in __init__
locale_dir = resource_filename(__name__, 'locale')
File "/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/pkg_resources.py", line 835, in resource_filename
self, resource_name
File "/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/pkg_resources.py", line 1305, in get_resource_filename
return self._extract_resource(manager, zip_path)
File "/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/pkg_resources.py", line 1316, in _extract_resource
zip_stat = self.zipinfo[zip_path]
KeyError: 'datasaver/locale'


I get the following stack trace when trying to load this plug-in in Trac 0.13dev-r0 (is there some other issue here... this looks odd) hosted on my OS X 10.6 machine. I'd be quite happy to track this down, but I'm noting this here for now since I was in the middle of another project and don't have time to work on this immediately.

### comment:1 Changed 7 years ago by Steffen Hoffmann

Status: new → assigned

This isn't related in any way to Trac 0.13dev (revision 0 is certainly wrong), but to building the plugin without i18n support in place.

This is a known i18n-related issue, or better due to the too clumsy way I did the initial implementation here (see #7850 for a similar case). I guess Babel isn't installed at your system, or has been installed after Trac. I'll modify the plugin source same way as I did for other plugins before.

### comment:2 Changed 7 years ago by Steffen Hoffmann

(In [10746]) DataSaverPlugin: Make sure to always include a 'locale' dir in zipped plugins, refs #9249.

Just some improved i18n code missing for this plugin, done elsewhere before.

### comment:3 Changed 2 years ago by uros@…

How is the status on trac 1.0.9 or newer, I've installed an egg however no restore button is seen.

### comment:4 Changed 2 years ago by Ryan J Ollos

Resolution: → fixed assigned → closed

Seems to work fine with Trac 1.0.9, even without Babel installed. I'll close this ticket since it looks to be resolved with [10746].

If you don't see the plugin installed, please check the log files, and ask on the trac:MailingList if you still have issues.

### comment:5 Changed 2 years ago by Ryan J Ollos

Keywords: 0.13 removed 0.11 → 1.0

### comment:6 follow-up:  7 Changed 2 years ago by anonymous

It works, however only for links inside trac.

If you type in the url line another page, restore form isn't able to restore the content.

Maybe a solution like: https://www.drupal.org/node/30220 Is to be integrated to prevent leaving the page with submitted content in it.

### comment:7 in reply to:  6 Changed 2 years ago by Ryan J Ollos

It works, however only for links inside trac.

If you type in the url line another page, restore form isn't able to restore the content.

If you enter a URL in the browser navigation bar to navigate away from Trac the data is not saved. According to testing I've done, if I navigate to an external site by following a link the data is saved.

You could create a different plugin to implement the behavior suggested on that drupal site. Users have mixed reactions to the confirmation dialogs. Some find them annoying: #4250.

I heard a complaint from my users a few years back about data not being saved in forms when navigating away from a page. I didn't really understand the justification for the complaint because that's the way nearly all pages on the web behave. In Trac there are some limited cases in which it is not obvious that data has been changed but not saved. In those cases we prompt the user before navigating away from a page: trac:#11682. I don't see a need for this on pages such as wiki edit. It should be obvious to users that their changes need to be saved. In the future hopefully we can improve on the overall editing experience of Trac and make it behave more like a desktop application.

I haven't seen any activity from the maintainer of this plugin in many months. I doubt there will be any development other than bug fixes in the near future.

### comment:8 Changed 2 years ago by uros@…

I think the issue is when trac is on https:// and when navigating away from https:// it is unable to restore.

On http:// it works, at least on my server with trac 1.0.9

### Modify Ticket

Change Properties