At this point, if I was advising someone building sites for small businesses and the like, my advice would be:
Can you use a hosted service? Wordpress.net, Shopify, that kind of thing? If you can make that work, that should be your first and only choice. If not... are you really sure that you can't use a hosted service? Okay, then build a site that does static HTML for end users, with a carefully locked-down admin section. On a different domain, if you can.
If you need dynamic features for users (a shopping cart, etc.), again, see if you can integrate a hosted service with your static site. If the reason you can't use a hosted service is because your client is too cheap to pay for it, do not take that client.
Otherwise, if your client absolutely needs bespoke, dynamic features for their end users, and absolutely no hosted service will work for them, they need to invest in a support contract, and you need to tell them up front that they'll have to do that. There are actually contractors out there that do long-term support for other people's apps, if you don't want to be saddled with it yourself.
It's template engine supports two tag types: one that gets run during the publish stage & one that get's run at the request stage.
It can then take an intelligent approach to publishing by having a publish step that renders each page to a static file. It's then trivial to test for the existence of 'run at request' tags and position the generated template accordingly: pure static files get put where a reverse proxy (nginx by preference) can see them, anything with per-request tags gets put in a 'private' directory out of nginx's paths for rendering & delivery by some front-end server.
This has many advantages, including:
- static pages can be served directly by Nginx - the public facing site runs in a separate process that consumes the generated templates - the public app (if needed at all) has no admin-centric code so has a smaller (& separate) attack surface - the publish step can be seen as a form of code generation so you could, in theory, publish a dynamic PHP powered site from this Ruby CMS
I'm also gradually working towards abstracting the template 'filesystem', currently you can render to the disk, redis, memcache or any other key-value store supported by the Moneta gem[1].
For the developer it gives the power of static site generators but provides a simple & usable editing interface for content editors.
But I do think there should be a good separation between html and admin backend. Security is only one reason. There are other very important reasons:
1. waste of resources. the machine that builds the html from the cms is completely idle for 99% of the time.
2. scalability. the html should be served from a storage server like S3 together with a CDN. there should be absolutely no downtime in viewing html as a result of overload.
the ideal system for small websites is a machine that is turned off by default, and when an admin needs to change something it is turned on (even if it takes a whole minute). After the changes are committed, the system creates html and sends to S3. For forms, comments, and dynamic things it's best to use third-party (like facebook comments and a billion forms services), or use a different small machine that captures user input (completely separate from the turned-off admin machine).
Why would that have to be a separate machine? It could easily be the same one.
How so? A separate machine is one more thing that can fail and since it isn't web facing it won't help with availability if the other one fails. And if it is a VM they will both go down if the underlying hardware fails.
E.g. the frontend can be replicated (if needed), S3 can be used, while the backend CMS remains intact. Or the backend CMS can be implemented in a HA setup and the static hosting in the cloud.
Search is an issue for static HTML sites. Swiftype [3] and Algolia [4] look like solid options - has anyone used these in production?
[1] https://github.com/torchbox/wagtail
Compare this NYTimes article:
http://www.nytimes.com/2012/05/15/technology/facebook-needs-...
to this one:
http://www.nytimes.com/2014/10/28/business/virginia-plans-to...
Everything pre-redesign was published in as a static. Back-publishing 1,000's of articles is impractical and risky (for other reasons).
Would be curious as to why.
Also, while the pages clearly have different designs, it isn't immediately clear which is "better" (or that this betterness is due to its being dynamic versus static).
Sure, static export plug-ins do exist in plenty, but I don't think that core functionality like this should be implemented as a plug-in.
First, if it isn't enabled by default, most people won't bother to enable it. Second, who knows how long and how well the plug-in will be maintained? Third, if static export is an architectural afterthought, it will probably break unusual features and workflows.
> a) it can lead to considerable complexity as an update to an atom of content may need to propagate to many parts of a site
We shouldn't let perfect be the enemy of good. Even if some blog article from months ago won't get the updated shiny new sidebar, what's the matter? The New York Times still have content from the web stone age on their server [1] - it doesn't use the latest template, but isn't it more important that this content is still available? It probably wouldn't be had they used a dynamic CMS back in 2001.
> b) the whole web is moving towards contextual dynamic delivery.
I'm not talking about amazon.com. They can probably afford proper maintenance of their fully dynamic site.
[1] http://www.nytimes.com/learning/general/onthisday/big/1014.h...
But not using server side dynamism like Drupal provides. It is moving towards sites serving up static files consisting mostly of Javascript that then call data services, so called single page sites.
SQL injection attacks are just as possible against those kinds of apps, although slightly tougher to configure because you need to read client-side JS to find the service URLs, tokens, etc.
Drupal is used to power client-side JS-based sites. The current Tonight Show website is a recent example.
There is an implementation out there that I think is the most intriguing, integrating Drupal with Jekyll: http://www.gizra.com/content/dekyll-drupal-on-jekyll/
There is at least one open source WCMS that uses static export at its core: http://openengine.de/ (site is in German, but docs are in English) - unfortunately, it has been unmaintained since 2010. It will export .htm or .php files depending on whether you need pre-processing on every request.
As far as I know, though, Publicis still use a closed source version of openEngine (openEngine Corporate ASP) for two clients: http://www.siemens.com/ (pretty big fish) and http://www.man-finance.de/ (search for "openEngine" in the source code).
So this is definitely viable as a core approach.
The problem is a lot of stuff is still dynamic even though it doesn't look like it.
Probably the best approach these days for a parish choir website is a hosted solution like Wordpress.com, Squarespace, Google Sites, or if we're talking Drupal specifically, Acquia Cloud Site Factory, or Pantheon.
1) reordering posts -- posts are displayed in _alphabetical_ order, as are directories, so the suggested nomenclature is a numerical prefix before every file name. So if I wanted to rearrange things, I had to decide whether not a linear shift was worth the benefits of file name readability.
2) the order of posts is reversed! I want new blog posts to show up at the top of my feed, but Stacey puts higher numbers underneath. I didn't want to count backwards, so I looked around and found a php hack for reversing this.
This might be fun if you're hankering for some DIY PHP, but I wouldn't recommend it otherwise.
https://github.com/kolber/stacey/wiki/Templating-Language#fi...
It's not like you're forcing them to build jekyll.
After all, most sites out there probably don't need server-side dynamic preprocessing for every request. The CMS directory could be locked using HTTP auth (implemented by the HTTP server); this way, not every little CMS bug would allow the world to compromise the whole server.
Do we really expect every parish choir with a web site to hire a CMS specialist who installs updates within hours of the release and fixes all compatibility quirks that occur with new major releases? This is an unworldly approach that bestows thousands of zombie machines on us.
And what happens if the CMS for some old site stops being maintained? A responsible admin would shut the site down, resulting in a loss of potentially valuable information. This issue would be solved by using static HTML export, too.
Are there any well-maintained open-source CMS out there where static HTML export is an integral part of the architecture, ideally with good usability and written in PHP (not that I like the language, but that's what is available everywhere)? (I'm not talking about command line static site generators without a user-friendly backend - those are only an option for techies.)