Attention CMS Vendors: The Web Root is Sacred
I’ve written here before about systems that are ridiculously hard to version control. You know, systems that spew their code all over the Web root so you can hardly tell what’s yours and what’s there’s. These systems need to die in a fire.
Well, there are two other things that need to come out of the Web root.
The admin interface to your CMS
Any content files the user uploads.
Do not put these in the Web root! The Web root needs to stay clean — anti-septic, even. It should be perfectly, succinctly version-controllable. What’s on the file system in the Web root should just be a temporary representation of what’s in source control, and should be utterly disposable in that respect.
The unwillingness of some systems to do this drives me up the wall. Here’s why.
The Admin Interface: Your admin interface is yours, not mine. In a perfect world, I will not modify it. If I do have to modify it, you have a plugin architecture, right? So I don’t have to mess with your code right? You do? Awesome. The admin interface is hopefully a black box, and any customizations are in a different place.
Uploaded Content Files: When I upload “furry-little-kitten.jpg” to illustrate my article on kitties, this file should not be confused with a executable file, like a template or class file. Content files are versioned and managed by the CMS. Code files are versioned by my source code management tool. Never the two shall meet.
Now, when you violate these rules, your CMS doesn’t make me happy. We work with a CMS that violates these rules, and here’s why it sucks –
This CMS has at least three directories full of content files in the Web root. Additionally, there’s an admin directory in the root that contains 11,672 files, totally 342MB. Version controlling this thing is a nightmare. You have to manually exclude all of their files, split among a dozen different directories.
You can’t version control the entire thing, because (1) the admin interface is just too big and slows deployments way down, and (2) you start getting uploaded content files mixed with source files, and Subversion keeps trying to commit stuff uploaded by editors.
Additionally, Visual Studio does not care for their admin interface. Any attempt to debug this app is greeted with “Validating Web site…” as it churns through almost 12,000 files. I once waited a full 10 minutes before the debugger started.
Subversion has issues with the amount of files too. Commits take way, way longer that they should because it’s looking through the admin interface trying to see if there’s anything you haven’t ignored that it should be added to the repository.
It’s so frustrating, and so counterproductive. And it doesn’t have to be this way.
Episerver does this right. The two offending sets of files are not in the Web root – they’re both mapped via virtual paths. The admin interface is actually out in Program Files, and the uploaded content files are somewhere else entirely. (In fact, the content files can be anywhere, which is handy because that can be deployed to a Distributed File System (DFS) root, that let’s us sync these files between servers in a farm.)
This allows you to make your Web root disposable, which is really handy. I can go to any production Episerver install, delete the entire Web root, re-check it out from Subversion, and we’re back in business. If something gets screwed up, I can revert to a prior version without worry of Subversion getting confused by some content file. Everything in the Web root is under source control.
It seems like a little thing, but it makes setting up, maintaining, and syncing environments so much easier. Remove that obstacle, and developers can concentrate on more important stuff…like code.