This is the second part of this former post : Some points about what we think about CMS.

After few projects and few architecture designs, we're up to deliver the second part of our mastering of content management with eZPublish.

Different ideas and concepts

Here are the following concepts you should know about before going on.

Content, messages and settings

eZPublih as all kind of software is made to store a lot of information regarding its source. We can distinguish several types of information :

• Contents : information used in the website pages, owner of the real value of the website. It can be text based pieces of information or pictures, or videos...
• Messages : information used in the website to deliver messages. It could be a label or an error message, something nearly static but which can change.
• Settings : technical information globally used in the website to structure the content.

Those types structure each website and each type must keep its original aim.

Use contexts

Use context are very important in a solution. The aim of a context is to ensure that users can do only what is coherent to do. It's a main principle that must be declared during the design phasis of any product and it allows the mapping between events and actions. More information about this on the spectacular book The Psychology of  Everyday Things by Donald A. Norman.

In eZPublish, such contexts are defined inside the back office : browse, edit, search... For example, if you are editing a content, you cannot edit another content or browse something. However, it's possible to switch from one context to another with a controlled input (Online Editor dialog box, for example).

The closest thing in eZPublish could be the navigation part used in menu.ini.

Aggregates

As explained in the former post, the aggregate is the concept that allows you to use different contents so it can be mashed up in one page. The edit of this kind of content has to respect the aggregate context : if you are aggregating, you can not edit a content. It also means that you have to prepare all the content you want to aggregate before aggregate it.

Composition and layout

The composition action relies on several axis :

• Definition of placeholders in the page : you shape the layout of your page, preparing the page to receive different contents, adding constraints to it : columns, height, width...
• Definition of widgets : you shape a bunch of independent blocks implementing different features : main story, google map, search box, gallery and so on... You may set each widget depending on its type.

Currently, this is mostly implemented in ezflow's eZPublish extension.

Dealing with complexity : content structure is not monolithic

Now that we're equipped with some concepts, we can approach complex needs of our customers.

The rule of thumb that should be learned is the following : each use context deserves a separate content structure. Currently eZPublish is coming with already set content structures (Content Structure, Media, Users and Settings) that could be extended so you can provide your own. As a matter of fact, we should always try to keep the solution genuine and only add things to it. We should also try to not replicate old ways of thinking like those used in DBMS but rely on what the software can do.

Case 1 : Dealing with messages

The case : your business team would like to manage some of the message shown on the website, for example, the small explanation on the confirm page of the shop or the next steps on the zero result search page. Their aim is to be self-sufficient on this part.

The solution : you can just do a smart class to store your messages and then organize it in one of the provided content structure. The point is to define a sub content structure dedicated to a use context, it's still not following the rule of thumb entirely but it's ok.

Solution 1.1 : Adding a hidden folder

You can create a folder and set its visibility to hidden. Then create a class called Message containing 2 fields : id (Text Line) and description (Text Block).

In your different templates or modules, just fetch the object of the class Message with the corresponding id.

Solution 1.2 : Adding a folder in the Media content structure

You create the folder like in the solution 1.1 but in the Media content structure. The benefit is that the Media content structure is visible but not simply reachable. Ok, you may access it by typing it's url directly.

Other solutions that could work but that are too complex considering the need

We could also store all the messages using other storage facilities like the translation file or a specific database table. We can reach the same goal but with a lot of development or worse, strong constraints for the user. I strongly think than using a content is still more efficient than modifying an XML and cleaning caches...

Case 2 : Dealing with settings

The case : your business team would like to make links between pages and mutualized contents. The aim is to manage reference data that don't need a page (reference to the one node = one page rule) but that is not changing very often.  To be closer to reality, let's take a real example. We have a company with a lot of departments. A department is just a part of a corporate body, so it doesn't really need a page for itself but it stores some typical data (address, logo, boss, etc.). In other pages, you will have to specify a department among the full list of departments.

Solution 2.1 : INI files+ Specific Datatype

In a typical application server based solution, you would use some reference tables declared as application variables, but with PHP, you don't have application variables. Instead we will use INI files that will be called from a specific datatype to generate a specific list.

The main limits are that you are limited to the INI file way of storing data. It means that you could not store complex objects but just key / value elements. The value must also be text based (no pictures or other media).

Solution 2.2 : Selection

The Selection datatype is very powerful and should be used very often to solve this kind of need. In our case, you can create a class department with all the required attributes. Then you create a folder called Administration (not in the sense of Set up, in a business way), and eventually sub folders if needed. In a folder, you create all the departments you need. In your other content class, you set the Selection attribute to use : the Administration sub folder previously created. That's done.

In order to have a clear back office interface, you way want to distinguish your use contexts. This can be done by adding specific RootNode and block settings to the menu.ini file.

Case 3 : Dealing with a reference

The case : your business team would like to organize a reference, like a catalog of product, and in the meantime have the flexibility to organize pages of the website. Their aim is to be flexible and shorten the time to market for the product marketing materials. We're talking of a lot of products, let's say 20k so the list approach described above is not useful).

The solution : Follow the rule of thumb by defining two use contexts : the first is obviously contribution for all the content you've already set. The second use context, less obvious, is the aggregation. It means that people would like to change some things that are not pages, because in eZPublish, each node is a page.

Solution 3.1 : Original eZFlow content structure

If you have just installed a fresh install of eZPublish, you will see the original content structure provided by eZSystems. Their main approach is to demonstrate the power of their solution so they have mixed contexts. eZFlow, an extension of eZPublish, allows you to aggregate content through the selection of already filled contents.

The content structure is designed so the FrontPage used by eZFlow contains classic content (Folders, articles, Galleries...).

This structure is efficient enough if you don't have so much content but has some limits. Indeed, the parent-child relation implies a 1-to-n relation between the main parent FrontPage and its children (understood that you will aggregate only content that are under the FrontPage).

Solution 3.2 : Separate use contexts and content structure

To go further, you may organize strictly your content structure to have two content structures :

• Global Fund : structure containing all the content, independent from the storyboard of your website.
• Sites : structure containing all the FrontPage based content, implementing the storyboard of your website.

By this way, you will have a n-to-m relation between your aggregation content and your classical content. You also separate totally your use contexts by telling user that if they want to put content in the system, they have to use the first content structure and if they want to compose pages, they use the second one. Then, it's easy to set up rights, sections, workflows and so on.

Think before !

We have seen different cases with different solutions all implying content and content, respecting or not the rule of use context separation. My recommendation is to carelly design you content structure before implementing it in eZPublish (or other systems by the way).

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.

This show a typical organization with content nodes (Article content type).

• 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.

This is how is organized the content with structure content types.

• 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.

This shows the organization with syndication content types.

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 .