Error updating old products after 1-click upgrade 1.6.1.1->1.6.1.13

[KarZan]

Hello

 

I am experiencing an odd problem. I first made a copy of my webshop and tested 1-click would work. After validating a successfull upgrade I updated my webshop. Everything seemed fine but then I needed to do a change on an existing product and after clicking save or save and stay I end up on front office with an error telling the page I am trying to reach is no longer available. So I checked my test site and it had the same problem. Stupid of me not testing the product update I know.

 

But now comes the odd part. I can create new products and edit those just fine. Just the products I had before the update is not working. I tried also copying an old product and it acted as the old products. So only if I create a productt from scratch it works.

 

This is how the url looks like when the product update fails after save and stay:

/index.php?controller=AdminProducts&token=xxx&updateproduct&id_product=492

/index.php?controller=AdminProducts&id_product=616&updateproduct&conf=4&key_tab=Informations&token=xxx

 

So as you can see they look different. I just do not know why or where to look.

 

I did set all options to "no" in the 1-click page because I have done some minor changes how specials a shown and did not want to do it all over. Though I do use the default theme so the changes are minor.

 

I read through quite many posts but did not find any matching my problem.

[ASWEB]

Check out this code change. You need to remove the highlighted code.

 

https://github.com/PrestaShop/PrestaShop/blob/5566c2d9d7e4ab88a201b2c5cf10e1cda2ff7150/admin-dev/themes/default/template/controllers/products/helpers/form/form.tpl?utm_content=buffer6f45d&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer#L252-L254

 

It's related to Prestashop using unsupported code. The latest Chrome update in the last week has made this stop working.

[KarZan]

Thanks for the hint but I've seen that and there is no such code in form.tpl. Most likely it has been removed from 1.6.1.13 already. And anyway it would be odd if it would have affected only products added BEFORE 1-click upgrade.

 

So I assume this has something to do with the database. Is there something that has changed between 1.6.1.1 and 1.6.1.13. I would think some field is added or removed or is being handled differently.

[Masteries]

Try regenerating the .htaccess file.

 

1. Find and delete the .htaccess file from your Prestashop directory.

2. Go to the Back Office, navigate to Preferences > SEO & URLs.

3. Disable and re-enable friendly URL (don't forget to save in-between).

 

Also, try clearing the cache by deleting the cache folder manually: Prestashop directory > cache > smarty > delete the "compile" folder.

[KarZan]

Thanks for the hint but did not help.

 

I did notice though that removing text from description (leaving only the short description) it made the saving work. It seems like there is some problem in the data in the field although I can not find out what. I have a table in the old products description field but if I empty it and create a new table it works. I can not see any extra characters in the html code either.

[KarZan]

And just as additional information. If the description field is empty in the old product it does not work. And it cannot be fixed by adding something to the field. Odd as I said.

[KarZan]

Does anyone have any knowledge what is the difference between 1.6.1.1 and 1.6.1.13 databases? If I restore the code of 1.6.1.1 does it work with the DB? I was planning to downgrade from 1.6.1.13 to 1.6.1.1 so I would retain everything that has happened since I made this unfortunate upgrade.

[KarZan]

 

Mostly of the problems while upgrades faile are due to wrong server configuration and the use of extra addons or theme. In this case before upgrade disable them.

 

Than you should check the following:

 

1) Activate debug modus: https://www.prestash...l-server-error/

 

2) Delete server cache manually.  https://www.prestashop.com/forums/topic/351956-how-to-clear-prestashop-16-cache-manually/

 

3) check server configuration

 

It should be:

 

PS 1.6 X

• magic_quotes_gpc = off
• memory_limit = 256M (better: 512M)
• max_execution_time = 300
• max_input_time = 300
• upload_max_filesize = 20M
• post_max_size = 20M
• max_input_vars = 10000
• allow_url_fopen = on
• safe_mode = off
• cURL
• mod_rewrite
• php 5.4.5+  (+php-fpm, + opcache + fast-cgi - for better performance)
• server firewall like cageFS disabled or configured to don't block Prestashop services. Prestashop uses several external services.
• mod_security = off
• mySQL 5.5

 

 

I do have created a post of my problem

https://www.prestashop.com/forums/topic/610263-error-updating-old-products-after-1-click-upgrade-1611-16113/

 

I am using default theme. I do have some extra modules like for payment. But I've got almost a vanilla installation. I am wondering if it could be that I do not have English at all only local language (Finnish).

 

1) This I have not yet tried

2) Done but did not help

3) Configuration

- PS 1.6.1.13

• memory_limit = 512M
• max_execution_time = 30
• max_input_time = -1
• upload_max_filesize = 2M
• post_max_size = 8M
• max_input_vars = 10000
• allow_url_fopen = on
• safe_mode = off
• cURL yes
• mod_rewrite ?
• php 5.6.30  (php-fpm/opcache/fast-cgi do not know)
• server firewall is what it is with my provider but any time there has been any problems they have reconfigured it
• Prestashop services. Prestashop uses several external services. No knowledge
• mod_security = off
• mySQL 10.1.21-MariaDB-cll-lve

So as you can see there are differences. But everything was working fine before upgrade from 1.6.1.1 to 1.6.1.13

[selectshop.at]

Max_execution_time is too low. Scripts end before they run till the end.

 

Error-logs of the server when something does not work or fail should be read as well

 

I've splitted your post, cause it was off-topic where you added your question.

[KarZan]

Changed max_execution_time but it had no effect. I did not think it would since the page not available comes immediately after clicking save.

 

Also I activated debug mode but there is no error messages.

 

Then I made a test installation of totally new PS 1.6.1.13 and copied over the database from nonworking to this new installation. I know it should not be done since the systems are not quite identical. But I could reproduce the problem. Thus I still do believe the problem is in database. Maybe I should have upgraded like every minor change separately

 

So my question still remains: Is there any documentation on how 1.6.1.1 and 1.6.1.13 databases differ. Or better yet how has product handling changed.

[KarZan]

Just noticed I end up in page not found also when trying to update email translations. If that helps anyway. Maybe it has nothing to do with the products anyway?

[selectshop.at]

Cache deleted ?

 

1) Delete manually the cache on FTP from: delete all, except index.php and flus files

 

\cache\smarty\compile
cache\smarty\cache

\themes\seutema\cache

 

2) Delete browser cache.

 

3) Regenerate .htaccess

 

4) If you are using php 5.4+ deactivate any optional caching, like memcache, xcache or APC. You can deactivate this also direct on the file on ftp /config/settings.inc.php.

 

Change both lines to this one:

define('_PS_CACHING_SYSTEM_', '');
define('_PS_CACHE_ENABLED_', '0');

[KarZan]

Cache has been disabled already and deleted both from bo and manually on the server.

Tried different browsers in different OS in different computers. Even android.

Also regenerated .htaccess already.

 

No change.

 

And to make things more weird some products can be edited???

Edited June 2, 2017 by KarZan (see edit history)

[selectshop.at]

server error-logs are saying what ? There must be error written in this case.

[KarZan]

I have no access to actual server error logs. Server access logs has nothing peculiar which could give a hint of what the problem is. When comparing a succesfull product update to nonsuccesfull one there is only three GET statements and no POST statements in the unsuccessfull case but when successfull there is two POST statements and over 10 GET statements.

 

I am not getting 404 from the server but prestashops own "page not available" page. And thus it is understandable that there is no error on the server logs.

 

And I would like to stress that all was working with 1.6.1.1 but just after upgrading to 1.6.1.13 this emerged. And I have now noticed that some products can be updated and some cannot. I have also noticed that in some cases by removing description text the update goes through but it does not apply always. Sometimes there is nothing in description and it still does not work.

[selectshop.at]

Well if you are getting 500 or 404, or nothing this depends on server configuration. When you configure the server there are several options for this. I'm sure error logs are written on mass as well in this case. And only these one can give you real information of about what is going on on your server at the time you are saving products that they are not saved.

[KarZan]

I believe I have said it a couple of times already. I am not getting 404 or 500 or any other webserver error message. I am getting prestashop "page not available" page. There is header and footer from my shoo and on the middle text saying "page not available". So from the web server point of view there is no error.

[KarZan]

Some additional information.

 

I installed a test shop with the same version I now have in production. I copied products data from the production to this new installation. Now I have a bit different situation.

 

If I edit one of those copied products I get

 

"You don't have permission to access /admin/index.php on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request."

 

But I can create a new product and edit it just fine. So obviously it should not really have anything to do with the permissions?

 

So my test shop is 1.6.1.13 with default modules and default settings. Just copied the images and the following tables over:

ps_attribute

ps_attribute_group

ps_attribute_group_lang

ps_attribute_group_shop

ps_attribute_impact

ps_attribute_lang

ps_attribute_shop

ps_category

ps_category_group

ps_category_lang

ps_category_product

ps_category_shop

ps_feature

ps_feature_lang

ps_feature_product

ps_feature_shop

ps_feature_value

ps_feature_value_lang

ps_image

ps_image_lang

ps_image_shop

ps_layered_category

ps_layered_filter

ps_layered_friendly_url

ps_layered_indexable_attribute_group

ps_layered_indexable_attribute_group_lang_value

ps_layered_indexable_attribute_lang_value

ps_layered_price_index

ps_layered_product_attribute

ps_manufacturer

ps_manufacturer_lang

ps_manufacturer_shop

ps_product

ps_product_attribute

ps_product_attribute_combination

ps_product_attribute_image

ps_product_attribute_shop

ps_product_lang

ps_product_sale

ps_product_shop

ps_product_supplier

ps_product_tag

ps_specific_price

ps_specific_price_priority

ps_stock_available

ps_supplier

ps_supplier_lang

ps_supplier_shop

 

At the moment it looks like it would have something to do with the products data. So I removed all text from both short and long description fields and was able to save the change. Then I copied the same text without any formatting and was also able the save the change. Then using the rich editor I changed colour of one word and was not able to save anymore. I can bold the word and make it a heading but it seems I cannot change the colour. And there are some products with table of sizes I had to remove formatting from the table to be able to save the changes.

[KarZan]

I have now double checked that on a vanilla 1.6.1.13 setting text color on a product description text using the in built rich text editor tools gives:

"You don't have permission to access /admin_folder/index.php on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request."

 

Can anyone confirm this?

[musicmaster]

The database differences between the versions can be found in the directory install/upgrade/sql. Every file contains the changes from the previous version. But I don't think that your problem is here.

 

If you use a debugger (like with F12 in Chrome) you can see which GET and POST ajax commands are made but you can also see what was returned. The latter might contain some error message.

 

Did you switch Development mode on? https://www.prestashop.com/forums/topic/224525-how-to-turn-on-error-reporting-for-debug-information-blank-page-500-internal-server-error/

 

One possibility is that somehow your TinyMCE settings have gone wrong.

[KarZan]

I agree it is not the DB difference. As I posted last I installed new 1.6.1.13 instance and then just created a new product. Nothing fancy just a simple product with only mandatory fields entered. Then after creating the product I edited it and put one word in desription and changed the colour of the text to red (ff0000). Saving the product gave me an error telling me I do not have rights to edit index.php file in the admin folder. Removing the colour red definition allowed me to save changes.

 

So to mee it looks like there is an actual bug but would like to hear if someone else could confirm it.

[selectshop.at]

Cannot confirm that it is a bug. I'm using 1.6.1.14 since yesterday. Here I can change text/colors without any problem.

 

Do you know if your server is configured to use varnish external caching ? Which php version are you using ? any extra caching activated on back-office. Tab "Advanced parameters" -> performance -> last section = Caching.

 

In last case update to 1.6.1.14.

 

If this applies:

 

 

One possibility is that somehow your TinyMCE settings have gone wrong.

 

Than it would be corrected during update.

[KarZan]

I have not had the possibility yet to upgrade to 1.6.1.14 so do not know if it would fix this.

 

I do not know if server is configured to use varnish external caching since it is webhosting. PHP version I think I mentioned earlier but it is 5.6.30. No extra caching activated. All caching has been disabled.

 

It would be odd if TinyMCE settings would have changed since as I also mentioned before I have put up a fresh 1.6.1.13 installation and still the text color addition causes error on any product.

 

Anyway I need to test the 1.6.1.14 upgrade at some point when I have the possibility.

 

EDIT:

I have not had the possibility to try the upgrade and the problem is gone??? I have not done anything. My only conclusion is there was something in the hosting that caused the problem in the first place and some change there has fixed my problem. I noticed PHP version is now 5.6.31 which is one minor bigger. And MySQL is now 10.1.24-MariaDB which is three minor versions higher. So not big changes. And now I installed mailchimp module and when updating contacts to mailchimp I still get the same error. Which seems odd and looks like it would have something to do with PHP settings. But this happens only on the first time using the module. So I will have a go with upgrading to latest 1.6 version on my test shop and see what happens
 

Edited August 5, 2017 by KarZan (see edit history)