Hi Bertrand, While I do agree that Apache's CMS is more convenient when it comes to editing content due to the fact that it only requires a web browser, its templating system combined with the fact that new views have to use Perl made it unattractive. From all the views available in our current site project the only one that's barely usable is the 'single_narrative' one. Furthermore, the view - page association is done using regexes in yet another file - path.pm.
Jekyll was designed with simplicity in mind. It only took me a couple of hours to get all the setup right and to create the two available layouts (default / news) and the templates from _includes without any prior proper exposure to it. Indeed, people who want to contribute to the website have to install VirtualBox and Vagrant, but it's only a matter of a few clicks here and there. The disadvantages of having to install some new tools are less than the advantages of having easily editable templates, layouts and content. Jekyll still uses Markdown for its content and each post / page file can also contain a short YAML header for configuration. With the current setup it's easier to implement SEO, not to mention that we have the ability to customise the website however we see fit without having to learn a new programming language (for the bunch that's not familiar with Perl). The site definitely needs more work but I'm sure that the barrier of customising it has been lowered, even with the addition of VirtualBox and Vagrant. Just my $0.02, Radu On Tue, Aug 26, 2014 at 10:00 AM, Bertrand Delacretaz < [email protected]> wrote: > IIUC the usage scenario is that people have to install something (your > vagrant box?) to generate the website pages, commit those to svn and > let svnpubsub sync the live site. > > I'll just note that requiring people to install *anything* just to > edit the project's website is likely to lower the number of website > contributions. The beauty of the Apache CMS is that you can just edit > content in svn using any tool, and use https://cms.apache.org/ to > check staged versions and make them live. AFAIK it is possible to > integrate non-Perl build systems into it, but I haven't done that > myself. >
