[Solved for most] Can't save Front Office Translation. have 404 error (permissions)

[Phantom48]

Hello all

 

i have problem with 1.6.0.5 Prestashop

 

I can't save Front Office Translation. after click save ot save and stay i see 404 page

other types of translations work. don't work only Front Office

 

befor i see problem  with suhosin and max_input_vars

 

i make max_input_vars = 4500

 

Help please

 

thanks

[tuk66]

See http://stackoverflow.com/questions/10303714/php-max-input-vars. You shoul increase more values:

 

php_value max_input_vars 4500
php_value suhosin.get.max_vars 4500
php_value suhosin.post.max_vars 4500
php_value suhosin.request.max_vars 4500

[Phantom48]

i try, but when i increase 4500 for FrontOffice i see 404 error. for one other part i have error message with info about i must increase 4935.

now i make 10000 for all values. and for FrontOffice translation not work. after click "save i redirected to 404 page.

 

i try reinstall prestashop, and try after install without any changes. don't work

[tuk66]

Try to enable development mode in /config/defines.inc.php

 

  define('_PS_MODE_DEV_', true);

 

if you can see more detailed error.

[Phantom48]

i make. any changes. 

when i in admin panel in translations for frontoffice.

url : ../admin156/index.php?controller=AdminTranslations&lang=ru&type=front&theme=default-bootstrap&token=4a8a913b9feabc5a9ed16df5b56103f6

 

after i click save or save and stay

url change: ../admin156/index.php?controller=AdminTranslations&submitTranslationsFront=1&token=4a8a913b9feabc5a9ed16df5b56103f6

 

and i see 404page in frontoffice style, not admin panel.

 

any error not show

[Phantom48]

i upgrade to 1.6.0.6 and have same problem ;(

[machpro]

me too!

[lacanijilla]

me too!

[nhelliwell]

Is there a resolution to this?  I still have this problem with 1.6.0.8

[srgioalvs]

Same problem here. Fresh install of 1.6.0.8 and PT translation.

 

a) php settings of max_input_vars are not causing the 404.

My server had a low limit and already in the BO selecting "backoffice translations" would give a warning that my input vars limit was too low and would not allow editing.

Fixed this and I can see the "backoffice translation" strings.

 

indenpendently of max_input_vars now being higher than required (7500) any attempt to "save" or "save and stay" generates a 404 error. - /index.php?controller=AdminTranslations&submitTranslationsBack=1

 

Dev mode is on, but where do I find the error log?

 

Thanks

[Xavier du Tertre]

Hi everyone,

 

This issue doesn't seem to have ever been reported on the bug tracker. Could you submit it on http://forge.prestashop.com please?

 

Cheers!

[nhelliwell]

Done: http://forge.prestashop.com/browse/PSCSX-2956

[Xavier du Tertre]

Our developers can't replicate the bug on 1.6.0.9... Any chance you can update your PrestaShop and check if you still have the bug?

[nhelliwell]

updated one installation to 1.6.0.9 this morning, get the same error when updating the translation for my own theme.

[El Patron]

maybe this post will work for you as it did other community member.  fingers crossed

 

http://www.prestashop.com/forums/topic/257980-cant-save-updated-translations-404-redirect-site-unavailable-urgent/?p=1286416

[srgioalvs]

Hi.

I'm using 1.6.0.9 and have the problem.

Also, tried the fix suggested by El Patron but it didn't work.

 

Xavier, if you want I can create a fresh install and give your guys access.

[Xavier du Tertre]

This seems hosting related.

 

Gregory tells me you guys are trying to solve this together on the Forge.

[Lermitte]

Same problem for me on 1.6.0.8.

 

I tried doing many translations and saving after it then 404. Doing them one by one was working until a certain point where I get 404 even for one small translation.

 

Here is the details of my php config:

max_execution_time : 300

max_imput_time: 600

max_imput_vars: 6000

memory_limit: 256M

 

This is happening to me only for back-office translations. So far Email,PDF,Front-Office translations were working without any problem.

[Vincent Terenti]

HI srgioalvs,

 

Could you please send me your FTP and Back Office access at this email adress : [email protected]

 

It could be easier for us to find the problem

 

 

Best regards,

[MacRoy]

Hi!

 

I had the same problem before and this has help.

 

Try to set this to max_input_time = -1

 

 

 

Regards

 

 

MacRoy

 

[Gregory Roussac]

Same problem here. Fresh install of 1.6.0.8 and PT translation.

 

a) php settings of max_input_vars are not causing the 404.

My server had a low limit and already in the BO selecting "backoffice translations" would give a warning that my input vars limit was too low and would not allow editing.

Fixed this and I can see the "backoffice translation" strings.

 

indenpendently of max_input_vars now being higher than required (7500) any attempt to "save" or "save and stay" generates a 404 error. - /index.php?controller=AdminTranslations&submitTranslationsBack=1

 

Dev mode is on, but where do I find the error log?

 

Thanks

 

 

HI,

 

If I reduce the number of input fields in the form on your site then the issue does not happen, so it means this is somehow a server security limit and I believe this looks like suhosin mod is blocking the request despite the apparently good configuration. IE, if your small forms are ok, then it 's a security feature involved.

 

404 because the server seems to kill parameteres sent in $_GET or $_POST, like the controller name for instance, so it sends you to front office which is lost too and redirects to the 404 controller. Not a code issue.

Maybe having a look at logs for suhosin or mod_security would give more clues ?

 

Regards

[nhelliwell]

Hi,

 

Yeah, not a code issue.  Hoster removed, or disabled, something in mod_security, and the problem went away.  We'll work through it at some point to find exact cause, and/or solution.

[piribipipi]

anyone knows the solution for this problem??

[Gregory Roussac]

Hi,

 

Yeah, not a code issue.  Hoster removed, or disabled, something in mod_security, and the problem went away.  We'll work through it at some point to find exact cause, and/or solution.

 

 

Hi,

 

Can you please tell what was removed or changed ?

 

Regards

[srgioalvs]

Reported the issue back to the hosting provider. Will update if I get any news.

[gabrielcr]

Hello All, I use Go daddy and prestahop 1.6.0.9. this issue was happening to me, i could update Front office, back office, mails, etc.. everthing except modules for any theme.

 

after more than one hour in a call with goDaddy Support, they said indeed there was a configuration on the server (mine is a shared host) and they changed some rules specific for my host. I requested for them to give me the rules they changed so i could post them here angd give you a hint, but they said those rules are confidential. nevertheless they are supposed to add this info to their server to have a beter idea of wwhat ws the problem in the future and hopefully take less time fixing it uppon your call.

 

fixed now!

 

thanks for letting me know this was a host problem!

 

 

[piribipipi]

Perfect! i hope godaddy solves my problem now

[srgioalvs]

Finally fixed after hosting provider disabling Suhosin.

[Gregory Roussac]

Finally fixed after hosting provider disabling Suhosin.

 

Hi,

 

Do you know which rule of suhosin was involved ? Thank you.

 

Regards

[Liliana M]

Hi

 

I have the same problem it is happening only for the installed module translations. The other translations modules are ok.  

 

 

 

Liliana

Prestahop 1.6.0.8

[Gregory Roussac]

Hi

 

I have the same problem it is happening only for the installed module translations. The other translations modules are ok.  

 

 

 

Liliana

Prestahop 1.6.0.8

 

 

This sounds more like a right issue on module folders.

 

Regards

[gabrielcr]

well, not necessarily, I had exactly the same case than Liliana, only modules had the problem, everything else was ok. at the end it was a server security configuration. Godaddy did not want to tel me exactly which rules they changed as this is a shared host and they reserve the right to keep that "confidential" being a security topic. But certainly whatever they did on the server rules fixed it.

[El Patron]

well, not necessarily, I had exactly the same case than Liliana, only modules had the problem, everything else was ok. at the end it was a server security configuration. Godaddy did not want to tel me exactly which rules they changed as this is a shared host and they reserve the right to keep that "confidential" being a security topic. But certainly whatever they did on the server rules fixed it.

 

check permission of modules folder, sub-folders and files.  if any have 777 (higher than hosting allowed for example) they can cause 500 call.  typically for ps install (most hosting) 755 folders 644 files 664 .htaccess.

 

so I suspect in your case, that godaddy turned off permission to check to high of a permission to run safely.  checking.

[Liliana M]

SOLVED    

 

My hosting provider did a fix, and they also told me that while I was saving the translations, the online store should be activated (not in maintenance)

 

The only info I gave to my hosting provider was "Check permission of modules folder, sub-folders and files.  if any have 777 (higher than hosting allowed for example) they can cause 500 call.  typically for ps install (most hosting) 755 folders 644 files 664 .htaccess." EL patron

 

 

Liliana.

[El Patron]

check permission of modules folder, sub-folders and files.  if any have 777 (higher than hosting allowed for example) they can cause 500 call.  typically for ps install (most hosting) 755 folders 644 files 664 .htaccess.

 

so I suspect in your case, that godaddy turned off permission to check to high of a permission to run safely.  checking.

 

 

SOLVED    

 

My hosting provider did a fix, and they also told me that while I was saving the translations, the online store should be activated (not in maintenance)

 

The only info I gave to my hosting provider was "Check permission of modules folder, sub-folders and files.  if any have 777 (higher than hosting allowed for example) they can cause 500 call.  typically for ps install (most hosting) 755 folders 644 files 664 .htaccess." EL patron

 

 

Liliana.

 

glad this is sorted for you.

 

I am closing this topic, if you have same or similar issue please follow guidance in this thread, if they do not work for you please do one or both of the following:

 

1. open forge bug report

2. open new topic (for best community review).