I've been mulling an idea for a while now. I've been calling it Cicada.
Instead of Yet Another CMS, or Yet Another Shopping Cart, I was thinking of an application for constructing bespoke sites with shopping carts, or with blogs, or with member logins, or with whatevertakesyourfancy.
Oh, and it also constructs the CMS for the site administrator to manage it.
It would also provide an environment in which the L&F of the site could be assembled - abstract templates that can be filled in with bits&bobs to customise them for a particular site.
Cicada users could write additional modules (both backend functionality and front-end UI) that they can then deploy in the sites they create.
One thing about its operation. While under development, everything runs out of the database. All there is in the development site document tree are the binaries (graphics, etc.) and three files:
A generic Cicada driver script. This is the same for all sites under construction.
A configuration file. The potential complexity suggests XML as the format for this, because it lists all of the modules the site uses, along settings for all of their options, and all of the other thingies that fully describe which Cicada assets are used in the site.
An .htaccess file that inclues a big mod_rewrite chunk for turning human-friendly URIs into URIs that reference the driver script with a nasty great querystring to say exactly which page in which state is to be displayed.
There are two databases. One is the database the site itself is using (user list, article storage, etc.); the other is the Cicada asset database. All of the site's code comes out of the asset database. That's HTML, CSS, Javascript, PHP, the lot. The driver script susses out which assets to pull and which code to eval() based on the querystring it's been given.
Yes, it will be slow, but this is just the development phase - it allows for sweeping changes to all aspects of the site's construction pretty much on-the-fly. Once the site is built, and the client is happy and signed off on it, the Big Friendly "Publish" Button is boinked, and Cicada does a load of bumping and grinding, pulling all the assets that are used out of the database, filling in the templates with site-specific stuff (company logo/homepage link goes here, AUP text goes here...) pulling all the code out and replacing the database lookup/eval steps with an include() (or even inlining the code) ... and then (optionally), as the pièce de résistance, writing all those files and the site's own database to the live server. The mod_rewrite chunk is a lot smaller since in most cases now the page being asked for physically exists instead of being written on the fly by the driver script.
Job done. NEXT!
Needless to say, the configuration file and client-specific assets are retained in case the client wants changes. As the Cicada asset library is updated and resources improved, those improvements can filter out to client sites as and when they're redeployed.
Unlike some similar apps I've seen, a Cicada-published site does not need a Cicada server after it has been deployed; it's a fully self-contained site, so the client isn't locked in to a relationship with the publisher that built the site to keep hosting it (it's nice to have the relationship, but it shouldn't be on the basis of a "leave me and you'll suffer" threat). The client could in theory go to another Cicada-using publisher and get them to do more work, or even to a publisher that doesn't use Cicada, who would have to do changes by hand (such tinkering however voids the manufacturer's warranty.) But that's only in theory. In reality, the publisher may have used any number of in-house modules (one of the points of distinction between one Cicada user and another), and the deployment process, during the course of extracting code, would be inlining and optimising throught the whole show (a trivial example: all those instances of $CONFIGURATION['short_company_name'] have been replaced by "IniTech") as anything that is generic because it varies from client to client is replaced by whatever is specific to this client would make the resulting code somewhat scary for a human to mess with (and even someone else using Cicada would have trouble, since they wouldn't have the configuration file the original publishers have for the client, let alone any in-house assets that were used. If they want them, they'll probably have to pay for them.)
Sounds similar?
