As we learned in the secondary menu, which is located on the left-hand side of the Content Structure section, we can easily create a content tree by using a folder/object paradigm.
Now let's work on the content tree of our site.
We decided that we need a container for all of the past and, of course, future issues of our magazine. This container will include folders for each year (2007, 2008, 2009...), which will in turn contain subfolders based on months, into which our articles will be placed.
This simple structure will allow us to easily group the articles by issue, and use the inner functionality of the eZ Publish templating system.
To create the Issue archive section, we need to left-click on the site's root folder in the secondary menu, to display the context menu. We will select the Create here | Folder option from the context menu.
The CMS will ask us which language we want to use. Select the default language you chose in the installation chapter, and then click on the OK button to go to the Edit New Folder page.
When we access a content object, the main interface of eZ Publish will change slightly. Although the whole interface will appear as shown the following screenshot, we will slice it, and discuss it piece by piece:
Here, we can see on the left-hand area of the screen, all of the information relating to the content object that we are creating (or editing).
The Object information, especially the object ID, will be used to extract the data that we need in the design step. This also gives us a shortcut button to the version management page, where we can administer all of the versions of the object that we are editing.
One of the most powerful functions of the eZ Publish is the version management of objects.
For any object, we can create both drafts and versions. The drafts are essentially not published, but are for internal use; the versions are the published revisions of a document.
If we click on the Manage versions button, eZ Publish will display a new page that contains the history of the selected object. Here, we can edit or delete old versions, create new translations by copying the existing content from one version to another, and compare two different versions to see the differences between them.
This version management workflow allows the editors to coordinate the update activities better.
For example, by using the compare action, two or more editors can create different drafts for the same object version, and then merge the edited content in a new version.
Let's come back to the discussion of editing an object. In the same column, we can see the Current draft box, which contains information about the draft that we are working on:
The View button will allow us to see a preview of what we are doing inside the design template. Moreover, if we click on this button, a new section called View control will be displayed. This section will give us the ability to see an object in a different siteaccess context, updating the preview accordingly. It will provide a possible switchback from the preview mode, by using the Edit button at the bottom of the page.
The Translate from box allows us to create new translation, based on one of the existing ones, if there are any.
The Section box (shown below) is used to move content from one section of the CMS to another.
The section is usually taken from the parent node, and if we change it—for example—from Standard to Media, the object will be moved from the Content structure section to the Media library section.
At the center of the page, we can see the main editing area. This area will contain the datatypes that belong to the object that we are creating (or editing).
We'll now take a look at the Folder content class editing area, as this is a good example for the other content classes.
Every time that we create a new content object, some information will be required for some purpose. For example, for the Folder content class, the Name field is a required field. This name will work as a readable reference inside the system. But if the Short name is not specified, the system will use the Name to create the object URI.
In the Folder content class, we can specify values for the following fields:
These two object attributes are both XML Block datatypes. This kind of attribute integrates a WYSIWYG textarea and is usually used to manage pre-formatted content by using HTML markup.
As we can see in the following screenshot, the XML Block editor is characterized by a button bar that contains all of available tags, along with options to add or link an object, such as an image or another content node, inside the text.
The editor is usually limited to only certain HTML tags, but can be extended by creating new custom tags. Moreover, the CMS WYSIWYG editor's philosophy is to give the authors less control on how the content should appear, in order to provide true separation between the design and the content itself. It will allow the addition of CSS classes, but will never allow a style that is not defined by the web designer.
If we click on the object button, a pop-up window will appear. This will give us two choices: upload a new object, or use an existing one.
For the selected object, we can choose the attributes that we want to use, such as the size (if it is an image), the CSS style class or ID to use, and the type of view we want to apply. We can choose any content object or image, and eZ Publish will create a link or an img tag for us.
Linking objects is fundamental inside the logic of eZ Publish, because this allows the CMS to track changes to objects and to automatically update all of the content, if someone changes its position or URI.
To see the generated XML, the editor can be disabled at any time by clicking on the Disable editor button.
There are some websites that allow us to include their widgets in our website. For example, YouTube.com allows the embedding of a video player in our site by copying some code, and SladeShare.com allows the embedding of a slides player in the same way. In eZ Publish, it's impossible to paste custom HTML codes in the XML Block attribute, but if you use the Insert literal text button, you can do it. All of the code added with this button will not be interpreted or checked by the eZ Publish editor, and by default, it will be rendered inside a pre tag. To override this default behavior, we have to add a new HTML class for the literal box. Then, we have to change the related configuration file and create a new template for the XML editor in our siteaccess.
To do this, open the settings/override/content.ini.append.php file with a text editor, and then add the following lines to the bottom of the file:
cd /var/www/packtmediaproject
vi settings/override/content.ini.append.php
...
[literal]
AvailableClasses[]=html
...
Now, the html class will appear as a choice in the literal properties, in the pop-up dialog box.
To append the code to the frontend, without using the pre tag, we need to create a custom template for the literal datatype in our design extension. We will learn how to do this in Chapter 6, when we talk about the template overrides.
The Tags input is a keyword datatype, which allows us to assign some comma-separated keywords or tags to an object.
These keywords will be used to add meta information to the frontend page, and allow us to develop some other useful features, such as related articles.
This checkbox is present in some of the default content classes that act as containers, and is used as a trigger to show (or not) the children of the object node on the frontend of the site.
These objects will not be really hidden or made unavailable from the front page, but their link will simply disappear from inside the template of the container.
After we create the first Issue archive folder, start over and create all of the other children folder objects.
We want to obtain a structure like the one shown in the following screenshot:
In this way, we will use the month folders to store all the related articles.
Note
To easily create the past year's folder, we can use the Copy subtree option from the context pop-up menu, by clicking on the 2008 folder icon. This action will create a complete node and subtree clone inside the node we decided to use. Now, we only need to rename the new 2008 generated note with the 2007 label.
Now it's time to use the Profile content class that we created in Chapter 3.
As the first step, we will create a folder called The staff, which will contain all of the profiles of our young and cool editors. Next, we will create our first editor profile inside the folder that we just created.
We saw in the previous paragraphs how to create new objects from the secondary menu that is located in the left-hand column of the admin interface. This time, we'll use an alternative way to create our new profile objects: from the Sub items section.
After we select and click on The staff node in the left-hand menu, we will see a couple of select boxes and a Create here button, at the bottom of the content area.
In the select box, choose the Profile option, and then click on the Create here button.
As before, the system inquires in which language we want to create the content object. Choose the default one, and continue.
The Profile edit page will contain all of the information that we previously added:
- A profile description
- First name and last name
- The editor's email address and birthday
- A photo upload form
- A CMS user associated to the profile (if needed)
Specify all of the necessary data, and then publish the content. Then return to the Issue archive | 2008 | January folder, where we will create our first article.
Wondering why we did not create an article content class before? The reason is in the latter part of Chapter 3. We have to add a new object relation attribute to the default article content class definition. In this way, we can relate the Profile content class to our article class. This attribute will be set as required. This means that without a published Profile object, we cannot create an article.
As we did earlier, in the select form at the bottom of the content area, choose the Article portion and then click on the Create button.
If the first form input of the article-editing page is very similar to those we saw in the folder, the latest attributes will introduce some new eZ Publish features. The most important ones are the time scheduling options for publishing, and the comments checkbox.
These two forms will allow the eZ Publish frontend to understand if the content has to be published and/or unpublished on a certain date. All of the logic behind the time scheduling publication is handled by the design and is enabled, by default, in the package site that we downloaded during the installation of eZ Publish.
Thanks to these features, we can prepare a lot of articles in advance and then publish one of them each day, to give the readers a feeling of a truly up-to-date magazine.
This capability will also be very useful to show or hide an article teaser in the home page, or want to cycle through several content objects in a box.
eZ Publish comes with a lot of preconfigured features. One such feature is the ability to enable comments to be entered for an article. This is done by selecting a checkbox in the backend, as shown here:
Every time that we select the Enable comments checkbox in the frontend, a Comment button appears under the article. When the user comments on the article, the related comment will be added as a sub-item object of the article itself.
Tip
To enable a comment by default in our Article content class, we have to update the content class in the Setup / Classes section, as we saw in Chapter 2.
If a comment system is very useful for creating a good community, we will not stop here, and in the next chapters we will enable a forum system.
Last but not least, the final page that we have to create is the Feedback form. We will create this page directly in the root of the site by selecting the Feedback Form content class.
In this case, the editing form will introduce the information collector datatype that we introduced in Chapter 3.
An information collector datatype will store all of the input data directly inside the CMS, but in a different manner than the comment system. The saved data will be placed in the Collected information section. To access this section, you need to go to Setup | Collected information.
Now we have to create more pages or sections for our site, such as the forum, some static pages such as the about page, the copyright notice or legal notices, and a site map.
For the forum, we will dedicate a whole chapter. All of the other pages can be created by adding an Article object inside the root of the content tree—or inside any other node, if you think that would be better.
We have to remember that we can create these pages at any time, in accordance with the changing requirements of the site.