Building mockup source in Plone 5.x, not in coredev, without pain?

What is the process for using an unreleased mockup?

For example, I am trying to use mockup 2.5 (unreleased) in Plone 5.0.7, including via mr.developer in my build.

In development:

  • Add to mr.developer/buildout (and pin rev, if you feel so inclined):
[buildout]
auto-checkout +=
    mockup

[sources]
mockup = git https://github.com/plone/mockup.git rev=1be95889f8fd0a03947b9bb79bf3109a7cb8e055
```
* Run buildout.
* Switch to development mode for JavaScript in you site's resource registries control panel, "Develop JavaScript" for `plone` bundle; save.  This allows you to use raw mockup source without building.

**In testing / production, or development where one wants a bundle:**

* Add to build, then run buildout as documented above.
* Manually, **_one painful site at a time_**, TTW build the `plone` bundle.
  * `./bin/plone-compile-resources` does not seem to actually rebuild the `plone` bundle when asked for a site, and still, it is site-specific.

I just want a way to use newer mockup via mr.developer-sourced git checkout for multiple Plone sites, without manually TTW re-building the `plone` bundle.  Ideally, a part in my buildout takes care of this for me.  **This is not clear, and I do not get the sense that this is sufficiently documented.  Any pointers?**

_My motive for using unreleased mockup is that there are bugs in mockup 2.4.1 (and possibly earlier releases) that break modals in plone.schemaeditor._
2 Likes

Maybe the plone-compile-resources script isn't reliably working in 5.0. A lot of fixes went there some time ago. But it's fine with Plone 5.1.

However, I would create a package with a plone.resource static directory configured, change the paths of the compiled css+js bundle resources to that new location via profile / registry.xml configuration (also, create the files otherwise it might break - although I recall having this fixed some time ago...) and recompile using the plone-compile-resources script.

That way you can ship your own version of the bundles to as many sites as you want.

By the way, this PLIP proposes (among other things) to move the bundles out of CMFPlone into a new package. When this is accepted and implemented it will be easier to depend on a specific version of mockup.

please elaborate: Plone 5.0 is supposed to be the stable branch while Plone 5.1 is still under development.

I suspect as much, I will try using 5.1b3 now.

Also, can you clarify if most of the changes in unreleased mockup 2.5 are pushed to static assets in Products.CMFPlone per your most recent commit?

Yes, please! That would make maintaining one-off, temporary forks of just compiled assets much easier.

@hvelarde I think there was some work done in the Products/CMFPlone/_scripts package for 5.1 that:

  • Changes how Gruntfile is generated;
  • Likely should be backported?
    * I have no idea if this is sufficient to cure what I have seen.

What I was seeing fail (when trying to use new mockup in "stable" 5.0.7 script), among other things, was build choking on finding XML templates for patterns.

IMHO, it should be made possible for tooling to support use of newer mockup in 5.0.x releases.

@seanupton yes - all changes from unreleased mockup as of time of this writing were pushed with that commit.

implementing the mentioned plip would also have another good side effect: plone.staticresources (or whatever that package will be called) will depend on a mockup npm release, thus mockup will have always have a release when we update plone.staticresources.

@hvelarde my opinion is that 5.1 should get a final release ASAP. We currently have 5.1b3 and should get a RC and final release soon. I always recommend to use the latest 5.1 release for any Plone project.

I'm not sure about the status of the plone-compile-script and the resource registry in general in 5.0 - but there were a lot of improvements in these areas for 5.1 and I do not have any issues anymore with it. I don't think it's worth backporting these changes but better to move forward for 5.1.

1 Like

If I create an integration package with a plone:static directory to put compilations in (and registry.xml entries to point at this), do you mean that plone-compile-resources wants to overwrite existing (even if empty) files -- it will not create before writing to the compilation filename(s) one's registry entries point at?

Sean

plone-compile-resources will always overwrite existing files. maybe it fails if the files do not exist... try it out...