Phantom48 Posted March 30, 2014 Share Posted March 30, 2014 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 Link to comment Share on other sites More sharing options...
tuk66 Posted April 2, 2014 Share Posted April 2, 2014 See http://stackoverflow.com/questions/10303714/php-max-input-vars. You shoul increase more values: php_value max_input_vars 4500php_value suhosin.get.max_vars 4500php_value suhosin.post.max_vars 4500php_value suhosin.request.max_vars 4500 1 Link to comment Share on other sites More sharing options...
Phantom48 Posted April 2, 2014 Author Share Posted April 2, 2014 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 Link to comment Share on other sites More sharing options...
tuk66 Posted April 2, 2014 Share Posted April 2, 2014 Try to enable development mode in /config/defines.inc.php define('_PS_MODE_DEV_', true); if you can see more detailed error. 1 Link to comment Share on other sites More sharing options...
Phantom48 Posted April 2, 2014 Author Share Posted April 2, 2014 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 Link to comment Share on other sites More sharing options...
Phantom48 Posted April 11, 2014 Author Share Posted April 11, 2014 i upgrade to 1.6.0.6 and have same problem ;( Link to comment Share on other sites More sharing options...
machpro Posted April 20, 2014 Share Posted April 20, 2014 me too! Link to comment Share on other sites More sharing options...
lacanijilla Posted May 2, 2014 Share Posted May 2, 2014 me too! Link to comment Share on other sites More sharing options...
nhelliwell Posted July 21, 2014 Share Posted July 21, 2014 Is there a resolution to this? I still have this problem with 1.6.0.8 Link to comment Share on other sites More sharing options...
srgioalvs Posted August 2, 2014 Share Posted August 2, 2014 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 Link to comment Share on other sites More sharing options...
Xavier du Tertre Posted August 6, 2014 Share Posted August 6, 2014 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! Link to comment Share on other sites More sharing options...
nhelliwell Posted August 6, 2014 Share Posted August 6, 2014 Done: http://forge.prestashop.com/browse/PSCSX-2956 Link to comment Share on other sites More sharing options...
Xavier du Tertre Posted August 6, 2014 Share Posted August 6, 2014 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? Link to comment Share on other sites More sharing options...
nhelliwell Posted August 6, 2014 Share Posted August 6, 2014 updated one installation to 1.6.0.9 this morning, get the same error when updating the translation for my own theme. Link to comment Share on other sites More sharing options...
PrestaHeroes USA Posted August 6, 2014 Share Posted August 6, 2014 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 Link to comment Share on other sites More sharing options...
srgioalvs Posted August 7, 2014 Share Posted August 7, 2014 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. Link to comment Share on other sites More sharing options...
Xavier du Tertre Posted August 7, 2014 Share Posted August 7, 2014 This seems hosting related. Gregory tells me you guys are trying to solve this together on the Forge. Link to comment Share on other sites More sharing options...
Lermitte Posted August 8, 2014 Share Posted August 8, 2014 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. Link to comment Share on other sites More sharing options...
Vincent Terenti Posted August 18, 2014 Share Posted August 18, 2014 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, 1 Link to comment Share on other sites More sharing options...
MacRoy Posted August 20, 2014 Share Posted August 20, 2014 Hi! I had the same problem before and this has help. Try to set this to max_input_time = -1 Regards MacRoy Link to comment Share on other sites More sharing options...
Gregory Roussac Posted August 21, 2014 Share Posted August 21, 2014 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 1 Link to comment Share on other sites More sharing options...
nhelliwell Posted August 22, 2014 Share Posted August 22, 2014 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. Link to comment Share on other sites More sharing options...
piribipipi Posted August 22, 2014 Share Posted August 22, 2014 anyone knows the solution for this problem?? Link to comment Share on other sites More sharing options...
Gregory Roussac Posted August 25, 2014 Share Posted August 25, 2014 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 Link to comment Share on other sites More sharing options...
srgioalvs Posted August 26, 2014 Share Posted August 26, 2014 Reported the issue back to the hosting provider. Will update if I get any news. Link to comment Share on other sites More sharing options...
gabrielcr Posted August 26, 2014 Share Posted August 26, 2014 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! Link to comment Share on other sites More sharing options...
piribipipi Posted August 26, 2014 Share Posted August 26, 2014 Perfect! i hope godaddy solves my problem now Link to comment Share on other sites More sharing options...
srgioalvs Posted August 26, 2014 Share Posted August 26, 2014 Finally fixed after hosting provider disabling Suhosin. Link to comment Share on other sites More sharing options...
Gregory Roussac Posted August 27, 2014 Share Posted August 27, 2014 Finally fixed after hosting provider disabling Suhosin. Hi, Do you know which rule of suhosin was involved ? Thank you. Regards Link to comment Share on other sites More sharing options...
Liliana M Posted August 27, 2014 Share Posted August 27, 2014 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 Link to comment Share on other sites More sharing options...
Gregory Roussac Posted August 27, 2014 Share Posted August 27, 2014 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 Link to comment Share on other sites More sharing options...
gabrielcr Posted August 27, 2014 Share Posted August 27, 2014 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. Link to comment Share on other sites More sharing options...
PrestaHeroes USA Posted August 27, 2014 Share Posted August 27, 2014 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. Link to comment Share on other sites More sharing options...
Liliana M Posted August 28, 2014 Share Posted August 28, 2014 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. Link to comment Share on other sites More sharing options...
PrestaHeroes USA Posted August 28, 2014 Share Posted August 28, 2014 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). Link to comment Share on other sites More sharing options...
Recommended Posts