Paul C

The most "performant" way is to firewall them. You can use a free cloudflare account and set up security rules to block bots accessing urls with the offending query strings. For non-bots you can use "managed challenge" and in cases where folks have bookmarked the urls, then they can still access the page (albeit with a turnstile captcha). Just be careful to check that the requests aren't referred by your own host and are simply the ajax calls used by the faceted module (can be set up as part of the cloudflare security rules). Using cloudflare with Prestashop isn't without challenge though and your server may need to be appropriately configured to pass through the genuine visitor ip addresses (otherwise you'll have issues with ip-matched cookies). For cpanel accounts there was also a recent issue with an easyapache release that broke proxy servers (421 Misdirected Request Error). I assume you're also seeing these kinds of urls in Search Console? Probably not indexed. Bing seems to be one of the worst at crawling these urls but that should be prevented by an appropriately configured robots.txt, although search engines these days (possibly related to machine learning) seem to be much more free and easy about their crawls.... EDIT: Whether cloudflare works for you can also be down to the particular modules that you use, so careful testing is required. This is particularly true of cache and payment modules. I have had success with using it with PrestaShop 8.x though. Paul

If you echo out those environment variables you're using in your test script, do the values exactly match what you're entering in the database fields during installation?

Yes. The fact that mysqli calls works but Prestashop fails indicates that you need the pdo_mysql extension added to your php config. EDIT: Also make sure that the values returned by those environment variables match what you put in the Prestashop config (or use the environment variables themselves).

Certainly appears to be a network error. I assume you're 100% sure you've got the database config settings correct and the PDO extension for your database type (pdo_mysql for MySQL, pdo_sqlsrv for SQL Server) is configured for the php version you're using? Docker would be easier to deploy than creating a VM.

The import processes lines in the import file sequentially (otherwise there would be issues with storing the entire file in memory and the import script timing out if too big) so yes, you need to make sure that the parent categories are processed first before the subcategories. I believe it would work as one import as long as that is the case. I suspect that excel will use commas as separators and may "decorate" the fields making them look like strings. I remember back in the day using a good "CSV" editor that let you handle such files much easier (this was way back when ZenCart and osCommerce were all the rage). Sadly I can't remember what it was called!

OK so in a fresh install of the development branch (9.1.0) from git I created a very simple category import file with the following contents (Note that category id = 2 is "Home" and category id = 1 is "Root" so both are there by default and omitted): Category ID;Active (0/1);Name *;Parent category;Root category (0/1);Description 3;1;Women;2;0;Clothing for women 4;1;Men;2;0;Clothing for men 5;1;Shoes;3;0;Shoes for women 6;1;Shoes;4;0;Shoes for men I imported it successfully and have the two top-level categories "Women" and "Men" each with a subcategory of "Shoes". There is the issue however that both the "Shoes" subcategories have their link_rewrite field in the database set to "shoes". I then tried again (selected options to "Delete all categories before import" and "Force all ID numbers") with the following import file: Category ID;Active (0/1);Name *;Parent category;Root category (0/1);Description;Rewritten URL 3;1;Women;2;0;Clothing for women;women 4;1;Men;2;0;Clothing for men;men 5;1;Shoes;3;0;Shoes for women;shoes-women 6;1;Shoes;4;0;Shoes for men;shoes-men This seems to work for me and all of the categories were individually accessible.

I have some free time today so will set up a fresh install and try out a few things. The code 100% supports the intent that the "Parent category" field in the category CSV import file can be either a category name or an absolute category id.

@madpugger what version of Prestashop are you using? I'm not sure I understand the "broken tree" part. If the actual category tree structure is corrupt, then you would need to force it to recalculate. This can be done via code, or more simply - just add a random category from the back office. That will force it to recalculate the tree as a side-effect and you can then delete this extra new category once it's done. If you mean "broken" as in products in the wrong categories.... It does appear that you *can't* remove categories during a subsequent product import to update. During the import it appears to only add new categories for existing products (in controllers/admin/AdminImportController.php): if (isset($product->id) && $product->id && Product::existsInDatabase((int) $product->id, 'product')) { $product->loadStockData(); $category_data = Product::getProductCategories((int) $product->id); if (is_array($category_data)) { foreach ($category_data as $tmp) { if (!$product->category || is_array($product->category)) { $product->category[] = $tmp; } } } } The above code takes the existing categories and appends them to the categories you have in your import file (for existing products). Later it removes any duplicates. Ideally there should be a switch in there to specify whether you want to keep the existing categories or not. It would be worth logging it as a "feature request" (Prestashop github issues click "New Issue" and mark it as a feature request). I *think* that if you were to simply edit the line: $category_data = Product::getProductCategories((int) $product->id); To: $category_data = []; // Product::getProductCategories((int) $product->id); Then you would only set the imported categories for the product. This has the side-effect of removing any categories not specified in the import. Importing categories themselves is fraught. It *should* work but with some caveats. I don't use the default CSV importer but when I look at the example import file for categories (in the docs folder) you can indeed specify the parent category in the category import. Looking at the code (I'm looking at 8.2.0 right now, although I don't imagine it has changed much if at all since 1.6) you can specify either a name or an ID for the parent category. From the docs folder: Category ID;Active (0/1);Name *;Parent category;Root category (0/1);Description;Meta title;Meta description;URL rewritten;Image URL If you use a name for the parent category, then it will pick up the first category of that name that it finds as it's using Category::searchByName(). The parent category, if specified by name needs to pre-exist AND be unique for this to work. If the parent category is specified by an id, then everything should be fine as it subsequently finds the subcategory id using the function Category::searchByNameAndParentCategoryId() The upshot is that you should probably always use an absolute category id for the parent field, so make sure that you import the parent categories first. Best practice would be to import categories by level (i.e. first import parent categories, then separately import subcategories once you know the parent ids etc.). Since you have a category structure that you want now, then this is probably all moot for you, but maybe not for others starting their "import journey" EDIT: Note that I don't recommend modifying core files as suggested above. Doing it temporarily to sort out a problem is slightly different though and you can revert the change once the issue is fixed and then hopefully it gets fixed via a feature request. If I can find the time I might consider submitting a pull request with the necessary changes required to make the above happen, but there's no guarantee that the request will be accepted or which version it could be applied to, hence the question at the top of my response.....

I'm thinking this sounds a cache thing as I'm pretty sure I've manually "undeleted" tax groups like this before and it has worked; although I may not have edited the group afterwards (it was just to fix an accidental delete just to restore it to the previous state). I would make the change, then clear the cache (if you haven't already) and then try editing it. If that doesn't work though let us know and I'd be happy to try and replicate the issue here and see if we can work out what's going on. I've written custom import controllers to get data from POS systems and tax settings have been one of the biggest pains with it. I submitted a pull request that has been merged with 9.0.0 as getIdByName() in that class would return the first name it found even if it had been deleted and a new group of the same name added in again.....

PrestaShop doesn't index feature names, only their values so you'll need to modify the function that retrieves just the values of the features you want. You can do it by adding an override to the Search class (sadly there are no hooks you can use). Below is an example of code you would place in override/classes/Search.php (you need to clear the cache when you add or remove files from the override directory): <?php class Search extends SearchCore { /** * @param Db $db * @param int $id_product * @param int $id_lang * * @return string */ public static function getFeatures($db, $id_product, $id_lang) { if (!Feature::isFeatureActive()) { return ''; } $features = ''; $featuresArray = $db->executeS(' SELECT fvl.value FROM ' . _DB_PREFIX_ . 'feature_product fp LEFT JOIN ' . _DB_PREFIX_ . 'feature_value_lang fvl ON (fp.id_feature_value = fvl.id_feature_value AND fvl.id_lang = ' . (int) $id_lang . ') WHERE fp.id_product = ' . (int) $id_product . ' AND fp.id_feature IN (1,2,3)', true, false); foreach ($featuresArray as $feature) { $features .= $feature['value'] . ' '; } return $features; } } The above will only add the values of features with id_feature = 1, 2 or 3 (obviously you need to replace 1, 2 and 3 with the IDs of the three features you want included in search). The above override should work for any PrestaShop version from 1.6 -> 9.0 (this function hasn't changed in all that time).

Like everything there will be winners and losers. If you're an expert on a subject and write public articles that answer specific questions, then be prepared for your work to be summarised and delivered to people with no visit to your site. If you sell a unique enough product that satisfies a niche, then you might well get referrals. I suspect small stores that sell commodity items will find it tough, particularly during the wild west stage - and that could be a significant proportion of *your* potential customer base. Google has every incentive to shift traffic via its AI products and monetise the sh*t out of it. They'll charge extra "because it uses AI".

As long as the multishop PrestaShop version is the same as the original site you should be able to just move the tables that contain your catalog, customer and order data across. Assuming you're not merging multiple stand-alone shops. In the latter case you're going to need to update the tables of each shop in turn to modify id_shop to be unique for each. It's usually best not to copy over any of the configuration tables (including modules, tabs, carriers etc. etc.) just the purely "shop data" tables which are, as a whole, self-contained.

I've just recently come across this but I think it was maybe a low-level issue for a while. Despite the standard robots.txt file disallowing crawling for /*?q= amongst others (same happens with /*?order= and /*&order=), bingbot is particularly bad at deciding to ignore these entries and go crawling the many possible combinations. These aren't links that are in any way useful to have indexed. I have implemented custom security rules on cloudflare for a customer whose site was recently getting hammered both by genuine bots crawling these, along with a weird collection of other apparently random ip addresses (all with valid user agents set). The challenge solve rate on the "non-bot" requests was 0% indicating that it was indeed automated and/or malicious. The issue with just blocking non-ajax calls is that someone might genuinely want to bookmark a particular filtered page on your site and you want that to work when they visit it or if it has been shared and others click the link. Using a "Managed Challenge" strategy for these maintains functionality, whilst protecting your site. @mypresta.rocks I work with content creators who have seen a massive decline in traffic due to AI. Google's AI results are literally stealing clicks from these folks and is reflected in the above Semrush prediction of lower total visitor numbers over time. I suspect the decline will be steeper and any recovery slower. This is part of the reason that cloudflare now block AI training bots by default. In terms of internet quality, AI is a race to the bottom.

You'll likely never struggle to get freelance work if you have PrestaShop skills. Been trying to retire from it for years...... started with it when it was still in alpha. It went through a very rough patch around the launch of 1.7. Seems things have picked up again and the current core development team have got their act together. It can be a really strong contender as an upgrade to a woocommerce or Shopify store (although I know very little about the latter so could be wrong there). The advent of AI is a blessing as there will be even more work to fix the mess it makes.

I quickly tried an upgrade on a local docker container (was 8.2.0 I think) and get an ssl loop in back office login with nginx proxy manager so gave up until I have time to look at it properly. Maybe ssl handling has been "improved" or "updated". You can turn ssl off (in database) and back office works for me though. SSL misconfiguration can give a 500 server error.