Right now there are 3 CMS systems which are being debated, and there may be another candidate or two which we haven't noticed. To help expedite the CMS selection, lets start getting the CMSs into one place. We also need to realise a lot of us have preconceptions about CMSs we prefer/dislike/don't know about, so we should set ourselves up to make fact-oriented decisions.

Here's a soft list of requirements I personally think we need in the CMS; it's slightly modified from my message in the mailing list, and more points have been added.

• Allow us to program pages and templates with standard PHP.
• Easily extend the system with custom types, and allow type association. E.g. add a project type and let that project type have multiple sub-types.
• Good administrative options with permissions; we should be able to easily grant people permission to manage specific projects.
• Good multi-language support, and an easy method for i18n teams to submit translations. Bonus points for using the POT translation format.
• Good security track-record and patch history. Project must be active.
• Easy paths to integrate other systems; specifically KIdentity should replace any 'native' logic system.
• Support reasonably good coding conventions.
• Native HTML caching mechanism or plugin.
• Able to run multiple sites from one installation

Below is a template for anyone proposing a CMS; to help everyone make informed decisions please provide links to each point so others can read the documentation, and assume you're the only individual who knows anything about the system. Please be honest and forthcoming about cons in the system being recommended. Also mention any experience you have with applicable systems, and also if you're willing to provide time and energy helping us develop with the system if it is chosen. Please treat plugin-oriented solutions as "PARTIAL" in the list below.


--- Quote & Copy ---

CMS Name

• PHP templates: YES|NO|PARTIAL, [url=#]Documentation Link[/url]
• Custom nodes: YES|NO|PARTIAL, [url=#]Documentation Link[/url]
• Sub-nodes: YES|NO|PARTIAL, [url=#]Documentation Link[/url]
• Per-Node Permissions: YES|NO|PARTIAL, [url=#]Documentation Link[/url]
• Good multi-language support: YES|NO|PARTIAL, [url=#]Documentation Link[/url]
• Uses POT format: YES|NO|PARTIAL, [url=#]Documentation Link[/url]
• Good security/Security Documentation: YES|NO|PARTIAL, [url=#]Documentation Link[/url]
• KIdentity/Replace auth system: YES|NO|PARTIAL, [url=#]Documentation Link[/url]
• Supports good coding conventions: YES|NO|PARTIAL, [url=#]Documentation Link[/url]
• HTML Caching: YES|NO|PARTIAL, [url=#]Documentation Link[/url]
• Multi-Site: YES|NO|PARTIAL, [url=#]Documentation Link[/url]

PROS:

CONS:

Sites using CMS:

--- End Quote & Copy ---

Wordpress

• PHP templates: YES, Documentation Link
• Custom nodes: YES, Documentation Link
• Sub-nodes: YES, Documentation Link
• Per-Node Permissions: PARTIAL, Documentation Link
• Good multi-language support: NO, Documentation Link
• Uses POT format: YES, Documentation Link
• Good security/Security Documentation: YES, Documentation Link
• KIdentity/Replace auth system: PARTIAL, Documentation Link
• Supports good coding conventions: PARTIAL, Documentation Link
• HTML Caching: PARTIAL, Documentation Link
• Multi-Site: YES, Documentation Link

PROS:
Strong community and plugin repository, good version tracking, good theming. Has experience with bad security and has leanred from mistakes. Powers a huge number of websites without issues.

CONS:
Blog-oriented design, requires more work to convert to project-oriented design. Will require some 'hacks' to implement things like Kidentity support. Some common plugin combinations can significantly degrade performance. Provides no compelling multi-lingual solutions.

Sites using CMS:
See https://wordpress.org/showcase/

Actually, wordpress does support POT files on a theme base. Or was the "NO" a typo?

EDIT:
Of course here is a link https://codex.wordpress.org/User:Skippy ... _POT_Files

neverendingo wrote:Actually, wordpress does support POT files on a theme base. Or was the "NO" a typo?

EDIT:
Of course here is a link https://codex.wordpress.org/User:Skippy ... _POT_Files

Thank you! Updated.

ProcessWire

• PHP templates: YES, Documentation Link
• Custom nodes: YES, Wikipedia Link
• Sub-nodes: YES, Documentation Link
• Per-Node Permissions: YES, Documentation Link
• Good multi-language support: YES, Documentation Link
• Uses POT format: NO, uses gettext-like system
• Good security/Security Documentation: YES, Documentation Link
• KIdentity/Replace auth system: PARTIAL, Link to module that can be used as starting point
• Supports good coding conventions: PARTIAL, Blog post about namespaces support coming in next version
• HTML Caching: YES, Link to the most powerful free module (NOTE: caching of templates is a core feature)
• Multi-Site: YES, Documentation Link

PROS:
An experienced PHP dev will grok the system quite fast - the architecture is the only thing that needs digesting.
The default philosophy of "Everything is a page" works for most content types, but other db table structures can be used, if needed.
You are free to choose your templating system and separation of concerns. Example template engine integrations: Latte, Twig, Smarty.
Default admin themes are very simple to use - many devs report their clients learned the interface by themselves, before they managed to teach them. Creation of new admin themes is straightforward.
No security vulnerabilities have been discovered.
Small community, but very knowledgeable and responsive in the forums. Forum already contains answers to most questions.
You are completely free to modify the content types and field types and create your own.
Easy to use PW's API with other PHP apps (bootstrapping).
Powerful selectors to fetch and use content.

CONS:
Dev community contributing to the core is still small, so low bus factor.
Centered around a single-person LLC and not a foundation/non-profit. This is reflected in the lack of self-organization: there is no i18n, marketing or infra team.
Default content database structure is not efficient for complex queries like ecommerce-related reports (anecdotal, no benchmark available).
Namespaces & composer support not yet in, coming late 2015.

Sites using CMS:
See https://processwire.com/about/sites/

I am a sporadic PHP dev, so I am always fumbling and stumbling and would not be of much help in building the site backend. I can help find solutions & strategies for building things, however, as the PW forums are full of them. I have a good picture of the module ecosystem, so I can pull a lot of stuff straight from my memory. I do have experience of setting up & tweaking two dozen different modules.
I am perhaps more useful on the frontend side.
My main idea was to act as a recruiter & orienter of new contributors and that is what I will do regardless of the CMS chosen. I've recruited contributors to FOSS projects since 2013.

Just a quick sidenote:

It is not necessarily a bad thing if the dev team of a certain CMS is not that big or slow in response. That usually changes if a huge project like KDE decides to use its system. I have seen that in the past with all the other systems we currently are using, be it phpbb, mediawiki, former redmine etc. Suddenly devs are very interested and becoming very responsive and helpful

beluga wrote:*snip!*

Nicely done!

I'm liking what I'm reading as well; I'll thoroughly read your links tonight, but skimming has already proven quite helpful.

Now, is anyone reading this experienced in Drupal able to add an entry? And are there other frameworks we should be looking into?

Sorry Kver,

something just struck me what i should have mentioned earlier as possible requirement but forgot about it... Multisite installations.

Right now those sites using the capacity library (it is not a framework, don't be fooled ) use it from a central point, so only one capacity codebase needed. It might be a nice extra point if the chosen system is capable of running multiple sites from one codebase.

Wordpress is (http://codex.wordpress.org/Create_A_Network), and so seems to be processwire (https://processwire.com/api/modules/multi-site-support/)

neverendingo wrote:Sorry Kver,

something just struck me what i should have mentioned earlier as possible requirement but forgot about it... Multisite installations.

Right now those sites using the capacity library (it is not a framework, don't be fooled ) use it from a central point, so only one capacity codebase needed. It might be a nice extra point if the chosen system is capable of running multiple sites from one codebase.

Wordpress is (http://codex.wordpress.org/Create_A_Network), and so seems to be processwire (https://processwire.com/api/modules/multi-site-support/)

Oh yes, very good point. I'll edit my posts.

Beluga, I hope you don't mind appending that point/link to your excellent post for posterity.

As no one steps in, let me try to summarize drupal. Note: I am no drupal guru by any means, this is the result of some simple research.

Drupal

• PHP templates: YES, Documentation Link for v8, Documentation Link for v6/7
• Custom nodes: YES, Documentation Link
• Sub-nodes: PARTIAL, Documentation Link (partial because it is a non-core module)
• Per-Node Permissions: YES, Documentation Link
• Good multi-language support: YES, Documentation Link
• Uses POT format: YES, Documentation Link
• Good security/Security Documentation: YES, Documentation Link (there are a ton more)
• KIdentity/Replace auth system: YES, Documentation Link
• Supports good coding conventions: YES, Documentation Link
• HTML Caching: YES, Documentation Link
• Multi-Site: YES, Documentation Link

PROS:
Huge community, huge documentation, KDE already uses it for websites. As drupal has more of an application framework than a CMS you can basically do anything with it.

CONS:
You can easily get lost in where you do what. Example: you write a template in php files, and then you notice that something does not work right. Reason? Someone else set up bits of HTML in the backend, which is possible thanks to Views. So you have basically 2 places for HTML/php markup. The template files and the database. (this is a personal con btw ).

Sites using CMS:
http://dot.kde.org


Feel free to give me hints on what else to add

Kver wrote:Beluga, I hope you don't mind appending that point/link to your excellent post for posterity.

Added multi-site. Btw., more multi-goodness coming in the next version (support for multiple instances of PW from the same request).

Also, after asking for a review from a PW guru, I appended three more relevant "Pros" to the list.

Very interesting ideas and useful comparison. I would like to thank beluga who brought Proceswire to my attention, it really seems a CMS to keep an eye for. I think however that drupal is the best tool for this project . I give my reasons below, please forgive me for not follow convention set above but neverendingo provides a fair review of drupal in respect with the other suggestions. My views are more of a hands on review of features rather than a comparative list.

Drupal is not as opinionated as wordpress is and is more of a CMS than django can ever be. Essentially it offers strong back office, editing and workflow capabilities without being narrowly defined for a particular use case as wordpress. It is enterprise oriented and comes with a dedicated security team (https://www.drupal.org/security-team) that has a very good track record by responding and providing fixes quickly.

A big advantage is that it has many third party modules that extend functionality and a very active community behind those modules. There are modules for oauth that we need in this project, modules like organic groups that support sub-communities, support for commerce functions that can handle donations and lots of other cool things.

Perhaps, though, the best function of drupal, one that makes it a serious contender for large projects with lots of functionality and content, is the wealth of devops tools that comes with. Modules like features, master and strongarm make it easy to develop on your local machine and deploy your changes programmatically. Drush (which is named from drupal shell) helps automated tasks and create deployment scripts that foster modern devops and continuous integration practises. Developing with drupal has the same advantages of using a framework like laravel or rails without the need to write a backend/cms system which comes out of the box. Modules like migrations can help create a content staging framework where content can be pushed to production much like code changes are pushed from a repository.

There is a lot of speculation about how easy or difficult is to theme drupal and create beautiful outputs with it. It goes without saying that most of the criticism is fair and the community has taken steps to remedy it. However taking a look at drupal showcase (https://www.drupal.org/case-studies) one can find beautiful websites of very diverse organisations, with lots of content and different needs. A vote for confidence on the versatility of drupal. Having said that a newcomer on the community will need to take some time to get used to all the drupalisms. Drupal 7 (D7 - latest stable) is a mature framework with a lot of third party modules. Drupal 8 (D8) is just around the corner heavily developed at the moment gearing towards to a Release Candidate some time in September. It is nice to see that D8 is addressing a lot of the shortcomings of D7 and many initiatives (like the PIE) make it easier for developers to start developing for it.

Drupal is a big community and moving KDE to drupal is going to be a huge thing for both communities. Both communities can benefit from the closer encounter of each other. I think there are expertise we can draw from the drupal community and expertise to give back to them.

BTW I am a drupal dev and scrum master working with drupal many years and I would be very happy to contribute to this project, help use drupal to its full extend and support other team members on drupal best practises / idiosyncrasies.

thanks tassos for jumping in, and good points.

One thing i also want to add, during my time working on the neverland builder i had the opportunity to work with theming quite some of the big players, be it drupal, wordpress, mediawiki and also this phpbb.
And basically it boils down to habits, not technical limits. Each of those systems provide a fair amount of theming options, one maybe slightly harder than the other, and one needs maybe a bit more code than the other (phpbb is the top scorer when it comes to the amount of needed files ). But IMO theme writing is the least thing to worry about. This counts for both drupal and wordpress, no experience in Processwire yet, though seconded, it looks very interesting.

ProcessWire lead developer defending Drupal

neverendingo wrote:thanks tassos for jumping in, and good points.

One thing i also want to add, during my time working on the neverland builder i had the opportunity to work with theming quite some of the big players, be it drupal, wordpress, mediawiki and also this phpbb.
And basically it boils down to habits, not technical limits. Each of those systems provide a fair amount of theming options, one maybe slightly harder than the other, and one needs maybe a bit more code than the other (phpbb is the top scorer when it comes to the amount of needed files ). But IMO theme writing is the least thing to worry about. This counts for both drupal and wordpress, no experience in Processwire yet, though seconded, it looks very interesting.

I've found that you can make anything look like anything if you put your head into it; the possibilities more come down to what you can *efficiently* present. Generally this is where Wordpress loses out because they have their ridiculous loop thing. If Drupal and Processwire take a more generalist approach it sounds like those are our two contenders.

No matter what system we go with, I imagine we'll be building on the 'next' versions, being Drupal 8 or ProcessWire 3.

I also like the fact that Drupal has a very well defined security process; no system is perfectly secure, and the idea that they have a plan down in case of emergency is very appealing. It's also interesting that the ProcessWire guys have mentioned Drupal as being better for large community projects.

That being said, one thing that caught my eye in a serious way was the ease which ProcessWire can be arbitrarily injected into another PHP application. That's a very high-value target considering the nature of the CMS we need to use; we need this system to serve as glue and go-between for other systems, like phpBB, Phabricator, and others. Even though it's not considered 'best practice', it would be very interesting to build extensions for non-ProcessWire systems which directly pull from PW.

Comparing the two, are there any other significant differences catching anyone's eye? Currently my vote is leaning towards Drupal, if for no other reason than it already having KDE.org-centric requirements met, though as a glue system ProcessWire has my attention. I can tip either way easily.