Plone 5.1.1 soft-released

Plone 5.1.1 has been soft-released. Please give it a try and let me know if there are any critical issues. http://dist.plone.org/release/5.1.1-pending/versions.cfg

For those who haven’t run across soft-releases before, this is the
last step before the final release. Because things haven’t been
finalized yet, some packages may change between now and the release. It
is not recommended to use soft-releases in production.

Changelog

tempstorage: 4.0 → 4.0.1
------------------------

Zope2: 2.13.26 → 2.13.27
------------------------

twine: 1.9.1 → 1.10.0
---------------------

plone.app.robotframework: 1.1.3 → 1.2.0
---------------------------------------
New features:

- Imports are Python3 compatible. Add six into install_requires set and sort
  each file's imports with the isort package.
  [b4oshany, @davilima6]


i18ndude: 4.3 → 5.0.1
---------------------

Plone: 5.1.0 → 5.1.1
--------------------
New features:

- Release Plone 5.1.1
  [esteele]


plone.api: 1.8.2 → 1.8.3
------------------------
Bug fixes:

- Improved code quality according to isort and flake8.  [maurits]

- Fixed regular expression in test for Plone version.  [maurits]


plone.app.upgrade: 2.0.11 → 2.0.12
----------------------------------
Bug fixes:

- Rename retina_scales to highpixeldensity_scales.
  Fixes `issue 2331 <https://github.com/plone/Products.CMFPlone/issues/2331>`_.
  [maurits]

- Hide our 'products' from installation for both CMFQuickInstallerTool and CMFPlone.
  [maurits]


plone.memoize: 1.2.1 → 1.2.2
----------------------------
Bug fixes:

- Drop travis and tox. A solution that works at one point does not necessarily work later.
  plone.memoize is being tested on jenkins.plone.org.
  [gforcada]

- Clean up dependencies.
  [gforcada]


plone.synchronize: 1.0.2 → 1.0.3
--------------------------------
Bug fixes:

- Release it as a wheel as well as an egg.
  [gforcada]


plone.theme: 3.0.3 → 3.0.4
--------------------------
Bug fixes:

- Minor administrativa fixes.
  [gforcada]


Products.CMFPlacefulWorkflow: 1.7.4 → 1.7.5
-------------------------------------------
Bug fixes:

- Remove traces of ZopeTestCase.
  [gforcada]


Products.CMFPlone: 5.1.0.1 → 5.1.1
----------------------------------
Bug fixes:

- Include TinyMCE 4.7.6
  [frapell]


plone.app.debugtoolbar: 1.1.3 → 1.1.4
-------------------------------------
Bug fixes:

- Remove unittest2 dependency
  [kakshay21]

- Make it work in chrome, as '<script />' no longer works.
  [jaroel]

Well, depends on what you mean by 'critical issues'.
are missing Tinymce fonts critical ?

in Plone 5.1 there was some nice icons where I have added arrows.

I forgot to say that this can be seen only in prod mode, if one runs instance fg all is normal.

I investigated a bit and found that:

  1. it's possible to save files downloaded from the server in Firefox, by using the network view and doing right click copy / copy reply (translated more or less appropriately), I had indeed noticed that with Plone 5.1 the logged-in file was about 800 K while it is only 520 K with 5.11
  2. looking at both logged-in.css files, the 5.1 had the tinymce fonts inlined while the 5.1.1 had only references to the font files, and it was failing to load them
  3. I tried to generate the Gruntfile.js with plone-compile-resources and it displayed some nasty error messages:
Running command: /usr/local/plone-5.1/ploneprod/bin/client1 run /usr/local/plone-5.1/buildout-cache/eggs/Products.CMFPlone-5.1.1-py2.7.egg/Products/CMFPlone/_scripts/_generate_gruntfile.py
Using site id: Plone
Target compile path: fetch from bundles
2018-03-24 23:29:47 ERROR plone.subrequest Error handling subrequest to http://nohost/Plone/++plone++static/components/tinymce-builded/js/tinymce/skins/lightgray/skin.less
Traceback (most recent call last):
  File "/usr/local/plone-5.1/buildout-cache/eggs/plone.subrequest-1.8.5-py2.7.egg/plone/subrequest/__init__.py", line 146, in subrequest
    traversed = request.traverse(path)
  File "/usr/local/plone-5.1/buildout-cache/eggs/Zope2-2.13.27-py2.7.egg/ZPublisher/BaseRequest.py", line 508, in traverse
    subobject = self.traverseName(object, entry_name)
  File "/usr/local/plone-5.1/buildout-cache/eggs/Zope2-2.13.27-py2.7.egg/ZPublisher/BaseRequest.py", line 344, in traverseName
    ob2 = ob.publishTraverse(self, name)
  File "/usr/local/plone-5.1/buildout-cache/eggs/plone.resource-2.0.1-py2.7.egg/plone/resource/directory.py", line 238, in publishTraverse
    raise NotFound
NotFound
No file found: ++plone++static/components/tinymce-builded/js/tinymce/skins/lightgray/skin.less
2018-03-24 23:29:47 ERROR plone.subrequest Error handling subrequest to http://nohost/Plone/++plone++static/components/tinymce-builded/js/tinymce/skins/lightgray/Content.less
Traceback (most recent call last):
  File "/usr/local/plone-5.1/buildout-cache/eggs/plone.subrequest-1.8.5-py2.7.egg/plone/subrequest/__init__.py", line 146, in subrequest
    traversed = request.traverse(path)
  File "/usr/local/plone-5.1/buildout-cache/eggs/Zope2-2.13.27-py2.7.egg/ZPublisher/BaseRequest.py", line 508, in traverse
    subobject = self.traverseName(object, entry_name)
  File "/usr/local/plone-5.1/buildout-cache/eggs/Zope2-2.13.27-py2.7.egg/ZPublisher/BaseRequest.py", line 344, in traverseName
    ob2 = ob.publishTraverse(self, name)
  File "/usr/local/plone-5.1/buildout-cache/eggs/plone.resource-2.0.1-py2.7.egg/plone/resource/directory.py", line 238, in publishTraverse
    raise NotFound
NotFound
No file found: ++plone++static/components/tinymce-builded/js/tinymce/skins/lightgray/Content.less

finally I compared the 4.5.6 and 4.7.6 packages downloaded from Tinymce, the skin.less file is not under js/tinymce/skins/lightgray anymore, but there is now a
src/skins/lightgray/main/less/desktop/Skin.less that is having a similar purpose I guess while its organization is completely different.

2 Likes

a little update and a question.
Finally after downloading the dev tinymce update, copying the src/ directory into buildout directory, adapting the 2 css path in the tinymce resource, rebuilding the logged-in bundle with plone-compile-resources, stuffing the rebuilt css it into the production directory, the icons of the tinymce toolbar are back.
However, what I wanted to try is really the D. Glick patch to get the image caption back.
So I stuffed also the rebuilt javascript into the Zodb production directory.
Then disaster: tinymce did not initialize at all. A blank window.
I decided to do a diff between the original plone-logged-in-compiled.js and the one I had generated with plone-compile-resources.
Here the end (there is a big bunch of html diff that I did not investigate):

@@ -66046,6 +66050,7 @@
         imageAlign: _t('Align'),
         scale: _t('Size'),
         alt: _t('Alternative Text'),
+        caption: _t('Show Caption'),
         externalImage: _t('External Image URL (can be relative within this site or absolute if it starts with http:// or https://)')
       },
       // URL generation options
@@ -66066,11 +66071,6 @@
         {title: 'Icon', value: 'icon'},
         {title: 'Large', value: 'large'}
       ],
-      imageClasses: {
-        'image-inline': 'Inline',
-        'image-right': 'Right',
-        'image-left': 'Left'
-      },
       targetList: [
         {text: _t('Open in this window / frame'), value: ''},
         {text: _t('Open in new window'), value: '_blank'},
@@ -66081,7 +66081,7 @@
       folderTypes: ['Folder', 'Plone Site'],
       tiny: {
         'content_css': '../../../bower_components/tinymce-builded/js/tinymce/skins/lightgray/content.min.css',
-        theme: 'modern',
+        theme: '-modern',
         plugins: ['advlist', 'autolink', 'lists', 'charmap', 'print', 'preview', 'anchor', 'searchreplace',
                   'visualblocks', 'code', 'fullscreen', 'insertdatetime', 'media', 'table', 'contextmenu',
                   'paste', 'plonelink', 'ploneimage'],
@@ -66314,8 +66314,6 @@
         tinymce.init(tinyOptions);
         self.tiny = tinymce.get(self.tinyId);
 
-        self.tiny.initialized = true;
-
         /* tiny really should be doing this by default
          * but this fixes overlays not saving data */
         var $form = self.$el.parents('form');
@@ -76513,5 +76511,5 @@
   'use strict';
 });
 
-define("/trabajo/plone/buildout.coredev/src/Products.CMFPlone/Products/CMFPlone/static/plone-logged-in.js", function(){});
+define("/usr/local/plone-5.1/buildout-cache/eggs/Products.CMFPlone-5.1.1-py2.7.egg/Products/CMFPlone/static/plone-logged-in.js", function(){})

now that's interesting. The first diff is coming from D. Glick's patch. The next I certainly did not add in the released buildout generated from your release.
In the interest of knowledge I added back to plone-logged-in-compiled.js the 3 remaining diffs quoted above. I stuffed the result in the Zodb, reloaded my browser, and lo ! Tinymce works again.
Now my question: how comes that rebuilding plone-logged-in with the released tool (plone-compile-resources) gives a different result than the released compiled file with crucial missing parts ? Could the (presumably spanish speaking, with a /trabajo directory...) person who is doing this compilation step in and explain ?

I found that session refresh support of plone.session was completly broken in 5.1 and I fixed it. It would be great to have a fresh release of plone.session included in 5.1.1.

Because of some odd non-releated tests in Products.CMFPlone I had to fix, that one would need a release as well.

Another update.
TinyMCE icons are back in a more normal way. I noticed also a nice new feature, an advertisement for Tinymce displayed with the editor. [actually it can be disabled by setting:
{
"selector": "'tinymce'",
"branding": false
}
in the other settings tabs of TinyMce.]

Some details for people (like me) not familiar with Plone dev on how to test Plone 5.1.1 with nice TinyMCE icons and beautiful branding without waiting for the Plone release manager to release a 5.1.1rc1 version. Warning, that's only my uninformed interpretation of what happened in my tests.

First it's necessary to get the latest updates from github. Since I am mainly interested in Tinymce for now, I got only the updates to mockup since I posted my first ramblings.

plone_sources:
- "mockup = git GitHub - plone/mockup: A collection of client side patterns for faster and easier web development"

And I launched buildout again. Well in fact I don't launch buildout directly, I ask ansible and it does the laundry for me.

After that I got a new directory under the src subdir with the latest commits to mockup, all confirmed by 'git log'.

Then I wanted to have these goodies in Plone in production mode.
I launched plone-compile-resources, everything worked nicely this time, I got a bunch of new js and css and compiled css and js in Products.CMFPlone/static. So far, so good.

I looked again at Plone code and convinced myself that the way to go was to enable dev mode in Resource Registry and to disable it again. In fact I got that by reading combine.py, there is a combine_bundles routine that is doing that. In fact doing the enable dev/ disable dev trick does a full 'cooking' of legacy bundle and meta-bundles rebuild, that's the true meaning of the word 'Save' in the UI.

Sort of, because it did not work. My changes were not used.

So I took another look at the beast.

>>> pr=plone.portal_resources
>>> pr.items()
[('resource_overrides', <BTreeFolder2 at /Plone/portal_resources/resource_overrides>)]
>>> pro=pr['resource_overrides']
>>> pro.items()
[('production', <BTreeFolder2 at /Plone/portal_resources/resource_overrides/production>), ('static', <BTreeFolder2 at /Plone/portal_resources/resource_overrides/static>)]
>>> prop=pro['production']
>>> prop.items()
[('default.css', <File at /Plone/portal_resources/resource_overrides/production/default.css>), ('default.js', <File at /Plone/portal_resources/resource_overrides/production/default.js>), ('logged-in.css', <File at /Plone/portal_resources/resource_overrides/production/logged-in.css>), ('logged-in.js', <File at /Plone/portal_resources/resource_overrides/production/logged-in.js>), ('plone-logged-in-compiled.css', <File at /Plone/portal_resources/resource_overrides/production/plone-logged-in-compiled.css>), ('timestamp.txt', <File at /Plone/portal_resources/resource_overrides/production/timestamp.txt>)]

Under the 'production' resource dir can be found the 'metabundles' that are really sent to the browser. Metabundles can be in concept bundles of bundles, that are built by mere concatenation of the bundle compilation results. They don't exist anywhere on the file system. In practice the logged-in.js metabundle (the one interesting me) is built only from the plone-logged-in-compiled.js bundle

>>> pros=pro['static']
>>> pros.items()
[('plone-legacy-compiled.css', <File at /Plone/portal_resources/resource_overrides/static/plone-legacy-compiled.css>), ('plone-legacy-compiled.js', <File at /Plone/portal_resources/resource_overrides/static/plone-legacy-compiled.js>), ('plone-logged-in-compiled.css', <File at /Plone/portal_resources/resource_overrides/static/plone-logged-in-compiled.css>), ('plone-logged-in-compiled.js', <File at /Plone/portal_resources/resource_overrides/static/plone-logged-in-compiled.js>)]

items under the static pseudodirectory are in fact 'personalisations' of file resources in the 'static' file system directory under Products.CMFPlone.
If they exists, they are joined to the metabundles in place of the system file bundles they represent. That was my problem; probably because at some point I had used TTW compilation, a personalisation existed and was taken in the logged-in.js metabundle instead of the plone-logged-in-compiled.js system file produced by plone-compile-resources.

The schema is as following:
plone-compile-resources -> system files (bundles) under the Products.CMFPlone/static directory
(system files OR personalisations with personalisations having priority) -> meta-bundles
meta-bundles -> browser

I had only to test my hypothesis:

del pros['plone-logged-in-compiled.js']
del pros['plone-logged-in-compiled.css']
import transaction
transaction.commit()

Reconnected to Plone, enable/disable dev mode in resources manager -> reload browser with Ctrl F5 -> success, TinyMCE icons are back, proof that the meta-bundles were successfully rebuilt from the system files produced by plone-compile-resources.

That was that easy.

Can someone with the resources registry knowledge look at the "Themeeditor: cannot compile LESS" issue that is broken since Plone 5.1?

http://dist.plone.org/release/5.1.1-pending/versions.cfg pinns i18ndude = 5.0.1, but in https://github.com/plone/buildout.coredev/blob/5.1/versions.cfg it's already reverted to 4.3 with d900d5417feb9fbcda2633c7460bd4aa3e13d2cc because is an encoding-issue (plus a conflicting dependecy on zope.tal >= 4.3.0). That needs to be updated on dist.plone.org.

while I don't have ressources registry knowledge, I have nonetheless a suggestion.
Could you in your failed install:

  1. copy less.js from a 5.08 install under Products.CMFPlone/static/components/less/dist

  2. edit variables.plone.less in the copied theme, search for 'mobile', then add the missing separations characters in the first found line and the 2 following, save the file

and try to compile again ?

There is no change except adding a ?burst=date in the urls between less.js included in 5.0.8 and 5.1.0. I don't understand what missing separations characters you're talking about, in parts/packages/plonetheme/barceloneta/theme/less/variables.plone.less the first "mobile" search hit is this:

151 //*// CONTAINER SIZE ALIASES                                                    
152 @plone-container-mobile               @plone-container-xs;                      
153 @plone-container-tablet               @plone-container-sm;                      
154 @plone-container-desktop              @plone-container-md;

I don't see any relation with the ace/mode/behaviour/cstyle missing error anyway. If you have more insight, please give it in the related issue to not pollute the discussion here. Thanks. But I don't think it's a less syntax error, because the styles.css can be generated with lessc on the command line like I did https://github.com/plone/Products.CMFPlone/issues/2319 So the issue is related to an update of the ace editor or requirejs pipeline I guess, this is not my area of expertise.

I now see the LessError indeed, added a screenshot to the issue https://github.com/plone/Products.CMFPlone/issues/2344#issuecomment-379453199

@gp54321 Ah I just understood what you meant, the missing ':'. It was indeed this issue, thanks. And it was actually already fixed since the 23 Feb, but plonetheme.barceloneta 1.8.1 was never released. :frowning: @esteele can you please release plonetheme.barceloneta 1.8.1 and include it in Plone 5.1.1? Thanks.

glad to help, however I feel that the cache busting issue is as important if not more. I found the ':' issue after 15' of research but trouble was that -very bafflingly - it did not change anything so I was for several hours of wading through the less.js code before understanding that the problem was indeed fixed. As soon as the cache busting was back in, the strange and erratic behaviour vanished. This could cause lot of frustration, it's absolutely necessary to get this fix back.

Thanks @gp54321 and @vincentfretin for the research on that. I've release plonetheme.barceloneta 1.8.1 and included it in the release.

@jensens: I've added plone.session 3.7.0 to the release. If the changes in CMFPlone are only test fixes, I'm going to skip a new release of that for now, and we'll get those into 5.1.2 which is in progress now.

@pbauer Thanks. I've updated that pin.

@esteele - w/o the fixes of CMFPlone tests wont be green together with the plone.session changes. If this does not matter in a release Products.CMFPlone wont need a release.

I've removed the pending tag from the release and passed it on to the installers team.

people caring about doing stuff with Tinymce have better to wait for 5.1.2.

Thanks. demo.plone.de is now running Plone 5.1.1.

editing a page on demo.plone.de and looking at tinymce.minorversion in browser debugger returns 5.6 though. The ChangeLog says 7.6. Products.CMFPlone on dist.plone.org and Pypi include Tinymce 4.7.6.