I’m trying to update a customers oxid shop from version 4.4.8 to 4.8.3 and started with the cumulative update package 4.4.8 to 4.6.8 but it seems to fail in the beginning.
I have to admit that I’m relatively new to the oxid shop system but I read the documentation and the guides about how to update.
Here are the steps I did during the whole update process:
- The database and the shop folder have been copied to my own server in order to create a safe sandbox for the update.
- The config.inc.php file has been adapted to the new environment
- The shop has been roughly tested to ensure that everything still works
- According to the update guide the content of “copy_this” (from the update package) has been copied to the root folder of the shop.
- The config file has been adapted again to match the new version from the “changed_full” folder.
- The new .htaccess file from “changed_full” has been copied to the root folder
- The “updateApp” folder has been copied to the shop folder
- The update has been started vie <sitename>/updateApp
Right after starting the update the first error appeared:
Error: script did not finish successfully.
Please check oxupdatetrack database table for executed actions.
The “oxupdatetrack” table has one entry with the following data:
oxid: 1
oxtime: timestamp when the update started
oxrev: 34028
oxpendingstep: setShopTheme
oxdata: BLOB with content “i:0;”
It seems like the update has a problem with the theme.
I noticed that my customer uses an modified theme called “stemp_theme” which is being set in the old config file using:
$this->sTheme = ‘stemp_theme’;
A similar line was missing in the new config file so I added it manually.
Additionally I checked the log/EXCEPTION_LOG.txt file which has many entries. For example the first exception points out that a table is missing a column:
oxConnectionException-oxException (time: 2014-02-13 05:45:18): [1054]: mysql error: [1054: Unknown column ‘oxmodule’ in
’where clause’] in EXECUTE (select oxvarname, oxvartype, DECODE( oxvarvalue, ‘fq45QS09_fqyx09239QQ’) as oxvarvalue fro
m oxconfig where oxshopid = ‘oxbaseshop’ and oxmodule=’’ , ) with user chris
Which could mean that the database has not been altered correctly during the update.
I also noticed when I reload the updateApp page several times that suddenly the update catches up and starts to continue. Somehow it’s even possible to complete the update until the end but when I try to open the site it tells me that the shop is offline. A logon to the admin backend is also not possible.
Any ideas what I could try next?
Hi codeslayer,
if I remember right, you can update the database only in this step. IMO it is necessary to connect completely new shop files to this database.
Also, I’d try to run the updateApp file in the terminal to get even more and useful error messages.
I suggest that you disable all modules and set the theme to a default theme before update. Probably neither the theme nor the modules will work in 4.6. Next verify the shop is 100% Standard with oxchkversion.
The documentation suggests to do the changes in changed_full after applying updateApp, not before, so i would try this first and only if this doesn’t work apply the changes before updateApp. When you apply changed_full, you need all files from it, not only htaccess and config.inc.php (You can just copy the other files because you verified your Shop is standard before). If the shop is in a subdirectory, you need to change htaccess rewriteBase.
If the updateApp fails, i would suggest not to reload with F5, instead restore the DB from Backup and start updateApp again by typing the Url and pressing Enter.
After update, you can recreate the theme and get new versions of the required modules.
Hi,
first of all I want to thank you for your help.
I followed your instructions:
- disabled all modules
- Changed theme to basic ($this->sTheme = ‘basic’; in config.inc.php)
- Verified that shop still works
- Started updateApp
Now the effect was actually the same. I got the same error message in the beginning. After recalling /updateApp 2 or 3 times I got carried over the initial error and the update continued suddenly (asking question and so on). I answered all questions with “yes”.
After the update the shop was basically in a running state except the articles listing. This appears to be broken so I activated smarty logging (debug level 1). Thy system complains about missing column(s). It seems that the new table [B]oxv_oxarticles[/B]_de is missing all columns which start with [B]oxupdateprice*[/B] and also the column [B]oxisdownloadable[/B] is missing.
This table probably gets modified during the update but for some reason the new columns have not been added.
Now I wonder if it’s possible to recreate the missing columns manually in the database or if they get filled with values during the update. Does that make sense?
If that columns are empty and just need to be there I would only need the types of that missing attributes or the SQL statement which modifies that table.
What I would like to mention is that oxchkversion.php reported nearly every file as “modified” but the reason for that might be that somone who installed that shop polluted the files with CR+LFs in Windows (or during FTP transfer) instead of leaving them in the original state.
oxv_oxarticles_de is a database view created from oxarticles. So you can look in oxarticles for the missing columns and if the are present you need to recreate views in backend (system/tools). If not, look for the SQL in the update package, execute it manually and then recreate the views.
As advised I tried out to run the update from the command line using “php5 run_cli.php” to see what exactly happens. Now I realised that the update script has problems to include the config.inc.php file which is quite elementary.
I get the following error/warning:
[Note:][exec:] rev: 34028 action: checkDBViewPermistions
-----
[Note:][exec:] rev: 34028 action: setShopTheme
PHP Warning: include(../../../config.inc.php): failed to open stream: No such file or directory in /home/chris/public_html/stempelmuehle.host42.com/updateApp/updates/php/34028.php on line 28
PHP Warning: include(): Failed opening '../../../config.inc.php' for inclusion (include_path='.:/usr/share/php:/usr/share/pear:/home/chris/public_html/stempelmuehle.host42.com/updateApp/core/../../') in /home/chris/public_html/stempelmuehle.host42.com/updateApp/updates/php/34028.php on line 28
PHP Notice: Undefined property: ConfOptions::$sTheme in /home/chris/public_html/stempelmuehle.host42.com/updateApp/updates/php/34028.php on line 1394
PHP Notice: Undefined property: ConfOptions::$sCustomTheme in /home/chris/public_html/stempelmuehle.host42.com/updateApp/updates/php/34028.php on line 1397
-----
[Note:][exec:] rev: 34028 action: requestTemplatesFilesStructureUpdate
--------------------------------------
Updating templates structure
Do you want to move the existing templates into the new template structure of the theme "Basic"?<br><br><span style='font-size:11px; color: #900;'>(Please backup the existing templates. The script will change the templates of the template set "Basic". If this templates were customized, please check the template documentation /templ_docu/index.html.)</span>
[1] Yes
[2] No
[please choose:]
Still the shop system runs quite well before the update and I even set the theme to ‘basic’ to avoid any template related problems.
The config.inc.php file is in the root of the oxid shop structure and all settings (db, paths, etc.) are correct - otherwise the site would not run properly.
I assume I have to sort out the described problem first before I continue to run the update.
Any idea what causes the trouble?
Should I modify the include path in:
updateApp/updates/php/34028.php
…to an absolute value?
Yes, or you could try just include(“config.inc.php”); which should also work because the shop base path is already in include_path.
Thank you for the hint. I tried this out and it seems to work and carried me over the fisrt steps of the update process.
Anyway some new php warnigs and notices popped up.
At the step:
[Note:][exec:] rev: 34028 action: updateMultilingualFields
I received a bunch (about 450 lines) of warnings of this type:
PHP Warning: Cannot modify header information - headers already sent by (output started at /home/chris/public_html/stempelmuehle.host42.com/updateApp/ui/cli.php:202) in /home/chris/public_html/stempelmuehle.host42.com/core/oxutilsserver.php on line 115
PHP Warning: array_keys() expects parameter 1 to be array, null given in /home/chris/public_html/stempelmuehle.host42.com/core/oxlang.php on line 451
PHP Warning: array_keys() expects parameter 1 to be array, null given in /home/chris/public_html/stempelmuehle.host42.com/core/oxlang.php on line 451
PHP Warning: array_keys() expects parameter 1 to be array, null given in /home/chris/public_html/stempelmuehle.host42.com/core/oxdbmetadatahandler.php on line 143
PHP Warning: Invalid argument supplied for foreach() in /home/chris/public_html/stempelmuehle.host42.com/core/oxdbmetadatahandler.php on line 143
...also line 191 was mentioned several times.
...and so on (about 450 warnings total)...
and in the middle of all warnings one PHP Notice:
PHP Notice: Undefined variable: aMultishopTables in /home/chris/public_html/stempelmuehle.host42.com/core/oxshop.php on line 111
At the step:
[Note:][exec:] rev: 34568 action: requestPermissionToProceed
PHP Warning: array_keys() expects parameter 1 to be array, null given in /home/chris/public_html/stempelmuehle.host42.com/core/oxlang.php on line 451
PHP Warning: in_array() expects parameter 2 to be array, null given in /home/chris/public_html/stempelmuehle.host42.com/core/oxlang.php on line 357
PHP Warning: in_array() expects parameter 2 to be array, null given in /home/chris/public_html/stempelmuehle.host42.com/core/oxlang.php on line 357
PHP Warning: max(): Array must contain at least one element in /home/chris/public_html/stempelmuehle.host42.com/core/oxlang.php on line 371
Should I just ignore those warnings (like this is normal behavior) or did something went wrong?
I think Update is OK if the message “Update finished” appears. You could verify the php-Part by checking whether the table “oxcounters” exists (this is created by php-Part), and the SQL-Part by checking the shop version in table oxshops.
Great tips in this thread if one has to update from 4.4.8 to 4.6.8!