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.
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.
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?
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.
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.