I have been given a new task from the client which is basically creating a CMS for actors/singers and the like that client will be selling out to them.
It will basically be a package and would work out-of-box pretty much similar to WordPress, you just hand over to whoever buys it but of course this is not going to be a blogging platform. It will allow developers to:
- Add plugins/widgets
- Add templates/themes
I thought the Observer Pattern may be useful but I am not that sure about it. What you guys could suggest to create such flexible/extensible CMS in terms of:
- Ability to add plugins (for example like WordPress)
- Ability to add themes/templates (for example like WordPress)
- Design Pattern
- Any other things
Observer’s fine, but you’re going to have to consider going beyond the basic pattern. The canonical Observer/Subject pattern only sends the Subject object to the Observer, nothing else, not even why it’s being notified.
Initially, the solution might seem like also including the reason for the notification to the Observer, but then you might end up notifying Observers that don’t care about certain notifications. A better solution might be requiring Observers to also ask for a list of notifications they’d like to receive.
But that also presents a problem. In order for the Observers to actually attach themselves to Subjects, they have to be instantiated. Every single time. Even if they’d never be needed. That’s silly.
So, we’ve quickly reached one of the canonical PHP implementations of plugins: “hooks”. Hooks use the same concept as Observer/Subject, but the implementation is different in a very important way: the actual Observers aren’t instantiated in order to Observe Subjects. Instead, Subjects send a notification to some variety of central repository. This repository is configured with a list of all installed and activated plugins (Observers), and contains a list of all of the events that each plugin wants to receive. Each plugin and notified only when the event takes place, often through a static method rather than by creating an instance of the plugin and notifying it.
call_user_func_arrayand a good autoloader makes this incredibly trivial.You can therefore create a simple Interface for all plugins to implement. Methods that you’ll need include but are not limited to:
Depending on how far you take the plugin concept, you could end up with plugins that have user configurable options. You might need to take that into account. Down that road lies madness and configuration systems.
In order to make plugins effective, you’re going to need to place hooks everywhere, and frequently work with end-users to add new hooks where they are needed.
Widgets can easily work in a similar way, as plugins that get called prior to page rendering.
Themes/templates, oh my. You probably have two big options.
This decision will be driven by your end users. Smarty is incredibly limiting, but if you want to make sure that only approved code runs in a template, it might be a viable option. Furthermore, it’s not unsafe to allow editing of Smarty templates right in the application itself.
On the other hand, one of the reason WordPress templates work so well is that they’re pure PHP. They can call any method exposed in the WordPress API, and even do their own interesting logic. If you expect your end users to be technically minded, or at least technically competent, then PHP templates are the way to go. On the other hand, allowing editing of PHP templates within the application can open up a huge potential security hole if a malicious user gets into the admin bits. You probably want to restrict editing to the filesystem.
While this covers HTML creation, you should also take CSS into consideration. Will your end-users be able to manipulate CSS directly? Will they want to? If your default templates include enough semantic classes, they can probably do a great deal of styling with not a lot of effort, if they know what they’re doing. On the other hand, your end-users might not know what CSS is, so they might want, oh, say, color pickers and pre-built color schemes, and a color scheme chooser, and other such annoying things to build. It’s probably best to think about those horrors now.
Miscellaneous things.
No CMS would be complete without the concept of drafts and publish states. I don’t have any advice for you here, other than code this first. If your customer or the end-users want any sort of historical archiving, managerial approval mechanism, or anything else that makes draft/published anything but a simple state field, you need to know very soon. (I’ve been bitten horribly by this one. We’d designed the entire system around a simple published/not-published model, and got about 9/10ths through spec building and related prototype code when we realized it wouldn’t work and we’d have to do something far, far more complex to actually meet customer requirements. Rebuilding the rough plan was the single largest time-sink we encountered so far.)
Will you use an ORM? If not, be sure to use a proper database interface library. PDO, or maybe something from PEAR, or maybe Zend_Db. You’ll inevitably have a customer that will insist that the code runs on Oracle or MSSQL. Or SQLite. It’ll be nice to tell them it can be done (with some effort). Plugin authors will thank you for the sanity as well. Don’t roll your own.
(Then again, with your rep level, I expect that you’re already familiar with pretty much everything I’ve said. Ah, the things I do to distract myself while thinking about my own set of coding problems…)