Just because you use a CMS doesn't mean you have to use it for everything. If you're managing content (blog content?) use a CMS. If you're making PPC pages, host them statically somewhere. If you sell something, use ecommerce software for that part.
If you're making PPC pages, host them statically somewhere.
I'd counter recommend this. In my limited experience with it, dynamic PPC landing pages are so effective as to be almost cheating.
BCC's AdWords campaigns are not doing well in 2013 for what I believe are unrelated (and mysterious) reasons, but the ~20 lines of Rails code which make URL #1 and URL #2 roughly the same today but will automatically switch URL #1 to a different creative in a few days have been worth, guesstimating a number here, somewhere north of $20,000. (Bingo cards are a very seasonal market. For the last couple of weeks, most teachers have been in the market for Thanksgiving bingo cards. This will not be true in a few days. The #1 URL, which I use for many of my campaigns, uses some really dead simple heuristics to guess which creative to show people. The heuristic was worth > 10% lift in conversions versus alternatives like "Pick our most popular activity ever", "Pick an activity at random", and "Pick Patrick's guess at what would convert best."
I didn't read the OP as advocating 900 static HTML pages... just using static pages as a first strategy, until reality, not your conjecture, tells you what you need.
You have some code that infers from usage that, for instance, civil rights cards are popular in late January (Martin Luther King Day is on January 20th)? Neat! :-)
Right idea, but I'm not sure it would work for your example. MLK Day for the longest time didn't work correctly. I had a string tied around my finger about that bug for 3 years, can't remember if I squashed it in January or not.
I took this a step further for a recent client with a low budget and used separate social sites to manage the content. I'm certainly not the first to do this, but it's worth mentioning as a viable alternative for a lot of smaller sites.
This particular client produces television advertisements. Videos are pulled in from Vimeo, photos and text updates are pulled from Tumblr. The API data is cached locally with serialized objects to keep it speedy.
Since they already had active accounts on both services, initial content population was minimal. We were even able to use categorization strategies already present on Vimeo to organize content.
It depends on what your needs are. If you need a central web interface with multi-stage workflows, multiple authors, image management, future publication, etc, then Jekyll isn't a CMS. But Jekyll focuses on content, handles markdown, reads metadata, and uses templates. For some people, that might be plenty. A pretty web interface isn't a must-have requirement.
> A pretty web interface isn't a must-have requirement.
According to most definitions of "CMS", it is. With static website generators, editing, versioning, publishing, etc is done externally. They aren't systems which encompass all of this. They just punch some content into your templates and write the result to disk. That's all they do.
The right tool for the right job.