Plone 5 registries: legacy bundle implementation broken-by-design?

Hi there,

this is a summary of my failed tries for getting my xmldirectory.plonecore add-on working on Plone 5.
Porting the Python code, browser views etc. from Plone 4 to Plone 5 was no problem (almost no changes needed).
However dealing with the resource registries - the Javascript registry in particular - is a huge mess. I tried to move my code to regular bundles but this failed to various reasons. So the plone-legacy bundle is the last hope. What is the promise of the plone-legacy bundle in particular?

As an example. One view loaded JS and CSS files directly into the head slots in Plone 4:

This was now moved to registry.xml:

Note that the DataTables files are now spread across 3 different resources (very ugly but that can be handled).

Second pitfall is that the path names of the CSS and JS resources must not contain trailing or leading whitespaces. It took some time to figure out that the resource where not properly (no proper error message propagated to the integrator)...not a big deal though.

However the biggest problem is that CSS resources like

containing relative references to images like

do no longer work properly due to the fact that URL of the plone-legacy bundle no longer works together with the assumptions made in the distribution.

The plone-legacy bundle is for that reason in most cases completely useless and broken:

  • in this case I have to adjust the CSS files in order to make the url() references work again
  • I need to touch a third-party package in order to make it available properly in Plone 5
  • I need to preserve two different versions of the Datatables CSS file for Plone 4 and Plone 5 compatibility
  • I need to provide two different versions of my own Datatables CSS customizations for Plone 4 and Plone 5 compatibility
  • in my case I had to split the resources of one third-party Javascript plugin over three resource registrations in registry.xml

True or am I missing something? Thoughts?


1 Like

I've come across this for CSS that defines relative images and has no LESS or SCSS to compile it.

A couple options:

  1. re-compile with something that'll inline include those relative image resources. This is what plone core does now.

  2. from your own integration css, just do a statement like:

    @import "some/other/library/styles.css";

And the CSS file will be loaded from it's original location, not compiled and all the relative images should still work.

Don't get me wrong but these are once again workarounds for serious
architectural problems?
The plone-legacy bundle does not do what it is supposed to do and raising
more problem
than it is trying to solve.


  1. Why do I have to recompile something myself? Isn't the plone-legacy bundle intended to work with existing resources as-is?
  2. So I should include the same 3rd party CSS with the plone-legacy bundle and a second time from my own integration CSS? Yet another broken workaround.

So what is the real value of the plone-legacy bundle?

Currently it raises more problems than it actually solves. Or am I missing something?


The real problem here is that we no longer have acquisition magic. The reason you saw this problem less in Plone 4 was that acquisition magically found things in portal skins.

However, in Plone 4, you can still get this issue. If you use a browser resource and compile it with portal_css, the same thing would happen.

I'm sorry you're having these issues but this is part of what it takes to integrate javascript/css into projects. I come across the same sort of issues with django, pyramid and using fanstatic with pyramid. If you want to be able to compile resources together, paths get annoying to deal with. Often people define build steps to rewrite paths in built css files, they copy all images into a share relative path or they use inline plugins to add images inline with css.

I'm not sure there is another solution besides doing magic with acquisition or ++plone++ url magically handling.

FWIW, I've been rewriting css shipped with js/css modules for a long time(plone 3/4).

So that way of doing it is fine.

I put together some quick notes on how I got semantic ui working on Plone 5 without going the bundles/resources route: