backoffice 1.7 Problem with web profiler on admin categories page

[Paul C]

After a fairly long break from Prestashop I find myself once again falling down the rabbit hole. I have a site that was on 1.6.1.0 that I have migrated over to 1.7.7.0 and then upgraded to 1.7.7.1.

Initially I upgraded the site to 1.6.1.24 (to allow me to use at least php 7.1) and then performed an in-place upgrade to 1.7.6.9. Upgrade was fine except the categories were broken. I then did a fresh 1.7.7.0 install and migrated the products over (from 1.6.1.0) using a migration plugin but the result was the same - so obviously a problem with the category structure on the source store. No custom modules are installed.

After much analysis I managed to fix the issue by removing an extra "root" category in the database which seemed to have been inserted at some point (Home category had this extra category as its parent, and then that category had the real category "root" as its parent). I also refactored the level_depth (one less) via SQL. Verifying the PS_ROOT_CATEGORY and PS_HOME_CATEGORY configuration was correct and making sure the home category was set correctly for the store (there is only one store as multishop is disabled) resulted in the correct home category being displayed on the admin page and everything seems to work fine (SQL is as expected, categories display correctly and I can add and delete categories without error in the backoffice). The only weird thing I noticed was that the categories weren't available in the main menu plugin so I uninstalled it, along with any other module referencing categories... hmm.

HOWEVER, I now get an error when running debug mode "An error occurred while loading the web debug toolbar."

Opening the symfony profiler shows the image attached...

Am really hoping someone has seen this and it's a really trivial thing to fix because it's annoying the heck out of me. I'm assuming it's not working for a reason. I have tried removing the cache files (/var/cache/dev/*), cookies, php session files etc. Accessing the backoffice from a browser on another machine makes no difference. Am now stuck on options to try. I could delete all the categories and put them back in again using the back office but that would be a pain as I need to keep the ids the same as well as the products needing to be placed in the correct categories. 

Running this on Ubuntu 20.04 (WSL 1) with apache 2, PHP 7.3.25-1+ubuntu20.04.1+deb.sury.org+1, MYSQL 8.0.22-0ubuntu0.20.04.3. All the settings and php modules are those recommended and required. No errors in the php error log....

[Paul C]

On another note (and as a bump) I'm also getting loads of "Translation not found" errors too, even though they are all defined in xlf files in 'app/Resources/translations/en-GB' and the locale is set to 'en-GB'. Seems this is an old version of symfony as I found out when I looked at the docs.....

 

As an update the categories show fine as options for the main menu now. No idea why they weren't - other than maybe some caching issue? The only outstanding problem is this "unserialize" one but I have have no idea where the data is coming from. Guess I'll just need to keep digging.

Edited January 15, 2021 by Paul C (see edit history)

[musicmaster]

That playing with the root sounded very dirty to me. Doing that kind of operations without understanding why it had become that way is always very risky.

Unserialize is a very simple function that converts json into a nested array. So you can just look at position 279465 and you will find a clue.

You could also try running the Prestools Integrity Checks. It might give some clues.

[Paul C]

Making changes to the root category (confusingly not the one that is flagged "is_root_category" as that's actually the "home" category) sounds scary but the actual category changes were fine and the structure hasn't changed since 1.6. I'm now questioning whether the categories caused this at all.

I'm beginning to think that the issue might actually be down to the collations in the database (I think that they should be  utf8mb4_general_ci but not all of them are). Basically I'm thinking there's a size mismatch in the serialized data but I am indeed exploring the data itself it to see if there are any clues....

Thank you for the heads up on the Prestools - I'd never heard of it before but it looks like it could be useful!

 

UPDATE: Prestools integrity check didn't find any issues (and under the category menu displayed the category tree correctly and completely) so am guessing the category fixes were a red herring and the profiler issue is something completely separate. All 124 categories are present and correct. Have changed the collation off the tables to utf8mb4_general_ci too, just in case but no luck yet.

Edited January 16, 2021 by Paul C (see edit history)

[Paul C]

As an update (if anyone is interested!) I seem to have narrowed it down to trying to instantiate an object serialized as "O:39:"Symfony\Component\VarDumper\Cloner\Data":6:{s:45:...etc". I can force the profiler to display by just simply muting the unserialize error i.e. modifying /vendor/symfony/symfony/src/Symfony/Component/HttpKernel/DataCollector/DataCollector.php and using @unserialize in the method unserialize($data).

 public function unserialize($data)
 {
     $this->data = \is_array($data) ? $data : @unserialize($data);
 }

Obviously this is just throwing away the data so not ideal, although I can't actually see what's now missing from the profiler.....

[joe16]

On 1/17/2021 at 4:05 PM, Paul C said:

As an update (if anyone is interested!) I seem to have narrowed it down to trying to instantiate an object serialized as "O:39:"Symfony\Component\VarDumper\Cloner\Data":6:{s:45:...etc". I can force the profiler to display by just simply muting the unserialize error i.e. modifying /vendor/symfony/symfony/src/Symfony/Component/HttpKernel/DataCollector/DataCollector.php and using @unserialize in the method unserialize($data).

 public function unserialize($data)
 {
     $this->data = \is_array($data) ? $data : @unserialize($data);
 }

Obviously this is just throwing away the data so not ideal, although I can't actually see what's now missing from the profiler.....

@Paul C it looks like it is related to a PHP 7.3 Unserialize decode issue https://bugs.php.net/bug.php?id=77302