webbrent

Hi Everyone, The first time this happened I was like okay that is bizarre and shrugged it off, but now it has happened a 2nd and a 3rd time. So now it is no longer a coincidence . Prestashop - 8.1.7 PHP - 8.1.29 I have had customers checkout their order only for their order to throw an error when attempting to open the order in the backend. The error being as per the attached. After reviewing of the issue it was found that the id_address_delivery field contained a customer address ID that was non existent as per the screenshots attached. A simple fix was just to add the correct customer address ID's to the Database and then the order became accessible in the backend. My concern though is how is this happening? Once is a coincidence but it is now 3 times that this has happened. Each time it has been a customer processing an order from the front-end.

Seems like the CDN is problematic again today. Is there anyway to disable this? Or better yet, should it be disabled?

I have a 8.1 client that has no issues - it is only 8.2 that is effected thus far. Shocking that a stand alone instance has to be dependant on an external CDN to operate efficiently. i know previous versions we used to disable comms with addons.prestashop to prevent these kind of performance issues and delays when addons.prestashop was experiencing latency issues. Seems to now be sorted out, but was not a great thing to wake up to on a Saturday morning.

I am assuming they have a separate CDN then per instance of Prestashop available as this is only effecting 8.2 instances?

Just to add, I have various other installations on the same host including 1.7.X and 8.1.2 installations and all of them are without issue.

Hi Everyone, I have multiple 8.2 installations that seem to have just gone haywire overnight. The front-ends are responsive and processing of orders is quick and without issue. It is however when accessing the admin back-end that the performance issues are being experienced. I have multiple hosts with multiple various installations. Anything below 8.2 is not experiencing any issues and is super responsive. I am seeing a lot of API calls received as per below in the logs - I am wondering if these instances of Prestashop are not trying to communicate with a Prestashop API of sorts which is problematic or experiencing an outage? It seems to be very haphazard and seems to have spurts where it is okay momentarily and then just reverts back to slowing down. API Call received = /adminXXXXXXXXX/index.php?controller=apiSecurityPsMbo&token=XXXXXXXX Any advise or assistance will be greatly appreciated.

We found that a hard refresh of local cache on the back-office and front-end cleared the issue for us. Check in a Incognito window or on a new device if the problem arises, if not then it is a local caching issue.

The server was preconfigured and a blank install of the latest Prestashop installed to perform the migration from the source shop. I have resolved the matter though - It would seem that it was just a local caching issue of sorts on the users device.

Migration Pro just moves your data from one instance to another - Not sure how it would be a Migration Pro issue? The Prestashop products page adjust stock quantity function is not allowing stock manipulation however it can be changed from Stock Manager.

Hi Everyone, I have a bizarre issue and hope that there might be some guidance. We have recently migrated a very very old site from Prestashop 1.5 to 8.2 using Migration Pro - The migration was a success and now the client is operating on Prestashop 8.2 on PHP 8.1.29. Stock Management is enabled as well. When opening a product and attempting to adjust the stock level it fails to update the stock level adjustment, so the stock just doesn't change whether it be an addition or subtraction stock adjustment. I can however from the Catalog --> Stock --> Stock Management window adjust the stock levels with success. I am actually stumped why this would be an issue and whether or not it is a potential bug that needs reporting? Perhaps I am missing something else? TIA For any recommendations or insights.

I recently had the same issue - I just bumped the website down to php7.3 instead of using 7.4 - Seems to have done the job.

Hi Everyone, I am experiencing a File Manager issue where it refuses to open or load. See attached Screenshot. The site is using Prestashop 8.1.4 with PHP 8.1. We have another site using the same PS and PHP on a different host that is not experiencing this issue. I originally had the site on PHP 8.2 however I downgraded it to PHP 8.1 as there were significant speed issues and noticed that 8.2 is not supported. I have noticed that if I turn off the Prestashop Marketplace Backoffice module that it rmeedies the issue - But surely this be having the effect that it is? Any insight or fix is welcome to keep Prestashop Marketplace Back office active will be appreciated.

Thank you @eugenata this worked for me and sorted out my problems as well...

Good Day SikoDK, No we are using the Akira theme. I have checked your shop and yes that is how I would like it to operate. I have raised the matter with the Theme Creator as well. However I see the redirect after adding to cart in the BO is no longer an optional configuration.

Hi Everyone, I know older versions of Prestashop used to have an option to select what happens with navigation once a product was add to the cart. The options used to be redirect to cart or stay on page. With Prestashop 1.7.8.7 and PHP 7.4..30 this option is just seemingly not available anymore? How would one go about now about ensuring that navigation stays on page instead of directing to cart/checkout? I have turned off the AJAX cart for the theme and it is definitely speeding up cart additions, but the redirect is painful. Any advice will be greatly appreciated. TIA,

I have isolated the module causing the error... Data mining for statistics seems to be throwing the aforementioned error. When disabled it stops throwing the Apache Error with regards to "Missing $Template Parameter. However now it has started throwing the following error when navigating the "Dashboard" section of the BO. I have attempted to reset the module and it has done nothing favourable either. Perhaps a total removal of this module would be more ideal.

I am assuming these changes are made in the smarty_internal_templatebase.php? My line 177 in this php file reads as follows: I am utilising PS 1.7.8.7 with PHP 7.4.30 - I am assuming there have been changes made previously to fix this with a release, but it now seems to have reared its head again. Any advice will be most certainly welcome as this error is slowing down our sites as well as effecting our sales in the process. TIA

Still nothing? Has anyone managed to solve this issue as of yet?

I see many are having the same issue, but there seems to be no resolution to the matter?

I can't believe I am the only person experiencing this issue? Surely there must be others?

Just giving this a bump, can't believe I am the only one to experience this issue.

Perhaps also to note that I am running the same them/template on another site on another server with PS 1.7.7.8 and php 7.2.26 and not experiencing any of these issues. So it shouldn't be a theme/template issue.

Hi Everyone, Hope everyone is well. I have migrated to a new server over the past week as I was having issues with the old site. I have moved to Prestashop 1.7.8.7 and using PHP 7.4.30. I am getting thousands of the following error in my apache error log. I have searched and there seem to be a lot of similar cases out there but no definitive remedy for the situation. It is every time something is clicked on the site it just throws out this apache error log. It is not effecting of the site operates, but it is definitely frustrating from a server administration side and also I am sure it is effecting performance and possible SEO. Has anyone run into the same issue or come across it and been able to resolve the matter? Thanking anyone in advance for their assistance.

Once selected it then allows the upload and shows the image in the category configuration page, however it does not display the image in the front-end. I assume this is because there is a 200 px x 200px configured to display with the categories option selected as per attached. I am assuming the them is referencing that Image Settings to display the category image. Perhaps these additional Apache Errors could be an accomplice to the issue:

Additional Information, not sure if it is 100% relevant, here is an error in the Apache Error Log that could be a possible symptom? PHP Fatal error: Uncaught --> Smarty: 0():Missing '$template' parameter <-- \n thrown in /var/www/domain.co.za/html/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php on line 177, referer: https://domain.co.za/253-product-co