About 2 years ago, I revamped my hub site using Django. This was the first step (I had hoped) toward a unified architecture for all my websites. It didn’t turn out that way, but this project is still simmering on the back burner.
Most content management systems are designed as monoliths with turnkey features. This is a wonderful boon for authors who want to, for example, throw up a blog, as they have a low-overhead solution they can deploy and quickly start publishing with. But it presents problems if you want to customize them (anything outside of the turnkey modules and settings available) because you have to work around the existing features before you can implement your customizations. And it presents problems when managing multiple websites because now you have to manage multiple independent monoliths and often can’t even benefit from automation.
I was hoping that my play with Django would be the beginning of a new relationship that would allow me to address these problems. Unfortunately, I was unhappy with where Django left me (and my hub site has been growing stale since then). In the meantime, I got a new job, which completely dominated my life for the better part of two years. (That is the explanation for my extended absence.) Then I got laid off in a downturn of pandemic proportions—literally.
But my dream of a unified website architecture never died. And I’d like to lay out the business case (as it were) for this solution and the requirements it will need to meet. I’ll go further down the road in a later post and talk about architecture options.
Pain Points
Keeping site software up to date. Popular systems like WordPress have built-in features to update the software automatically or with a single click. This is needed to maintain a secure system. I wouldn’t want someone hacking into my blog and using it to perpetrate a phishing scheme. That would be bad for the victim and bad for me. But updated software can require updated modules, and any custom code (such as my custom theme code) may need to be maintained if there are framework bugs or breaking API changes.
In fact, that happened at one point on this very site, where suddenly I was unable to manage my sidebar widgets when the upgraded WordPress admin UI thought there was no sidebar.
But in general, to update a whole fleet of blogs, I need to pull up Every. Single. Blog. And I need to make sure the core, plugins, and themes are up to date on each. I even have a saved browser session for that, which pulls up each site’s upgrade page in a separate tab. This also tends to overwhelm my host, so I need to take it easy and space out the upgrades. In general, it’s a royal pain in the a–.
Moving content from one site to another. I will often find myself wanting to start a new site and seed it with content from an existing site, or the converse—decommission a neglected site, wrapping its content into a more active site.
Again, that’s how I started this very blog. I had been writing occasionally about software development on my personal blog, which makes sense because it’s part of my life. But that was mixed in with many other different kinds of personal content. I decided I wanted to start a blog dedicated to software development, transfer over all the SD posts from my personal blog, and have the old URLs redirect to the corresponding page on the new site. I did figure out how to do that, but it required migrating all the content over to the new blog (via export and import) and manually enabling redirects from each the old post to the corresponding new URL (using a redirect plugin for WordPress).
I’ve repeated this pattern numerous times, and I currently have a neglected political blog that I’d like to decommission as well as a new religion blog to which I’d like to transfer archival posts from my personal blog. I haven’t gotten around to either of those, because each is a project in its own right.
I’d really like to be able to go to a unified content management UI, select which content I’d like to move, tell the UI where to move it, and have the new content appear under the desired domain with redirects from other domains.
Maintaining shared content. For example, terms of service or my comment moderation policy. I want to be able to post these once, in one central data store, and select where they appear on each site. I’d also like to feature “best of” content on my hub site and engage in other cross-site promotion (e.g., “related articles [on other sites]). Right now, the only way to accomplish anything like this would be—er—very messy and effort-intensive.
Moderating comments. In other words, spam. The Akismet plugin does a lot to ease the burden of spam. And I’ve been moving toward disabling comments on my blogs (although I haven’t on this one). I’m considering alternatives for blogs that I do want to have discussions available for.
But for comments that I do allow, I really would like to be able to manage them in a single place. Right now, it’s like upgrading: I need to go to each site’s comment-management page in turn.
Theming and layout. Existing tools try to make layout easy with GUIs, but to configure and maintain each site, it turns out, requires a lot of time as well as specialized plugins, e.g., tag cloud, PHP in a display block, “related posts” widget, redirect.
All I really want is just to plop in some JSX that says, “Insert a list of related posts here,” or, “Insert a tag cloud of author names weighted by the number of posts authored.” Of course, that requires general-purpose widgets, arbitrary back-end queries, and dependency injection—all of which you can do using React. And I do not need a UI for this, and I would actually prefer to have automated tests and a deployment process for this, rather than doing the layout directly on the production site. #JustSaying
Features and other Requirements
There are a number of requirements I’m looking to meet:
- Reduce maintenance effort when maintaining multiple websites.
- Decouple authentication from presentation.
- Tolerate spikes in traffic.
- Decouple administration from presentation.
- Centralize the administration of content.
- Support a distinct presentation for each website and path.
- Decouple content from presentation (for real, not like WordPress).
- Migrate by steps from the existing architecture.
- Support staging and blue-green deployment.
I’ll go into these in more detail in future posts.
Additionally, there are several non-features that I can identify:
- Installation does not need to be accessible to a layman.
- It does not need to support shared hosting (or even VPS hosting).
- It does not need to operate at enterprise scale. (It’s a personal system.)
- Themes do not need to be configurable. (Themes can be code.)
- It does not need to support third-party plugins.
I also want to support all of the standard features I use on my sites:
- Content served on one or more URLs.
- Blog-style preview lists (e.g., the blog’s main page, monthly archives).
- Content tags.
- Redirects (to move content to a new URL).
- Images and other embedded assets (managing and serving them).
- Image scaling.
- Comments.
- Tag clouds and lists.
- XML sitemaps.
- RSS feeds.
Not all of these need to be supported using built-in code! For example, comments can be embedded using Disqus. Spikes in traffic can be handled via Cloudflare (which would also protect against DDoS attacks).
Next Steps
I’ve already thought quite a bit about how to address these issues. (Sometimes, it seems, I can’t stop thinking about it.) I intend to go into further detail regarding the options I’m considering and their pros and cons in future posts. But for now, I just wanted to get the list of requirements down on paper (as it were).
May all your bars turn from red to green.
Tim
