andyfick

Fantastic! Thanks so much, and keep up the good work, it's really appreciated!

Hi @musicmaster I've been using Prestashop since 2014, and I've only just found your suite of tools - they are awesome, and I can't believe I haven't found them before now. I used to do everything in PHPMyAdmin ... Anyway, I've just installed the latest version of the suite, and I did a category update on a set of products, to add them to a new category I'd created, called Sale: - Search for all products with a specific supplier name - Click Edit button on the category column - From Mass Update box, choose Category -> Add -> Sale - Update and Submit - As expected, all products had the new category ID added to their list of categories. All good and no visible errors! However, what I didn't notice (until I was editing an affected product in the back office), was that for some of the amended products, the default category was no longer set. On others that were changed, the default category remained as it was previously. I checked the affected products vs my DB backup, and prior to the above update, they did have a default category set, so I'm not sure what I've done wrong. Are you aware of anything that could reset the default category when doing an update like this? Prestashop version: 1.7.7.8. Prestools version 1.32q. Release date: 13-nov-2023. PHP version 7.4.33 and MySQL version 10.6.16-MariaDB Thankfully, using your tool I can go through quickly and set the default categories for the ones that need it.

Although there's a lot about URL rewriting on the forum, I haven't been able to find this specific problem. Background - I'm migrating an existing 1.6.1.24 shop to 1.7.7.3 (using a migration addon). All categories, products, customers, etc are in the new store and look fine. The issue I'm having on the 1.7 store can be reproduced by doing this: Browse to a category page (e.g. Dressing Table Mirrors) - displays category page as expected URL shows /90-dressing-table-mirrors View a product page (e.g. Circular Black Mirror) - shows the product page fine URL shows /dressing-table-mirrors/1536-circular-black-iron-dressing-table-mirror-5055672484653.html Now, choose a different category from the nav (e.g. Seating), and I get a 404, because ... URL shows /dressing-table-mirrors/80-seating The URL rewriting isn't resetting the URL to start from the base URL, it's adding it on to the previously viewed category! On my 1.6 shop, this URL is correctly re-written to /80-seating. I've tried: Switch on / off Friendly URLs, clear cache Delete htaccess completely, switch on Friendly URLs, clear cache (htaccess file is being generated OK, so it's not a read-write issue) Switch off the two Apache settings in SEO, which state they may cause issues, clear cache Put a / before the Route to category (URL is still wrong, I just get two // in it) This is on the same server as my existing shop, so the environment is the same for both. I'm out of ideas! Help! Store is at https://presta17.accessoriesforthehome.co.uk so you can see for yourself what's happening. Andrew

Hi DanGB, Just reading through your post from last year, and I'm about to do a similar thing: upgrade from 1.6 to 1.7 and update my WorldPay module. My original WorldPay module was the 'official' one from Prestashop, and even though it says it works with 1.7, it's from 2018 and it won't install on 1.7.7.2 without throwing an error. It is now no longer listed on the addons site. There is just one module now listed for WorldPay on addons, and it looks almost identical to the one I'm currently using, but of course I'm going to have to buy it again despite already owning it. I was interested to know whether your module is now working OK and, if it isn't the one listed on the addons store, where did you get it from? Many thanks, Andrew

So, I guess that answered my question - no-one seems to have come across this before. However, if you come across this thread with the same problem, hopefully the following solution will help you. The issue described above is caused by line 539 in the file ganalytics.php which you'll find in the ganalytics module folder. As this module is no longer being updated, I chose to edit this file directly rather than add an override. So, in version 2.3.4 of the module, line 539 reads: 'price' => number_format($product['price'], '2') This is the wrong number format, as it retains the comma thousands separator (which breaks GA). Change this line to: 'price' => number_format($product['price'], 2, '.', '') Which removes the comma and means the correct price is sent to GA. Here's some things that helped me arrive at this solution: Chrome extension - Google Analytics Debugger Add this to Chrome, and you get a read-out in the developer console of all the info that is being sent to GA as you browse your website. Very handy indeed! Github repository for the ganalytics plugin Can be found here: https://github.com/PrestaShop/ganalytics There is a new version of the plugin (2.4.0) but it was never released. However, all the code is there for you to use, and one of the changes addressed was the above formatting issue. So, I hope that's useful for somebody else. Now onto my second GA issue, lack of 'Add to Basket' events ... Andrew

Hi All, I have a couple of issues with the Prestashop provided GA plugin on my 1.6.1.24 UK store using default bootstrap theme. Here's the first one: If an individual product in an order has a pre-tax price which is over 1000 pounds, then the Sales Performance report in Google Analytics does not properly record the product price. It looks like it's having problems with the comma in the price, as a product that is, say 1,085 pounds gets reported as 1.08 pounds. Other amounts work fine (like total order revenue, for example). If it is a number representation issue, I guess I either need to tell my smarty template to not represent the product price with a comma, or tweak the JS of the analytics call to ignore the comma. However, before I dive in I thought it might be sensible to see if anyone else has seen / fixed this issue previously. Thanks for any assistance! Andrew

I don't know what it is, but I removed all the non-native modules before attempting the 1-Click update (by which I mean I uninstalled all modules that were not originally supplied as part of Prestashop 1.6). I think I'll have to go down the migration route, as this seems to be the safest option, and it will ensure I start with a 'clean' install of 1.7. Thanks again for your help! Andrew

OK, so I removed that module, and also blockwishlist, which was throwing an error. Front office loads with my logo and a blank page with just the Prestashop copyright text. Back office is giving me this error when I try to access Modules: Attempted to load class "ImportModule" from the global namespace. Did you forget a "use" statement? in modules\importerosc\importerosc.php (line 30) Really appreciate you helping me Leo, but I'm thinking this is a lost cause. Should I try to update to a lower version of 1.7, or is this going to happen whichever version I try to update to? Thanks, Andrew

Some progress, thanks Leo: I just replaced the ps_currency table with one from a fresh install, and that's cleared the ComputingPrecision error. I now get this on the front end: Call to a member function isRegisteredInHook() on bool in ganalytics.php line 451

Thanks Leo, My dispatcher.php file already has the line shown as added in the link you sent (line 36). I'm on 1.7.7.0. Here's what it looks like: // Cart is needed for some requests Context::getContext()->cart = new Cart(); Context::getContext()->container = ContainerBuilder::getContainer('webservice', _PS_MODE_DEV_); Context::getContext()->currency = Context::getContext()->currency ?? new Currency(Configuration::get('PS_CURRENCY_DEFAULT')); Andrew

Hi, I've been doing a bit more on this. Update to PHP7.3 makes no difference so far. So, I create the ps_currency_lang table, and that removes that error. On the Front office, the next error is: Type error: Argument 1 passed to PrestaShop\PrestaShop\Core\Localization\CLDR\ComputingPrecision::getPrecision() must be of the type integer, null given, called in C:\wamp64\www\afth\classes\Context.php on line 467 On the back office, I couldn't login, and had to create ps_employee_session and ps_customer_session tables, after which I got: The slug ROLE_MOD_TAB__READ is invalid I copied a new ps_authorization_role table over from a fresh install and overwrote the ps_access table (which was previously empty). I also overwrote the ps_tab table with a fresh copy as there was a lot missing from that. I can now get into the back office, although the menus don't appear properly - each menu item starts with the word Admin (e.g. AdminCatalog). Tried to go into the Products list and got another missing table, ps_admin_filter, so I added that. Now I'm at exactly the same ComputingPrecision error that I get in the Front Office above. I'm stuck! Andrew (post edited a few times)

Hi All, I've been experimenting with the 1-Click update to move my store from 1.6.1.24 to the latest 1.7. I've set up a local dev instance to work on, running PHP 7.1.33, MySQL 5.7.31, using 1-Click version 4.11.0. I've uninstalled all non-native modules from the shop. I'm in the UK and the shop is in English only. The theme is default-bootstrap. I get the following errors when performing the update (these appear in the 1-Click update Errors window): [INTERNAL] C:\wamp64\www\afth\src\PrestaShopBundle\Install\LanguageList.php line 100 - Symfony\Component\Debug\Exception\ClassNotFoundException: Attempted to load class "PrestashopInstallerException" from the global namespace. Did you forget a "use" statement? #0 C:\wamp64\www\afth\admin2796\autoupgrade\latest\install\upgrade\php\migrate_tabs_17.php(57): PrestaShopBundle\Install\LanguageList->setLanguage('gb') #1 internal function]: migrate_tabs_17() #2 C:\wamp64\www\afth\modules\autoupgrade\classes\UpgradeTools\CoreUpgrader\CoreUpgrader.php(395): call_user_func_array('migrate_tabs_17', Array) #3 C:\wamp64\www\afth\modules\autoupgrade\classes\UpgradeTools\CoreUpgrader\CoreUpgrader.php(360): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader->runPhpQuery('1.7.0.0', '/* PHP:migrate_...') #4 C:\wamp64\www\afth\modules\autoupgrade\classes\UpgradeTools\CoreUpgrader\CoreUpgrader.php(284): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader->runQuery('1.7.0.0', '/* PHP:migrate_...') #5 C:\wamp64\www\afth\modules\autoupgrade\classes\UpgradeTools\CoreUpgrader\CoreUpgrader17.php(55): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader->upgradeDb('1.6.1.24') #6 C:\wamp64\www\afth\modules\autoupgrade\classes\UpgradeTools\CoreUpgrader\CoreUpgrader.php(101): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader17->upgradeDb('1.6.1.24') #7 C:\wamp64\www\afth\modules\autoupgrade\classes\TaskRunner\Upgrade\UpgradeDb.php(41): PrestaShop\Module\AutoUpgrade\UpgradeTools\CoreUpgrader\CoreUpgrader->doUpgrade() #8 C:\wamp64\www\afth\admin2796\autoupgrade\ajax-upgradetab.php(53): PrestaShop\Module\AutoUpgrade\TaskRunner\Upgrade\UpgradeDb->run() #9 {main} As per other topics on this subject, the ps_currency_lang table doesn't exist. Creating this table (copying from a clean install) resolves that error, but then I'm into another exception, and on it goes - it turns out a number of tables are missing. I'm guessing that the upgrade process is borking before it has chance to create certain tables. There's clearly something about my shop that's causing this, but from all the troubleshooting I've done so far I can't see what it is. Any thoughts, pointers or guidance gratefully received! Andrew

@Rutger Can I ask - I was looking at the module you are using, and from reading the description it sounded like it sends events into the Shopping Behaviour section of GA automatically - is this not the case? Do you still have to manually set up funnels? I don't want to spend the money on it if it still doesn't allow me to see the full shopping journey! Thanks, Andrew

I'm in the same position, and keen to get a funnel set up (in PS1.6). However, based on spending the last 2 hours Googling, I've come to the conclusion that it mustn't be possible to track the Prestashop checkout in a GA funnel due to the friendly URLs it uses for the checkout pages. The only instructions I can find date back more than 5 years, and don't work in PS1.6. I'm amazed there isn't a clear and accurate guide for this, and I'm hoping I'm just looking in the wrong place, and someone out there is doing this successfully!

This was a life-saver for me as I had exactly the same problem. Fixed now! Thanks so much, Andrew