Updating static files with legacy bundle in Plone 5

We're working in one add-on that uses the legacy bundle to register it's static resources (CSS and JS).

Recently we made a change on CSS and noticed it was not easy to make Plone 5 aware of this.

In Plone 4 we had the option of cook resources and we use it all over the place on upgrade steps every time we change something:

def cook_css_resources(context):
    css_tool = api.portal.get_tool('portal_css')

def cook_javascript_resources(context):
    js_tool = api.portal.get_tool('portal_javascripts')

how can we inform Plone 5 that changes have been made to those files?

I has been my understanding (maybe wrong) that the legacy bundles continue to use "portal_css" and "portal_javascript". Then, the approach from Plone 4 should still work.

A recent discussion (initiated by Dylan Jay) suggests that the new bundles can also be updated programmatically. Up to this discussion, I had the impression that for the bundling the JS engine in a browser were used for the bundling - likely, the impression was wrong.

Indeed we can update meta bundles programmatically with this:

thanks, Eric! can you provide a real world example of how do I have to use that on my upgrade step?

once again, this is why the whole thing is broken:

instead of giving a proper deprecation warning and pointing to the right way of doing things, we just keep including the same old (and now broken) code.

I would love to make a PR to fix it, but I have no idea how it works.

I made some tests and I can confirm the resources are not automatically updated after the upgrade step.

after upgrading my package, I had to do the following (correct me if there is another way of doing this):

  • go to the Resource Registries
  • select Development Mode(only logged in users)
  • Save
  • unselect Development Mode(only logged in users)

this kind of works, except for one detail: my upgrade step removed an item from portal_javascript and it still listed in the RequireJS configuration:

    baseUrl: PORTAL_URL,
    paths: {
    "resource-collective-lazysizes-ls-respimg-min-js": "++resource++collective.lazysizes/ls.respimg.min", 

I even created a part to deal with that in Plone 5 but is not working:


seems like a bug to me; can somebody confirm?

Everything you can do via the ZMI, you can do in Python code (e.g. your upgrade step code) as well. There will be no need for a manual intervention.

As mentioned here: https://github.com/plone/Products.CMFPlone/pull/1961#issuecomment-285309343 this is my answer to this question:

The best solution IMO is to clear set last_compile of the legacy bundle in registry.xml:

    <value key="last_compilation"></value>

After each profile import, the first time the plone-legacy bundle is accessed, it is re-cooked.
After cooking, the last_compilation attribute of the bundle is set and for further requests, the already cooked bundle is delivered.

If it's not already documented, this should go into the plone docs.

A button to manually re-cook would be a nice addition to the resource registry control panel.


seems this is not working; I added the following code to the end of the cookResources() method in BaseRegistry.py:

# fire Plone 5 legacy bundle re-cooking
registry = queryUtility(IRegistry)
registry['plone.bundles/plone-legacy.last_compilation'] = None

after running it, the old resource is still listed in the RequireJS configuration.

BTW, instead adding the code all over my add-ons, I would prefer to patch all methods in Products.ResourceRegistries to behave reasonably well.

UPDATE: can someone point me also to the code used to rename a resource from ++resource++collective.lazysizes/ls.respimg.min.js to resource-collective-lazysizes-ls-respimg-min-js?

Recooking has nothing to do with what is included in plone-legacy.
If you want to get rid of that resource, you:

  1. Remove the resource from the legacy bundle:
    <value key="resources" purge="False">
      <element remove="True">resource-collective-lazysizes-ls-respimg-min-js</element>
    <value key="last_compilation"></value>
  1. Remove the resource itself (actually this step is not necessary):

Plone Foundation Code of Conduct