Situation: moving an add-on from Plone 4 to Plone 5. All CSS and Resource exist as browser resource by concatenating the files and minifying them using yuicompressor.
The corressponding files are available as ++resource++onkopedia.policy/onkopedia.min.cs and ++resource++onkopedia.policy/onkopedia.min.js.
I receive the following error while installing the add-on...why is this?
2018-10-31 10:36:22 WARNING Products.CMFPlone No js_path or css_path found. We need a plone.resource based resource path in order to store the compiled JS and CSS.
2018-10-31 10:36:22 WARNING Products.CMFPlone No js_path or css_path found. We need a plone.resource based resource path in order to store the compiled JS and CSS.
I need the JS and CSS for a complete site and not only for a single package. And I can not inject the stuff with a theme/diazo.
I am fully aware that the resource registry is an accumulated pile of misconceptions - both in the backend and frontend.
I wanted to say that we don't use a theme at all here and the functionality must be available through my policy package without further theme or styling.
I ended up including both minimized files for now as only entries in cssregistry.xml and jsregistry.xml and they are happily merged into the plone-legacy bundle. The viewlet is crappy but clearly the best option for getting around resource registries completly..especially it is a pain in the a@@ using resource registries for development.
Only a clarification for the original question why the "plone.resource based resource path" is showing up. It seems the value key="compile" "False" flag is ignored. But this key is only useful if you specify already 'compiled' resources in the plone.bundles/onkopedia bundle with the jscompilation and csscompilation values and don't pass in any resources:
Because there's an 'onkopedia' resource in the bundle definition, the compile bundle step is still triggered and it needs to store it's compiled version somewhere. This can only be done in the ZODB (Zope security don't write to filesystem) in portal_resources (plone.resource). Hence the error.
Unfortunately plone.resource is only vaguely mentionned and never explained on docs.plone.org, but it's the intermediary zodb store where both compiled "resource into bundles" are stored (as the legacy bundle) and also the final 'combine_bundles' step (if you specifcy merge_with) for production delivery of the default and logged_in css/js.
I've stumbled my way through the resource handling in Plone 5.X this summer, one of the main issues I found is not that there are still some bugs left (there are) or the process is complicated (it is, inherent to resource handling) but that there was and is no 'high/mid level' overview documentation of how it is intended to work. (for which I have some WIP).
Not repeating my usual rant about resource registries but the only reasonable way to CSS/JS in recent Plone 5 projects is to inject the resources manually per-template if the required functionality is limited to a particular template or browser view. Or by loading the resource through a viewlet as Hector proposed. This works without problems and side-effects, it's developer friendly and in particular you understand what's going under the hood. Using resource registries is like play Russian roulette with six bullets.