So I dedicded to upgrade my version of magento to the latest stable version so the security checks will return all clear again. However it has failed and now I am in a bit of a pickle.
The admin backend won’t load, and the frontend is offline. 500 Error. I can access phpmyadmin.
As it the update failed, my first thought was to roll back to previous version, but with the admin console down I would need to do this via line command. So I thought I would check the backups. So as you do, I run the command “bin/magento info:backups:list” to check the backups, and I get the following error:
PHP Warning: require(/var/www/html/vendor/composer/../temando/module-shipping-m2/registration.php): failed to open stream: No such file or directory in /var/www/html/vendor/composer/autoload_real.php on line 73
PHP Fatal error: require(): Failed opening required '/var/www/html/vendor/composer/../temando/module-shipping-m2/registration.php' (include_path='/var/www/html/vendor/magento/zendframework1/library:.:/usr/share/php') in /var/www/html/vendor/composer/autoload_real.php on line 73
Does anyone know how to resolve this error? At the minute, I thinking of doing a manual roll back, where I manually uplaod the older code and database, however I cannot access PHP as I get the error
mysqli::real_connect(): (HY000/1045): Access denied for user 'database_username'@'localhost' (using password: YES)
I believe that is apart of the security setup, to the stop account logging in?
Looks like I was able to resolve the 2nd error regarding the database access. USER ERROR! multiple times!
So question is, do I attempt to do a manual restore of the database and code? Is a simple upload and replace, or is there anything else I need to be aware of?
Manually uploading the code files only and disabling maintenance mode restored the backend and frontend of the the website.
Using the command “php bin/magento info:backups:list” is now displaying the backups again. I thought I would attempt a restore using command line. Just to ensure everything is the correct state. However I get the following error when attempting to restore the code.
The rollback can’t be executed because not all files are writable.
Was able to resolve the none writable by changing owner at level /var/www/html, I guess the manually copy or cache files was not set to the correct owner.
sudo chown -Rv magento:www-data /var/www/html
The last thing I want to attempt is restoring the database, however I get this error.
Multiple queries can’t be executed. Run a single query and try again.
Had that in the past, cant remember how to resolve it! DOH!
After disabling all modules apart from the magento core modules. The rollback still failed with the same error, I am starting to think this is a setting on MySQL somewhere?
/var/www/html$ bin/magento setup:rollback --db-file="1591534333_db.sql"
Enabling maintenance mode
You are about to remove current code and/or database tables. Are you sure?[y/N]y
Do you want to keep the backups?[y/N]y
DB rollback is starting...
Multiple queries can't be executed. Run a single query and try again.
Disabling maintenance mode
Not really sure here… The message suggests that there could be a problem with the 1591534333_db.sql file. Backup/Restore via Magento isn’t something I do anymore so I can’t say I’ve ever run into this issue.
You might be able to salvage the sql file by opening it locally and forensically dissect it. But I couldn’t tell you what to look for or how to solve it - So, you’d need to put in some serious research.
As a final “Hell Mary”, it might also be caused when you select “Y” for “Do you want to keep the backups”. But I really can’t be sure if that will help of hinder.
I tried this method once, but I don’t think the output from a bin/magento setup:backup [--db] is compatible with a traditional mysql import. But do let me know how you get on. But it may simply be a case of editing the raw sql file to add/remove something first to make this work.
I suspect there’s something in the “header” of the file that might just need removing. If you do run into an issue, it might be worth doing a mysql dump of the current db and comparing both formats side-by-side.
Trying it manually gave the following large error! lol
Static analysis:
4 errors were found during analysis.
Unexpected character. (near “” at position 0)
Unexpected beginning of statement. (near “” at position 0)
Unexpected beginning of statement. (near “nCREATE” at position 1)
Unrecognized statement type. (near “ALGORITHM” at position 9)
SQL query:
CREATE ALGORITHM=UNDEFINED SQL SECURITY INVOKER VIEW `inventory_stock_1` AS select distinct `legacy_stock_status`.`product_id` AS `product_id`,`legacy_stock_status`.`website_id` AS `website_id`,`legacy_stock_status`.`stock_id` AS `stock_id`,`legacy_stock_status`.`qty` AS `quantity`,`legacy_stock_status`.`stock_status` AS `is_salable`,`product`.`sku` AS `sku` from (`cataloginventory_stock_status` `legacy_stock_status` join `catalog_product_entity` `product` on((`legacy_stock_status`.`product_id` = `product`.`entity_id`)))
MySQL said:
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\nCREATE ALGORITHM=UNDEFINED SQL SECURITY INVOKER VIEW `inventory_stock_1` AS se' at line 1`
I am going to update this thread so it can be closed with a solution.
Basically my upgrades was failing due to the Temando shipping module. Now, I didn’t disable this module from day one, but I never used it either. After disabling this module, I ran into an error where you could not edit products. Basicly, there was 3 lines that had used “eav_attribute” So you need to manually remove these from the database. Once removed upgrade worked like normal.
You can use this php query to remove the entries, The majority of people report 3 entries removed.
DELETE FROM `eav_attribute` WHERE `source_model` LIKE '%Temando%'
