@thet could you please elaborate why we need the fonts rooted? What's the reasoning behind? This will break any deployment that involves not having Plone in the root.
an attempt was already made to revert the use of / prefix for loading the font resources, but there is an issue with it being bundled in a released package as @cekk reported there as a last message.
I don't understand what is so complicated. We also have preprocessors, so use them to set the levels of ../../ (plone 6 needs 3 ../) in css. This is not a bug but mismanagement due to abuse of traversal.
++production++, ++static++, ++webresources++ are not regular objects to traverse, you will get a lot of insufficient privileges if you rely on it.
These bugs exists because we want to handle them with Acquisition, which is wrong and unneeded in this case because we know the paths (actually we create them, so...).
Wouldn't be better to fix those traversal issues, so these resource paths are evergreen and fulfil their initial purpose? If they are incapable of doing that purpose well, then, is it worth to even continue using them?
@jensens do you think it is possible to fix these traversal issues when the traversed paths are fully/partially private or the user has no permissions over them?
Please note, in the next Plone 6 alpha release which will introduce the change to ES6, inline SVG icons and the new resource registry this should not be an issue anymore. Fontello isn't used anymore and we include all icons inline. Also the resource registry does not do this bundle merging and path mangling with ++unique++ and ++production++ urls.
Yes, not merging "should" be the easiest fix to use it with relative path.
Also it's probably not much use for anonymous users and should get a only-for-logged-in-condition.
Ok! So in Plone 6 we will be ok in the next release. One down.
Regarding the workaround you proposed, I think that this is beyond to find a workaround. The fact is that everybody upgrading their sites to that versions, will get the issue, no matter what they do. I don't know if we could have minimised it with an upgrade step (I can see one in p.resources, but apparently not for dealing with this).
So I do not see reverting that PR an option, because we will break again some deployments, and we will have to write an inverse upgrade step.
Also I can't see now how a link to a static resource in ++plone++static has to do with a bundle. When the production bundle is created, then it gets it from the instance root at the moment of compilation, right? There is no way to continue using relative resources instead of using the root? I would need someone to explain it to me and show me the issue. Why we cannot revert this?
OK, I tried it. But it doesn't work anyways. The generated URL is /Plone/++plone++static/++unique++2021-10-22%2014%3A35%3A54.260820/plone-glyphicons-compiled.css, so still this ++unique++ in between.
So, changing the paths from absolute /++plone++static/fonts/ to relative ++plone++static/fonts/ or even fonts/ should just work fine with the added benefit, that the resulting URL will contain the ++unique++ part for caching/cache breaking.
That is probably what you want, right @sneridagh ?
Do you see any problem with that approach, @agitator ?
the ++unique++ string is a feature of plone.resource and ensures unique URLs which can easily be cached. I just before talked with @jensens about that - we need that ++unique++ (++webresource++ in Plone 6) because cache-breaking URL search strings (?t=1234) are not allowed with some popular CDNs (right @jensens ?).
The ++production++ is part of the resource merging into production bundles and done in CMFPlone.
yeah, at least is how I thought that it used to work, right? Sorry for being so rusty on RR matters I can barely remember how they work, least to say internally! :')
I have installed the 1.x branch in a client's site running Plone 5.2.7, and after running the upgrade step the icons are showing OK in both deployment scenarios (full domain and a path under the domain) and with debug mode on and off.
Awesome! Thanks for the swift response @thet! Thanks, @erral for giving it a shot! I guess we can make a plone.staticresources release now and then include it in the upcoming Plone 5.2.8 release.
I briefly talked to @mauritsvanrees and @thet on Discord and then went ahead and did the release. Please give it a shot folks and report back if the release fixed the issue.
I can barely remember how they work, least to say internally! :')