ibexa

Path

ez publish / technical manual / 3.6 / installation / upgrading / from 3.6.x to 3.6.y


Caution: This documentation is for eZ Publish legacy, from version 3.x to 5.x.

from 3.6.x to 3.6.y

This section describes how to upgrade your existing eZ publish 3.6.x installation to version 3.6.y, for example from 3.6.0 to 3.6.11. If you are upgrading from a version prior to eZ publish 3.6.0, you should first upgrade to 3.6.0 as described in this section.

Please 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:

  1. Upgrading the distribution files to 3.6.11
  2. Upgrading the database to 3.6.11
  3. Running the system upgrade scripts
  4. Updating INI settings for "html" classification
  5. Clearing the caches

Step 1: Upgrading the distribution files

The easiest way to upgrade the distribution files is to unpack eZ publish 3.6.11 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:

  • design/example
  • design/example_admin
  • var
  • settings/siteaccess
  • settings/override

Replace "example" and "example_admin" with actual names used by your siteaccesses.

Custom extensions

If you are using custom extensions then 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 (for example the "PayPal" extension).

Step 2: Upgrading the database

To upgrade 3.6.0 database to 3.6.11, you should navigate into the eZ publish 3.6.11 directory and run the following database upgrade scripts one after another:

  1. dbupdate-3.6.0-to-3.6.1.sql
  2. dbupdate-3.6.1-to-3.6.2.sql
  3. dbupdate-3.6.2-to-3.6.3.sql
  4. dbupdate-3.6.3-to-3.6.4.sql
  5. dbupdate-3.6.4-to-3.6.5.sql
  6. dbupdate-3.6.5-to-3.6.6.sql
  7. dbupdate-3.6.6-to-3.6.7.sql
  8. dbupdate-3.6.7-to-3.6.8.sql
  9. dbupdate-3.6.8-to-3.6.9.sql
  10. dbupdate-3.6.9-to-3.6.10.sql
  11. dbupdate-3.6.10-to-3.6.11.sql

MySQL

The database upgrade scripts are located in the "update/database/mysql/3.6/" directory of your eZ publish installation. Each of these scripts can be launched using the following shell command:

mysql -u <username> -p<password> <database> < update/database/mysql/3.6/dbupdate-3.6.x-to-3.6.y.sql

PostgreSQL

The database upgrade scripts are located in the "update/database/postgresql/3.6/" directory of your eZ publish installation. Each of these scripts can be launched using the following shell command:

psql -d <database> -U <dbowner> < update/database/postgresql/3.6/dbupdate-3.6.x-to-3.6.y.sql

Step 3: Running the system upgrade scripts

There are currently no upgrade scripts for upgrading from 3.6.x to 3.6.y.

Step 4: Updating INI settings for "html" classification

In eZ publish versions from 3.6.5 to 3.6.10 it is possible to include HTML code in XML blocks by using the "html" classification. However, this feature can also be used to insert JavaScript code, making it possible for users with sufficient privileges to make an XSS exploit. This feature is therefore disabled by default in eZ publish 3.6.11 and later, and should only be enabled if you really trust your editors.

To enable html classification, add the following lines to your "content.ini.append.php" file:

[literal]
 # The class 'html' is disabled by default because it gives editors the
 # possibility to insert html and javascript code in XML blocks.
 # Don't enable the 'html' class unless you really trust all users who has
 # privileges to edit objects containing XML blocks.
 AvailableClasses[]=html

Step 5: Clearing the caches

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:

  1. Navigate into the eZ publish 3.6.11 directory.
  2. Run the clear cache script:
    bin/shell/clearcache.sh --clear-all
    

Please make sure that all caches are cleared. 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.

Svitlana Shatokhina (23/05/2006 10:03 am)

Julia Shymova (14/09/2007 10:50 am)

Svitlana Shatokhina, Julia Shymova


Comments

There are no comments.