No js_path or css_path found. We need a plone.resource based resource path in order to store the compiled JS and CSS

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.

My registry.xml contains:

<?xml version="1.0"?>
<registry xmlns:i18n="http://xml.zope.org/namespaces/i18n" i18n:domain="plone">
  <records interface="onkopedia.policy.interfaces.IOnkopediaSettings"/>
  <records prefix="plone.resources/onkopedia" interface="Products.CMFPlone.interfaces.IResourceRegistry">
    <value key="js">++resource++onkopedia.policy/onkopedia.min.js</value>
    <value key="css">
      <element>++resource++onkopedia.policy/onkopedia.min.css</element>
    </value>
  </records>
  <records prefix="plone.bundles/onkopedia" interface="Products.CMFPlone.interfaces.IBundleRegistry">
    <value key="resources">
      <element>onkopedia</element>
    </value>
    <value key="enabled">True</value>
    <value key="depends">plone</value>
    <value key="compile">False</value>
  </records>
</registry>

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.

try avoiding the resource registries at all as documented here:

please stop using obsolete technologies; it's 2018, use webpack as everybody else.

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.

1 Like

yes, you can; see:

check webpack's configuration; this is in production on Brazilian Presidency site.

(the documentation is in Brazilian Portuguese, I'm sorry abut that.)

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.

and that's exactly what you get when you skip the resource registries: you have a viewlet injecting the resources site wide.

just be aware you may need to avoid some common issues with RequireJS, especially the Mismatched anonymous define() modules.

better to include you code in a var, as described here:

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.

you're just kicking the can down the road and you know that:

the viewlet is not crappy; it's the easier way to go until the resource registries are completely rewritten to avoid the bundling step.

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

2 Likes

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.

See you in Tokyo.

1 Like