This section describes how to upgrade your existing eZ Publish 3.9.x installation to version 3.10.y (but not 3.10.0, since direct upgrade to this version is not recommended). If you are upgrading from a version prior to eZ Publish 3.9, you need to first upgrade to 3.9 before you can upgrade to 3.10.
The upgrade procedure described below is generic and does not cover any specific cases. If you are running eZ Publish in a clustered environment, refer to the developer documentation for upgrade instructions. In case the eZ Publish Extension for Oracle® Database is used, refer to the documentation of the database extension.
Before continuing, note that it is strongly recommended to upgrade directly to the latest stable release in the 3.10 branch (3.10.1 at the time of writing), which contains all important bug fixes. Refer to the changelogs and security advisories for more information about the issues that were fixed in the latest releases or view the short list of changes below.
Make sure that you have a working backup of the site before you do the actual upgrade. The upgrade procedure consists of the following steps:
The easiest way to upgrade the distribution files is to unpack eZ Publish 3.10.1 to a directory and then copy the directories that contain site-specific files from the existing installation. Make sure that you copy the following directories:
Replace "example" and "example_admin" with the actual names of your siteaccesses.
If you are using custom extensions, the subdirectories inside the "extension" directory will also have to be copied. However, make sure that you do not overwrite any extensions that come with eZ Publish (currently "ezdhtml", "ezodf", "ezpaypal" and "ezurlaliasmigration").
If you are using the Website Interface front-end, make sure you copied the "extension/ezwebin/" directory. It is also possible to upgrade the Website Interface extension to a newer version (you can find more information and instructions in the "Upgrading the Website Interface" chapter of the Website Interface installation guide).
eZ Publish 3.10 has less translations than 3.9 releases because not all of the translation contributors have submitted a CLA yet. If you are using a multilingual site the possible workarounds in that case can be either to use the 3.9.x translations or to download translations from http://ez.no/developer/translations. It would also be highly appreciated if translators for existing translations send us the CLA so that we can include the translations in future 3.10 releases.
Due to some bugs in previous versions of eZ Publish (3.9.0 and others), it might happen that not all content objects in your database have unique remote IDs. This basically means that the "remote_id" column of the "ezcontentobject" table in the database might contain duplicate values. In eZ Publish 3.10.1, a database schema change was introduced in order to ensure that only unique remote IDs can be stored in this table. Because of this, you need to make sure that there are no content objects with identical remote IDs before upgrading the database. This can be done by running the "fixobjectremoteid.php" upgrade script. (Note that both the database schema change and the upgrade script were added to eZ Publish 3.9.5 and 4.0.1 as well.)
This script should be run once for each database, specifying one siteaccess per database. If you only have a public and an administration siteaccess that share the same database (which is the most typical/usual case), you only need to run the script for one of the siteaccesses. If the siteaccess isn't specified, the default siteaccess will be used.
The following example shows how to run the script:
Run the script (replace "example" with the actual name of your siteaccess):
php update/common/scripts/3.10/fixobjectremoteid.php -s example
The script will search for objects with non-unique remote IDs. Every time such an object is found, the script will suggest to either display more detailed information or fix the problem automatically. If you choose the first option, the script will display the list of objects that have the same remote ID and let you decide which one should remain unchanged; all other objects in the list will get new remote IDs. Otherwise, the script will fix the problem automatically based on the objects' creation dates. This means that the script will generate new remote IDs for all objects in the list except the one that was created first.
The optional "--mode" parameter makes it possible to run the script in either "auto-fix" or "manual-fix" mode as shown below.
php update/common/scripts/3.10/fixobjectremoteid.php -s example --mode=value
If you replace "value" with "a" in the command above, the script will automatically fix all non-unique remote IDs that are found in the database based on the objects' creation dates. In this case, no further input is required from the user. If you specify "--mode=d", the script will display the list of objects for each non-unique remote ID so that you can manually choose which objects should keep their remote IDs.
To upgrade a 3.9.x database to 3.10.1, navigate into the eZ Publish 3.10.1 directory and run the following database upgrade scripts one after another:
Note that some of the database changes from eZ Publish 3.9.0 to 3.10.0 have been included in other 3.9 releases. If you are upgrading from a version later than 3.9.0, it is recommended to skip some parts of the database upgrade scripts. These are marked with "from 3.9.z" comments in the ".sql" file; make sure you skip all sections with "z" less than or equal to the last digit in your current version number. For example, if you are upgrading from 3.9.3, skip sections marked with "from 3.9.1", "from 3.9.2" and "from 3.9.3" comments (if any).
The database upgrade scripts are located in the "update/database/mysql/3.10/" directory of your eZ Publish installation. Each of these scripts can be launched using the following shell command (replace "script_name" with the actual name of the script):
mysql -u <username> -p<password> <database> < update/database/mysql/3.10/script_name.sql
Note that the CREATE TABLE statements in the database upgrade scripts do not specify which storage engine to use (no ENGINE or TYPE option), and thus the default storage engine will be used. Normally, it is MyISAM (starting from MySQL v.3.23). If you are using InnoDB, make sure the default storage engine is set to InnoDB before you run the database upgrade scripts (refer to the MySQL documentation for information about how to set the default engine). If you were not able to change the MySQL configuration on your server, and the upgrade left you with a mix of table types, you can use the "bin/php/ezconvertmysqltabletype.php" script for database conversion. You can also convert the newly created tables individually by using the following SQL query for each table:
ALTER TABLE <name_of_table> TYPE = innodb;
The database upgrade scripts are located in the "update/database/postgresql/3.10/" directory of your eZ Publish installation. Each of these scripts can be launched using the following shell command (replace "script_name" with the actual name of the script):
psql -d <database> -U <dbowner> < update/database/mysql/3.10/script_name.sql
The 3.10 version of eZ Publish introduces a couple of new features. In order to make sure that your site is compatible with these features, you'll have to run a few upgrade scripts.
In eZ Publish 3.10.0, a new feature has been added that makes it possible to use multi-lingual virtual URLs. In eZ Publish 3.10.1, the multi-language support for URL aliases was substantially improved, along with some important bug fixes related to this functionality. In addition, the support for wildcard based URL forwarding was re-added and the default type of URL transformation was changed to "urlalias" in 3.10.1.
When upgrading from 3.9.x to 3.10.1, you need to specify the desired type of URL transformation using the "TransformationGroup" setting located in the [URLTranslator] section of an override for "site.ini" and run the "updateniceurls.php" script as described below. It is also possible to choose which word separator should be used in the URLs. This can be done by setting the "WordSeparator" configuration directive also located in the [URLTranslator] section to either "dash", "underscore" or "space". Note that this setting will be ignored when the "urlalias_compat" transformation is used (it only supports underscores as separators).
Before running the script, make sure that you have specified the same transformation settings for all siteaccesses that are using the same database. If all your siteaccesses are using the same database (which is the most typical/usual case), you can set the "TransformationGroup" and "WordSeparator" directives in "settings/override/site.ini.append.php". Otherwise, you will have to configure URL transformation from within "settings/siteaccess/example/site.ini.append.php" (where "example" should be replaced by the actual name of your siteaccess) for each siteaccess.
In addition, you must clear the INI cache before running the script, so that the system will re-read the changed configuration files.
The "updateniceurls.php" script should be run once for each database, specifying one siteaccess per database. If you only have a public and an administration siteaccess that share the same database, you only need to run the script for one of the siteaccesses. If the siteaccess is not specified, the default siteaccess will be used.
The following example shows how to run the script.
php bin/php/updateniceurls.php --import --fetch-limit=number -s example
Replace "example" with the actual name of the siteaccess and specify the desired number of items to handle per one iteration instead of "number". (The script will automatically do as many iterations as necessary to convert all the URLs, based on the number specified. If the optional "--fetch-limit" parameter is omitted, the script will handle 200 items per one iteration.)
The script will go through all content objects stored in the database and create new virtual URLs for them in accordance with the specified transformation settings. Old virtual URLs will be transferred to the new system and stored as history entries. (The "--import" parameter makes the script go through all entries in the "ezurlalias" database table, which was used for storing URL aliases in eZ Publish 3.9. As a result, old URL aliases will be imported to the "ezurlalias_ml" table, which is used for storing multilingual URL aliases in eZ Publish 3.10.)
Note that new URL aliases will be generated for all the languages of your site regardless if they are available or not for the specified siteaccess. The time it takes to update all URL aliases is proportional to the number of nodes on your site.
In eZ Publish 3.10, the handling of ISBN-13 numbers has been significantly improved (refer to the ISBN datatype documentation for details). The different ranges are now stored in the database, allowing the system to fix up incorrectly entered ISBN-13 codes (codes with misplaced or missing dashes). When a new version of eZ Publish is released, the latest information about the different ranges is downloaded from http://www.isbn-international.org/converter/ranges.js and stored in a ".dba" file. During the installation process, the setup wizard imports this information to the database. When upgrading, you need to import ranges to the database manually. This must be done even though your site does not use ISBN-13 numbers. You can either import ranges from the ".dba" file using the "ezimportdbafile.php" script or download the latest "range.js" file and run the "updateisbn13.php" script.
The following example shows how to import ranges from the ".dba" file:
php bin/php/ezimportdbafile.php --datatype=ezisbn -s example
The "datatype" parameter tells the script which datatype the data should be imported for.
The next example shows how to get the latest ranges from the ISBN International website:
php bin/php/updateisbn13.php --file=ranges.js
The script will import information from the "range.js" file to the database.
In order to use ISBN-13 numbers on your site after upgrading, you need to do the following:
php bin/php/ezconvert2isbn13.php -s example
The script will go through all content object attributes using the "ISBN" datatype in the database and convert their values into valid ISBN-13 numbers. The following table reveals the available options for this script.
| Option | Description |
|---|---|
| --class-id=value |
The script will only update attributes of content objects that belong to the specified class. You need to replace "value" with the actual ID number of the class. |
| --attribute-id=value |
The script will only update content object attributes that correspond to the specified content class attribute. You need to replace "value" with the actual ID number of the class attribute. |
| --all-classes |
The script will go through all content objects. |
| --force |
The script will update all attributes of the "ISBN" datatype regardless if the "ISBN-13 format" checkbox is enabled for the class attribute. It will also enable this setting at the class attribute level where it was previously disabled. |
These scripts should be run once for each database, specifying one siteaccess per database. If you only have a public and an administration siteaccess that share the same database, you only need to run the scripts for one of the siteaccesses. If the siteaccess is not specified, the default siteaccess will be used.
In eZ Publish 3.10, a new datatype called "Multi-option2" has been added in order to replace the old "Multi-option" datatype. The new datatype allows option selections and makes it possible to create multiple and distinctive groups of multi-options for each content object. In addition, it supports rules and provides a handful of new and interesting features. Note that the old "Multi-option" datatype is deprecated and should no longer be used (it will be removed in the future).
In order to be compatible with the new datatype, you will have to run the "updatemultioption.php" script. This script should be run once for each database, specifying one siteaccess per database. If you only have a public and an administration siteaccess that share the same database, you only need to run the script for one of the siteaccesses. If the siteaccess is not specified, the default siteaccess will be used.
The following example shows how to run the script:
php update/common/scripts/3.10/updatemultioption.php -s example
The script will go through all content object attributes that are using the old "Multi-option" datatype in the database. The content object attributes will be modified (converted) so that they use the new "Multi-option2" datatype.
The following table reveals the available options for this script.
| Option | Description |
|---|---|
| --all-classes |
The script will go through all types of content objects. |
| --contentclass=value |
The script will only update objects of the specified class. You need to replace "value" with the actual identifier of the class. |
Note: overridden templates of the public siteaccess for the "Multi-option" datatype will also need to be updated (manually).
From 3.10, users (typically those to which the anonymous role applies) need to have access to the "tipafriend" function of the "content" module in order to use the "Tip a friend" feature. Because of compatibility reasons, you need to run the "updatetipafriendpolicy.php" script.
Note: there is no need to run the script if you are upgrading from 3.9.3 or later versions (3.9.5 or later if you are running eZ Publish on Windows).
The following example shows how to run the script:
php update/common/scripts/3.10/updatetipafriendpolicy.php -s example_admin -l login -p password
Replace "example_admin" with the actual name of your admin siteaccess and use the administrator's login and password instead of "login" and "password".
The script will add a new role that grants access to the "Tip a friend" feature and ask for confirmation about assigning this role to each user or user group located one level beneath the "Users" top level node.
In eZ Publish version 3.10.0 - 3.10.1, the handling of country dependent VATs has been improved. Because of compatibility reasons, you need to run the "updatevatcountries.php" script.
Note: there is no need to run the script if you are upgrading from 3.9.5 or a later version.
The "updatevatcountries.php" script should be run once for each database, specifying one siteaccess per database. If you only have a public and an administration siteaccess that share the same database, you only need to run the script for one of the siteaccesses. If the siteaccess isn't specified, the default siteaccess will be used.
The following example shows how to run the script:
php update/common/scripts/3.10/updatevatcountries.php -s example
The script will go through all the VAT rules in the database and make them compatible with the newly introduced changes.
In eZ Publish version 3.9.4 and earlier versions, there is a bug in the "File" datatype which may cause problems with binary file uploading via WebDAV. The typical symptoms are that the file extension of the uploaded file is missing and that you may not be able to download the file once it is uploaded (refer to http://issues.ez.no/9450 for more information). The same bug exists in eZ Publish 3.10.0. This issue was fixed in eZ Publish 3.9.5, 3.10.1 and 4.0.0.
If your site has objects that were created by uploading files via WebDAV and you have configured MIME-type-to-class mapping using the "MimeClassMap[]" directive in an override for "upload.ini", you need to run the "updatebinaryfile.php" script in order to fix the file extensions. (If a content class does not have any attributes that make use of the "File" datatype, instances of this class are not affected.)
Note: there is no need to run the script if you are upgrading from 3.9.5 or a later version.
The "updatebinaryfile.php" script should be run once for each database, specifying one siteaccess per database. If you only have a public and an administration siteaccess that share the same database, you only need to run the script for one of the siteaccesses. If the siteaccess isn't specified, the default siteaccess will be used.
The following example shows how to run the script.
php update/common/scripts/3.10/updatebinaryfile.php -s example
The script will go through all the binary files and fix their extensions. The filename entries stored in the "ezbinaryfile" database table will be changed accordingly.
If your site makes use of the "urlalias" or "urlalias_iri" transformation method, read this part carefully. If you have specified "urlalias_compat" in the "TransformationGroup" configuration setting in step 3, skip this part.
After running the "updateniceurls.php" script in step 3, you need to review your configuration settings and update the URL aliases that are used in configuration files. For example, if your site makes use of the "PathPrefix" and "PathPrefixExclude" settings, this functionality might stop working if the specified URL aliases have changed (which will likely be the case because the virtual URLs are re-generated in accordance with the "TransformationGroup" and "WordSeparator" directives). Even though the old virtual URLs are stored as history entries and redirect to new ones when being accessed on the actual site, configuration settings do not work with URL history entries, i.e. you need to specify correct URL aliases there.
Also, you need to review the configuration settings in your "override.ini.append.php" file(s), otherwise your override templates activated by the "url_alias" condition will most likely stop working. For each line in the "override.ini.append.php" file that contains something like this:
Match[url_alias]=<virtual_url>
make sure that the correct virtual URL is specified.
Note that for multi-language sites, you need to specify URL aliases in the most prioritized language (controlled by the "SiteLanguageList" configuration array located under the "[RegionalSettings]" section of "site.ini.append.php").
In eZ Publish versions prior to 3.10, the left tree menu in the administration interface didn't scale very well (refer to the specifications for details). This has been substantially improved in 3.10.0. The newly added implementation is called "dynamic content structure menu". It makes use of the AJAX technology, which is supported by all modern browsers. The old implementation is still available and enabled after upgrading. It is however recommended to switch to the new implementation, specially for large sites with many nodes. This will make the tree menu work much faster and decrease the usage of network bandwidth. (Note that new sites created from scratch using the setup wizard will have "dynamic" tree menu in the administration interface.)
Note that eZ Publish 3.10.1 introduces some changes to the dynamic tree menu functionality. In particular, the "treemenu" view of the "content" module no longer makes use of parameters that are transferred using GET variables (this improves tree menu compatibility when running PHP in FastCGI mode; refer to http://issues.ez.no/11806 for more information).
If you want to use the new implementation of the tree menu, do the following:
[TreeMenu] Dynamic=enabled
It is possible to boost the performance of the dynamic tree menu by using the "index_treemenu.php" script. This can be done by instructing Apache to use "index_treemenu.php" instead of "index.php" when the treemenu view of the content module is requested. This is an optimized script that only takes care about a specific case and thus it works faster than the regular "index.php".
Note that due to a bug in eZ Publish 3.10.1, you need to download the updated version of "index_treemenu.php" from http://pubsvn.ez.no and replace the corresponding file in your installation. The same bug exists in eZ Publish 4.0.1.
Then, update your ".htaccess" file to make the system use "index_treemenu.php" when needed. This can be done by adding the following lines above the existing rewrite rules for eZ Publish:
RewriteRule content/treemenu/? index_treemenu.php RewriteRule index_treemenu.php - [L]
If no ".htaccess" file is used, it is strongly recommended to update the Apache configuration file. You can do this by adding the following line above the existing rewrite rules for eZ Publish:
RewriteRule content/treemenu/? /index_treemenu.php [L]
eZ Publish 3.10 comes with the Online Editor extension version 4.2.4 and later. In these versions, the "AnchorAsAttribute" setting located in the [header] section of the "extension/ezdhtml/settings/content.ini.append" configuration file is disabled by default (refer to http://issues.ez.no/11312 for more information). The above mentioned setting controls whether the usage of the deprecated "anchor_name" attribute for the "header" XML tag should be allowed or not. With the new default configuration, the Online Editor will automatically convert all occurrences of this attribute into separate "anchor" tags when you edit a site page. If XML content on your site is using this attribute and you want to keep the old behavior, enable the "AnchorAsAttribute" setting from within the "settings/override/content.ini.append.php" configuration file. (Do not edit "extension/ezdhtml/settings/content.ini.append"; this file is overwritten whenever you upgrade the extension.)
Whenever an eZ Publish solution is upgraded, all caches must be cleared in a proper way. This should be done from within a system shell:
php bin/php/ezcache.php --clear-all --purge
Purging allows to make sure the caches are physically removed. Without the "--purge" option, the caches will be expired but not removed.
Sometimes the script is unable to clear caches because of restrictive file/directory permission settings. Make sure that all caches have been cleared by inspecting the contents of the various cache subdirectories within the "var" directory (typically "var/cache/" and "var/<name_of_siteaccess>/cache/" directories). If there are caches left, you need to remove them manually.
Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2013 eZ Systems AS (except where otherwise noted). All rights reserved.