Improper resource URLs generated in Plone 5.0.5

I tried again to get my XML Director stuff flying on Plone 5.0 with the 5.0.5 release - however the nightmare with falling from one trap into another continues.

I have a stylesheet referencing to some SVGs in my resource folder:

The stylesheet is configured using cssregistry.xml

However the resource files can not be loaded due to some improper URL.

Where is this ++plone++production/++unique++/... prefix in the URL of the resource files coming from???


Does changing "++resource++xmldirector.plonecore/images/svg/raw2.svg" to relative urls work(images/svg/raw2.svg)?

(of course) no difference.

Why should the image URLs be resolvable without naming the resource inside the URL?
What is the meaning of the ++plone++production and ++unique++ namespaces? Where are they coming from? When and why were they introduced?


Highly unlikely in this case, but you can set a prefix in the theme:

maybe @ebrehault or @Alec Mitchell has some ideas.

The reason why I asked if making it relative fixed the problem is because I thought there was some logic for fixing css resource locations so it is not "obvious."

I believe the ++plone++production and ++unique++ urls were introduced so you could have highly cached resources. I forget the reason why but appending unique urls with a query string wasn't enough for some people to do cache busting urls.

What do you want to tell me?

browser:resourceDirectory is supposed to work in Plone 5.x - or?
Same code and configuration was working until why this sudden change or different behavior?


I'm pointing you to where ++unique++ namespaces are implemented and you can also see when they were introduced in Plone stack (look at the changelog). Also:

FWIU it's a namespace to allow caching for items in your ZMI's portal_resources. On site creation, Plone builds an aggregate of all bundles in order to reduce the number of resources in (resource registry's) production mode. That's part of what you see in the URL.

Problem is AFAIK you shouldn't have two ++namespaces++ in any URL so if you're manually adding the ++resource++ reference in your CSS/JS files, you should probably drop it.

No idea what you are trying to tell me.

Browser resource directory worked as expected until 5.0.4. Now in 5.0.5 there is something horribly broken.
I am not using plone.resource in an explicit way. I am using browser resources as we used it for years and as configured for this is a behavioral change a bug or a feature or a regression?


Further investigations: the problem with the broken resource URLs disappears when I enable the dev mode for resource registries and starting the development mode for CSS for the plone-legacy bundle and saving afterwards...then the icons are loaded properly...disabling the dev mode again makes the problem again we have to blame the resource registries?


Right, and the only reason it'd work the way you're doing it in Plone 4 when resources were compiled is because of acquisition magic.

Seems to me like url rewrites need to also be applied to legacy bundle---right now they are only applied to non-legacy bundles it seems. Maybe Eric can comment.

" the way you're doing it " else would you do it? There is nothing different from the way we did it in Plone 4.X. How else other than using url(..) with a relative URL would you reference resources from a configured resource directory?

Well, why was this working in all Plone 5.0.X releases so far? Why is it broken with 5.0.5?

I am under the impression that the resource registry implementation is in duct-tape mode...fixing bug and edge-cases here and there without having the big picture and having an idea about constraints and implications...since nine months there is no working resource registry implementation available that would be working for the most basic usecase (in this case using my own JS and CSS file).


I think it's because of the additional ++ urls that have been introduced...

And yes, everything for the "legacy" bundle is sort of duct-tape.

Yes, the reason it previously worked is because ++plone++static was traversable, now we have ++plone++production and ++plone++unique which are not traversable.

Again, I'm not sure why that was even necessary but it was added for some reason...

gentlemen, this conversation should be taken place on the GitHub issue and not here.

that way we will help @ebrehault to identify and fix the issue.

1 Like

again: when was this introduced? between 5.0.4 and 5.0.5? Why did it break within two minor releases? QA?


Regarding the "when", you got a reference in a previous answer which should allow you to find out by "git" means.

Regarding the "why", it is likely a bug. Bugs might get introduced at any time. Maybe, you can help by providing test cases for all the situations that are important for you?

1 Like

Dieter, please save your time and don't post unrelated and unhelpful meta-answers unless you can comment on these very specific issues.



Please more duct-tape!

My suggestion is to remove the Plone legacy bundle completely as soon as possible (best for Plone 5.1).


It is broken.
It does not work.
It is obviously impossible to fix outstanding issues.

Nobody has the full picture for understanding the problem and fixing the outstanding issues (and there is always one issue more).

There must be one working and documented way to include a JS extension and its resources in a straight forward way. A JS extension might consist of multiple Javascript files and CSS files. The handling of modules depending on RequireJS or without RequireJS must be documented carefully - in theory there should not be much difference. Keep in my that not everyone is JS wizard. Even we as integrators have issues using JS properly in Plone 5. Don't forget the non-integrators or people working with Plone 5 and JS from time to time. Plone 5 is absolutely not approachable and hackable regarding the integration of arbitrary JS module. There is a huge universe of JS components and in general you want to make use of it (I have my experience with moving from -> JSGrid -> agGrid).