How to upgrade from Jahia 5.0.x to Jahia 5.0.4
This document explains how to upgrade from Jahia 5.0 to Jahia 5.0 SP4.
Basically, if you have a jahia version under 5.0.2, you need first to execute some sql scripts in order to upgrade your database to Jahia 5.0 SP2.
Then, whichever is your starting version you need to setup a separate installation of Jahia 5.0 SP4, then recover from your existing Jahia 5.0.x the data, content and specific setup you may have made (connection to LDAP server, fine tuning, additional libraries required by your templates, etc).
You will finally need to run some patches from the Jahia administration center to update your existing database. The following procedure should get you up and running.
Start at appropriate section depending on your current Jahia version, and then follow each section one by one until last one. You can click on the titles to expand the sections.
How to upgrade from Jahia 5.0.0 to Jahia 5.0.1
You need to create 2 additional tables in your existing 5.0.0 database. Connect to your database server with a tool that allows you to run a sql query on it, and execute the following commands:
For Microsoft SQL Server :
ALTER TABLE CUSTOM_PORTLET_MODE DROP CONSTRAINT CUSTOM_PORTLET_MODE_FK_1;
CREATE TABLE CUSTOM_PORTLET_MODE
(
ID INT NOT NULL,
APPLICATION_ID INT NOT NULL,
CUSTOM_NAME NVARCHAR (150) NOT NULL,
MAPPED_NAME NVARCHAR (150) NULL,
DESCRIPTION NTEXT NULL,
CONSTRAINT CUSTOM_PORTLET_MODE_PK PRIMARY KEY(ID));
ALTER TABLE CUSTOM_WINDOW_STATE DROP CONSTRAINT CUSTOM_WINDOW_STATE_FK_1;
CREATE TABLE CUSTOM_WINDOW_STATE
(
ID INT NOT NULL,
APPLICATION_ID INT NOT NULL,
CUSTOM_NAME NVARCHAR (150) NOT NULL,
MAPPED_NAME NVARCHAR (150) NULL,
DESCRIPTION NTEXT NULL,
CONSTRAINT CUSTOM_WINDOW_STATE_PK PRIMARY KEY(ID));
For MySQL :
drop table if exists CUSTOM_PORTLET_MODE;
CREATE TABLE CUSTOM_PORTLET_MODE
(
ID MEDIUMINT NOT NULL,
APPLICATION_ID MEDIUMINT NOT NULL,
CUSTOM_NAME VARCHAR(150) NOT NULL,
MAPPED_NAME VARCHAR(150),
DESCRIPTION MEDIUMTEXT,
PRIMARY KEY(ID),
FOREIGN KEY (APPLICATION_ID) REFERENCES PORTLET_APPLICATION (APPLICATION_ID)
ON DELETE CASCADE
);
drop table if exists CUSTOM_WINDOW_STATE;
CREATE TABLE CUSTOM_WINDOW_STATE
(
ID MEDIUMINT NOT NULL,
APPLICATION_ID MEDIUMINT NOT NULL,
CUSTOM_NAME VARCHAR(150) NOT NULL,
MAPPED_NAME VARCHAR(150),
DESCRIPTION MEDIUMTEXT,
PRIMARY KEY(ID),
FOREIGN KEY (APPLICATION_ID) REFERENCES PORTLET_APPLICATION (APPLICATION_ID)
ON DELETE CASCADE
);
For PostgreSQL :
DROP TABLE CUSTOM_PORTLET_MODE CASCADE;
CREATE TABLE CUSTOM_PORTLET_MODE
(
ID INTEGER NOT NULL,
APPLICATION_ID INTEGER NOT NULL,
CUSTOM_NAME VARCHAR(150) NOT NULL,
MAPPED_NAME VARCHAR(150),
DESCRIPTION TEXT,
PRIMARY KEY (ID)
);
DROP TABLE CUSTOM_WINDOW_STATE CASCADE;
CREATE TABLE CUSTOM_WINDOW_STATE
(
ID INTEGER NOT NULL,
APPLICATION_ID INTEGER NOT NULL,
CUSTOM_NAME VARCHAR(150) NOT NULL,
MAPPED_NAME VARCHAR(150),
DESCRIPTION TEXT,
PRIMARY KEY (ID)
);
For Oracle :
DROP TABLE CUSTOM_PORTLET_MODE CASCADE CONSTRAINTS;
CREATE TABLE CUSTOM_PORTLET_MODE
(
ID NUMBER(10,0) NOT NULL,
APPLICATION_ID NUMBER(10,0) NOT NULL,
CUSTOM_NAME VARCHAR2(150) NOT NULL,
MAPPED_NAME VARCHAR2(150),
DESCRIPTION VARCHAR2(2000)
);
ALTER TABLE CUSTOM_PORTLET_MODE
ADD CONSTRAINT CUSTOM_PORTLET_MODE_PK
PRIMARY KEY (ID);
DROP TABLE CUSTOM_WINDOW_STATE CASCADE CONSTRAINTS;
CREATE TABLE CUSTOM_WINDOW_STATE
(
ID NUMBER(10,0) NOT NULL,
APPLICATION_ID NUMBER(10,0) NOT NULL,
CUSTOM_NAME VARCHAR2(150) NOT NULL,
MAPPED_NAME VARCHAR2(150),
DESCRIPTION VARCHAR2(2000)
);
ALTER TABLE CUSTOM_WINDOW_STATE
ADD CONSTRAINT CUSTOM_WINDOW_STATE_PK
PRIMARY KEY (ID);
For HyperSonic :
drop table CUSTOM_PORTLET_MODE if exists;
CREATE TABLE CUSTOM_PORTLET_MODE
(
ID INTEGER,
APPLICATION_ID INTEGER,
CUSTOM_NAME VARCHAR (150),
MAPPED_NAME VARCHAR (150),
DESCRIPTION VARCHAR,
PRIMARY KEY(ID)
);
drop table CUSTOM_WINDOW_STATE if exists;
CREATE TABLE CUSTOM_WINDOW_STATE
(
ID INTEGER,
APPLICATION_ID INTEGER,
CUSTOM_NAME VARCHAR (150),
MAPPED_NAME VARCHAR (150),
DESCRIPTION VARCHAR,
PRIMARY KEY(ID)
);
Make sure the tables are correctly created in the database.
How to upgrade from Jahia 5.0.1 to Jahia 5.0.2
You need to delete some attributes not used anymore in the jahia_link table.
ALTER TABLE jahia_link DROP COLUMN status;
ALTER TABLE jahia_link DROP COLUMN creation_date;
ALTER TABLE jahia_link DROP COLUMN creation_user;
ALTER TABLE jahia_link DROP COLUMN lastmodif_date;
ALTER TABLE jahia_link DROP COLUMN lastmodif_user;
You also need to drop some constraints in your database. Connect to your database server with a tool that allow you to run a sql query on it, and execute the following commands.
For Oracle, PostgreSQL and Microsoft SQL Server :
ALTER TABLE jahia_sl2_binding DROP CONSTRAINT fkab79b8e923e1f4c2;
ALTER TABLE jahia_sl2_binding DROP CONSTRAINT fkab79b8e94605c954;
ALTER TABLE jahia_sl2_locks DROP CONSTRAINT fk53da340c22ea3034;
ALTER TABLE jahia_sl2_locks DROP CONSTRAINT fk53da340c33924d02;
ALTER TABLE jahia_sl2_locks DROP CONSTRAINT fk53da340c69f368a3;
ALTER TABLE jahia_sl2_locks DROP CONSTRAINT fk53da340cfcf9e20f;
ALTER TABLE jahia_sl2_parent_binding DROP CONSTRAINT fk21da510c23e1f4c2;
ALTER TABLE jahia_sl2_parent_binding DROP CONSTRAINT fk21da510c603f6ee2;
ALTER TABLE jahia_sl2_version_history DROP CONSTRAINT fkb5a4b691454fef2;
ALTER TABLE jahia_sl2_version_history DROP CONSTRAINT fkb5a4b69123e1f4c2;
ALTER TABLE jahia_users DROP CONSTRAINT fkc1adc5327a6024d5;
ALTER TABLE jahia_site_prop DROP CONSTRAINT fkc9188385fcf86241;
ALTER TABLE jahia_sites_users DROP CONSTRAINT fkea2bf1bf6496a1b8;
For MySQL :
ALTER TABLE jahia_sl2_binding DROP FOREIGN KEY fkab79b8e923e1f4c2;
ALTER TABLE jahia_sl2_binding DROP FOREIGN KEY fkab79b8e94605c954;
ALTER TABLE jahia_sl2_locks DROP FOREIGN KEY fk53da340c22ea3034;
ALTER TABLE jahia_sl2_locks DROP FOREIGN KEY fk53da340c33924d02;
ALTER TABLE jahia_sl2_locks DROP FOREIGN KEY fk53da340c69f368a3;
ALTER TABLE jahia_sl2_locks DROP FOREIGN KEY fk53da340cfcf9e20f;
ALTER TABLE jahia_sl2_parent_binding DROP FOREIGN KEY fk21da510c23e1f4c2;
ALTER TABLE jahia_sl2_parent_binding DROP FOREIGN KEY fk21da510c603f6ee2;
ALTER TABLE jahia_sl2_version_history DROP FOREIGN KEY fkb5a4b691454fef2;
ALTER TABLE jahia_sl2_version_history DROP FOREIGN KEY fkb5a4b69123e1f4c2;
ALTER TABLE jahia_users DROP FOREIGN KEY fkc1adc5327a6024d5;
ALTER TABLE jahia_site_prop DROP FOREIGN KEY fkc9188385fcf86241;
ALTER TABLE jahia_sites_users DROP FOREIGN KEY fkea2bf1bf6496a1b8;
If your MySQL instance is case-sensitive, you may need to use uppercase for the constraints names.
How to upgrade from Jahia 5.0.2 or Jahia 5.0.3 to Jahia 5.0.4
-
New Jahia installation
-
Shutdown the existing Jahia instance.
-
Copy or uncompress Jahia 5.0 SP4 to a separate directory from the one where your existing Jahia server is deployed. Before running the configuration wizard, copy a packaged set of templates containing the same templates as the ones used in your existing Jahia server install to tomcat/webapps/jahia/WEB-INF/var/shared_templates/ . This will allow you to deploy during the configuration wizard the same templates that you are currently using on your Jahia server.
-
Run the configuration wizard. During the database setup, point to a SEPARATE database than the one currently used by your Jahia server. For instance, if the database used by your current Jahia server is named "jahia5", create in your database server a new database named "jahia5_temp".
When presented with the screen to create the initial web site, enter the same name as your existing Jahia site (or main site if you have several Jahia sites) and chose the same template set. Finish the configuration wizard and make sure you can access the home page. -
Shutdown the Jahia 5.0 SP4 instance.
-
If you are not using database content storage for the bigtext files and files uploaded in the files repository of Jahia, copy the directory tomcat/webapps/jahia/WEB-INF/var/content/ from your current Jahia install to the 5.0.4 install.
-
Copy the template sets used for each existing virtual site from tomcat/webapps/jahia/jsp/jahia/templates to the same directory of Jahia 5.0.4.
-
For each templates set that have been deployed on your Jahia server, you also need to copy or merge if you edited them, the resource bundles located in tomcat/webapps/jahia/WEB-INF/classes/jahiatemplates/ and tomcat/webapps/jahia/WEB-INF/classes/. Copy all the ".properties" files specifics to your set of templates from your current Jahia server, and reapply on the ".properties" files in your new Jahia 5.0 SP4 server the modifications you had done on same files.
-
Changes have been made to the corporate portal templates V2 (the set of templates packaged with Jahia). Lots of improvements have been made, so we encourage you to check the differences between the sets packaged with Jahia 5.0.0 or Jahia 5.0.1 or Jahia 5.0.2 and Jahia 5.0.3 and to port them in your set of templates. You can find the details of the differences:
- Corporate portal templates V2: diff from
Jahia
5.0.0,
Jahia
5.0.1,
Jahia
5.0.2,
Jahia
5.0.3
Here are the mandatory diff from Jahia 5.0.0 or a Jahia 5.0.1.
- Corporate portal templates V2: diff from
Jahia
5.0.0,
Jahia
5.0.1,
Jahia
5.0.2,
Jahia
5.0.3
-
If you have deployed some web applications in your existing installation, copy each of them from tomcat/webapps/ to the same directory in your new Jahia 5.0 SP4 server.
-
Search indexation should be performed on the new install after the migration is complete, as changes in the way the indexation is made have been implemented between Jahia 5.0 SP3 and Jahia 5.0 SP4. However you can recover the content of the tomcat/webapps/jahia/WEB-INF/var/fileextraction directory and copy it to the 5.0 SP4 install. That way the search engine won't need to read again the content of all uploaded files (MS Office and PDF documents) when re-indexing.
-
If you have modified some configuration files (LDAP connection, fine tuning, taglibs definitions, etc...), you need to port your changes to the equivalent configuration files of Jahia 5.0 SP4. Do not overwrite with the old version as we may have done some structural changes to some of them, added some new properties, or modified some default values to optimize performances.
If you have a cluster environment with one ore more dedicated indexing servers, then there is a new important configuration, which is described here. -
If you have modified some Jahia engines, you also need to port these changes to the Jahia 5.0 SP4 engines. Make sure in this case that you modify the web.xml of Jahia to comment all pre-compiled JSPs that you have changed.
-
Finally, connect your 5.0 SP4 migrated install to the existing database. For this you need to edit the file jahia.xml located in /tomcat/conf/Catalina/localhost.
Change the url attribute of both jdbc/jetspeed and jdbc/jetspeedNonTx tags to point to the database used with former Jahia server. -
Launch your new jahia, go to the administration center, server settings and click on the patch management icon.
Actually this patch management covers the migration from 5.0 SP2, so you should put 17724 as the build number if your previous Jahia version has not been automatically detected.
-
It is important to communicate to your end-user that they will need to flush their browser cache in order to be sure to have the latest version of the javascripts used in Jahia when upgrading.
-
If your are using the Jahia Cache Server (ESI), you should also upgrade it to the corresponding release of the Jahia Service Pack. It is available in the download area of the jahia.org web site.
-
If you have a system with large load, you should check the performance tuning guide available with this release.
Copy of previous Jahia installation
Fix your templates
Optimize your new Jahia