In my previous post, I was talking about main practice on designing content tree on eZPublish and some limitations due to the current architecture of this CMS.

It seems that this matter of concern was shared by a lot of people, in particular at eZSystems as Paul Borgermans has shown us during the eZDeveloper Meeting. See there.

The project V is the full reimplementation of eZPublish core to lighten it and make it more powerful and flexible. Looking back the evolution of eZPublish, a such great upgrade did not happened from the 3.x series, since 4.x was just a porting to PHP5. Thanks to new tools like a bug tracker or a testing suite, eZSystems has set a mature development system which can produce software of higher quality than before. So the difference between 3.x and 4.x is few bugs and PHP5.

What's next ? The Project V has the ambition to provide two things :

• a very modular and flexible Unix-like micro kernel. It will allow you to access more efficiently its API and will be based on ezComponents, specifically on the MVCTools component. This particular feature might let you use other components than the ezComponents : Smarty for another template engine or Doctrine / Propel for the persistence layer. It meets up with functionalities of another product we know well.
• a bundle of RAD tools to ease and quicken the development.

As it will be a complete different kernel, extensions will be different. To ease this migration, the engine of the Project V will appear as soon as 4.2 : the broker would bring the possibility to choose between old and new behaviour.

Quite exciting !

This post is about different things. It came from a long talk with Damien Pitard, web architect at Prisma Presse, which began with the difference of concept between using content as children rather than putting it in the direct content. For example, if you have an article related to companies, you can organize differently your content :

• You can upgrade your article to put some extra data, like a matrix attribute. There's no limit with this kind of data type : you are sure to store what you want inside the content. So the point is that all your data, related data and main data will be together. The only issue is that this kind of data type does not exist if you consider more complex data type.

• Another point is to make your article class like a container and create a new class called company with two or three attributes. By this way, you can add as many companies under your article node and with few template codes, show them. There is no limit with the number of content or the complexity of you content. However, the main issue is that maybe the company does not have a real existence on your web site. It means that you maybe don't want to have a page with a full view of your company. This is the source of a lot of SEO related issues and bug.

There is also a third but not right solution : you can mix basic data types in your content to reach what you would like to have. For example, you have a content with attributes Title, Subtitle 1, Text 1, Subtitle 2, Text 2 and so on. The main issue, even if you got almost what you need, is that you might be limited by the number of attributes. What will happen if you're asked for a subtitle 32 and text 32 ?

As eZPublish is a great product, we just challenged it in a regular way : what we want is to fill customers need and what we have is in eZPublish. We went by two phases : how we use eZPublish and how we would like to change in it.

Underlying concepts

The more you make technical specifications for eZPublish projects, the more you find strange solutions to reach your aim. Looking back, we both made experiments with eZPublish and as the versions went up, we understood some points about the main matter : the content.

This is how the content is typically used in eZPublish :

• To store content. We can find this kind of content at the end of the tree, the leaves. There is nothing under them and they are the representation of a page in the CMS. In eZPublish, you expect to have a lot this kind but it's not exactly what happens on projects.

• To structure the content. You can find some contents which are only set up with one attribute, a text line, to make it clickable in the back office. The main point is that it doesn't its own content. A counter example is the Folder content provided in standard by eZSystems in their packages (eZWebin or eZFlow). This class is composed with other attributes like a Description field or a date. It adds content to the website and isn't here to represent a way to categorize your content. This is what you may be tempted to do but it causes several issues.

• To syndicate the content. You'll use a content to be the start node of your tree to syndicate content which is under. For example, the typical homepage does not own content or is just a structure node which will put nodes back up. eZSystems has provided a great interface to do this but it still remain on nodes with the Front Page class.

What we have understood is that the main a key of a CMS is to provide a page for a content, and in eZ, as you are free to organize you content (you're not guided), you can make great mistakes.

Content rules to make your content rules

Those are the rules that may have to be respected but which are not always and that contribute to provide main issues on standard features :

• Don't use structure nodes or syndication nodes in your tree. It doesn't supply any content. Make a module instead.
• One content is one page. This will allow you to easily organize your tree and consolidate your content in one and indivisible content. If you decide to display your content in some complex layout, it will ease the separation between the content linked to the uri and the other kind of information. Consequences of this rule are that each content must represent only one page and that your content have to be a complete content, not scattered in few pages. There is a lot of advantages to proceed like this :
  • it's easier to publish content and to set the SEO rules (No duplication in pages).
  • all part of your content can be visible in the same page : you won't have to cheat with redirection or include templates to correct this.
  • your tree is lighter.
  • your content is complete.
• Don't make relations between content that does not need a real representation of itself. For example, don't try to link a content that is only shown as a line in a folder override. It implies that you will have to make an override for the full view which doesn't mean anything. All types of relation are concerned : child relation and content relation.
• Use transversal categorization like a category data type or a tag data type to avoid useless tree nodes.

Powerful but useless

Finally, the most important in a CMS is to efficiently manage content. This truism shows that sometimes we forget the things which has to be perfect in the software and that is polluted by other provided features that are used in 10% of your projects. Those become useless features as long as you apply our rules :

• The multi positioning system : this feature allows you to add several locations to an object. When you modify the content, the modification is affecting all the locations. However, it implies that you have a 1 to many relation between content objects and nodes. If you don't use multi positioning, you can merge the table of nodes and objects, increasing all your requests on content.

• The class tables : this features is not longer useful provided that each time you make a modification in a class you have to modify the corresponding templates. Let stop deluding ourselves here, in an eZProject, developers don't make perfect templates with all the cases and your users doesn't modify the classes. It is possible to store it elsewhere like in an XML file that will be cached. If we remove this tables, the requests on content are improved.

• Users and roles management : all users and groups are stored as content. Provided that all the modules use those ones, it is heavily eating up resources. As we have to manage it on line, it's better to keep the current interface but not to store it as content.

Conclusion

CMS are evolving quickly, users are asking new features everyday, high performance and availability level is becoming a standard and the software law of evolution is wreaking havoc. It is a matter of fact that eZPublish has a perfect conception model to store any content lying on a complex and full featured architecture. We are resigned : what has brought eZPublish to its CMS high rank will maybe lead it to the end. Nowadays, this model is reaching its limits and new CMS are coming out with light interfaces and light and flexible architectures.