What is the difference between installing plone with cookie-cutter and configuring with buildout?
it would be better if any explain this in detail 
!
Thanks!
2 Likes
I was thinking the same thing and there are other doubts too.
I guess cookieCutter and buildout are scaffolding tools that stitch your packages together. Different methods I think.
I was also installing plone and used cookie-cutter to achieve the same. After installation, I saw that the frontend folder has the folder omelette as mentioned in the mastering plone 6 documentation. Then closed the frontend server and left the backend server running
Next thing I went to github/volto/plone repository and downloaded it. Installed the dependencies and started the frontend server. Note: Backend server was already running. The website was working fine.
But I noticed one thing git volto repo has many other folders like storybook and even the omelette folder was missing.
Anyone from the community could clarify what is the difference. and What is the proper method to install, work and contribute to plone.
1 Like
If you clone the volto repo and run it, you're running Volto as its own standalone thing.
To be able to customize Volto and make it suitable for your website, you should create your "Volto project", by running the yo @plone/volto my-project command. See the Getting Started documentation.
Also, please note the distinction: Volto is the React frontend layer for Plone, the Python-powered backend. Plone can also run standalone.
1 Like
See the note.
1 Like
Once upon a time, one of the 'selling points' of Plone was that it had a 'one click installer'… 
6 Likes
Why not include documentation for buildout? At my work, we have UNIX based dev and prod servers, but locally I work on a Windows machine with security restrictions precluding Docker and WSL. I am obviously not trying to deploy a site on my PC, I just want to use it to write an addon package or a site policy configuration package. The cookiecutter documentation is a nonstarter for my needs in this case, but buildout has been great. I just set up a venv with all of Plone 6 installed and a buildout to make the binaries, for each of these projects.
Is it dropped from documentation because of a lack of people to support it, or because building code this way is discouraged? My concern is mostly with the latter, because I don't see an alternative that works for me. I know during a lot of Plone 6's development the documentation didn't have cookiecutter at all and put a bit more reliance on the user to configure the frontend and backend. I can appreciate wanting to have a user experience that skips some of that with cookiecutter but I would still like to have the documentation help me make alternative choices.
2 Likes
This is a good question.
I should emphasize that the cookiecutter only creates a project to facilitate its ongoing management. Management of a project created with the cookiecutter is primarily done with GNU Make and the utilities it invokes. There is also a container-based method.
May I ask why the cookiecutter is a non-starter for your situation?
As you probably know, but others reading this might not, Plone documentation is created from 100% unpaid volunteer labor. Plone is a "do-acracy", where if you want something done that others don't want to do, you have to do it yourself.
With that as background, we discussed this within the Documentation Team and asked the question, "Is there anyone who wants to document buildout as another installation and maintenance method?" The resounding response was silence 
.
I believe more experienced developers than I may be able to add to this discussion. One technical issue with pip, and therefore in buildout, is the management of package versions. Details of that issue may be read in the section Manage Plone backend packages with mxdev. @jensens can you elaborate further?
With cookiecutter and containers as the actively used and supported methods to install and maintain Plone, the buildout method has become neglected. If someone is willing to maintain documentation of the buildout method, while resolving the technical issue of package management, then it may be supported. Right now, no one has volunteered. Will that be you?
In the meanwhile, the Plone 5.2 documentation of a minimal buildout is not going away. We also have much higher priorities with Plone 6 Documentation.
- Release Plone 6 docs
- Install Docs (this is a focused subset of the foregoing project)
I also heard it would give me cleaner, whiter teeth and fresher breath.
Times change. The one-click installer was great for getting started, but then how do I maintain it?
I know it is difficult, but it also means we get 'no new users )In 'my early days of Plone', there were lots of sites made by people without technical skills (including myself at that time)).
Stop by Discord, Volto's repo, or the GSoC crowd. We get several new users—and even better, contributors—every day.
The last time I checked in here about a month ago, there were just under 2000 users. Today, 2055.
What do you mean with "maintain it"? Maintaining the installer? Or Maintaining the resulting installation?
IMHO the easy and quality of an installation is not determined by those who successfully use it but by how many users do have problems with it.
Most of us have no problems installing Plone in different systems and configurations. We read and understand the code in the Makefiles and Docker scripts and are able to adapt it to our actual requirements.
But if Plone has to reach a wider audience we should accept that lots of users without full stack skills also could be attracted by Plone with a simpler (kind of "one click") installation.
Take for instance the case of installing Plone 6 Classic UI. Is it really wise to overwhelm new users who simply want to install Plone locally an test it with requirements like docker, nodejs, nvm, yeoman, make etc.? Where is a clear (tl;dr) path in the documentation for such an installation?
This.
Can you document a Plone 6 Classic UI simple installation process? Please pick an open issue from the Install Docs GitHub project. I'd like to review the PR.
BTW, compared to WordPress, our cookiecutter and Docker processes are vastly more simple.
Web applications are not simple. I think we would be performing a disservice to users by claiming it is easy or simple. It's not. That's why there are commercial services that take care of the installation and maintenance for the non-technical end user.
Personally, I found 1) Installing with universal installer and 2) Editing buildout.cfg and run bin/buildout was very easy to understand ' in my early days of Plone'. That approach still works 'good enough' for 'that audience', I think.
I am not sure if maintaining other systems (like Wordpress) is easier (with an endless update cycle of add-ons, php and wordpress itself)
- for Debian 11: https://gist.github.com/me-kell/e1dba01840816fa1930676b77c26a785
- for Windows 10: https://gist.github.com/me-kell/9fb4a8c97e875c8f529a0bbce0699ee9
Please keep in mind that those scripts are very opinionated.
Most people install wordpress where they bought the domain, that is 'one click'.
That said: I agree with the 'not simple part', but I think many would like to test Plone 'locally' (not on the demo sites), since they could keep the data / content and test/try a little).
Off topic: Since I also make Wordpress sites, I am really surprised (all the time) when I see things that are 'basic, default stuff' in Plone, that does not 'work in Wordpress'. Plone has a lot of strengths, maybe they are not 'shared properly' (?)
(on the front page plone org, the selling points are: Fast, secure and Open/free. Sounds good, but it does not really say 'where Plone is better'. For example 'folder based structure' is something I mention when I try to 'sell Plone')
In Plone's WebSite under Getting Started > Download we find a Page with Title Installing Plone. The advertisement reads "Easy as 1-2-3"
Back to the original question "What is the best way to install Plone".
I think that this question cannot be answered without specifying what do we mean or intend to do with an installation.
There are many different cases that cannot be subsumed under the same. On the one side we have very complex installations with apache or nginx, load balancers etc. On the other side we have very simple installations where a (e.g. web designer) wants to locally develop some parts of a site. In between there is a wide spectrum of a continuum of growing complexity.
An installation should aim to serve at least two or three points in such a continuum.
A "one click" installer would be obviously be at the simpler end of the continuum. And it will of course not be recommendable for productive configurations at the complex end of the continuum.
The issue of maintenance costs of a resulting installation are very different depending on what we are talking about (simple or complex installation in the above mentioned sense).
No, that is a commercial service. A one-click installer installs it on the user's local machine.