Can not revert changes to page and now toolbar icons display is broken

You are not alone …

I've done a bit of poking about and I've got the icons to display properly now. I think the icons issue may have been related to uninstalling and removing collective.easyslideshow? I had a poke in the resource registry and saw that I still had a JS related to easyslideshow installed as part of the plone-legacy bundle. I removed this and rebuilt plone-legacy, but no difference noted. Taking the resource registry in/out of debug mode after this seems to have fixed the problem.

I still have the problem with not being able to revert any content to previous versions. Any ideas where to look for this?

This is a wild guess, but sometimes 'Insufficient Privileges' can be something wrong with a view.
(so it could be that the 'revert view' gives you errors

Do you get it at the @@historyview or 'when you try to revert' ?

actually, taking the resource registry in/out of debug mode is the only way to rebuild plone-legacy. I don't see how you could have 'rebuilt' the plone-legacy bundle without the debug mode switch, there is no 'build' button with this very special bundle.

You're right, this is the case. I've just checked and my site was still in debug mode. Taking this out of debug mode causes the icons display to break again...

I can view all the history for all content. I can compare, I can preview all versions. When I click on any of the revert buttons (on any content) I get the "Insufficient Privileges" error.

I don't want to be a nag but did you actually take a look at the browser console to see if there was any resource load problem ?

Except from installing something (that has some resources), I have found no way to fix this except the 'rewriting solution mentioned earlier'

Symptoms like this usually indicate some breakage in a previous bundle part. In debug mode, resources are provided individually and there is few interference from one resource with following resources; in non-debug mode, resources are bundled and problems in one part (for example syntax errors) may cause severely affect following parts. Check the browser console to learn about JS and CSS problems detected during page rendering.

If you are lucky (likely, you will not), then the "Insufficient Privileges" error is associated with an Unauthorized exception. In this case, reconfiguration of the error_log object in your site (not to ignore Unauthorized) can give you an entry there for your problem. In this case, configuring verbose-security can give you quite detailed information about the problem.

Unfortunately, it is quite likely, that Plone uses its own code for the "Insufficient Priviledges" - and likely no Unauthorized exception is involved or it is caught early by Plone. In this case, the above approach will not help. Instead, you could try to localize the Plone code responsible for the "Insufficient Priviledges" check and debug it to find out why it fails.

actually if the problem is Javascript from a disabled add-on remaining in the plone-legacy bundle, switching on and off the development mode does remove it. I have yet to see a case where it does not work (if the Javascript still exists in the buildout-cache, you have to remove the reference from the plone-legacy bundle manually, unfortunately)

What Plone is doing while 'cooking' the legacy bundle can be checked on the console if one starts it in fg mode, it's easy to see if there is some weird Javascript persistence.

Browser console shows the following when rendering any page:

Source map error: request failed with status 404
Resource URL: http://vm-tallinn.ee.ucl.ac.uk:9090/ipes-cdt/++plone++production/++unique++2018-03-12T16:20:02.869263/default.js
Source Map URL: jquery.min.map
patterns.Patternslib Base: This pattern without a name attribute will not be registered!

The browser console errors still appear if I put this in debug mode, but the icons display is fixed, so I don't think this is the cause of the problem. Out of debug mode the icons display is broken again....

I've stopped the error log ignoring Unauthorized errors and now this is logged when I try to revert:

Traceback (innermost last):
Module ZPublisher.Publish, line 138, in publish
Module ZPublisher.mapply, line 77, in mapply
Module ZPublisher.Publish, line 48, in call_object
Module Products.CMFCore.FSPythonScript, line 127, in __call__
Module Shared.DC.Scripts.Bindings, line 322, in __call__
Module Shared.DC.Scripts.Bindings, line 359, in _bindAndExec
Module Products.PythonScripts.PythonScript, line 344, in _exec
Module script, line 4, in revertversion
<FSPythonScript at /ipes-cdt/revertversion used for /ipes-cdt/front-page>
- Line 4
Module AccessControl.ZopeGuards, line 305, in guarded_import
Unauthorized: import of 'six' is unauthorized

This is good news: the problem is in a Python script named revertversion. Recursively search you file system (when the Plone components are placed) for a file revertversion.py. It imports the module six (a helper to get code compatible with both Python 2 and Python 3) but six is not declared "safe" for imports in untrusted code.

There are several possibilities to fix the problem:

  • allow the import of six in untrusted code. For this you would put the following code sequence somewhere executed during startup:
    from AccessControl import allow_module
    allow_module('six')
    
  • find out to which component the script above belongs and try to use an older version of this component (by version pinning) -- one that does not yet try to be compatible with both Python 2 and Python 3. The components "Change log" likely gives hints towards this version.

Your browser console is rather quiet. I am using "firefox" and especially its "inspector" ("SHIFT+CTRL+I"); it is much more verbose. Maybe, you can "tune" your browser console to get more information.

Yes as @dieter said use Firefox and especially the network window, where you could see if URL are failing (404 errors) it would indicate that really the resource redirection problem that @espenmn was talking about is hitting you. If you see 404 errors and weird URL with ++production...++plone.static it's the culprit.

Revert problem solved!

The problem is with the release of Products.CMFEditions that was installed as part of the 5.1 upgrade. The changelog states that version 3.1.1 is to "Prepare for Python 2 / 3 compatibility", so I guess this is where the "six" dependency was added?

I fixed this issue by adding the following to the "[versions]" section of buildout.cfg and rerunning buildout:

Products.CMFEditions = 3.1

Now I can revert to earlier versions of content. I have 3 sites currently running 5.1 and this problem affects them all, so maybe this version of CMFEditions needs to pinned in the default version.cfg for plone 5.1?

Thanks so much for all your help.

Hopefully we'll get the toolbar icons issue sorted as well!

I've managed to fix the icon display issue.

All pages were throwing up 404's when trying to access any of the fontello files, or any of the "woff" files:

i.e.
....++plone++production/++unique++2018-03-12T20:03:10.995007/++plone++static/fonts/plone-fontello.ttf
...++plone++production/++unique++2018-03-12T20:03:10.995007/++plone++static/components/bootstrap/fonts/glyphicons-halflings-regular.woff

2018-03-12T20:03:10.995007 is the last compile time of the plone-legacy bundle.

I manged to fix this with the help of this bug report on Error 404 loading fontello font while upgrading to 5.1b3

Based on this clue I did:

  • Goto the ZMI >> PLONE_SITE >> portal_resources
  • Rename the "static" and "production" folders
  • Goto the Resource Registry Control Panel and turn debug mode on and then off

This should recreate the "static" and "production" folders in portal_resources and magically the icons should finally be displayed again.

Thanks to everyone for all their help resolving this.

1 Like

Hey @lheagney, just want to say thank you for taking the time to publish this information - we spent hours troubleshooting this exact issue and finding this post was the only thing that enabled us to solve it and move on with our project.

It's because of people like you who are willing to share their solutions, instead of just doing them, that makes this community so strong and keeps it moving forward.

Thank you brother!!!

1 Like