Development of a Plone Site (Volto). A Project Website with one time filled text, no or less editing in the future of the project. The structure and the content of sites are available in some Word Docs. Images not final. My thought is to implement the content via a distribution. make this sense? to much overhead?
pros:
in the development lifecycle i can reuse the content in any stage of my work and build
no "lorem ipsum" placeholders
better experience how look the site with the final setting of text, headings, list etc...
placeholder images can easy changed by editors in the final version of the project website
cons:
in my opinion, the goal of a distribution is not to provide content, it should rather be a "preconfiguration tool" or am I wrong?
is it better to use collective.export/import without plone.distribution and an initial prefill content profile?
I support creating content with your distribution.
In many cases, this makes wonders for writing tests that fully reflect what is happening on your site.
Usually I have:
Content created in a default profile (e.g. the directory/documents/whatever structure)
Content created in a testing profile (e.g. test users, dummy content, etc...)
This allows me and my coworker to share a common dev env and to immediately understand each other.
Silly e.g., saying "User X cannot edit an event location in workspace Y" is something immediately understood. You do not have to provide details about the workspace type or the workflow state, for example.
Piggy backing on this issue with some further questions about plone.distribution
My org has three types of sites we start from, currently using a python package/GenericSetup profile. Turning these into plone.distributions sounds perfectly suited for this.
We often have patches we want to apply to all of our sites of a certain type. Currently we do this with an upgrade step for their GS profile. Is there any benefit to tracking by distribution type instead?
Is there a concept of inheritance of distros? Like, distroB does all of the settings and content of distroA, and then does some other stuff on top of that. Or should I just have distroB load profile bases and content like in David's example above?
Is there any documentation on how to create select options in the site setup schema, like portal_timezone and default_language? I'd like to make an option to select one of our theme packages.
Overall, this tool looks great, thank you all for your work on it.
These are great ideas. I will add that I want to have this for the same reason that demo.plone.org uses it - create a site with dummy data that I can rebuild daily. With the import/export feature I can more easily have a coworker add content to the site, and then I export it down into the distro files. That's way easier than having to create this content completely programmatically.
A distribution is a combination of one or more of the following: a GS profile, some example content in plone.exportimport format, a JSON schema for questions to ask when the site is created, and hooks for processing those questions before or after the profile is installed. Most of this is only relevant during initial creation of the site. Upgrade steps for a GS profile are probably still the best way to manage updates over time.
Not really. At kitconcept @ericof has been experimenting with having several distributions that all extend a kitconcept.core profile which is a replacement for the CMFPlone:default profile, but this is still somewhat experimental.