Jump to content

Update from 9.0.0 to 9.0.1 fails after Database Update

BeeJayF

By BeeJayF
in General topics

 Share

Recommended Posts

BeeJayF Contributor

BeeJayF

Posted
Posted

Hello all,

my upgrade to 9.0.1 fails during the installation of assets: 

Step UpdateDatabase
Running generic queries
Database update OK
Installing assets
/htdocs/Presta9/modules/autoupgrade/classes/UpgradeTools/CoreConsoleExecutable.php line 81 - PrestaShop\Module\AutoUpgrade\Exceptions\CommandLineException: Could not find a valid way to call PrestaShop's bin/console. Check your environment PATH or add executable permission on the file.
PrestaShopException in /htdocs/Presta9/classes/db/Db.php line 307
#0 /htdocs/Presta9/classes/db/Db.php(240): DbCore::getClass()
#1 /htdocs/Presta9/config/alias.php(47): DbCore::getInstance()
#2 /htdocs/Presta9/classes/shop/Shop.php(1387): pSQL(false)
#3 /htdocs/Presta9/classes/shop/Shop.php(356): ShopCore::findShopByHost(false)
#4 /htdocs/Presta9/config/config.inc.php(122): ShopCore::initialize()
#5 /htdocs/Presta9/bin/console(18): require_once('/pages/9b/36/d0...')
#6 {main}

In FileLoader.php line 182:

The file "/htdocs/Presta9/app/config/admin/../doc
trine.yml" does not contain valid YAML: The constant "PDO::MYSQL_ATTR_INIT_
COMMAND" is not defined at line 20 (near "!php/const PDO::MYSQL_ATTR_INIT_C
OMMAND: "SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''))"
") in /htdocs/Presta9/app/config/admin/../doctrin
e.yml (which is being imported from "/htdocs/Pres
ta9/app/config/admin/../config.yml").


In YamlFileLoader.php line 781:

The file "/htdocs/Presta9/app/config/admin/../doc
trine.yml" does not contain valid YAML: The constant "PDO::MYSQL_ATTR_INIT_
COMMAND" is not defined at line 20 (near "!php/const PDO::MYSQL_ATTR_INIT_C
OMMAND: "SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''))"
").


In Inline.php line 640:

The constant "PDO::MYSQL_ATTR_INIT_COMMAND" is not defined at line 20 (near
"!php/const PDO::MYSQL_ATTR_INIT_COMMAND: "SET sql_mode=(SELECT REPLACE(@@
sql_mode,'ONLY_FULL_GROUP_BY',''))"").

The server runs PHP 8.4.8

I disabled all 3rd party modules

Since the error log contains a hit about executable permission of bin/console - I checked and found the console file has no executable rights - but setting those (chmod +x) did also not help.

Once the update has failed, the shop is still running but I rolled back using a full backup just not to end up in a semi broken state.

Any ideas what might be to cause of this error?

 

Thanks,

BJF

Link to comment
Share on other sites
El Patron Veteran

El Patron

Posted
Posted

What appears to be happening

Could not find a valid way to call PrestaShop's bin/console → the autoupgrade module can’t invoke PHP CLI to run Symfony commands. Either PHP-CLI isn’t in PATH, the wrong PHP binary is used, or functions like proc_open are disabled. PrestaShop

The constant "PDO::MYSQL_ATTR_INIT_COMMAND" is not defined → the PHP process running bin/console doesn’t have the pdo_mysql extension loaded, so Doctrine’s config that references that constant blows up very early. (The forum post shows this right after the first error.) prestashop.com

FYI: PrestaShop 9 supports PHP 8.1–8.4, so 8.4 itself is OK — but only if CLI and FPM both have the required extensions enabled.

see: https://devdocs.prestashop-project.org/9/basics/keeping-up-to-date/update/update-from-the-cli

 

Re-run the upgrade from CLI (more reliable than the browser)

 

Link to comment
Share on other sites
El Patron Veteran

El Patron

Posted
Posted
5 hours ago, BeeJayF said:

Thanks a lot for your help. I'll try this in the next scheduled downtime. 

 

BJF 

you schedule downtime? loool.  tip: make a staging copy of production on a subdomain to test 'everything' before applying to production..test everything on a staging copy before applying to production.  for an upgrade on staging, the scheduled downtime is like 5 minutes, time it takes to copy upgrade into production file sysTem

Link to comment
Share on other sites
BeeJayF Contributor

BeeJayF

Posted
  • Author
Posted

Right! I've been thinking to do that for ages. Maybe a good time to set up a test system. Up till now I do a backup of the whole server, so an update - done in 15 minutes, if the update fails it takes another 15 to restore. 

Link to comment
Share on other sites
El Patron Veteran

El Patron

Posted
Posted (edited)
1 hour ago, BeeJayF said:

Right! I've been thinking to do that for ages. Maybe a good time to set up a test system. Up till now I do a backup of the whole server, so an update - done in 15 minutes, if the update fails it takes another 15 to restore. 

After you set up a staging environment and have enough disk space, just zip your root files and export your staging database — you can restore everything in about four minutes. Do it!

the real reason to have staging is so one can with confidence install new front office features to improver visitor experience,  without they tend not to improve visitor experience, change some .css, add a new module feature, switch on faceted search etc.  

 

Edited by El Patron (see edit history)
  • Like 1
Link to comment
Share on other sites
BeeJayF Contributor

BeeJayF

Posted
  • Author
Posted

okay - I checked the following:

proc_open enabled? 

php-cli -r "echo function_exists('proc_open') ? 'enabled' : 'disabled';"

--> enabled (also checkes out for php)

pdo_mysql extension: 

php-cli -m|grep pdo_mysql

--> yes - is there (also for php -m|grep pdo_mysql - if that would make a difference

Version of php and php-cli is both 8.4.8

I tried command line update form the modules/autoupgrade folder with 

php -d memory_limit=-1 bin/console update:start admin234

failed just like the backend update.

Is there a chance that using a bit earlier php version would increase the chances?
 

Link to comment
Share on other sites
El Patron Veteran

El Patron

Posted
Posted
3 hours ago, BeeJayF said:

Well that's exactly what I did coming from 8.something...

Great module - but still a lot of work going through for each little upgrade. Want to get those done with autoupdate. 

10 4, respect....are you using github, reporting issues, I think  they would appreciate your feedback there as well.

  • Haha 1
Link to comment
Share on other sites
El Patron Veteran

El Patron

Posted
Posted (edited)
1 hour ago, BeeJayF said:

great suggestion - doing that right now!

Issue on GitHub

Cheers,

 

BJF

that's great! I subscribed.  Having a working method of upgrade 9.0.0 to 9.0.1 ++, we can then recommend those 'very' early adopters to upgrade with more confidence to upgrade to get major fixes.  

I see in issue report that you are using php 8.4, I recommend backing that to php 8.3, learn more here.  I should have noticed that in your original post.  

 

 

Edited by El Patron (see edit history)
Link to comment
Share on other sites
  • 2 weeks later...
BeeJayF Contributor

BeeJayF

Posted
  • Author
Posted

I tried to upgrade with php 8.3 but with exactly the same error message.

So I'll wait for autoupdate 7.5 that is supposed to solve this issue.

Thanks for your help - I'll report once I have news.

BJF

Link to comment
Share on other sites
El Patron Veteran

El Patron

Posted
Posted
13 minutes ago, BeeJayF said:

I tried to upgrade with php 8.3 but with exactly the same error message.

So I'll wait for autoupdate 7.5 that is supposed to solve this issue.

Thanks for your help - I'll report once I have news.

BJF

neither 9.0.0 or 9.0.1 should be used, both have add to cart issues, you should wait until at least 9.0.2 (soon  I think)...but in reality 9.1 would be best as it's stable version that then should have been the one ps released.  

  • Like 1
Link to comment
Share on other sites
  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...