UnicodeDecodeError when attempting to compile barceloneta.plone.less

I have problem on a site updated to 5.1.5 recently. I have a theme copied from barceloneta via the TTW tool.

I can not compile the barceloneta.plone.less file in the theming TTW tool. The LESS Builder just sits there with the message "Building".

An instance .log entry is generated thus:

2019-03-22T21:32:23 ERROR Zope.SiteErrorLog 1553290343.010.147106795153 http://blah.blah.blah:3030/Internal/++theme++internal/@@plone.resourceeditor.filemanager-actions
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 plone.resourceeditor.browser, line 583, in call
Module plone.resourceeditor.browser, line 533, in do_action
Module plone.resourceeditor.browser, line 226, in saveFile
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 66843: ordinal not in range(128)

I've tried this with a new Plone 5.1.5 install. I've created a new theme by copying the barceloneta theme TTW, but I have made no changes to the new theme. I still get the same problem where I can no compile bareloneta.plone.less.

This process works fine on other sites running plone5 < 5.1.5.

Any ideas will be most appreciated!

Which version of plone.resourceeditor are you using? The bug was fixed in 3.0.0.


This behaviour occurs with the default version (2.1.3) installed with the Unifiedinstaller for 5.1.5.

If I pin plone.resourceeditor to 3.0.0 in buildout.cfg and run buildout it pulls the new version in, but this creates a much bigger problem. I can run "instance start", and the processes for this startup, but I never get a working server available to use. The instance.log file shows that the server is repeatedly trying to startup.


2019-03-23T20:08:50 INFO Zope Set effective user to "web"
2019-03-23T20:09:14 INFO ZServer HTTP server started at Sat Mar 23 20:09:14 2019
        Port: 3030
2019-03-23T20:09:14 INFO Zope Set effective user to "web"
2019-03-23T20:09:38 INFO ZServer HTTP server started at Sat Mar 23 20:09:38 2019
        Port: 3030
2019-03-23T20:09:38 INFO Zope Set effective user to "web"
2019-03-23T20:10:09 INFO ZServer HTTP server started at Sat Mar 23 20:10:09 2019
        Port: 3030

This just goes on forever....

Any ideas?

You could try:



I tried that suggestion and running buildout generated the following error:

Updating instance.
Getting distribution for 'plone.app.contenttypes==2.0.2'.
Got plone.app.contenttypes 2.0.2.
Getting distribution for 'plone.resourceeditor==2.1.1'.
Got plone.resourceeditor 2.1.1.
Version and requirements information containing plone.behavior:
  [versions] constraint on plone.behavior: 1.2.1
  Requirement of plone.app.dexterity: plone.behavior>=1.0b5
  Requirement of plone.dexterity>=2.2.2dev: plone.behavior>=1.0b5
  Requirement of plone.behavior>=1.0b5: zope.schema
  Requirement of plone.behavior>=1.0b5: zope.interface
  Requirement of plone.behavior>=1.0b5: zope.configuration
  Requirement of plone.behavior>=1.0b5: zope.component
  Requirement of plone.behavior>=1.0b5: zope.annotation
  Requirement of plone.behavior>=1.0b5: setuptools
  Requirement of plone.app.multilingual: plone.behavior
  Requirement of plone.app.contenttypes: plone.behavior>=1.3.0
  Updating instance.
Error: The requirement ('plone.behavior>=1.3.0') is not allowed by your [versions] constraint (1.2.1)

I've changed the buildout.cfg to just pin plone.resourceeditor=2.1.1 and that seems to buildout OK and everything runs properly from "instance start". I've created a basic theme TTW and I've managed to compile barceloneta.plone.less.

I'm really surprised that this issue doesn't seem to have affected many other people?

Do I need to open a bug report about this, or is it a known issue fixed in 5.2?

p.s. Thanks to all for the replies/suggestions so far

In general, when you see (from tailing the instance log file or otherwise) a Zope instance restarting over and over again, it is best to stop it and start it in foreground, i.e.

bin/instance fg

(substitute the name of the client script for instance)

This way, you will almost always get a much more descriptive error that for some reason gets swallowed in background logging.

This is such a common practice that it should be added to our docs, if it isn't already. I just don't have the time to do so at the moment.