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

Hi there,

Long time since the last blog post. Time to have an idea, to make it mature and then prototype it.

So, the next extension after WSE Status we're working on concerns the developer ability to easily modify templates and make overrides in eZ Publish's back office.

In last version of eZPublish, developers have been prejudiced due to focus on high value added features. This is mainly linked to the emergence of the eZ Market place that provided packaged extension to companies.

By the way, our extension provides a new menu in the back office allowing you to do the followings :

• Understanding easily what design and what site access that are set in your eZ Publish installation
• Create an extension and a design so you can work independently from other extensions
• Add a new template to this design
• Find a template in the existing designs and override it
• Fine edit online code with Ace and live preview !
• Drop files like javascript and images inside your extension

This extension is still in progress and may be out at the end of January.

Manage projects

Eclipse PDT is one of the most powerfull IDE for PHP developpers, even if some prefer to use more classical editors (vim).

When developping your extensions or websites, you might want to have access to all the API of eZ publish, Drupal or other libraries.

To do so, we used to create separate PHP project with the different sources. Let say we want to develop an eZPublish extension. We create the following projects :

• One for your project, synchronized with a control version system (CVS, SVN, Git...).
• Another one for your references, eZ publish.

Now, in your project, right click on the project, choose Include Path > Configure Include Path.

Then go in the Projects tab, click on Add, select the project with your eZ publish bundle. You will have something like that :

PDT - Include Path

Click OK to save.

If you got some troubles, don't forget that you may not have the last version of PDT (even if downloaded from the website).

You can check updates by Help > Check for updates.

Cool shortcuts

Now, some shortcuts to go faster in your development tasks :

• CTRL + SHIFT + R : Open a resource, open quickly a file if you know its name.
• CTRL + SHIFT + T : Open a type, open quickly a class if you know its name.
• CTRL + SHITF + H : Open a type in hierarchy, quickly open the hierarchy of a class if you know its name.
• F3 :
  • On a class name, open the class file.
  • On a function name, open the function inside the class file.

And autocomplete feature on words, for example, in a PHP file, do CTRL + SPACE :

• On a class name, will give you purposes for the class name. Example : type eZU and you will get eZUser, eZUserAccount...
• On a variable, if Eclipse succeeds in determining the type, it will find the class and the functions for you. Example : typing $node->fet will return all the functions for eZContentObjectTreeNode class.

Cooler shortcuts

You can use CTRL and ALT with arrows, tab and Page Down and Page up.

• CTRL + UP or DOWN : make scroll the file without moving the cursor.
• CTRL + PAGE DOWN or PAGE UP : go to the following or previous open file (works also in Firefox with tabs, in Excel with Sheets...)
• ALT  + UP or DOWN : swap lines, useful to move one line or one block from one place to another without using cut and paste
• CTRL + ALT + UP or DOWN : copy the selection just after or just before, useful to duplicate lines.
• CTRL + TAB : useful to change from one tab to the next one.
• CRTL + K : on a selection, will find the exact same instance.

Working on one of my projects with eZ Systems French consultant Jérôme Cohonner, we got an excellent conversation on how users were handled in eZPublish and how sometimes this could lead to some troubles. This post will give you some clues on how important users management can be, what are the limits and some common solutions to get the best way of doing things. I will not talk about SSO or procurement systems as I have already dealt with or as it's out of the scope.

Users management, some concepts

Let's get back to the roots and have a look on principle concepts of AAA :

• Authentication : the fact that someone can prove that he is who he is by any way of proof : password, certificate, tokens, fingerprint...
• Authorization : the fact that someone has been given some rights, credentials, habilities to do something.
• Accounting : the fact that someone activities could be observed, monitored, audited to get data to be exploited after.

Generally, in all IT systems, these concepts are implemented in different ways, together or alone, merged with other systems or not. When an IT solution becomes complex, you will need to provide a strong user management strategy to be sure that all will work together. The strategy is defined by combining different approaches that could be listed like this :

• Authentication : handle authentication ways, simple to complex, available everywhere in the system
• Data : handle user data and make it available everywhere in the system
• Organization : handle an organization of people, available everywhere in the system
• Access : handle rights, what people are allowed to do

Moreover, all those approaches are submitted to the centralization dilemma : do we need to centralize all those things in one service or not ? If one of these approach is not centralized, do all the software of our solution are able to do the job ?

On each IT projects, choices are done, sometimes depending on the software capabilities, sometimes not. The most important is to know where you want to get the maximum flexibility.

eZ Publish and the limits

In eZ Publish, users are stored and considered as content objects which is a choice in itself. It means that the accent has been set on data management before everything. The cool thing with that is that you can handle your users as pages (as they are nodes) and that you can add and remove attributes as you want. Best, data can be versionned. The only thing you have to do is to ensure that the user content class gets the User account datatype.

You can also plug the LDAP Login Handler to access a remote directory. The mechanic is quite good. At the authentication, the user provides its login and password. eZ Publish will try to log this user in the LDAP and if it succeeds, eZ Publish will create an eZ user or update it if it does not exist. Then the user is authenticated and receive eZ Publish credentials.

It's also possible to use the multi locations mechanism to get some flexibility on the role assignment. For example, as you can set a user in several groups, you can give each group a different role so multi located users will inherit all the roles from all their parents. You can look at one of my former post about content design, it explains how to organize your content in eZPublish.

The limits of this model are :

• Data and user account are in the same place and that the data container is not efficient when there is a lot of users.
• If user data has to be shared, size and count of data really imports as it has to be managed locally or remotely.
• The remote model implies a direction on the way data are managed. Data needs a reference that should be unique at one time and on which all other software must refer. It also implies that you will have to have a simple model in your directory as rights must be managed locally.

Some examples :

• Try to have a user class with 50 class attributes, which is possible if you are storing every information of your users at the same place. Create then 100 000 users, that is quite normal for a big website. Requests that are made against the generic model of eZ Publish are just to slow for standard fetches. Having a lot off attributes in a user is quite common and is resulting from very strong business needs or technical needs. For example, you may need an attribute to avoid to use a directory. This has been explained in one of my former post about content design.
• Having a very big LDAP with a lot of users with a lot of attributes can be long to synchronize with regular scripts.
• The LDAP Login Handler is very powerful but a bit tricky to master. If you got a complex LDAP, your LDAP configuration will be crazy. Moreover, there's no script to impact an LDAP by users updates in eZ Publish.

eZ Systems is refactoring, time after time eZ Publish's model so everything is split and highly efficient little by little.

Solutions to common issues

Case 1 - It's too late : there's too much data in the user !

It can give you some troubles on performance when you reached high number of users. The main issue is that user data are in eZ Publish and not away. The first point is to know if you need some customization or finally if you just need the user to be logged in to just access some private area.

Solution 1.1 - Store it elsewhere

Make a datatype or extend the eZ User type to only let eZ Publish manage what it needs to authenticate the user, I mean the eZ User Account. Ok, it's cool to have users as pages but in real life, customers don't really want a picture directory of the whole members of the web site. It's not done today in eZ but the global approach of un-content-ization has began. More recently, the eZ Comments extension provides comments for everything in eZPublish but is not set with the classic content mechanism.

The approach of the datatype may not be the right one. You may except some troubles, depending on your storage mechanism. I was thinking about several containers, like LDAP (of course), a custom SQL table, even a file (XML or whatever).

Solution 1.2 - You don't (really) need that

Sometimes troubles are coming from a bad interpretation of the customers need. Sometimes, people don't want data to be hold by the system, it's just an helper for them and avoid to get information elsewhere. Sometimes, people, I mean the main population of the website, doesn't know that there are data about them loaded in the system. The point is that finally you don't need the data, you can do without it.

An example : your customer is telling you that their eZ Publish instance is holding 400K users with a lot of data. This data is not shown on the front side because it's an institutional web site with a poor logged in section. The data is shown in the back office to the webmaster in the user section (so for 1 guy).

One good approach is the following : ask why customer needs all these data and try to figure out if the data is stored elsewhere and if it can be accessed in a asynchronous way, by requesting a LDAP or other external data source.

The solution that will work is to set up a meta user by big business role you are using. For example, define an HR user, IT user, a Board user and so on. When people are logging in, check access against the source and then log the user with eZ Meta User predefined. You will get a severe reduction of your members count : 400K to 4 !

Case 2 - It's not too late : how to share users data ?

The second point is the way you can share users between different application of your IT system. We can think of it on two aspects : the fact to share data (first name, last name and so on) and the fact to authenticate people. It's different and this could be implemented in different ways.

Solution 2.1 - Define a reference

The most important thing in your IT system is to define an architecture block that will handle a centralized reference of user data, both for the data and the authentication. From a strict architecture point of view, directories can provide both features and that's not good. However, as the password is generally the cheapest and easiest way to authenticate people, architects do not recommend two services and prefer to have only layer for this.

So, the most important thing is to use an external service to hold the data and the password mechanism.

Solution 2.2 - Purely share user data

Sometimes, it's a bit difficult to find the allocation of your data between the remote (I mean the reference users data) and the local (data from your application). At this point, you may have three choices with drawbacks and advantages :

• Full local : so why put a remote reference ? :-)
• Full remote : all your data are hold in a remote system and you need to request it each time you want to have an information.
• Half remote - half local : data are stored at remote's and some are synchronized (or not) with local.

As your system needs some consistency, you have the choice to centralized everything at the remote reference but this is implying a bottleneck. Moreover, you will have to get a fine strategy to synchronize remote and local, replicate data from one to the other.

Questions to ask yourself :

• Do all data have to be in the reference ? Does the business piece of data that I manage in my application can be shared with others ?
• What is important, performance or consistency ? Do I have to store all data inside the directory ? How do I synchronize all this ? What if I have update at local's ?

For eZ Publish, it's quite simple as the User mechanism is not so efficient with a lot of users. So the best way, if possible, is to

• simplify the user attributes to the minimal user account datatype attribute, 
• store everything which can be shared out in the directory,
• store all others attributes in another place (for example a custom datatype that writes a list of fields in a table).

Conclusion

Users management is not so easy, there's a lot of thing to think and some merged concepts that make us difficult to take decisions about how to manage the users in an IT system. This is a common issue that is shared by all companies aver the world and leads to interesting solutions like oAuth or OpenID.

Regarding to eZ publish, the difficulty is coming from the technical lock inferred by the eZ User Account type that forces you to have a data user instance in eZ Publish. My recommendation is to quickly kick out the user account (login, email and password) from the user class. This will lead to the division between data and authentication and then it will be possible to authenticate someone without any data inside eZ publish. Then if we actually need a node, we can make a synchronization or an after account creation trigger to generate the node. This mechanism has to be disengageable.

WSE Status has been enhanced to be compliant with eZPublish 4.5 Community 2011.7.

This major update contains the following :

• Support of eZFind 2.5-dev (latest one) with Apache Solr 3.1
• Add of several scripts for cleaning / synchronization of index and tables
• Wildcard research on persons

Moreover, this product is now automatically tested with Selenium scripts ( around 20 tests now and still increasing ).

Next step is implementing new features. If not not already done, help us choosing the right features.

Beta is over now

Thank's a lot for beta testers helping us to fix the bugs.

The demo will be maintained, just get an account on it to try it.

• Register on the demo instance : http://wsest.demo.wascou.org/user/register
• Try WSE - Status on the demo instance : http://wsest.demo.wascou.org/status/profile

To get this extension, you can contact us directly with the contact form.

What is the next step ?

The next step is to choose next features to implement amid this ones :

• #49: Add a list system
• #50: Add a system to shorten URL
• #73: Add a moderation system

If you have other ideas, let us know, we will add it to the list.

Let a comment to this post so we can know what is the most important.

Another delivery that is correcting several issues, notably on the direct messages feature.

The search is also working back to the normal with @person searches.

Register on the demo instance : http://wsest.demo.wascou.org/user/register

Try WSE - Status on the demo instance : http://wsest.demo.wascou.org/status/profile

Thank's for Nicolas, Damien, Lars, Carlos and Ana helping me to identify bugs.

Any feedback is welcome !

Thanks to people helping us to test WSE - Status.

We have made a first bunch of correction which are the following :

• #51 : [Search]Back button
• #52 : [Search] Seconds elapsed
• #53 : [Links] #word leads to a white page
• #55 : [Search] User search does not work
• #56 : [Status] No links to the person's profile
• #57 : [Status] Order of status
• #58 : [Mine] Layout is broken
• #59 : [Favorites] Layout is broken
• #60 : [Favorites] Status are not in the favorites
• #61 : [Direct Messages] Layout is broken
• #62 : [Direct Messages] Unable to send a message
• #64 : [Mails] Link error in the New follower mail

Another delivery is planned for Monday.

Keep it in touch.

The WSE Status extension is nearly complete and we need some help to beta test the product !

The full description of the features are in the related description page.

If you want to participate to this beta, fill the contact form indicating your email, I will create you an account.

There's only 40 seats so, don't hesitate !

Busy, busy, busy... But something is going to get out !

WSE - Status

This is the new extension of Wascou Edition Software that provides great social network for eZPublish !

This extension is available now and can be bought. Contact maxime dot thomas at wascou dot org for further information and look at the product page WSE - Status.

This extension has also been purposed to be added in the eZSystems XTEND Market Place.

There will be soon a movie and some screenshots to picture it.

Other projects

The point has been made on other projects we want to develop :

• WSE - InGrid : still maintained
• WSE - People Selector : still maintained
• WSE - Scrum Manager : Cancelled for the moment
• WSE - Deployment Suite : planned for a v2 with a full UI refresh

Books

We will publish some book reviews in the next weeks, some good stuff have been learned.

eZPublish Community

We will answer this week to an interview for the Research Program initialized by eZSystems.

This is it. We keep in touch.