Basic Rules for creating a core CCK for Joomla

Note: See also Matthew's post on the same subject

As Content Management Systems mature and become more and more a part of day to day website development, so the pressure is on to create systems that can be tailored for their end users requirements rather than swamp the user (and for that matter the developer) with so much functionality that the entire system becomes fragmented and unweildy.

Content Contruction Kits (CCK) are one way of extending a system that allows the developer (and even user) to create templates and customised data fields so that content can be stored in exactly the way that it needs to be written. Advanced CCK systems even allow the development of simple applications from the data sets to add more power and functionality. But there is a danger that a CCK can make a CMS more complicated than is required and add many additional layers that complicate and even slow down the website. 

I have been testing out the CCK produced by Seblod for the most recent Joomla 1.7 release and it certainly expands the usefulness of Joomla. This is a developer orientated tool desgned to allow the site developer to produce content types rather than just being stuck with the basic Joomla article. I am using it on my new profile site and the original of this article was written using the system. 

This is all well and good, but should Joomla have a built in CCK as part of its core rather than as an addon? The answer is, of course, yes, but Joomla has currently nothing even remotely resembling a CCK so this would be starting from scratch. In many ways this is a good thing as a CCK can be properly developed that is slick, easy to use and compatible with existing installations. However, there is the risk that any fundemental mistakes made now will, in the long run, threaten to cripple any future developments as changes could easily make the system incompatible. 

I believe for "Joomla CCK" to be properly developed there need to be some very set rules.

Data Integrity

A field in a database is simply an empty hole that only defines the type of data and the quantity. Once those have been set up, what goes in comes back out again without any corruption; any additional work done on the data is and should be "post" database. In an ideal world this should include text mark up such as HTML or Creole, but short of storing two synchronised versions of every thing (the HTML version and the unformatted version) we generally have to put up with some formatting being saved in the database.

Keeping the data simple is vital for the long term preservation of information - it should be possible to save and export from a database without encountering additional markup that is very specific to the system in which it was originally stored. In other words, we expect the database files to have markup associated with the running of the database system and we expect the data to have markup related to the display medium, (Web page or word processor document, for instance), but since these are universally used systems to a certain extent this is acceptable. But additional data that pins the content down to not only the type of system but the unique installation of that system should be avoided at all costs.

In practice, this means that any data that is required to define the data type or to link the data to any extended resources (such as a related database table) should be stored in its own unique field and not within a field not originally specified for the purpose.

Allocation of Storage

An addon CCK is required to use or not use any table structure that already exists. For instance, in Joomla the #_content table has fields for metadata, title, category and so on - it makes sense to reuse those. But there can be confusion as to whether you should use the introtext field for your new content type, or whether you should have your introtext stored in a table specifically for that new type.

That latter makes a lot more sense because all data specific to that content type is then stored in the same place.

However, if ALL your various content types are basically articles, but with some small variation, you now have your data spread amongst many tables instead of one neat one. You can, of course, simply shove all your customised fields into one huge array in one of the existing content fields, but although this now keeps all your data in one place and is beloved of some programmers, it breaks our first rule of keeping the integrity of the raw data in a spectacular fashion. There is no halfway house here either. You cannot do a rule that says "as long as you keep the integrity of the core tables, what you do in your own table is your own problem." A content management system is a single entity, and the rules of how everything works, core or third-party, should apply to all, if simply for the sanity of the end user and data owner!

The solution may lay in a little bit of practicle planning through our built-in CCK. 

With a Web CMS in particular, most of the data will probably be article based in some guise or other and it is probably a good thing that the majority of that type of data is kept in one particular table - in Joomla that is the #_content table. However, what fields should be available might well vary from installation to installation.  A good developer working with the website editor should be able to determine what common fields may be required by all content types. For instance, most articles will need a field to store the main text of the article. A summary or excerpt will probably be required for listings. The article will definitely need a title, possibly subtitle, a category reference, an author reference and so on.

So, at the beginning of the developent process, once all the possibilities have been mapped out, the CCK should give the developer the ability to customise the various content type tables in the database to the basic requirements of the website. This is not creating forms or form fields but simply allocating the basic starter storage. 

From that point on, any additional information required by content types that falls outside of these core tables should be kept in a separate table, either as a complete stand-alone or related to content that is stored in a core table.

The rule could be thus - If a field is required by more than one content type that uses a core table, then that field should be part of the core table as it is a common resource. If The field is specific to only one content type then it should be in a table that is only for that content type.

Accessing New Content Types

It is all too easy to assume that a content type must be a variation or addition to the core content table in Joomla. This is rightly so for something that resembles an article, but if our many content types include data sets of lists, numerical data, graphical data and others that need to be accessed in their own right, do we want any reference to these clogging up our article database?

The current Joomla framework, out of the box, revolves around the #_content table and the related category table. The easiest way of adding data is to use this system because the tools already exist to access the data via the menu and search system.

If all your data is articles (mine almost always is) then this is fine and you might as well use this system for all your content types. If you want to produce content types that really bear no relation to articles, then you will understandably want to create new, standalone data sets in unique tables that can be accessed via their own Menu plugins. Our Joomla CCK should, therefore allow the creation of menu links that can access data from any specified table. 

This is possibly one of the more complex areas since accessing a record or group of records might not be as simple as calling up the record by ID. You may wish to call the data in a certain way, exactly as you can when calling an article - show/hide title and other elemnents, order data in a certain way and so on.

A fully fledged system should, therefore, be capable of creating menu item types based on how you have set up your content type so that your are not reliant on the exsiting menu/article types that come with the core. Basically, the system is able to create its own plugins.

Contradictions between Content Types and Categories

Categories in Joomla are one of those things that are somewhat overlooked when it comes to importance. The Joomla category system revolves around the article system although it can be accessed by third party components. 

This has always been a fundamental flaw in Joomla. Categories should be at the heart of Joomla thinking and design in the same way as a CCK should be. When you create a category, you should be able to use that for an image, an article, a user even and any third party systems - there should not be seperate sets of categories scattered all over the place. 

When it comes to Content Types (through a CCK) should there be a relationship between a content type and a category? The answer is both yes and no. A developer should be able to create a content type and assign it to a category so that anything that is related to that category automatically uses the content type. This allows the developer to keep a very tight ship should that help the way the website needs to be managed. However, the developer also needs to allow a more free system where any content type can be used for a category or only some. This should be a many to many relationship, of course. 

Media Management

One element frequently left out of CCK is media management, or rather it is a weakness in the current Joomla framework that could make any built-in CCK less than impressive. I am uncertain why the Joomla Media Manager has been regarded as such a low priority item - multi media is the very essence of the web and not being able to properly categorize, notate and manage a proper media library seems idiotic.

With a CCK it becomes vital that relationships can be set up between a content type, the category and the media library so that the developer can define storage rules, upload rules, editing rules and so on for each content type depending on permisions of the user. This would include limiting a user to a personal library on installations that are based round community membership and social networking.

This is one area where relying on third party plugins is unwise since a media management interface should be common throughout the entire system and not just the CCK or a couple of components.

Creating a Content type - who should do it?

There are two ways a CCK can and should be used. The primary use would be as part of the web solution development and management. This is the all singing and dancing system where, via a dedicated and easy to use interface, the developer can create field types (for instance fields that come with formatting or built in plugin code), content types including all the core database functions, templates and so on.

But there is also room for a cut down version where a user can create a content type on the fly while writing an article.  In this situation the user would be starting with one of the admin created content types and then adding functionality. For instance they would be able to create a list that is embedded in the article but stores data in a separate table and is related to the article. Or they may want to add a side bar to an article that does not have one - this would be more of a template function, but the two are related.  The other situation is where for a specific article the template needs some fine tuning - the article image needs to change sides or size, or one or other of the elements needs to be moved around. This means that there needs to be an advanced template system available either as part of the core or as an addon.

A permissions structure would be used to set who could do what based on the Joomla groups system. 

Templates

Templates are often one of the most attractive parts of a CCK (pun intended) - creating lots of interesting content nicely arranged in a database is fine, but being able to manipulate how that is displayed, sometimes on a time by time basis, is the icing on the cake.

A content type should be broken down into three elements - the data and how it is stored, the interface for inputting the data and the templates that can be used for retrieving and displaying the data.

Retrieving and Displaying the data is the odd one out of the three as it does not effect the integrity or the make up of the data and consequently it is the most versatile. There are a multitude of ways in which any fixed data can be displayed and this should be taken into account when designing a CCK. The developer should be able to create several layout templates within the system without having to resort to working at file level, and allocate one or more of these templates to the content type. The user or editor (depending on the permission structure) would then be able to choose the template from a selection for content belonging to a particular content type/data set without having to ask for changes in the backend.

Giving a developer an in-system design tool for templates is also a very mature way of running a system. I am not keen on multi-position template systems - it is probably silliness on my part but I have a problem when I examine my "Title" in Firebug and see that is it nested ten deep in Divs, when it only needed to be an H2! Surely it is not an impossible task to create an online system that allows a developer to create a clean, simply coded template by dragging and dropping elements?

This is also needed for speed. On a very large site where the demands on the developers and administrators may be pretty heavy, if they can put together templates within the system itself that are then instantly available for the writers, then this is a very proactive and efficient way of working. If the solution is intuitive and non technical enough it can even be propagated down to the editors at which point the system is truly Managing Content!

Conclusion

CCKs should not make a site more complicated to use but should make it more taylored to the use that is required. Whether or not a CCK can be advanced enough to actually create applications is less important than making sure that the core functionality of the CCK, the organisation and handling of data is done in a clear, precise and predictable way that allows the data to be as clean and reusable as possible. 

It is pure arrogance for us to assume that information created and collected on our favoured CMS will only ever be used in that way. To be honest and fair to the client, the data owner, their data should, as much as practicably possible, be stored in such a way that it can be used, reused and transported with the minimum of fuss and the greatest of integrity. Perhaps as part of any CCK data SHOULD be duplicated so that there is one set that is stored complete with HTML markup or whatever and another set that is kept as text only - or at least an option to do so. 

A carefully tailored CCK as part of the Core of Joomla makes a lot of sense as long as it is logical, easy and ignorable. It should be there to extend the system without changing how the system works or how information is stored. It should be presented in a step by step fashion, for both developer and author, to keep the learning curve as gentle as possible.

Some idiot proofing is also a good idea! (I need that regularly for myself).