1-Click Upgrade 1.6.1.24 to 1.7.7.2 keeps failing

[roarockituk]

Quote

QL 1.7.7.0 1146 in ALTER TABLE `x_pagenotfound` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci: Table 'x.x_pagenotfound' doesn't exist
SQL 1.7.7.0 1146 in ALTER TABLE `x_statssearch` CHANGE `keywords` `keywords` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL: Table 'x.x_statssearch' doesn't exist
[INTERNAL] /home/x/public_html/src/Core/Addon/Theme/ThemeManager.php line 347 - PrestaShop\PrestaShop\Core\Domain\Theme\Exception\FailedToEnableThemeModuleException: Unfortunately, the module did not return additional details. #0 /home/x/public_html/src/Core/Addon/Theme/ThemeManager.php(226): PrestaShop\PrestaShop\Core\Addon\Theme\ThemeManager->doEnableModules(Array) #1 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/ThemeAdapter.php(92): PrestaShop\PrestaShop\Core\Addon\Theme\ThemeManager->enable('classic') #2 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/ThemeAdapter.php(51): PrestaShop\Module\AutoUpgrade\UpgradeTools\ThemeAdapter->enableTheme17('classic') #3 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/CoreUpgrader/CoreUpgrader.php(687): PrestaShop\Module\AutoUpgrade\UpgradeTools\ThemeAdapter->enableTheme('classic') #4 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/CoreUpgrader/CoreUpgrader.php(118): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader->updateTheme() #5 /home/x/public_html/modules/autoupgrade/classes/TaskRunner/Upgrade/UpgradeDb.php(41): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader->doUpgrade() #6 /home/x/public_html/mezrqz3blblqkyjl/autoupgrade/ajax-upgradetab.php(53): PrestaShop\Module\AutoUpgrade\TaskRunner\Upgrade\UpgradeDb->run() #7 {main}

Hello! Above is all the errors from doing the upgrade
I switched to the default theme.
I turned off all cache and cleaned the cache out. Varnish always disabled.
I disabled all modules.
I only have the default language on.
Database is 10.4.18-MariaDB
PHP is 7.1 during upgrade as that is the only one I can see that 1.6 runs on that 1.7 also runs on.
1 click options set to switch to the classic theme upon installing.

In 1.6 my database has 427 tables
after each botched upgrade the database has 379 tables.

Trying to go to most menu items on 1.7 leads to being redirected to the Dashboard. Such as trying to go to Orders, Shop Parameters, Customers or Advanced Parameters > Administration. Going to Modules and trying to upgrade any module results in an error, sometimes it makes the entire site 500 permanently. Then I restore the backup from just before trying to upgrade and start again with slightly different variables.

I'm not sure what to do to make the upgrade actually work. I'm happy to create a new 1.7 installation and then move the Orders, Catalogue, Customers etc over but doing it that way seems to be even more hellish. Thanks for any help anyone can give..

[Rhobur]

try copying these two tables, pagenotfound and  statssearch from another PS install into your old shop DB prior to upgrade then try the upgrade again.

[roarockituk]

Hi, thanks for your suggestion. I added those tables and now those first two errors don't occur, but all the other do. All the same problems persist.

 

Edited March 21, 2021 by roarockituk
Removing personal info (see edit history)

[Rhobur]

Try uninstalling all the modules rather than disabling them. 

[roarockituk]

It took a few hours to uninstall them as it would only let me do a couple at once and kept going to a page that I had to go out of and come back in. But I finally did it....... and exactly the same errors again. 😭

 

Quote

[INTERNAL] /home/x/public_html/src/Core/Addon/Theme/ThemeManager.php line 347 - PrestaShop\PrestaShop\Core\Domain\Theme\Exception\FailedToEnableThemeModuleException: Unfortunately, the module did not return additional details. #0 /home/x/public_html/src/Core/Addon/Theme/ThemeManager.php(226): PrestaShop\PrestaShop\Core\Addon\Theme\ThemeManager->doEnableModules(Array) #1 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/ThemeAdapter.php(92): PrestaShop\PrestaShop\Core\Addon\Theme\ThemeManager->enable('classic') #2 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/ThemeAdapter.php(51): PrestaShop\Module\AutoUpgrade\UpgradeTools\ThemeAdapter->enableTheme17('classic') #3 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/CoreUpgrader/CoreUpgrader.php(687): PrestaShop\Module\AutoUpgrade\UpgradeTools\ThemeAdapter->enableTheme('classic') #4 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/CoreUpgrader/CoreUpgrader.php(118): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader->updateTheme() #5 /home/x/public_html/modules/autoupgrade/classes/TaskRunner/Upgrade/UpgradeDb.php(41): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader->doUpgrade() #6 /home/x/public_html/x/autoupgrade/ajax-upgradetab.php(53): PrestaShop\Module\AutoUpgrade\TaskRunner\Upgrade\UpgradeDb->run() #7 {main}

 

Edited March 21, 2021 by roarockituk
removing directory info (see edit history)

[Rhobur]

Weird.. is this the default Classic PS theme? A custom one? If custom are you sure it is PS1.7 compatible along with its modules?

The reason for this is that it can't enable the theme after upgrade and this if:

- it can't update the theme's configuration, or

- it can't enable a module.

So, you can try again the upgrade with all module disabled, set to switch to the classic theme to No and see what happens next.

If you have then access to the BO you can try enabling/disabling the modules one by one to find the culprit.

 

[roarockituk]

Thank you for the continued support  

With all the modules disabled, and the classic theme set to no, and using 1.7.7.2 as the upgrade there are no errors shown in a second box but it says 'A warning was encountered' in the normal text but doesn't say what warning. However, all the problems remain, with it just redirecting to the dashboard if you try to click Orders, Shop Parameters, Customers or Advanced Parameters > Administration.

With all the modules disabled, and the classic theme set to no, and manually using 1.7.4.0 I get the error:

Quote

SQL 1.7.0.0 1242 in /* Save the new IDs */ UPDATE `ps_tab_transit` tt SET `id_new_tab` = ( SELECT `id_tab` FROM `ps_tab` WHERE CONCAT(`class_name`, COALESCE(`module`, '')) = tt.`key` 😞 Subquery returns more than 1 row

It causes the site to 500 error if you go to Modules or Payment, and there's a constant rotating arrow but absolutely everything else works that redirected when upgrading to 1.7.7.2 😵

With 1.7.7.0 I get
 

Quote

[OK] SQL 1.7.0.0 ALTER TABLE `tcru_tab` ADD `icon` varchar(32) DEFAULT ''
Errors:
[INTERNAL] /home/x/public_html/src/PrestaShopBundle/Install/XmlLoader.php line 467 - Symfony\Component\Debug\Exception\FatalThrowableError: Call to a member function trans() on null #0 /home/x/public_html/src/PrestaShopBundle/Install/XmlLoader.php(347): PrestaShopBundle\Install\XmlLoader->flushDelayedInserts() #1 /home/x/public_html/src/PrestaShopBundle/Install/Install.php(476): PrestaShopBundle\Install\XmlLoader->populateEntity('tab') #2 /home/x/public_html/x/autoupgrade/latest/install/upgrade/php/migrate_tabs_17.php(63): PrestaShopBundle\Install\Install->populateDatabase('tab') #3 [internal function]: migrate_tabs_17() #4 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/CoreUpgrader/CoreUpgrader.php(396): call_user_func_array('migrate_tabs_17', Array) #5 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/CoreUpgrader/CoreUpgrader.php(361): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader->runPhpQuery('1.7.0.0', '/* PHP:migrate_...') #6 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/CoreUpgrader/CoreUpgrader.php(285): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader->runQuery('1.7.0.0', '/* PHP:migrate_...') #7 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/CoreUpgrader/CoreUpgrader17.php(55): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader->upgradeDb('1.6.1.24') #8 /home/x/public_html/modules/autoupgrade/classes/UpgradeTools/CoreUpgrader/CoreUpgrader.php(102): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader17->upgradeDb('1.6.1.24') #9 /home/x/public_html/modules/autoupgrade/classes/TaskRunner/Upgrade/UpgradeDb.php(41): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader->doUpgrade() #10 /home/x/public_html/x/autoupgrade/ajax-upgradetab.php(53): PrestaShop\Module\AutoUpgrade\TaskRunner\Upgrade\UpgradeDb->run() #11 {main}

 

Edited March 21, 2021 by roarockituk
1.7.4.0 vs 1.7.7.2 vs 1.7.7.0 (see edit history)

[SBD]

Does this module currently work at all?

I have tried numerous times over the past 12 months to upgrade a clone of my 1.6.1.20 store. It is a good thing I tested with clone, it has failed everytime including setting to defaults, clearing cache etc etc...

Time for a TRUE TEST.
I did a FRESH INSTALL of 1.6.1.24.
I activated the 1-click module.
I attempted the suggested upgrade of 1.6.1.24 to 1.7.7.3 .... and I get the same result as with trying to upgrade my clone of 1.6.1.20...., which uses default modules only, and has been customised with the recommended override method.
BUT since it even fails in the same way with a default install of 1.6.1.24, I do not think there is actually any issue with my store.
 

Quote

 

"All files upgraded. Now upgrading database...[Ajax / Server Error for action upgradeDb] textStatus: "error " errorThrown:"Internal Server Error " jqXHR: "

500 Server Error

Oops, something went wrong.

Try to refresh this page or feel free to contact us if the problem persists."

 

Well, consider this a contact, the problem does persist.
It was a default fresh install 5minutes old. It still won't upgrade with the 1-click module.

Did I miss a magic window of versions it would actually upgrade? Has this been tested as working successfully?

 

[musicmaster]

On 4/13/2021 at 2:30 PM, SBD said:

Does this module currently work at all?

I have tried numerous times over the past 12 months to upgrade a clone of my 1.6.1.20 store. It is a good thing I tested with clone, it has failed everytime including setting to defaults, clearing cache etc etc...

Time for a TRUE TEST.
I did a FRESH INSTALL of 1.6.1.24.
I activated the 1-click module.
I attempted the suggested upgrade of 1.6.1.24 to 1.7.7.3 .... and I get the same result as with trying to upgrade my clone of 1.6.1.20...., which uses default modules only, and has been customised with the recommended override method.
BUT since it even fails in the same way with a default install of 1.6.1.24, I do not think there is actually any issue with my store.
 

Well, consider this a contact, the problem does persist.
It was a default fresh install 5minutes old. It still won't upgrade with the 1-click module.

Did I miss a magic window of versions it would actually upgrade? Has this been tested as working successfully?

 

1-click upgrade is rather sensitive to deviations in the database structure.

look in the errorlog for the meaning of the 500 error. If you find nothing there enable debug mode.

You can try making a copy of your shop with my tool copy_shopdata en upgrade that: 

 

 

[SBD]

On 4/17/2021 at 1:41 AM, musicmaster said:

1-click upgrade is rather sensitive to deviations in the database structure.

look in the errorlog for the meaning of the 500 error. If you find nothing there enable debug mode.

You can try making a copy of your shop with my tool copy_shopdata en upgrade that: 

 

 

Thank you for the suggestion, but migrating to a fresh install then upgrading, is not going to work, when a fresh default install can not be upgraded either. The upgrade process is severely flawed if I can not work on a fresh clean presta 1.6.24 installation with zero user data.  I'm attempting for the last time with some php timeout settings, before looking for a new eCommerce solution.  I may test the thirty bees option.
I am not even that set on keeping customer data, order history, and with only a handful of active products, it is more the site appearance integration that I wished to preserve. But wasting 30-50 hours trying to upgrade copies of Prestashop, that's a significant portion of the effort it took to customise it in the first place. Yes I tried disabling all theme over-rides etc....
The upgrade does not work on a default 1.6.24 installation, so it is nothing to do with my site at all. All PHP requirements confirmed as active, last possible option timeouts and memory limits.

I originally chose Prestashop for being able to set sales units as grams, and a fast loading time with limited products. Perhaps the sales units can be replicated in other platforms for the same overall coding time investment.  The pay for an addon for each basic functionality platform has grown old also.
The lesson to test payment platforms before investing time into designing store was valuable though, several payment modules from Australian providers have clearly never been tested as they contained fatal flaws.

[musicmaster]

1 hour ago, SBD said:

Thank you for the suggestion, but migrating to a fresh install then upgrading, is not going to work, when a fresh default install can not be upgraded either. The upgrade process is severely flawed if I can not work on a fresh clean presta 1.6.24 installation with zero user data.  I'm attempting for the last time with some php timeout settings, before looking for a new eCommerce solution.  I may test the thirty bees option.
I am not even that set on keeping customer data, order history, and with only a handful of active products, it is more the site appearance integration that I wished to preserve. But wasting 30-50 hours trying to upgrade copies of Prestashop, that's a significant portion of the effort it took to customise it in the first place. Yes I tried disabling all theme over-rides etc....
The upgrade does not work on a default 1.6.24 installation, so it is nothing to do with my site at all. All PHP requirements confirmed as active, last possible option timeouts and memory limits.

I originally chose Prestashop for being able to set sales units as grams, and a fast loading time with limited products. Perhaps the sales units can be replicated in other platforms for the same overall coding time investment.  The pay for an addon for each basic functionality platform has grown old also.
The lesson to test payment platforms before investing time into designing store was valuable though, several payment modules from Australian providers have clearly never been tested as they contained fatal flaws.

 

I am afraid that your main problem is with your server settings. 

In case of a 500 error you should enable debug mode and report the error here. You never did so so we couldn't help you.

[SBD]

On 5/4/2021 at 10:39 PM, musicmaster said:

 

I am afraid that your main problem is with your server settings. 

In case of a 500 error you should enable debug mode and report the error here. You never did so so we couldn't help you.

Noone had asked prior to your suggestions.
I was delving into the debug log, which was not particularly helpful. That is a beyond the key problem of the 1-click not working as implied when following it's instructions and lack of. After uncovering some more server settings, I managed to get most of it, but not all, and only for a fresh default installation, nowhere near upgrading an actual store.

For those attempting to get somewhere with the 1-click module, on a clean fresh 1.6.24 install;

Add these to the end of the .htaccess; it may correct some server level settings, timeouts etc. This at least prevented the upgrade falling over partway through.

=== .htaccess ===
php_value memory_limit 512M
php_value max_execution_time=300
php_value max_input_time=-1
php_value upload_max_filesize 10M
php_value post_max_size 20M

On top of this, ensure that your PHP settings under CPanel, or server configuration have the following enabled;

   

Quote

Must have PHP extensions: cURL, DOM, Fileinfo, GD, Intl, Mbstring, Zip, Json, iconv
    To improve performances: MemCached, Apcu, OpCache

In my case cURL, iconv, OpenSSL were not available for selection, but confirmed with host and testing that they were turned on.

But even with this, the backend is non-functional following an 1-click upgrade. There's a few threads around discussing a long overdue bug requiring you to reset the admin privileges.  Ie... if this manual step is required, the 1-click is not functioning as 1-click 1.6.24 to 1.7.x

access not complete until resetting admin account;
In CPanel, start PhpMyAdmin, select the Prestashop database, and in the SQL tab enter; alter psjz_ to whatever prefix your tables may have...
 

Quote

UNABLE TO ACCESS BACKEND ADMIN FEATURES
https://www.prestashop.com/forums/topic/876786-solved-prestashop-17-access-denied-as-admin-in-bo/?tab=comments#comment-3311835
Solved issue with this query that reset all permissions in SuperAdmin

delete from psjz_access where id_profile = 1;
insert into psjz_access (id_profile, id_authorization_role) select '1' as id_profile, id_authorization_role from psjz_authorization_role;

 

=part way there, but nowhere near a successful migration. It shows even a fresh install can run into problems with hosting settings, and that 1-click screws up the admin permissions in the database. As far as I can tell the need to reset database has been reported for the past 18months or more.

Quote

You can try making a copy of your shop with my tool copy_shopdata en upgrade that: 

Thank you for that, having given up on the 1-click, I've spent the past few days on the thirty-bees 1.2.0 conversion option (default thirtybees migrate/upgrade to 1.2.0 resulted in shopping carts that empty themselves on checkout), and so today I tried the copy_shopdata path instead.
Another brick wall unfortunately, even with running through prestatools, cleaning etc.

Without inspiration, I'll need to start from scratch or piece together some of the migrated data into a fresh install, or ... give up.

Trying to run copy_shopdata results in "MySQL error 1045: Access denied for user"

This is not the obvious stuff up of users, servers, passwords... or % characters in passwords.
Resetting password etc multiple times, entering into store clone and successfully viewing the frontend...

... as testaccess.php next to the copy_shopdata.php file in the destination admin/prestatools/ directory of a thirtybees Cpanel-softaculous installed version, the following script indicates  a successful connection.  Variants of localhost etc also tested. I'm stumped on this one. I also tried adding the .htaccess limits and timeouts I posted above into the destination store directory.

Quote

 

<?php
$servername   = 'domain.net.au';
$database = 'domainau_prestst';
$username = 'domainau_prestst';
$password = 'plainpassword5';

// Create connection
$conn = new mysqli($servername, $username, $password, $database);
// Check connection
if ($conn->connect_error) {
   die("Connection failed: " . $conn->connect_error);
}
  echo "Connected successfully";
?>

 

 

Edited May 9, 2021 by SBD
addition (see edit history)

[musicmaster]

 - > still no debug mode and reports from there

 - > you write "I was delving into the debug log, which was not particularly helpful.": It was not helpful to you. For others it could be enlightening. But you don't even bother to share this information. So how do you expect anyone to be able to help you?

 - > "Solved issue with this query that reset all permissions in SuperAdmin": Are you serious that you are working with reduced rights accounts before getting things to work with full accounts?

 - > "reset database": I have no idea what you mean by that.

 - > Did you check your rights in the file system? Some people report problems when the directories are owned by "root" instead of "www-data".

 

 

 

[SBD]

I was editing and expanding my reply .....  it should address those points now.  Following your original suggestion of the copy shopdata code it took a few days... I didn't realise at first the second comment was from yourself also.

Server settings were part of the problem. Log was not useful as it would sometimes attempt to work on a table, other times drop it due to timeouts. Once settings allowed the "upgrade" to "complete" the backend was non-functional.  It would appear that the 500 errors were result of corruption from insufficient resources under server settings, which is why I have listed everything that resulted in a partial successful upgrade.

not reduced rights, the core admin account has no access to the backend after 1-click upgrade.
Superadmin is part of the quote from the quoted thread, along with the solution.

all files are 755 directories, 644 files etc as per an usual installation.

Edited May 9, 2021 by SBD
addition (see edit history)

[SBD]

In summation; 1-click does not work with even a default install.

I provided the server overrides to place in .htaccess that appeared to help, the upgrade completed rather than timing out or dropping tables with varying results.

But the backend still did not function without SQL database  manipulation (copied/linked to original thread) to correct access permissions. It's also mentioned there or elsewhere the backend access problem has been long reported.
A real store may or may not work from this point, I didn't test the clean install further.

a standard process ThirtyBees upgrade worked far better, but for some reason breaks cart functionality in the conversion, upgrade 1.08-1.2.0 process. Might be worth investigating further, maybe the cart may have worked before upgrade?

copy_shopdata 1.6.24 clone to ThirtyBees 1.2.0 fresh softacalous install, is encountering DB user access problems, with a simple accesstest php script confirming all database variables are correct.

It's looking simpler to give up and continue using the old store, as I've already been doing with >12mths failed 1-click update tests. My new season is about to start in a month, July-August then shuts down again, times ticking. Alternatively, I start from scratch and possibly attempt to manually port some data such as original appearance theme and customer database from the failed conversions.
Every failed upgrade conversion that is presented as a working solution, reduces confidence in the Prestashop platform when it fails to perform.  The pay per everything model of 1.7 falls apart when the underlying structure can't be updated.

A few hundred hours into redesigning from scratch is making more sense than wasted effort chasing bugs.  Likely far less to restart, I documented most/all of my alterations and used the recommended override method of the default Theme. In my instance, repeat customers are so few I could enter them manually and send a new password. Simpler to host an offline maintenance version of the old store if I think there's a use for old data.