|
Author
|
Message
|
|
Christian Rößler
|
Friday 13 November 2009 8:12:18 am
hey community, i managed to wrap up a howto on how to update directly from 4.0.1 to 4.2.0 - without any need for those incremental updates. The howto is hosted on projects.ez.no, in the doc-project: http://svn.projects.ez.no/doc/incubator/croessler/update_ez401-420.txt cheers, Chris
Hannover, Germany
eZ-Certified http://auth.ez.no/certification/verify/395613
|
|
André R.
|
Thursday 19 November 2009 4:26:00 am
Cool! Some stuff: 1. updating to 4.0.4 or 4.0.4
Should be 4.0.4 or 4.0.7 ? first section about ez componets is a bit unclear, 1 you mention it before and after db update. 2. you refer to the ezc install doc and doesn't mention it is only needed if you don't go for the bundled package. You shouldn't link directly to the file imho, as the user might not want the bundled version and as there might be a 4.2.1 update at one point to update direclty to instead (ok, might not fly as it might have additional update steps compared to 4.2.0). Removing setunp and changing admin/site.ini.append.php only makes sense if you have plain install, on webin and flow there is different names for the admin siteaccess (and on custom install it can be named anything really). And the setup siteaccess isn't enabled by default, so no need to remove it. Other then that, thanks for sharing!! :)
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
Christian Rößler
|
Thursday 19 November 2009 5:59:24 am
Thank you for your feedback André. I have modified some parts of the doc and checked it in. Chris
Hannover, Germany
eZ-Certified http://auth.ez.no/certification/verify/395613
|
|
Gaetano Giunta
|
Thursday 19 November 2009 6:13:25 am
I think it misses the part about those ini settings that changed format between 4.0 and 4.2 - if they have not been put in siteaccess/override config files it's ok, otherwise they should manually be fixed...
Principal Consultant International Business
Member of the Community Project Board
|
|
Christoph von Siebenthal
|
Monday 21 December 2009 6:20:03 am
Really great. It helped me a lot. much more as the confusing www.ez.no instructions. One thing could be added so: chmod -R 770 var/ settings/ design/ autoload/ or chmod -R 777 var/ settings/ design/ autoload/ Afterward it was obvious. But as the only visible error message is: "No right to access this area..." I needed a couple of hours to find it.
By the way it's the occasion to tell that ez error messages often mislead me.
Last Week a .htaccess has been lost. If ez had written "wrong php version" I would have found it out quicker than with "error at line 106!" Perhaps I shall propose a little "if wrong php version than adequate message and die for the php.ini" file.
|
|
Maarten Holland
|
Monday 04 January 2010 3:18:34 am
Hello Christian, Just wanted to thank you for the clear instructions! The normal eZ Publish instructions drove me crazy after 3 unsuccesful tries to upgrade from 4.0.1 to 4.2.0. Your guide did the job in about 15 minutes! Thanks a lot for sharing! Maarten
|
|
Christian Rößler
|
Thursday 14 January 2010 5:48:35 am
Thanks for your reply's and feedback. Currently I encountered a small issue as stated here: http://issues.ez.no/IssueView.php?Id=15999 The howto has been updated right now and is available under the known url. @Gaetano: May you provide a link to more details of what you mean with '...settings that changed format...'? Seems I am missing important informations here...
@Christoph: Altering those folders (settings, design, autoload) to group and/or others writeable makes me really uncomfortable. I know the ezPublish admin-interface can set settings and activate extensions, but to do so it needs write and exec permission to several folders. I totally dislike that kind of behaviour. So i always manually change settings and activate extensions by altering configfiles via shell instead of using the gui.
But if you have a nive round-up and explanations of the advantages please be so kind to add some lines to the document by joining the doc-team and edit this howto. @Maarten: Thanks for your feedback. Indeed I made it for exactly this reason: to be able to upgrade in small site in about 15 minutes. Great it could help you... A current customers ezPublish is a really big one - all those database and php-scripts now need approx 45min's to complete. But it still works as expected. So besides some private eZPublish's this howto seems to work on bigger sites as well. As expected.
Cheers,
Chris
Hannover, Germany
eZ-Certified http://auth.ez.no/certification/verify/395613
|
|
Gaetano Giunta
|
Friday 15 January 2010 1:59:52 am
@Christian: you can find them in the file in doc/bc/4.1/ (at the bottom): image.ini file.ini package.ini
Principal Consultant International Business
Member of the Community Project Board
|
|
cliffp pratt
|
Sunday 26 September 2010 5:25:50 pm
Hi Christian, The upgrade notes for 4.0.x to 4.0.y have a step called URL Alias Migration which doesn't seem to be in your upgrade documents. Is this step needed? Cheers, Cliff
|
|
Christian Rößler
|
Monday 27 September 2010 12:16:57 am
"
Hi Christian, The upgrade notes for 4.0.x to 4.0.y have a step called URL Alias Migration which doesn't seem to be in your upgrade documents. Is this step needed? Cheers, Cliff
"
Cliff, URL-alias stuff is not needed when upgrading from eZP 4.0.1 or higher. It is described here: http://doc.ez.no/eZ-Publish/Upgrading/Upgrading-to-4.0/from-4.0.x-to-4.0.y As my howto covers upgrading from 4.0.1 to 4.2 the url-alias stuff is not mentioned. Again: url alias updates are only needed when upgrading from 4.0.0 . See also my descriptions in the howto: this howto is only for updates from 4.0.1 to 4.2.0. If you have other versions (source or target), you have to ensure to include and maintain a correct order of any scripts/statements i might not cover in my update procedures. There was also a thread in this forum covering update from 4.0.x to 4.3.x directly by adding a few sql-statements to this howto. good luck, chris
Hannover, Germany
eZ-Certified http://auth.ez.no/certification/verify/395613
|
|
cliffp pratt
|
Tuesday 28 September 2010 5:50:20 pm
Thanks for the clarification, Chris. The page to which you referred me has the following section under "Upgrading to 4.0.2" - "
URL Alias upgrade The 4.0.2 release expands on the work which was made to the URL alias system in 4.0.1. The fix to the URL alias system, changes the structure in which URL entries are stored. This means that the URL alias entries needs to be regenerated, as was the case when upgrading to 4.0.1." I must have misread this as it seems to imply that you need to re-do the URL Alias migration steps in going from 4.0.1 to 4.0.2. Thanks, Cliff
|
|
Christian Rößler
|
Wednesday 29 September 2010 12:16:50 am
I'm glad I could help Cliff. Indeed the update procedures as described on the official pages sometimes make no sense or are really complicated/frustrating formulated for an outsider (not being a kernel developer). I think you are fine the following ways: Upgrading from 4.0.0: Run the url-alias migration as described. This involves a urlaliasmigration extension and stuff. Upgrading from 4.0.1: It should be enough to update the url-aliases when done upgrading. I think this is done via "php bin/php/updateniceurls.php" - but check this first. You also can remove the extension "ezurlaliasmigration" introduced by the 4.0.0 upgrade. It is not needed anymore and only seems to ensure a proper migration. If i'm informed correctly. Regards, Christian
Hannover, Germany
eZ-Certified http://auth.ez.no/certification/verify/395613
|
|
cliffp pratt
|
Monday 04 October 2010 9:58:53 pm
Thanks Christian, I actually did the URL Alias migration stuff as part of the 3.10.x to 3.10.y upgrade where it is in a section called "Multilanguage support for URL aliases". I'm guessing that I only need to do it once, probably in the 3.10.x to 3.10.y steps. In the section I refer to there is a bit that says 'When upgrading from 3.10.0 to 3.10.1, these operations are exactly the same as when upgrading from version 4.0.0 to 4.0.1. Read the corresponding subsections of the "Upgrading from 4.0.x to 4.0.y" documentation page starting from "4. Create the migration table".' This gave me the idea that it is necessary to run it twice, once for 3.10.0 - 3.10.1 and once for 4.0.0 - 4.0.1. From what you say above I should be able to get away with running the update once in the 3.10.0 to 3.10.1 upgrade step and then just run the 'updateniceurls.php' script for each upgrade. Sorry, I should have mentioned before that I was upgrading from 3.8 but this thread is about 4.0.1 to 4.2.0 and I've learnt a lot from it. Many thanks, Christian.
|