If there’s a bunch of small websites you want to maintain, — who you’re gonna call?
Note
Introduction
For just a few pages, it may be tempting to just write static HTML files. If you just write them once and do not have to apply changes from time to time, you are done.
Applying changes, having recurring elements and design on several pages (aka theming) — with some kind of templating engine we could handle these requirements more comfortably. Static site generators like Pelican help us here. With Pelican, we compose our pages using Jinja templates, and the tool builds the static HTML files for us, which we then can easily publish. Plugins allow us to insert more complex (dynamic) content.
But even with plugins, static site generators are not dynamic enough. One use-case I have to handle is to display on one page a calendar of activities. A second page, called “current activities”, displays the next three activies. And “the next three” are determined by the date when the page is accessed (not built!).
JavaScript making an AJAX call to a webservice to fetch the next three activities may solve this even from static HTML pages.
But now some owner of a site wants to edit content herself. Alright, alright! — I thought. At least now, I will install a CMS.
Alas, all CMSs I evaluated disappointed. Below I give some use-cases to illustrate my points.
Project PySite
Born is PySite, a simple, yet multi-tentant capable server for websites, based on the Pyramid Framework.
Please visit PySite on github to read more about implementation details, the roadmap, and look at/fork the code.
I had been asked about the relationship between PySite and Pelican, whether they are competing products. PySite is not a competing product, at least it is not intended to be. Although both have some overlapping functionality, the primary use-cases are different.
Nontheless I consider both projects related, because I could imagine that people who use Pelican may have also use-cases that PySite tries to solve. I regard and use both more as complementary web-publishing tools.
Use-Cases
One
Ada is an experienced software developer who likes to program in …err, Python. Several people asked her to host and maintain their respective websites, which are really simple and have only a handful pages each.
Ada loves bash, vim, rsync, and therefore she needs a tool that allows her to:
- host different sites (domains) from the same installation
- control every aspect of the site via the filesystem
- all settings and meta data are accessible as a file
- all content is stored in files
- themes (images, CSS, templates) are accessible as files
- build simple sites where everything (styles, scripts and HTML) is in a single file
- build really complex sites, with a nested page hierarchy, complex layout and design
PySite can do this, and in its current state this use-case is solved.
Two
The owners of the sites asked Bethany, a web designer, to create nice themes. Bethany does not have shell access to the server, but needs to access content and themes.
PySite will provide a file manager UI (elFinder) that gives access to all files: content, templates, static assets, meta data. Bethany can build a nested structure by creating subfolders, and she can also rename files and move them around. She may also upload and download files as an archive (zip, tar etc.).
PySite will use Pyramid’s facilities for authentication and authorization.
Three
Cecilia, Bethany’s colleague, wants to work from on the road with her mobile device (herPad), which lacks a decent code editor.
PySite will implement Ace, to allow comfortable code editing from within the browser.
Four
Delilah is owner of one of the sites, and from time to time she likes to change some content, brighten the background color from blue to light blue, correct a spelling mistake etc. HTML, CSS and code editing are Böhmische Dörfer for her.
PySite will implement an in-place WYSIWYG editor like hallo or aloha.
Five
Ada’s boss, Eunice, wants her to choose a tool that meets these criteria:
Be based on a well-known and established framework.
Drupal is established, but exposes just an API, not a framework. SilverStripe meets this criterion perfectly, but fails others. Typo3 Phoenix may also be a good candidate, but it is not yet production ready. Mezzanine, based on Django, is promising.
Make simple things simple.
If my site has only one page, allow me to put styles, scripts, content, HTML into a single file. Do not force me into a certain CMS metaphor, use templates etc.
SilverStripe fails here, because it forces a developer to write a page controller in PHP for each page. And Mezzanine, unfortunately, requires decent knowledge of Django even for a simple site.
Allow complex sites.
All CMSs meet this criterion in one way or another. And all can be extended by plugins.
Allow access to/editing of themes from within the browser.
Afaik, all mentioned CMSs fail this one.