Enabling DataSaverPlugin breaks 0.13dev-r0

[Benjamin Lau]

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
    template = self.load_template(filename, method=method)
  File "build/bdist.macosx-10.6-universal/egg/trac/web/chrome.py", line 942, in load_template
    self.get_all_templates_dirs(), auto_reload=self.auto_reload,
  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.

[Steffen Hoffmann]

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.

[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.

[uros@…]

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

[Ryan J Ollos]

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.

[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.

[Ryan J Ollos]

Replying to 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.

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.

[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