Blog

I have recently been working on my first development project with Plone 5 --upgrading the Plone issue tracker Products.Poi to Plone 5-- and will share here my experience, trials and errors, as well as some thoughts.

While the majority of the work was nothing new for me, there was the hurdle of the new Resource Registry. This registry is the replacement for portal_javascripts and portal_css in older versions of Plone. After reading complaints about the registry and my own failed attempts of working with it, I avoided it for as long as possible. Eventually I had to really dig in in order to get this registry to work for me.

The Objective

For those unfamiliar, Poi is an add-on that allows you to add issue trackers to your Plone site. With Poi, you can allow anonymous users to submit Issues. These Issues have two rich text fields and a related items widget, but these widgets aren’t available for anonymous users. The next three sections outline the work that was done to display the widgets.

Making TinyMCE Available for Anonymous Users

The work to get the fields to display the visual editor was not done directly in the Resource Registry, but had to be activated from Javascript. I could not have gotten this part completed without help from Nathan Van Gheem. First, a require statement had to be included to specify which pattern to load. Second, I had to specify which fields should display the visual editor. And third, this was wrapped in a condition to only load on the Add Issue page for anonymous users. Here is what I ended up with:

if($('body.userrole-anonymous.template-products-poi-content-issue-issue').length === 1){
 require(['tinymce'], function(){
 displayEditor($("#formfield-form-widgets-details textarea"));
 displayEditor($("#formfield-form-widgets-steps textarea"));
 });
} 

Making the Related Items Widget Available for Anonymous Users

The Related Items widget is a new feature we’ve added to Poi, allowing you to link related Issues to each other. I started by following my steps with TinyMCE, requiring the necessary pattern wrapped in the same condition.

require(['mockup-patterns-relateditems']);

This only half worked. The widget would load, but was missing the styles. This led me to start investigating how I could get the widget working properly by using the Resource Registry.

Demystifying the Resource Registry

We already had a basic bundle for Poi in the registry, but we couldn’t utilize it to help us load the widget since we needed to add a condition to the bundle to only load in a specific context. This would ensure resources were not loaded twice for some users.

So I created a new bundle that only loaded mockup-patterns-relateditems. Once compiled, the widget properly loaded for anonymous! But I still needed to set everything up in the Poi code to make this work automatically on install. Here were the steps I eventually followed:

• registry.xml needed the information about the bundle. I started with this:

  <records prefix="plone.bundles/poi-resources" interface='Products.CMFPlone.interfaces.IBundleRegistry'>
   <value key="resources">
   <element>mockup-patterns-relateditems</element>
   </value>
   <value key="enabled">True</value>
   <value key="last_compilation"></value>
   <value key="depends"></value>
   <value key="jscompilation">++resource++poi/poi-resources-compiled.js</value>
   <value key="csscompilation">++resource++poi/poi-resources-compiled.css</value>
   <value key="compile">True</value>
  </records>

• Next I imported this into the Plone site and went to the Resource Registry. My poi-resources showed up in the list of bundles with a ‘Build’ button. After the files built, I refreshed the page and viewed poi-resources again. The jscompilation and csscompilation URLs had changed from ++resource++poi (a browser resource folder set in the product) to ++plone++static, showing that a compiled version stored in the Data was being used instead of the versions from the product (which didn’t actually exist yet). I visited the URL for these compilations, and copied their contents into Poi, in poi-resources-compiled.js and poi-resources-compiled.css.
• I noticed these compiled files included a lot of extra code that I didn’t need because it was already being loaded in Plone. This is what the 'Stub JS Modules' field is for. Here you can specify all the resources you don’t need included in your compiled version. For our new bundle, I just copied the list from the plone-logged-in bundle. Then I was able to recompile, check that the widget worked as expected, and copied the new compilation into Poi.
• The final piece was to add an condition, limiting when this bundle would load:

  python: member is None and '++add++Issue' in request.get('URL')

My Assessment of the Plone 5 Changes

1. I am not sure why you need to specify which fields should display the visual editor for anonymous users, when it works automatically for authenticated users.
2. Similar with the related items widget: Once the bundle is set up and set to load on a single page, the require statement still needs to be included. I expected the require statement to work on its own, but the styles were missing. I suppose this was because there wasn’t a compiled version of just the CSS file, perhaps this is something that can be done better.
3. I wonder why my bundle included so many other JS files. It seems it should be much easier to specify the one file that I want without it automatically adding all the dependencies. This happens whether the plonebundle is listed as a dependency or not.
   1. The build screen does show which files it is adding, but the file names don’t always line up with the resource name, so it wasn’t easy to determine which resources needed to be listed in stub_js.

What Can Be Done to Improve this Code?

All that being said, I’m sure there are bits of this I did wrong or could do better. Since I’m still learning, and want to follow best practices, please let me know what needs to be fixed, or if I just need to enter issues in the GitHub tracker.