Many problems with oxid eshop

From Readme:

Please note: updates to OXID eShop version 4.7 (CE, PE) and 5.0 (EE) can only be provided from former version 4.6.5.

This looks like I cannot update to 4.7.0 from current 4.6.8?

As the name of the article is: https://oxidforge.org/en/update-from-4-6-5-to-4-7-0-or-5-0-0.html

Update from 4.6.5 to 4.7.0 or 5.0.0

Would you advise to update to 4.7.0 or directly to 5.0.0 to spare some update steps? Also not sure when to swap php/mysql versions as following update steps I have to install 4.7.0/5.0.0 on same machine where older 4.6.5 is located. Therefore I should not update php/mysql now to ensure proper communication with 4.6.5?

Maybe best way would be to get from 4.6.8 to 4.7.0 now using 4.7.0 fresh installation, later update from 4.7.0 to 4.9.11 and then from 4.9.11 to 4.10.8 - I hope here still the same php/mysql versions used now for 4.6.8 will be ok to do this.

Once having 4.10.8 I can go directly to 6.x if I understood correctly
https://docs.oxid-esales.com/developer/en/6.0/update/eshop_from_53_to_6/index.html

During this step it would be best to upgrade php/mysql to latest versions? Or I am wrong and you can advise better procedure?

Thanks.

5.0 exists only for Enterprise Edition, thus 4.7. You can use the “update manually” section because you don’t care about themes and modules, you can skip these parts.

Yes the new oxid 6 installation (it’s a new installation similar to 4.7) should be installed using php 7, mysql requirements didn’t change (5.5 - 5.7)

Thank you for info.

Now I installed 4.7.0 on same machine, pointed DB from 4.6.8, used again updateapp instead of “update manually”, checked I want to move themes and modules from old eshop, put the 4.6.8 directory path, waited, updateapp finished successfully.

I deleted /tmp and updated views, background working fine. Frontpage shows only shop logo when selected basic theme and for Azure it is showing structure and products but with messed up cz language and with long variables seen for some “widgets”. In other words frontpage looks very awful now.

Still the shop data looks good to me. So maybe I should not care about layouts now and continue with updates?

Current oxchkversion:

oxchkversion v 3.2.1 detected at 2020-01-21 18:18:37

Edition CE
Version 4.7.0
Revision 51243

Summary

OK 1237
Modified 0
Version mismatch 0
Unknown 168
Number of investigated files in total: 1405

This OXID eShop was not modified and is fully original.

So maybe time to backup 4.7.0 files and db now and then apply

UPDATE_OXID_ESHOP_CE_V.4.7.0_TO_V.4.9.11

and later

UPDATE_OXID_ESHOP_CE_V.4.9.11_TO_V.4.10.8

?

When running on 4.10.8 it would be fine if you could provide some best steps order regarding 6.x update vs mysql/php update. Also will I be able to get from 4.10.8 directly to 6.1.5 or lower 6.x version needed first? Thank you.

Trying to update now 4.7.0 to 4.9.11
It asked me if I want to fix languages and themes - I said Yes to Azure+EN - didnt install any other theme or cz lang now - so I believe I wont regret this.

Now after heavy 4.8.0 DB updates updateapp finished successfully.

oxchkversion:

Edition CE
Version 4.9.11
Revision 2297ef424e76f9e3907041367cc38eed1cdbe140
## Summary
OK 1360
Modified 1
Version mismatch 0
Unknown 166
Number of investigated files in total: 1527
This OXID eShop does not fit 100% CE_4.9.11_2297ef424e76f9e3907041367cc38eed1cdbe140.

Modified file: application/views/azure/tpl/page/compare/inc/compareitem.tpl
Not modified by me manually.

Hopefully I can try to update from 4.9.11 to 4.10.8 now?

I made a backup of files and DB 4.9.11 and tried to apply update 4.9.11 to 4.10.8

Unfortunately an error occured immediately after Start button pressed in updateapp:

Fatal error : Declaration of mysql_driver_ResultSet::GetArray() must be compatible with that of OxidEsales\Eshop\Core\Database\Adapter\ResultSetInterface::getArray() in C:\eshop\core\adodblite\adodbSQL_drivers\mysql\mysql_driver.inc on line 408

Error: script did not finish successfully.
Please check oxupdatetrack database table for executed actions.

This looks more painful than duplicate rows sooner today?

It looks like php version too old for this update?

I was thinking the way I will update php+mysql once having eshop in version 4.10.8

Can I update to php7 while having 4.9.11 and run update to 4.10.8 and later update to 6.1.5 under php7? Or I need newer php but not v7 and onlylater while having 6.1.5 shop I can deploy php7?

Thank you.

Edit: I am bit confused now as I am using currently php 5.3.0 and I read through requirements up to 4.10.8 and still php 5.3 supported. So my problem seems to be elsewhere. Not sure whats wrong.
Happy I was finally able to get shop from 4.5.0 to 4.9.11 but it seems to be a bit early to celebrate, still long way to 6.1.5

Edit2: In case documentation is wrong while saying php 5.3 is supported I installed now 5.4.13 in parallel to 5.3.0 - switched to 5.4.13 and eshop loads empty page only. No php errors, no error on page - just blank page and no content. Checked php settings and modules - same settings as in 5.3.0

When I switch php back to 5.3.0 eshop loads.

When I try to apply update 4.9.11 to 4.10.8 = copy_this + copy updateapp and run in browser, the update page loads, I click Start button and immediatelly get message:

Error: script did not finish successfully.
Please check oxupdatetrack database table for executed actions.

Without any errors.

Thanks for any suggestion.

Edit3: This is really crazy, frustrating and very much time consuming.
As a last step today I completely restored all files and db for 4.9.11 and switched back to php 5.3.0 to prepare working state for next time. Funny or not so funny thing is after I restored everything same way I did several times during the evening without problem - now I am getting error when trying to load frontpage and also admin page.
I am exhausted and really frustrated and dont know why this is happening to me as I completely restored from working copy which I used several times before to restore 4.9.11 to working shape. Oh no.

Fatal error : Smarty error: [in page/shop/start.tpl line 1]: syntax error: invalid attribute name: ‘js/widgets/oxcenterelementonhover.js’ (Smarty_Compiler.class.php, line 1550) in C:\eshop\core\smarty\Smarty.class.php on line 1094

Fatal error : Smarty error: [in login.tpl line 4]: syntax error: invalid attribute name: ‘LOGIN_TITLE’ (Smarty_Compiler.class.php, line 1550) in C:\eshop\core\smarty\Smarty.class.php on line 1094

No, switch to 5.6. The error is caused by PHP Version 5.3.

I understand but it’s just like reparing your car yourself, the guy in the garage would need much less time.

Clear tmp dir and try again. If it’s still not working you could do a vanilla install of 4.9.11 and connect your db, then copy picture folder to the new installation.

1 Like

Thank you for your reply. Based on it the documentation is wrong and there should be no php 5.3 compatibility written for 4.10 versions.

Anyway, I decided to switch to new wamp now as the latest version contains php 5.6.40 as well as 7.x versions. Hopefully I will be able to update shop 4.9.11 to 4.10.8 under php 5.6.40 ale later switch php to 7.4.0 or 7.3.12

Still wamp offers me now MariaDB 10.4.10 together with Mysql 5.7.28 and 8.x. I installed Maria and mysql in 5.7.28 version. Maria running now on port 3306 and mysql on port 3308

Q: should I stay with mysql for oxid, or it would be worth to switch to Maria now? System requirements for oxid speaks only about mysql. If Maria is not recommended or supported, I will set oxid to connect to mysql using localhost:port. Or I can swap mysql to be default db running on 3306 while Maria will be moved to 3308.

Your opinion?

There are some people here using mariadb, and it runs but is not supported because it is not tested by Oxid. The only error i know of is that empty fields were not saved empty but with two quotation marks inside, this can be solved by editing a file in core, and bugtracker says it’s resolved in upcoming 6.2 Version. But for me this would be enough not to use mariadb, because if something doesn’t work i would always think, maybe it’s because of mariadb.
https://bugs.oxid-esales.com/view.php?id=6914

Thanks a lot.
I read there are several benefits while using Maria when compared to mysql (speed etc.) but I wanted to be sure Maria will not cause problems with oxid. Based on that I decided to install both.

I think I will continue with mysql now for oxid while using Maria for other stuff where supported and maybe I will swap for Maria later in future Oxid releases when Maria compatibility fully tested and without problems.

Now going to deploy fresh 4.9.11 and connect with mysql backup. Hopefully I will regain functional oxid so I can move forward to 4.10.8 and later finally to 6.x

Is it better to update from 4.10.8 to 6.0.x or I can directly go from 4.10.8 to 6.1.5? Asking in advance, hopefully I will be able to move to 4.10.8 soon.

Of course new errors as always. This is longest and worse migration I ever did.

Installed fresh 4.9.11 - working.
Pointed shop to DB backup from 4.9.11 I did while 4.9.11 was working under 5.3.0 - shop offline!

How this ever could be possible?
Eshop files from fresh working installation.
DB swapped for working 4.9.11 DB.
/tmp deleted
Nothing else changed.
Wanted to navigate to admin backgroung to Update views - shop offline!

This is really not funny.

Reverted back to DB created by installation - shop offline! Definitely makes no sense to me.

Couple of hours later, after plenty of errors finally running 4.10.8 default english with oxchkversion 100% OK. FINALLY!

Edition CE
Version 4.10.8
Revision 44ff4fda9e204ebfc150cf47ef81c0bd8ea4d1b1
## Summary
OK 2334
Modified 0
Version mismatch 0
Unknown 0
Number of investigated files in total: 2334

By the way, oxchkversion shows deprecated warning for mysql extension telling me I should use mysqli. Not sure if I can do anything with it or I should ignore because e.g. it was written couple of years ago. From php 5.6.40 view I have now both mysql and mysqli extensions enabled.

Making backups now and another crazy action ahead - bring it from 4.10.8 to 6.x.x

Need to verify if I need to go to 6.0.0 first or I can go directly to 6.1.5. And whether to switch to php 7.4.0 before any action performed. And if 7.4.0 is supported or I need older 7.x version. Mysql 5.7.28 hopefully will be ok, didnt see anywhere statement whether oxid runs smoothly under mysql 8.x

If oxid 6.0.0 needed while upgrading from 4.10.8, hopefully composer updates from command line will be much more smooth than updates till now. Need to read documentation properly as next step.

Now installing Oxid 6.1.5 in parralel to 4.10.8 according to manuals.
Setup GUI reporting all green but orange for 1st item PHP 7.0 or 7.1
Should I downgrade or is it safe to run eshop with 7.4.0?
If neccessary I can downgrade to 7.3.12 or 7.2.25 or 7.1.33 or 7.0.33
If not neccessary I would rather stay with current 7.4.0 as newest version will last longer.

Thank you.

You will get lots of php warnings if you use php 7.2 or greater, I would switch to 7.1 until OXID adds compatibility with newer versions. (I heard, it should be there with OXID 6.2 update)

Thank you. So I will prefer 7.1.33 to avoid errors.

Changed to PHP 7.1.33

I moved now a bit further on and it looks like setup GUI ignore database port parameter.

I clearly set localhost + 3308 and DB user+password, DB created with success with 65 tables, in next step I filled in shop url and paths. Error occured during last step before setup finish:

Error while executing command ‘Migration’. Return code: ‘0’.
The command returns the following message:

An exception occured in driver: SQLSTATE[HY000] [1045] Access denied for user ‘eshop’@‘localhost’ (using password: YES)
ERROR: Issue while inserting this SQL statements:

End of message, no list of statements. And of course Access denied as on default DB port 3306 sits MariaDB without “eshop” user. I believe the Migration command should connect to localhost:3308 instead of localhost only.

Not sure what I have to do now as setup webpage refresh brings me to message “There is already eshop installed” and when navigate to eshop frontpage or admin background I can see Maintenance mode on both pages so I cannot do anything there. Also Setup directory is not empty now.

What would be the best here?

Simulated previous situation more times - it looks like it really doesnt care about DB port. Then I set manually in config.inc and was able to finish setup.
Then I set cs language and I will be using flow theme as I cannot see difference in wave - only from description I was able to read bootstrapper 3 vs 4. Dont know what this is. Never mind.

Having now fresh 6.1.5 installation + cs language, no need for any module and any non-default theme. Some translations are missing in cs language although marked as 100% in translations center. Also for wave theme cs folder in structure missing. Another point for me to use Flow. Maybe I could only copy cs from Flow to Wave and it would work but not sure. Still cs lang will not be 100% as stated in translation center as some admin background translations missing too (received long EN strings on some pages in admin background).

Folder OUT I am about to copy from 4.10.8 in the end as many pictures there and nothing around functions.

Folders BIN / EXPORT / LOG from manual https://docs.oxid-esales.com/developer/en/6.0/update/eshop_from_53_to_6/files.html
I am not sure whether it is needed to copy from 4.10.8 as it looks ± similar or empty files there.

Modules, Smarty plugins, own config/scripts I am not using so I believe I am done with FILES chapter and I will only copy pictures from 4.10.8 once done with DB migration.

Now focusing on DATABASE chapter.
If I understood correctly, I will point 6.1.5 config to 4.10.8 DB. Should I delete oxv_ tables at this point?
Then I will run 2 migrate SQLs downloaded from page
https://docs.oxid-esales.com/developer/en/6.0/update/eshop_from_53_to_6/database.html
I believe phpmyadmin will be ok to do this.

Once done, I will perform commands from steps 3+4 using windows command line pointed to root folder:
vendor/bin/oe-eshop-db_migrate migrations:migrate
vendor/bin/oe-eshop-db_views_generate
I hope these commands will work from wincmd as I can see bat files under defined path.

And I should be done and migrated under 6.1.5 properly. Correct?
Honestly the documentation for Doctrine commands and DB engines and APIs were a bit too much for me and I believe I will not need these.

I hope I didnt miss anything in my plan above.

You can go directly to 6.1.5, Migrations will take care of needed DB adjustments.

Yes known issue: 0006679: Setup at migration fails because of wrong dbPort (6.0.0 RC2) - OXID eShop bugtrack

oxv_tables will be recreated but it’s a good idea to delete them to verify recreation.

PowerShell works, with cmd you have to use backslashes.

Yes Correct. You should enter admin first and set a new theme active.

Another portion of problems today, not surprised. Again whole evening and night consumed but finally it seems I have 6.1.5 with migrated data from 4.5.0
I am happy and exhausted. Plenty of cosmetic details to be corrected but that was expected. Now I only hope no error will occur during fine tuning.
By the way, the buggy ini_set didnt happen to me this time - all green.
For the oxv_ I dropped all View tables as recommended and they were recreated.

Going to backup everything now before any error occur.

A big thanks to all your advices!

One question for now - I activated Flow theme once DB migration finished and switch to CS language. Home/Startseite Menu button was refreshed correctly to cz equivalent “DomƯ” while More/Mehr button at the end of Menu line (when you have more categories than Menu line width) stayed as “Mehr” instead of cz “Více” although I checked language file and it has proper definition for “More” => “Více”. Why it is not translated?

Or this has to be changed manually in different file?
Thank you.