Paul C

You can set specific prices for a product that is based on a whole number of factors (not just customer group) down to an individual customer (see attached image). The issue would be importing them all (I believe you can only import certains types of specific prices with the standard import tools). The query to select the price for the customer shouldn't slow the store down significantly but additional queries will obviously always slow things down to an extent. It wouldn't be impossible to script an import as long as you can create the import files with product id, customer id and the price for that customer.

@ZHSoft The OP was setting it up for theme and module development though. Even if he IS a store owner, given the garbage that I've seen that customers have bought from the addon store I would fully support a diy approach - assuming you have the necessary programming skills. There are great developers and modules on the addon store (I've come across the work of a good few), but the poor quality ones put people off to be honest. The summary of this thread is that his use of docker was a red herring (which is why it wasn't repeatable). The problem was with the data he imported.

Docker itself isn't complicated - the exact opposite. I can have an exact replica of a customer's production server with the same OS version, PHP version and database version spun up in minutes. Alternatively I can use the PrestaShop supplied images and have a known-good server up and running even quicker, for any version of PrestaShop I need (including server technology and subsystem versions). The problem encountered here was 100% down to data integrity and nothing to do with docker - the same problem would have existed using an outdated server build 1. You can use Git with docker and manage versions with ease. 2. You can make multiple backups of the database easily by taking down the instance, copying the persistent db data folder and then bringing the instance up again. Restoring to a known good point takes minutes. Much faster than an import/export regardless of the database size with no upload file limits etc. to worry about. 3. It can scale easily for multi-server setups. 4. It can be replicated exactly with ease on any machine you need it to be, or as per (3) - multiple instances, all exactly the same. 5. I can test modules and themes across multiple PHP and PrestaShop versions just by changing a couple of lines in the docker config file, or automate it. With docker everything is controlled and the majority of the complication of setting up a development environment are removed. You should try it. I certainly wouldn't want to go back to using the tools I used when I started with PrestaShop pre version 1.0.0 .....

@mtdkuser you're welcome. Sorry I couldn't help get you there quicker but I'm not sure I could have replicated it anyway!

Hi @buzzvicky by chance I actually had to do something similar and this is the hook I used (although I was just removing them, not adding my own): public function hookfilterProductSearch($arguments) { // Get the source data $searchVariables = $arguments['searchVariables']; // We need to build a new list of our included sort orders $new_sort_orders = []; if (!empty($searchVariables['sort_orders'])) { foreach ($searchVariables['sort_orders'] as $order) { // Filter out the ones we don't want if ( $order['label'] != $this->trans('Sales, highest to lowest', [], 'Shop.Theme.Catalog') && $order['label'] != $this->trans('Name, A to Z', [], 'Shop.Theme.Catalog') && $order['label'] != $this->trans('Name, Z to A', [], 'Shop.Theme.Catalog') && $order['label'] != $this->trans('Reference, A to Z', [], 'Shop.Theme.Catalog') && $order['label'] != $this->trans('Reference, Z to A', [], 'Shop.Theme.Catalog') ) $new_sort_orders[] = $order; } // Set our new sort orders $searchVariables['sort_orders'] = $new_sort_orders; $arguments['searchVariables'] = $searchVariables; } } Paul

Odd. Maybe they used a VPN? Not 100% sure how those restrictions are applied to be honest. It is a really weird one though and would be interested in whatever answer you do get! Paul

@ReneSoh that property is deprecated (per the change log): #################################### # v8.0-beta.1 - (2022-08-08) #################################### .... - #26685: [BC Break] Remove Order::$shipping_number (by @PierreRambaud) .... Maybe a module needs updating?

config/defines.inc.php could have been altered to enable debug mode. The others shouldn't have been modified unless deliberately (which wouldn't be a good idea anyway). None are a smoking gun for your particular issues though. I would replace the above files from the 1.7.8.11 archive too, however it looks like the upgrade hasn't gone well....

Download Version 1.7.8.11 and extract it. The files you need to replace are in the root of the themes folder: I would look at the Information page first though as it may not be necessary and could be an entirely different issue.

I think you need to replace the files in the theme directory with those from the 1.7.8.11 download archive. I suspect something hasn't been updated, but it's just a theory. Can you look at the "Advanced Parameters-->Information" page in the Back Office and check if it comes up with a list of file changes (at the bottom of the page. It will take a little while to populate)? Just in case we're looking in the wrong place.

That hook is just maintained for backwards compatibility. Here's an example module to add fields to the (symphony) product page: https://github.com/PululuK/democustomfields17

For sure it's a javascript issue. Those buttons beside the quantity are controlled by bootstrap touchspin and obviously the cart updates are done via ajax. Do things like quickview work? Have you spotted any other weird behaviour? It could be core.js in the themes directory (which also specifies the selectors used by the theme js) is missing or corrupt. You can download it from the appropriate branch on github.

Nothing to do with PHP 8. Those functions go way, way back. Native functions have existed and were alternatives since PHP 5.2.0.... safe to use json_encode() and json_decode() in modules that need to be backwards compatible with 1.7.

@ComGrafPL I've had success upgrading a theme easily from 1.7 to 8.... out of interest why do you think a complete new theme would be required? Is there anything in particular to look out for that would require a complete replacement? I guess for the inexperienced that's the only option and maybe that's what you mean. Tools::jsonEncode() and Tools::jsonDecode() account for the majority of incompatibilities in modules and even this shouldn't actually be a thing..... It appears that there's no penalty (or audit) when a module is sold on the Addons store, but relies on code that has been flagged as deprecated. In fact writing modules that way ensures additional income when a new version comes out and the deprecations are finally removed. "Compatible with" <> "written for" a particular version. In fact NO 1.7.x module ever sold should use these functions. 1.7.0 was released in November 2016. It does keep many of us employed though, picking up the pieces It's far too easy to criticise the core developers and the 1-click module... /** * @deprecated Deprecated since 1.7.0 * Use json_decode instead * jsonDecode convert json string to php array / object * * @param string $data * @param bool $assoc (since 1.4.2.4) if true, convert to associativ array * * @return array */ public static function jsonDecode($data, $assoc = false, $depth = 512, $options = 0) { return json_decode($data, $assoc, $depth, $options); } /** * @deprecated Deprecated since 1.7.0 * Use json_encode instead * Convert an array to json string * * @param array $data * * @return string json */ public static function jsonEncode($data, $options = 0, $depth = 512) { return json_encode($data, $options, $depth); }

Prestashop 8 wasn't such a huge leap to be honest (it was more to mark a new "era" for Prestashop) and your payment modules *should* work just fine if they have been properly written and maintained. You can always check with the author for updates. You might need to update your theme to support the new password policy (if your theme is remotely based on the classic theme then it could be a minor change for you by merging changes from the new classic theme. I would recommend using a tool like WinMerge to assist in updating a theme). It is also very much worth setting up a local staging environment and then doing the upgrade to test, of course! Changelogs https://devdocs.prestashop-project.org/8/modules/core-updates/8.0/ https://devdocs.prestashop-project.org/8/modules/core-updates/8.1/ New password policy https://github.com/PrestaShop/PrestaShop/pull/28127/ EDIT: You also need to check that any third-party modules you are using in your store support php8+ as well as PS8+. It should be fairly easy for module authors to upgrade compatibility.