Plonetheme-upload CLI based theme management

@datakurre,
I didn't see how to comment on your blog


I'm especially excited about plonetheme-upload https://www.npmjs.com/package/plonetheme-upload looks very useful, it looks a lot like the tools with firebase and heroku, something to add to my workflow.

I started using theme fragments on a project but since discovering that I can do the same thing with rapdio I've decided to standardize on one tool (rapido) for "theme fragments" type functionality.

Thanks for proving that there are alternative ways for comments these days :slight_smile:

I agree about themefragments vs. rapido. Fragments is older, has less features and thanks to Rapido, there's no need to develop it further. (There will be some enhancements for Mosaic support, once Mosaic has better interface to generate tiles into its Insert-menu, but no more.)

On the other hand, sometimes Rapido has "too much" features and then fragments is still an option.

1 Like

@datakurre nice summary of the approach. Fat themes is a nicer name than going eggless :slight_smile:

I think you only touch on the benefit of creating quicker iterations. It's kind of hard to quantify but I can attest it makes the process of building sites more agile and more productive. You really have to try yourself to find out. I hope lots attend the TTW training at the ploneconf to see for themselves.

rapido: I wouldn't describe it as a successor to plomino, even though it was originally intended as that. It is actually more a successor to themefragments. It takes the idea of adding ZPT inside your theme and adds .py files that contain multiple python functions. These are similar view callables in pyramid. It is more pythonic than zope python scripts. In terms of using either diazo or tiles to insert it into your site, it works the same as themefragments.
If your usecase demands it, it comes with a simple field/form framework and the ability to store light records easily in a non DX/OO way. But you don't have to use that.
Is that a fair assessment @ebrehault?

c.listingviews and c.facets are the other tools we normally use in our fat themes. We find that the combination of c.faceted navigation + c.listingviews + DX often makes for quick turn around on customising search and listing pages for clients.

@datakurre have you thought anymore about the git experiment at https://github.com/collective/collective.gitresource. ie git push your theme to plone on the server, edit via the theme editor if you want and then git pull the changes back.

@djay Thanks for correcting me about Rapido.

About gitresource. Right now I feel plonetheme-download next to plonetheme-upload and doing commits manually afterwards feels simpler and good enough. In theory, gitresource could add versioning features for theme editor, but that would require a lot of UI development (and making versioning control easy to use is always hard).

On Plone 5 collective.listingviews is not yet an option.
Mosaic is able to do what collective.listingviews does and feels far more flexible, so I consider it to be an acceptable replacement.

@datakurre I do think themefragments are slightly simpler with less moving parts but rapido has the following going for it:

  1. Genuine TTW - It doesn't require a restart of Zope when a new block is created
  2. Learn once - It presents a single, buildout free paradigm to learn (a novice can create a rating system by following a simple tutorial while a more experienced developer might be able to quickly integrate a third party shopping cart (see: https://makina-corpus.com/blog/metier/2016/paypal-tracking-with-rapido), a mailing list platform like mailchimp or a smart recommendation system)
  3. The potential to grow a community around rapido - since it can be decoupled from Plone, rapido.pyramid or rapido.kotti seem like legitimate possibilities.

collective.themefragments is TTW. Maybe you are mixing it with non-TTW views and overrides of plone.app.themingplugins?

Other than that, I agree on Rapido benefits over themefragments.

@pigeonflight Mosaic doesn’t solve most of what c.listingview does. e.g. it doesn’t let you customise listings. At the moment all you can do is pick from a list of baked in templates for different kind of listing views, ie pretty much the same as display views.

I’ve began exploring some ideas that could make mosaics work well for customisable listing view without the need for c.listingviews here https://github.com/plone/plone.app.mosaic/issues/239. It would be good to get some additional feedback on these ideas from someone like you who is used thinking about plone from an onboarding perspective.

yes, you are totally correct

@datakurre,
You're right, what I was using was plone.app.themingplugins not collective.themefragments, my apologies :slight_smile:

Just took a look at your prototypes, very nice. Do you just prototype with code?

@pigeonflight me? Yes, those two gifs were implemented with code as the code was simple. but to make them work fully would be harder and I'm not sure when I will have time for it. if I don't use code I use gomockingbird.

@datakurre,
Trying out plonetheme-upload and getting an error:
I installed with the following command:

sudo npm i plonetheme-upload -g

And then pointed it at my theme and Plone site:

plonetheme-upload mytheme http://localhost:8080/Plone/

And I get the following:

fs.js:549
return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
^

Error: ENOENT: no such file or directory, open 'package.json'
at Error (native)
at Object.fs.openSync (fs.js:549:18)
at Object.fs.readFileSync (fs.js:397:15)
at Object. (/usr/lib/node_modules/plonetheme-upload/index.js:15:26)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Function.Module.runMain (module.js:441:10)
at startup (node.js:139:18)

@pigeonflight My naive mistake. Please, reinstall plonetheme-upload. It should be 0.9.2 now.

Great! It worked this time.

I ran:

sudo npm update plonetheme-upload -g

And then

plonetheme-upload mytheme http://localhost:8080/Plone/

I figured that prompt: meant it wanted my username
and the second time I saw prompt: I put my password

Thiis what my screen looked like:

So a bit rough around the edges (scary for a newbie) but it works!

I think I'll do a lightning talk about this :slight_smile:

Nice! About prompt. After "prompt" should read username/password, but probably contrast is very bad for their colours against background.

@datakurre,
I keep wanting to be able to:

  1. List all available themes on a site
  2. Pull a theme down to my filesystem
  3. Maybe even set active site (while I'm working on a specific site then pulling always pulls from that site, pushing always updates that site)

I don't know if it is a design decision to make plonetheme-upload ONLY able to push themes, the name certainly suggests that. If you do add pulling, activating and listing as part of the feature set then you may need a new name...

plonetheme-cli
plonethemer
plonetheme-util

or if it becomes a universal bridge between TTW and filesystem then something like:
plonebridge (which I "secretly" want to be the name of a Plone distribution :slight_smile: ).