Distilling it into it's most basic functionality, the vB CMS allows content authors to create pages of content; categorize those pages into lists; and place widgets of functionality onto those pages to make them more interesting. Although the first release will cover these principals, the CMS is being designed to be far more powerful, which will become more apparent in future development blogs. Content Types One of the main goals with the CMS was to allow the creation of 'non static' pages. This could be achieved in a number of ways. From the outset, the simplest way would be to add the ability to create articles that can be listed and managed, in the style of some of the existing content in vBulletin. However, we would eventually need to add other types of content. As an example, it's easy to compare social group discussions with threads and wonder why they aren't pretty much the same thing. Unfortunately the code in vB3 for these (and other types of content) doesn't lend itself well to reuse. Because of this, the code for things such as inline moderation, read marking and subscriptions of these two similar features is currently duplicated and modified to suit each as if they were almost entirely separate. As vB3 has grown in functionality, the benefit of consolidating these separated features has grown too. The CMS is designed to be content agnostic, allowing all manner of content types in a way that allows us to create and implement features that can apply to all content equally; without the need to duplicate the effort for each supported type of content. For example, if I wanted to create a user rating feature; it should be available for all content regardless of whether it is an article, gallery image or video. Conversely, it should also be much easier to create a new type of content and allow it to be used for pages, while automatically benefiting from all of the existing content orientated features without having to write lots of specific code just for the new type. Not only will the CMS allow the vBulletin developers to quickly create new content types for your pages, it should also be very exciting for mod developers to come up with their own content types and widgets. Widgets Along with the main content, the vB CMS also allows you to place widgets on the pages. Widgets are used to express non page content and allow you to liven up pages with related content, provide further navigation options to the user, to highlight other site content, or do pretty much whatever widget developers can think of. Widgets are a very simple concept and are fairly standard to content management systems, but they should not be underestimated in terms of the features that they can provide. What's Working Now In the future I'll be talking about some of the more technical aspects of the CMS and the framework that it's based on, for now I'll walk through some of the functionality that's currently up and running, and discuss features that should be included in the initial release. However, there are a couple of caveats - Firstly it's important to bear in mind that most of the work done so far has been on the framework, and abstract features that will enable cool things to happen in the future. I contemplated discussing some of these concepts and the design goals behind them in this blog but decided against it. Not only can abstract concepts be overly technical, but describing them requires me to allude to examples and potentials that may never actually be developed. I'd rather discuss concrete features in future blogs, but will be happy to go into more detail in the blog comments. Secondly, as most of you know, vBulletin 4.0 will be shipping with a new style. As that isn't finished yet, the CMS isn't using it - but as it will be using it eventually I haven't wasted much effort in making it look pretty. Creating a Page The design of CMS pages and the widgets that are included on them is defined by the Layout that the page uses. Freddie published a screen cast about Grid and Layout Management last month that goes into a lot of detail. Essentially, you need to create a layout before you can create a page; although the CMS should ship with a few default layouts. After the CMS is installed and running, a default page will be available. Here's a development test page: From here you can enter Edit Mode by clicking Edit this Page. In the future, there will be a nice toolbar UI for all of the page management tools, for now it's just a bunch of links. Once in edit mode, you can now edit the content on the page; configure the content; configure any widgets; add content or delete the page. Here you can see a text area for editing static html in a development content type. There is also an edit link in the toolbar for the content, next to it's config link. Depending on their individual behaviour, widgets and content may be edited inline while the page is in edit mode; or be edited with a dedicated UI by clicking the edit link on the widget or content. The static html content type here has the edit link enabled for demo purposes only, as this particular content type is edited inline. Content and widgets may also allow you to configure how they behave on the page. Clicking the config link in the widget toolbar opens the config UI. In this instance, clicking Config on a widget's toolbar while editing a page will allow you to configure the widget for that specific page. However, widgets can also have a global config that can not only determine global settings, but also define what content authors can change per page. In a future blog we will take a closer look at how widgets are created and configured. Clicking Add Content allows you to create a new page. When you create a new page you can select the type of content to use as well as the Style and Layout. As mentioned before, the Layout is predefined and determines the layout and widgets that will be included on the page. Optionally you could add the title to the URL or allow it to be generated automatically. The location defaults to the page that you were viewing when you clicked 'Add Content'. It specifies where the new page will be on the site as a whole. There will be a better UI to browse the site structure (a la Freddie's asset management), instead of a simple drop down. You can of course delete a page. After a confirmation, the page will be removed and you will be redirected to the nearest parent content. The walkthrough above appears simple, but is just enough for basic content driven websites. A lot of effort is being put into the code behind the CMS to ensure that it is flexible enough for many powerful features to evolve in the future. It's possible to create subsites with different styles and layouts; widgets can read the content on the page for more advanced and dynamic features such as content highlighting or automatic related content links. Mod developers can develop content types and widgets in their own packages with minimal hooking required.