The installation requires about 50 MB on your hard disk, but as always, the more space you reserve for the system the better. For a good system experience, we suggest some minimum values: at least 1GHz CPU and 512 MB of dedicated RAM.

As with any other software application developed in PHP, eZ Publish also needs some configuration to better work with the interpreter. The most important is the one related to memory usage and timezone settings. Moreover, the same settings should be applied to both the command-line site and to the Apache (or IIS) module.

date.timezone = <timezone>

One of the main questions to consider before using eZ Publish is whether to use shared or dedicated hosting. There is no simple answer because the choice depends on the type of site that you develop. You have to take note that the variables that affect the performance of the CMS are:

If the site that you want to develop is a showcase site for a company, with few pages and few visitors, then the minimum requirements we saw in the previous paragraph will be sufficient.

If you want to develop a great site for a media agency, such as the project we'll develop in the next chapters, a site with high freshness of content, with a respectable number of visitors per day (over 5,000 unique visitors), where we will add advanced features and the ability of users to add content, then the minimum requirements will increase to:

For medium-sized projects, you can also use aVirtual Private Server (VPS), but if the site receives a lot of visits and the CMS makes extensive use of a caching system, then the performance could be diminished because of slow I/O. As a rule of thumb, when possible, try to avoid using virtual disks if you plan to have a popular site.

First of all, download the latest version of eZ Publish from http://www.ez.no/download (at the time of writing this book, the latest version is 4.0.1). Unzip the file that you downloaded, to your web root, and rename the folder with the name of the project.

For example:

# cd /var/www
# wget http://ez.no/content/download/242355/1643191/version/1/file/ezpublish-4.0.1-gpl.tar.gz
# tar -xvfz ezpublish-4.0.1-gpl.tar.gz
# mv ezpublish-4.0.1 packtmediaproject
# cd packtmediaproject

Once you have unpacked the source code of eZ Publish, you must create a new database. It is important that the charset (character set) of the new database is UTF-8 as this has been a mandatory requirement for a correct installation since version 4.0.

To create a new database, open a shell and use the following code, which shows how to set the character set:

# mysql -u root
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.0.67 MySQL Community Server (GPL)
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> CREATE DATABASE packtmediaproject CHARACTER SET = 'utf8';

Now create a separate user called packuser who owns all rights to manage the database, and who can access the database only from localhost. You'll use this user in the eZ Publish configuration files.

mysql> GRANT ALL ON packtmediaproject.* TO 'packtuser'@'localhost' IDENTIFIED BY 'packtpwd';
Query OK, 1 row affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 1 row affected (0.00 sec)

A virtual host setup is needed by eZ Publish only when configured to use the host access method, which is the suggested method.

When using virtual hosts, it is possible to have several sites running on the same server. The sites are usually differentiated by the name under which they are accessed. Apache will look for a specified set of domains and use different configuration settings based on the domain that is accessed.

Virtual hosts are usually defined at the end of the httpd.conf file, which is the main configuration file for Apache, and is placed on Debian-based distribution in /etc/apache2/conf. Adding a virtual host for eZ Publish can be done by copying the following lines and replacing the text encapsulated by the square brackets with real values.

Please refer to the following code for a real-life example of using virtual hosts.

NameVirtualHost [IP_ADDRESS]
<VirtualHost [IP_ADDRESS]:[PORT]>
<Directory [PATH_TO_EZPUBLISH]>
Options FollowSymLinks
AllowOverride None 
</Directory>
<IfModule mod_php5.c>
php_admin_flag safe_mode Off
php_admin_value register_globals 0
php_value magic_quotes_gpc 0
php_value magic_quotes_runtime 0
php_value allow_call_time_pass_reference 0 
</IfModule>
DirectoryIndex index.php
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule content/treemenu/? /index_treemenu.php [L]
Rewriterule ^/var/storage/.* - [L]
Rewriterule ^/var/[^/]+/storage/.* - [L]
RewriteRule ^/var/cache/texttoimage/.* - [L]
RewriteRule ^/var/[^/]+/cache/texttoimage/.* - [L]
Rewriterule ^/design/[^/]+/(stylesheets|images|javascript)/.* - [L]
Rewriterule ^/share/icons/.* - [L]
Rewriterule ^/extension/[^/]+/design/[^/]+/(stylesheets|images| javascripts?)/.* - [L]
Rewriterule ^/packages/styles/.+/ (stylesheets|images|javascript)/[^/]+/.* - [L]
RewriteRule ^/packages/styles/.+/thumbnail/.* - [L]
RewriteRule ^/favicon\.ico - [L]
RewriteRule ^/robots\.txt - [L]
# Uncomment the following lines when using popup style debug.
# RewriteRule ^/var/cache/debug\.html.* - [L]
# RewriteRule ^/var/[^/]+/cache/debug\.html.* - [L]
RewriteRule .* /index.php 
</IfModule>
DocumentRoot [PATH_TO_EZPUBLISH]
ServerName [SERVER_NAME]
ServerAlias [SERVER_ALIAS]
</VirtualHost>

The following table explains the variables as referred to in the code above:

The NameVirtualHost setting might already exist in the default configuration. Defining a new one will result in a conflict. If Apache reports errors such as "NameVirtualHost [IP_ADDRESS] has no VirtualHosts" or "Mixing * ports and non-* ports with a NameVirtualHost address is not supported", try skipping the NameVirtualHost line. For more information about the NameVirtualHost directive, see: http://httpd.apache.org/docs/1.3/mod/core.html#namevirtualhost.

If the ServerName is not a registered domain, you will need to add the record to the file /etc/hosts, so that the system DNS can resolve it.

Open the file /etc/hosts and insert the following code at the end of file:

127.0.0.1 packtmediaproject

In order to scale, convert, or modify images, eZ Publish needs to make use of an image conversion system. Either of the following software packages (both are free) can be used:

ImageMagick supports more formats than GD2 and usually produces better results (better scaling, and much more). The setup wizard will automatically detect the pre-installed image conversion system(s).

The installation and setup of required software solutions (outlined above) is far beyond the scope of this document. Please refer to the eZ Publish homepage and the relevant documentation for the different software solutions.

Some features of eZ Publish depend on the maintenance script that takes care of various tasks behind the scenes. This script is located in the root of the eZ Publish directory and should be executed at regular intervals. The script is called runcronjobs.php. Among other things, it processes workflows, checks and validates URLs, sends out notification emails, and so on. Although eZ Publish works without a periodic execution of runcronjobs.php, it is still recommended that you have it running in the background. Some features, for example the notification system, will not work if the script is not running.

The most common practice is to instruct the operating system to automatically run the script every 30-60 minutes. However, some tasks should be executed more frequently than others, and thus it is a good idea to divide the cronjobs into groups/sets, and run them separately.

In the coming chapters, we'll set up some cronjobs: clear draft, start workflow event, and notification.

The default configuration files end with a .ini extension and are located in the settings directory. Each file controls the behavior of a specific part of the system. The main and the most important configuration file is called site.ini. Among other things, this file tells eZ Publish which database, design, and so on, should be used. The default configuration files contain all of the possible directives (with default settings), along with brief explanations. These files should only be used for reference, and should never be modified.

An eZ Publish configuration file is divided into blocks. Each block contains a collection of settings. For example:

...
# This line contains a comment.
[DatabaseSettings]
Server=localhost
User=allman
Password=qwerty
Socket=disabled
SQLOutput=enabled #

This line contains another comment.
[ExtensionSettings]
ActiveExtensions[]=ezdhtml
ActiveExtensions[]=ezpaypal
...

The example above shows two blocks: DatabaseSettings and ExtensionSettings. Each block has several sub-settings, which control the behavior of the system. A setting can usually be set to enabled/disabled, a string of text, or an array of strings. If the name of the setting ends with a pair of square brackets, it means that the setting accepts an array of values. In the example above, the ActiveExtensions setting tells eZ Publish to use two different extensions: ezdhtml and ezpaypal. Lines starting with a hash mark (#) are treated as comments.

As pointed out earlier, the default configuration files should never be modified because they will most likely be overwritten by a new set of files during an upgrade. Because of this, custom configuration settings must be placed elsewhere. Global configuration overrides can be placed in the /settings/override directory. The settings of the configuration files located in this directory will override the default settings. The name of the configuration files in the override directory must end with extension .ini.append.php or .php.

If an override configuration file exists with both extensions, eZ Publish will process the one with the .ini.append.php extension. The .php extension is more secure, because will be processed by the web server as a PHP script. If someone attempts to read it directly using browser software, the server will not display the contents because the configuration settings are commented out. This method will prevent the disclosure of secure information such as the database username and password.

In order for this to work, the contents of the configuration file must be encapsulated by a pair of PHP comment markers: /* and */. The following example shows how an override (for example test.ini.append.php) should be set up:

<?php /*
#?ini charset="utf-8"?
# These are my example settings
[ExampleSettings]
ExampleSettingOne=enabled
ExampleSettingTwo=disabled
...

*/ ?>

The charset directive reveals the character set that was used to construct the .ini file (usually UTF-8).