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).
As an example. One view loaded Datatables.net 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 DataTables.net 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
True or am I missing something? Thoughts?
I've come across this for CSS that defines relative images and has no LESS or SCSS to compile it.
A couple options:
re-compile with something that'll inline include those relative image resources. This is what plone core does now.
from your own integration css, just do a statement like:
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
The plone-legacy bundle does not do what it is supposed to do and raising
than it is trying to solve.
- Why do I have to recompile something myself? Isn't the plone-legacy bundle intended to work with existing resources as-is?
- 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 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: