CMS Search Update: The Requirements
865 words, ~ 5 min reading time
Note: This was initially published on Scribbles, my previous “micro blog”. I discontinued it and moved the contents into this blog on 2023-12-05.
Back when I started searching for a content management system for my photography website a few weeks ago I first wrote a list of requirements that should be fulfilled. Categorised as “Nice to have”, “Important”, and “Deal Breaker”.
Using four deal breakers as basic criteria I culled through a total of 40 relevant finds and created a longlist including 18 different systems.
After being occupied during the last weeks with other tasks I got back to the “hunt” at the end of last week and wrote myself a more detailed requirements list. To not bore you to death I summarize each one as short as possible.
Feasible Theming (Important)
With a relatively low effort it should be possible to create my theme or customize an existing one to fit my needs (I like to design my websites myself, more often than not entirely from scratch (yes, Scribbles is an exception)). The templating language should either be already known to me or very easy to learn and easy to apply to a previously created “raw” HTML design. Adjustments (in the best case: only a few) should only be necessary for major upgrades and a higher initial effort is prepared to constant effort to keep the template working.
Self-hosted (Deal Breaker)
Well… Of course, this is a deal breaker. And although it won’t, it should be even possible to run the software on the cheapest VPS. The initial installation should not take more than an hour.
Or – to be more precise – editable on mobile. Basic changes like publishing new pictures or writing/updating text should be possible on a smartphone from everywhere. Spoiler: Hard to believe, but some quite new system failed here…
Open-Source / No VC Funding / Community-Driven (Nice to have)
To make it short: A VC-funded product is an unreliable product IMO. And I want to choose a system which runs without major issues for at least five years. Also: community-driven does not necessarily exclude projects where the community mostly consists of companies.
All three together would be perfect, of course. However, I would choose a proprietary project of a reputable company over an open-source product backed by VC funding.
Potentially usable for other sites (Nice to have)
The CMS should not be so specific to my use case that I cannot use it anywhere else. It would be nice to run all my pages using the same software and potentially even the same theme (or at least the same theme basis).
Shop System (Important)
It could be possible that I may offer some digital assets for purchase at some point in the future. Nothing is planned as of yet but I’m quite sure that this could happen at some point. The system should therefore be capable of handling a shop of digital assets (or provide a plugin for doing so).
Blog (Deal Breaker)
Although the primary goal of the page is to have a portfolio I also would like to start a photography blog (and potentially write an article a bit more often than on my main blog :D). Of course, a blog isn’t a blog if it doesn’t have a RSS or Atom feed. Oh, and why not choose something that has a (built-in or plugin-based) newsletter functionality?
Digital Asset Manager (Deal Breaker)
OK, less slang: a module (or whatever you may call it) to upload and manage upload files. It must be possible to sort them into folders (a folder hierarchy would be preferred) and it would be nice if I could tag uploaded pictures.
Additionally, I would like to see in the asset information on which pages it is currently linked. Spoiler: Not many solutions have this. And I don’t get why. The asset has most likely a database entry and the page where it is used will reference it in its DB entry. So why not write a little query and show me where the asset I’m thinking of deleting is currently used?
Actively Developed (Deal Breaker)
This is very difficult to define. I’m not one of these people who say “What? No commit today???” or “The latest release is older than a week?” followed by “This must be a dead project”.
In most cases, it was quite clear that the project is actively developed. Recent activity in the source code repository, regular releases and in some cases even a clear release schedule. Nevertheless, there were a few cases that were not so clear and during the analysis of those CMS, I spent a considerable amount of time checking this. Those included (but were not limited to): response activity on issues, forum and chat activity, blog activity, blog announcements about upcoming releases (that never happened), in case of company-owned products even a check of the company’s website if they still promote or use the product themselves.
OK. Sorry… This got WAY longer than I would like to have…
The CMS on the long list are also already analysed and I post the results as soon as possible (meaning most likely this evening).