Paul C

Can you post a screenshot of the errors you're seeing? Also what are the global import settings you are using? I don't import products using the standard importer so am not an expert in it but I seem to remember people having to set the id column to 0 for every product.

I was originally under the assumption that there was to be a quality control process on the addons store. How wrong I was. The partner programme? From my limited experience (examining the work of one "authorised agency") - you may as well use fiverr.... not that there are many "experts" left on the list. I thought that there was none in the UK as I searched on "Europe" as a region but it seems they've redefined it as EU perhaps. Someone needs a geography lesson If they're proposing a cost to module and theme authors that will mean genuine (functional/security) analysis and quality control, then I think it would benefit both customers and developers (and hopefully remove the junk modules and themes that are on there). The open source side is going fairly well now that it has been split off. The commercial arm, not so much as it stands.

If you need to preserve the wholesaler's id numbers then you should use them either as the reference or as a supplier_reference but not as the PrestaShop product id. The only time you would use the id field in an import is if you're updating existing products and need to preserve the id (they form part of the url for your products so will affect indexing in search engines). There's a whole lot of business logic that's built around the assumption that those fields are defined in a specific way and any addon or module that uses those fields (directly or indirectly) have a good chance of not working if you mess with them, so you don't just have the core functionality to worry about. You will spend the rest of the lifetime of the store messing with fixing stuff rather than selling if you insist on using those ids in place of PrestaShop generated ones. My advice would be to delete any products you've added so far and start again (or re-install the store from scratch, which might be your easiest option). This time use those wholesaler numbers as the reference or supplier_reference (those are both 64 characters long, so plenty big enough) and let the import assign an internal product id. It might seem like a lot of extra work but it will be well worth it in the long run - and you'll have a store that can (a) be supported, and (b) have a chance of working properly. If you're going to be doing a lot of data import and updating, then I'd strongly advise working with a developer on a bespoke solution or using a "Store Manager" 3rd-party add on. It's hard enough selling online without also doing all your own tech support and data management with basic tools. I've never used the latter but I'm sure there will be recommendations on here (and not just from the author....).

Don't change the database structure. At various times upgrades have modified the size of database fields so you're just saving up a problem for yourself down the line. 4.3 billion products should be enough.... Is your store live?

To be honest I would go for the official developer documentation (it's come a long way in recent times) and also check out the example modules. A lot of content out there is pretty dated and doesn't always adhere to good coding practice (or PrestaShop coding standards). For the best experience brush up on composer, symfony (4!), twig, smarty and docker. Also look out for deprecated functions - there are loads that WILL come back to bite you if you use them. A decent IDE should help identify those as you go. I'm currently using VSCode + PHP Intelephense because life's too short. Best idea is to come up with a learning project - say a module to add a new Admin tab in the back office to manage some arbitrary custom data in your own custom database table and then display that data in the front office. Once you've worked through something like that, then you're 80% of the way there.

The hook additionalCustomerFormFields is sent the array of the field definitions, so you can manipulate them in there and never have to worry about files getting updated and having to mess with core changes and overrides. There's an equivalent for most forms. Here's an example module that uses this process to change a field name (but you can do the same with the setRequired() method too, of course). This specific module is intended to target Prestashop 8.0.0 onwards and PHP 8.1. May need to be modified for earlier versions, but the principle is supported from 1.7 onwards. You may need to remove declare(strict_types=1) and the function return types if you're using an older version of PHP. Documentation can be found here (PrestaShop 😎. <?php /** * Module Name: formlabelmangler * Description: Example code to show how to modify field labels * Version: 8.0.0 * @author: Paul Campbell [https://www.prestashop.com/forums/profile/11264-paul-c/] * @license https://opensource.org/licenses/AFL-3.0 Academic Free License 3.0 (AFL-3.0) */ declare(strict_types=1); if (!defined('_PS_VERSION_')) { exit; } class formlabelmangler extends Module { /** @var array */ private $hooks; /** * @param string|null $name (Deprecated parameter) * @param Context|null $context * @return void */ public function __construct() { $this->name = 'formlabelmangler'; $this->tab = 'front_office_features'; $this->author = 'PaulC'; $this->version = '8.0.0'; parent::__construct(); $this->displayName = $this->trans('Fun with forms and hooks.', [], 'Modules.formlabelmangler.Admin'); $this->description = $this->trans('Modify field names on customer registration form.', [], 'Modules.formlabelmangler.Admin'); $this->ps_versions_compliancy = array('min' => '1.7.0', 'max' => _PS_VERSION_); // Hooks to install to $this->hooks = [ 'additionalCustomerFormFields' ]; } /** * Install and hook module. * @return bool True on success, False if an error is encountered */ public function install() { return parent::install() && $this->registerHook($this->hooks); } /** * Respond whether the module uses the new translation system. * * @return bool */ public function isUsingNewTranslationSystem(): bool { return true; } /** * Inject additional customer registration fields and/or manipulate existing * Hook::exec('additionalCustomerFormFields', ['fields' => &$format], null, true) * @see https://github.com/PrestaShop/PrestaShop/blob/develop/classes/form/FormField.php * * @param array FormField &$arguments['fields'] any additional data * @return array The field definitions to be rendered * */ public function hookAdditionalCustomerFormFields(array $arguments) : array { // The current fields which are set can be retrieved with the following // since the data is passed by reference. $fields = $arguments['fields']; // Uncomment the following if you want to record the current field details in the // PHP error log for reference. //error_log('We got ourselves some fields to play in: '. print_r($fields, true)); // In this example we want to spruce up the 'email' field and call it "Email Address" // instead of just plain old "Email". foreach ($fields as $field) { if ($field->getName() == 'email') { $field->setLabel( $this->trans( 'Email Address', [], 'Shop.Forms.Labels' )); } } // This is where you would return any additional fields you want to create return []; } }

No, they are notices that fill up the error log on production systems and *aren't* disabled, ever - even when you downgrade to a more sensible reporting level for a production system from the default. E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED I know it's not a high priority but stuff like this just makes using the software more of a hassle than it really needs to be. It's an example of adding a feature (store statistics) that is intensive to maintain (hard-coded values) and then unsurprisingly not maintaining it....

Those aren't errors just notices and they're fine. Fingers crossed it will work for you There's no link sadly between module version and shop version, so a module won't ever check what version of PHP you're running before an install or update. Ideally a module developer should update the details of which versions it works with (factoring in PHP compatibility), but sadly that just doesn't seem to happen..... PHP 5.6 is seriously old and hasn't been actively maintained for some time now. If you want to see how far behind PrestaShop 1.7 is with PHP then compare the system requirements link in my post above with the official PHP supported version list! There was no PHP 6 but even so, PHP 5 dropped off the list years ago..... EDIT: 5.6 was unsupported as of 5 years 8 months ago......

OK, you need v7.0+ if you're going to use that faceted search module and PHP 7.2 is what PrestaShop recommends for your version of PrestaShop (although 7.4 will *probably* work fine, maybe). The system requirements, including php versions can be found on this page and while it says that PHP 5.6 is compatible, that's only the core and doesn't include modules. The original error you got was because the faceted search module uses a new feature "return type declarations" (the : void at the end of line 77). Support for this was added in PHP 7 which is why you get that error - PHP 5.6 doesn't support it. These new language features are documented here. You can either remove modules which require PHP 7.0+ (such as the faceted search module, but there may be others), downgrade modules to older versions that work with PHP 5.6 or upgrade your PHP to version 7.2 (or maybe 7.4 if 7.2 isn't available on your server). PHP 8 isn't supported for your version of PrestaShop. I use PHP 8.1 for PrestaShop 8.1.x though, so upgrading may also be something you may want to consider.

What php version are you running? Nothing wrong with that syntax, assuming you're not running an outdated version of PHP. I think the recommendation is php 7.1

There are likely a few "Attribute.php" files (including in the override directory)! First step for me would be to locate the appropriate file and check what's at line 77... (for example, according to GitHub classes/Attribute.php Line 77 is in a function's DocBlock for 1.7.6.7). You can compare the files in your install with the ones in GitHub for your version: https://github.com/PrestaShop/PrestaShop/tree/1.7.6.7 As I said - that's not the only file with that name (ps_factedsearch has one in its src directory, for example) and you need to also check if there's anything of that name in the override directory. If there is, then you can rename it temporarily, clear the cache again (changes in that directory are only picked up at a cache clear) and test again. Rename back -> cache clear to restore it. I'm surprised you got a result from debug mode but everything is worth trying when it comes to PrestaShop.... 😀 Good Luck!

Things you can immediately look at: - Try clearing the cache (manually by deleting var/cache/prod and/or var/cache/dev) - You can check the php error logs to see if this gives any clues. - Debug mode likely won't help you so likely not even worth trying. - Check Advanced Parameters -> Logs in the Back Office (but unlikely to show anything). - If possible in the Back Office try and create a new category. If there is just an issue with the category tree db structure then this can *sometimes* fix it. - Using phpMyAdmin check that the tables ec_category, ec_category_lang and ec_category_shop all have the same number of records. - Using phpMyAdmin check that the table ec_category_lang contains the names of the categories you expect. - Using phpMyAdmin check that the table ec_category_product has a number of records proportional to your shop (e.g. if 1,000 products this should contain > 1,000 records)

As a first step, did you refresh the rewrite rules? Shop Parameters -> Traffic & SEO under 'Set up URLs' You could also try toggling friendly urls off (save) and on (save) again. (And for good measure clear the cache)

From a list of commentary on Google Algorithm changes:

Just go to phpmyadmin and in the xx_configuration table add that record. It should fix the "error" although you can also "disable" it by changing the value of "PS_ALLOW_MOBILE_DEVICE" in that same table and setting it to 0 (not sure where/if it is configurable from the BO - probably under the theme settings). From the Context class: return isset($_SERVER['HTTP_USER_AGENT'], Context::getContext()->cookie) && (bool) Configuration::get('PS_ALLOW_MOBILE_DEVICE') && defined('_PS_THEME_MOBILE_DIR_') && @filemtime(_PS_THEME_MOBILE_DIR_) && !Context::getContext()->cookie->no_mobile; As I understand it, you would only enable this if you have a specific, separate mobile theme.