Building “The CMS” – Part 1
Hey!
In the first part of the blogging series about my new project, I'll look over the most important features / modules "The CMS" should have - The name of the CMS haven't been decided yet, and is therefore referenced to as "The CMS".
There's a quite long list of features I want implemented, but most of them is backend stuff which is going to make "The CMS" unique, and some of it can therefore not be shared - or at least not yet!
1. System Logs
Logs... Which developer doesn't love a log to tell them what went wrong where and why, when the client says "The thing is broken, I didn't touch anything - I swear!".. yea right. I guess all people that works with computers have heard that line at least 10 times. System logs will help finding the source to the problem either for you as a developer or for the client if he's a bit techie. A fully featured system log monitor to view different levels of errors or messages is just a must - at least for me!
2. Modules
First of all, all modules needs to be able to turned on / off. I want my clients to be able to download modules from a website and easily install them, either by dropping the files into the modules folder or by interface in the control panel haven't quite decided on that yet
2.1 Blog
Every CMS should have a blog. It's just mandatory, not much to talk about here. I'm thinking something like Wordpress with comments for each blog entry with the ability to comment on comment. Depth can be discussed though.
2.2 Forum
I've wanted to make a forum for a long time, but it's going to have a low priority because my current client isn't in need of one. I think I'll get back to this later when it's relevant.
2.3 News
News is lovely. When having a website, you might want to update the users of the site with news about your company or just the site in general. I'm thinking RSS feeds (ATOM, RSS2), email to suibscribers, and a dedicated page for news. User should be able to choose which or all via CP options.
2.4 Gallery
Gallery should support unlimited categories, unlimited nested categories (who the heck needs that, but it should be easy to do so whatever), image into multiple categories and image & category descriptions. The use of effects (defined in gallery layouts?) when browing categories / showing images in large format.
2.5 Articles
Instead of old static HTML, this will be used. Almost all HTML tags should be allowed - pretty much up to the user how these pages should look besides the layouts that's being defined somewhere else in the CP.
2.6 Widgets
Create widget areas to put data from other modules in them. I'm thinking that each module has output functions that represent different widgets. Like the forum could have "newest topics", "latest replies", "newest members" - all which are different widgets and can be placed different places around the site. Instead of having to edit files and hardcode {widget.run('test')} - like I THINK I saw PyroCMS use - I think some clever widget hooking could be put in place, so that you can choose from a list of available places when creating the widget.
2.7 Profile
A module for profile information. This could be post count for forums, blog / news posts, account balance for eShop ect. Might just work as a user control panel for changing email, password ect.
2.8 Memberlist
A list of members on the site. That be feed / mail subscribers, eShop customers, forum users ect.
2.9 Private messaging
When having a decent amount of users, private messaging could come in handy right? This could be a forum-only feature instead of a standalone module - who knows...
2.10 eShop
This could be a seller. I've already been contacted by a friend whose friend might be interested in an eShop, and it's a pretty handy module - could even use it for the company I'm doing with THP44.
3. System Restore
Everyone is able to fuck up once in a while. Having system restore points could be handy when some critical unrecoverable error occurs - god forbid it ever happens. Udi Mosayev has an interesting approach to this. He's using a database table to record every update statement used on another table, holding the old and new field value with the field and table name so he can revert it if needed. This could be a good idea if you need an option to revert the last process e.g. when updating settings in the CP. An issue with this could be when mass updating settings, which could possibly create hundreds of rows within seconds. A cron taking snapshots of stuff like settings every x minute, hour or day could be neater.
A lot is on the drawing board and subject to change. Can't wait till I finish up the E/R diagram and start working on the core 
