Paul C

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.

I thought that had been killed a long time ago! In my experience it was just used by scammers to get your site to send their spam to unsuspecting victims mainly..... Honestly, nobody (ok, very, very few people) email shop products to people. MUCH more likely to share something on their social media account of preference or text/pm a link.

id_shop_default isn't a required parameter so perhaps just don't include it? https://devdocs.prestashop-project.org/8/webservice/resources/products/ (Same for 1.7) Paul

To be fair Creative elements is designed to make the site design user-friendly, not to create a super fast site. Compromises. You should really test your site with an external tool, such as 'Pagespeed Insights'. The profiler really just gives an indication of where savings might be made. You could also consider using Cloudflare and/or another CDN.

It's only an SEO issue if it returns that permanently. Yandex doesn't know your planned maintenance, so warns you just in case it's an unintentional event/error From the RFC

It isn't an error, just a warning and it won't affect the working of your store. You can also get these where themes use other php functions such as in_array. Basically the smarty project is removing all the php function wrappers from their code and this is advanced notice that this will happen. If it *really* bothers you, then you can create a smarty modifier plugin as a wrapper, although you'll need to give the modifier a slightly different name and then search and replace them in your theme template files. For example for the php function is_array you can create a new modifier called isarray e.g. create the file <yourtheme>/plugins/modifier.isarray.php: <?php /** * Smarty plugin * * @package Smarty * @subpackage PluginsModifier */ /** * Smarty is_array php wrapper modifier plugin * Type: modifier * Name: isarray * Purpose: check whether input is an array or not and stop those pesky deprecation warnings * Input: * - Object|array: array or object to count * * @param mixed $$mixedInput input array/object * * @return bool */ function smarty_modifier_isarray($mixedInput) { /* * @see https://www.php.net/is_array * Returns true if value is an array, false otherwise. */ return is_array($mixedInput); } You would then search your theme and look for "is_array" e.g. a line like this: {if $product.customizations|is_array && $product.customizations|count} And you need to change it to the new modifier name which is: {if $product.customizations|isarray && $product.customizations|count} Then the warnings will stop (for that particular php function). Just need to repeat the process for any others, creating a modifier as appropriate.