This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal

eZ Community » Forums » General » Upgrading from 4.0 to 4.7
expandshrink

Upgrading from 4.0 to 4.7

Upgrading from 4.0 to 4.7

Thursday 30 August 2012 9:34:19 pm - 8 replies

Hi!

A potential client wants an update from a 4.0 install of eZ Publish, and we do not have any experience with solutions on eZP versions that old.

Activated extensions are:

ezwebin

ezodf

ezjaxx

ezdhtml 

 

and a custom module

 

In your experience, should we have big issues upgrading this version using regular update scripts. What are the risks? 

Appreciate any help as I need to get this potential client a realistic estimate on the upgrade happy.gif Emoticon

Thursday 30 August 2012 10:33:09 pm

My first question is - do you have any kernel hacks and/or is your design in ezwebin.  I don't think ezodf or ezdhtml will count much - unless you have custom stuff.  ezjaxx I'm not not familiar with.

ezwebin will be the hard part with the extensions - do you have other extensions that you use?  Do you have custom modules anywhere - they will have to be tweaked a bit with changes in i18n for example.

Otherwise, the url aliases will be difficult because they were broken until 4.1...

Otherwise, take a look at https://github.com/leidentech/ez-...l-tools/blob/master/convertscript.sh

this might help.

Edit: changed link to the github repo.

Modified on Tuesday 05 February 2013 8:21:00 pm by Steven E Bailey

Thursday 30 August 2012 10:48:31 pm

Quote from Steven E Bailey :

My first question is - do you have any kernel hacks and/or is your design in ezwebin.  I don't think ezodf or ezdhtml will count much - unless you have custom stuff.  ezjaxx I'm not not familiar with.

ezwebin will be the hard part with the extensions - do you have other extensions that you use?  Do you have custom modules anywhere - they will have to be tweaked a bit with changes in i18n for example.

Otherwise, the url aliases will be difficult because they were broken until 4.1...

Otherwise, take a look at http://www.leidentech.com/eng/content/download/667/2806/version/2/file/convertscript.sh this might help.

Thanks. This is entirely done by another company so I will have to dig deeper into your questions, but yes, the design is in ezwebin.

Friday 31 August 2012 10:04:58 am

HI.
I've done the same level of upgrades 4.0 to community 052012.  However, I did not have to use the extensions you have listed.

Here is my (probably obvious) word of caution:

Upgrade step by step and test as you go:

4.0->4.1 sql AND upgrade scripts

4.2->4.3 sql AND upgrade scripts

4.3->4.4 sql AND upgrade scripts

after 4.4, I believe you can more confidently step forward much faster.

Yes, there may be notes on a fater upgrade path from 4.0 - 4.4, but the above is not too bad to do (other than funny notes in the SQL because of an attempt to allow for larger steps in the upgrade.

 

SQL:

In relation to the SQL - run each one and ensure that it finishes.  There are duplications in some of the alter/create statements(by design fr easier).  This includes running the script until an ettor (table exists or column extsts, etc) and then removing (well, commenting them out) the consumed lines in the file and running again.

SCRIPTS:

The upgrade scripts at each step are extremely important at every step as some items fix errors that are assumes to be fixes when you move further on.

DESIGN TAB:

If you have people using the design tab (toolbars), they will be missing by default upon upgrade(4.3 and beyond, I believe).  The tab can be added back in.  However, there are much more elegant solutions for toolbars now (like ezflow , for example), so consider replacing toolbar functionality with an alternaive solution. Example: we use a content class that is nothing but a holder for ezflow. The we build a toolbar as a subcontent item and then the logic is similar to using a  toolbar.

REWRITE RULES:

Rewrite rules will surely need to be changes as you move through the versions.  This is a definate fact in regards to the admin2 user interface, for example (ezJScore).

TEST AS YOU GO:

In general, at each step, make sure you have a working version in between each upgrade(cache, etc).  That way, of there are issues, you don't need to try to figure out which of the 5 sql scripts or 20 upgrade scripts broke something.

 

I am probably making it sound more scary than it is - and someone else will probably suggest a much faster approach.  I just prefer being a bit cautions as there are soo amny tlittle thinsg to consider (reqrite, settings, sql, scripts).

Regards,

David

Friday 31 August 2012 11:21:08 am

Thanks David, love your input!

I have to be very open with the client here and make sure he understands that there could be issues as we do the upgrade, and that this could cause some tuning and take more time than usual upgrades.

thanks again!

Saturday 01 September 2012 3:32:45 pm

When I upgrade eZ, I start by checking my eZ installation.

Setup > Upgrade check and check both the filesystem and database for consistency with the currently running version.

  These checks will tell you whether eZ has been customized, or if it is running 'out of the box'. Differences may arise if patches were applied, or if a previous upgrade was incomplete, so check any reported issues carefully.

  You can expect the .ini files to be different, they will be preserved or updated during the upgrade.

Plan the upgrade

  ** Notify site editors and administrators that an upgrade has been scheduled.  Overriding the admin login template is a nice method.  You can also send emails.  Give them the start time and expected end time.

  I start here: http://doc.ez.no/eZ-Publish/Upgrading, and scroll down to the existing version.  For each upgrade step, I copy out the text from the site into a text file. 

  I don't install interim versions of eZ.  I install the final target version, with the understanding that the system will not run until all the upgrade steps have been completed.  I don't try to access the application until all the steps have been completed.  That said, if any script throws an error, I refer to the URL in the text file and review that step, as well as the previous ones, to resolve the issue.  This strategy has worked well for me.

  Each step has the URL where the steps came from, an the steps, in order, exactly as they would be typed on the command line:

  This is from an upgrade from 4.2 to 4.7/Community edition:

 Extract the 4.7 tar (this means install the new version of eZ in a new directory and copy files you backed up into it)
 Extract the reCaptcha (any extensions - check for version conflicts)

 You can make a copy of your database, or upgrade on the database in use.  That's why a backup is important.
 
 http://doc.ez.no/eZ-Publish/Upgrading/Upgrading-to-4.3/Upgrading-from-4.2.x-to-4.3.x
 
 RewriteRule ^/var/([^/]+/)?cache/(texttoimage|public)/.* - [L]
 
 update/database/mysql/4.3/dbupdate-4.2.0-to-4.3.0.sql
 
 http://doc.ez.no/eZ-Publish/Upgrading/Upgrading-to-4.4/Upgrading-from-4.3.x-to-4.4.x
 
 update/database/mysql/4.4/dbupdate-4.3.0-to-4.4.0.sql
 
 Upgrading from eZ Publish Community Project 4.2011 to 2011.5
 
 http://doc.ez.no/eZ-Publish/Upgrading/Upgrading-to-4.5/Upgrading-from-4.4-to-4.5
 
 update/database/mysql/4.5/dbupdate-4.4.0-to-4.5.0.sql
 
 [DatabaseSettings]
 DatabaseImplementation=ezmysqli
 
 php update/common/scripts/4.5/updatesectionidentifier.php -s site
 
 http://doc.ez.no/eZ-Publish/Upgrading/Upgrading-to-4.6/Upgrading-from-4.5-to-4.6
 
 update/database/mysql/4.6/dbupdate-4.5.0-to-4.6.0.sql
 
 php update/common/scripts/4.6/removetrashedimages.php
 php update/common/scripts/4.6/updateordernumber.php
 
 Upgrading from eZ Publish Community Project 2012.2 to 2012.3
 
 SET storage_engine=InnoDB;
 UPDATE ezsite_data SET value='4.7.0beta1' WHERE name='ezpublish-version';
 UPDATE ezsite_data SET value='1' WHERE name='ezpublish-release';
  
 ALTER TABLE ezcontentobject_attribute MODIFY COLUMN data_float double DEFAULT NULL;
 ALTER TABLE ezcontentclass_attribute MODIFY COLUMN data_float1 double DEFAULT NULL;
 ALTER TABLE ezcontentclass_attribute MODIFY COLUMN data_float2 double DEFAULT NULL;
 ALTER TABLE ezcontentclass_attribute MODIFY COLUMN data_float3 double DEFAULT NULL;
 ALTER TABLE ezcontentclass_attribute MODIFY COLUMN data_float4 double DEFAULT NULL;

Take the system offline

  I use a special subdomain - down.domain.com, with a page that returns a 503 for search engines and text for people. 

  .htaccess file:

 RewriteEngine On
 RewriteRule .* http://down.domain.com/index.php [L]

  PHP file:

<?php header('Status: 503'); ?><!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 
<!-- remainder of file content here -->

*** Make a backup ***

  Be sure you include all extensions and settings.

echo 'Database (enter the password)'
mysqldump -p -udatabase_ez database_ez > backup.sql
echo www
cd www
echo var directory
tar czf ../var.tgz --exclude=var/cache
 --exclude=var/site/cache --exclude=var/mobile/cache var
echo design
tar czf ../design.tgz design/base design/site design/mobile
echo settings
tar czf ../settings.tgz settings/siteaccess settings/override extension/recaptcha/settings
echo .htaccess
cp .htaccess ..
echo manifest.appcache
cp manifest.appcache ..
echo Done

  The action at this point is to assess whether to install a new version of eZ over the old one, or preserve any customization.  Usually, there's no issue and you can just place a new version of eZ on the system.

  At this point, you have a nice clean backup of the site.  This is extremely important.

  If the upgrade cannot be completed, the data in the backup will be restored.  Thus, it's better to delay the backup until right before the upgrade.

  You can decide whether you want to do the upgrade in place, on the server eZ is installed on, or copy the site to a development server and do it there.  Either way, the site should be off-line during the upgrade.

  Both the site and admin interfaces must be blocked.

  This ensures the backup remains current.

Upgrade

  Carefully cut and paste the commands from the text file to the command line.

  Read the output carefully.  Resolve any issues as they arise.

Test

  Check the site thoroughly to ensure it is functioning properly.

  Use Setup > Upgrade check in the admin console.

  Restore the admin login template if it was modified

Bring the site on line

Keep the backup

Keep the eZ installation current, watch for security updates/warnings.  It is easier to upgrade through one or two versions than 5 or more.

Most upgrades take me six to eight hours, and there are usually no issues.

Modified on Saturday 01 September 2012 3:40:33 pm by Betsy Gamrat

Thursday 29 November 2012 12:43:04 pm

Hi All,

I have problem with .htaccess file.

I have upgraded eZ-Publish from 4.3 to 4.6 and my .htaccess stops working after upgradtion.

After R&D i got read your post that "

REWRITE RULES:

Rewrite rules will surely need to be changes as you move through the versions.  This is a definate fact in regards to the admin2 user interface, for example (ezJScore).

"

Can you please tell me why we need to change .htaccess? ( i want to know why the previous working.htaccess rules are not worked in upgraded version?)

And what should we have done the changes in .htaccess so it can work properly as before?

It is grate if you can help me in this, as i am stuck on my .htaccess from past 7 days and still cant find any solution.

Thursday 29 November 2012 3:14:36 pm

Here is my generic rewrite rules that probably work thorugh 4.7 well enough (definitely communuty 201205):

Some items to note:

  • There are lots of flavours out there  - even some 2-line versions that work using a different approach.
  • Your server setup may have some other odd changes needed:
    • RewriteBase
    • Maybe Rules starting like this example:
     RewriteRule /api/
    • Or Maybe rules starting like this example:
     RewriteRule ^api/
    • Plus, maybe the ForceVirtualHost Ini settings needs changing
    • As for your question about what needs to change: as an example, the newer admin interface uses javascript to show the children content. You will know this is not working because there will be a count of children, but none showing.. The actual subtle change for this is about allowing javascripts from extensions, I believe.
    • Depending on serve rsetup, its also possible to get an infinite loop of redirecting.. Thats another issue and solvable with a RewriteCondition just before the index.php rewrite

How do you troubleshoot rewrite issues?  well, I open the web developer tools (firebug or native in Chrome) and look at the fetches for the page.. Anything RED is bad.. look at where the script is trying to go and see what rewrite rule should be dealing with it.  NOte: earlier versions of eZ Publish gave a 200 OK even for module not found(common error with bad rewrites), so sometimes you can find this with viweing the response for the javascript requests (instead of a web page you get HTML). In newer versions, module not found throws a 400 response code, so the issue stands out well in the developer tools)

    RewriteRule ^/api/ index_rest.php [L]
     RewriteRule ^/index_rest\.php - [L]
     RewriteRule ^([^/]+/)?content/treemenu.* index_treemenu\.php [L]
     RewriteRule ^/var/([^/]+/)?storage/images(-versioned)?/.* - [L]
     RewriteRule ^/var/([^/]+/)?cache/(texttoimage|public)/.* - [L]
     RewriteRule ^/design/[^/]+/(stylesheets|images|javascript)/.* - [L]
     RewriteRule ^/share/icons/.* - [L]
     RewriteRule ^/extension/[^/]+/design/[^/]+/(stylesheets|flash|images|lib|javascripts?)/.* - [L]
     RewriteRule ^/packages/styles/.+/(stylesheets|images|javascript)/[^/]+/.* - [L]
     RewriteRule ^/packages/styles/.+/thumbnail/.* - [L]
     RewriteRule ^/var/storage/packages/.* - [L]
 
     RewriteRule ^/favicon\.ico - [L]
     RewriteRule ^/design/standard/images/favicon\.ico - [L]
     RewriteRule ^/robots\.txt - [L]
 
     RewriteRule .* /index\.php

 

Friday 30 November 2012 8:33:36 am

HI David,

Thanks for your help.

We have modified our rules in .htaccess file and they are working now.

We are still doing changes in .htaccess file so all the urls can work.

If i have any confusion regarding .htaccess or upgrade i will get back to you.

Thanks for your support and help.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from