tdc666 Posted January 30, 2014 Share Posted January 30, 2014 (edited) i've been posting about his over here, but i don't feel like the op of that thread is completely relevant to my issues, plus no one will respond. i figured i should make my own thread about it in a more appropriate place and bump it instead. i first noticed it when i was going through the catalog and updating pictures, giving each combo of each product their own images. this requires me to "save and stay" after assigning a photo to a combo. i would get through maybe one product when i would get an error message. "Some tabs was not loaded correctly. Would you like to reload them?" this lasts for up to 2 min and is happening as often as once every 60 seconds or so. when this happens, it takes out the current website that is unrelated to prestashop. we currently get ~60% of our business from our current website (trying to improve that with a new prestashop site), it's kind of a big deal when the site goes down. especially when it's every other minute and two minutes long. we've had customers calling complaining about the site being down. i made a video of it happening while i was uploading images (sorry for the music, i didn't think about frapps recording pandora) - http://youtu.be/KDFyRnVhFl8 i've been going through and adding prices, changing prices and adding specific prices, and this error has been happening consistently for days, weeks even. i would like some guidance as to what i should do. i don't know why it's happening to me and not other people. so far it's happened to me 10 times already in the last hour of work. i have no doubt it would have happened more, but i stopped working for a bit to write this and search around to see if anyone else is having this issue. haaaaalp! Edited February 6, 2014 by tdc666 (see edit history) Link to comment Share on other sites More sharing options...
selectshop.at Posted January 30, 2014 Share Posted January 30, 2014 Please check your server configuration for the minimal settings to run Prestashop. Ask your provider if you don't have access to phpinfo.php: Server configuration should be: magic_quotes_gpc = off memory_limit = 128M min. (better 256M) max_execution_time = 300 max_input_time = 300 upload_max_filesize = 20M post_max_size = 20M max_input_vars = 5000 allow_url_fopen = on safe_mode = off cURL - for Paypal and other services with API can to be work mod_rewrite = on Link to comment Share on other sites More sharing options...
tdc666 Posted January 30, 2014 Author Share Posted January 30, 2014 what does each of those configs do, and why would changing them stop this issue? Link to comment Share on other sites More sharing options...
tdc666 Posted January 30, 2014 Author Share Posted January 30, 2014 i tried your changes and now my prestashop is just a blank white page. Link to comment Share on other sites More sharing options...
selectshop.at Posted January 30, 2014 Share Posted January 30, 2014 The settings mentioned are for several server modules. If you want to know more about server modules, php and apache settings, please revert to apache manual, php manual or at least google search. It cannot be explained in 3 lines what each server module is responsible for. The issue you are having is due to a not for prestashop correct configured server. And yes, if you configure the server by the minimals suggested values, you will avoid these problems. Link to comment Share on other sites More sharing options...
selectshop.at Posted January 30, 2014 Share Posted January 30, 2014 What did you tried and where ? You have access to the server modules with cPanel and have rights for to do changes on that ? Please ask your provider for help on this. Link to comment Share on other sites More sharing options...
El Patron Posted January 30, 2014 Share Posted January 30, 2014 for pop up (original question) this post it not to address your changing php values. check that you do not have errors turned on in config/defines.inc.php This has been known to fix this issue, but not always. /* Debug only */ define('_PS_MODE_DEV_', false); Link to comment Share on other sites More sharing options...
tdc666 Posted January 30, 2014 Author Share Posted January 30, 2014 What did you tried and where ? You have access to the server modules with cPanel and have rights for to do changes on that ? Please ask your provider for help on this. i changed the configs as you said in the php5.ini file, which broke everything, hah. i guess i have to find an original version of my .ini file to upload to set my configs back to as they were. for pop up (original question) this post it not to address your changing php values. check that you do not have errors turned on in config/defines.inc.php This has been known to fix this issue, but not always. /* Debug only */ define('_PS_MODE_DEV_', false); i'll give this a whirl, assuming i can fix the damage done by selectshop's suggestions and get my shop back. Link to comment Share on other sites More sharing options...
selectshop.at Posted January 30, 2014 Share Posted January 30, 2014 The major problems of sever time out are incorrect or too shorten set values on the server modules. I'm not sure if by changing debug modus to false you will fix server time outs. Perhaps it can shorten some execution time, but at least do not solve the real problem, which are incorrect set values needed for prestashop script termination. i'll give this a whirl, assuming i can fix the damage done by selectshop's suggestions and get my shop back. sorry but for each change you make on your files you must do a back-up of the file before. It's not my fault. Link to comment Share on other sites More sharing options...
tdc666 Posted January 30, 2014 Author Share Posted January 30, 2014 ok, i fixed that php biz. errors are turned off /* Debug only */ define('_PS_MODE_DEV_', false); if (_PS_MODE_DEV_) Link to comment Share on other sites More sharing options...
tdc666 Posted January 30, 2014 Author Share Posted January 30, 2014 sorry but for each change you make on your files you must do a back-up of the file before. It's not my fault. the thing with a lot of those php.ini files on many hosts is that you can't access them and have to upload your own. you're unable to backup the original for that reason. i didn't mean for it to sound like it was your fault, sorry. it was my fault for assuming that taking my php.ini file out would revert it back to my host's original settings, which it did not. it's ok, i have it taken care of. Link to comment Share on other sites More sharing options...
selectshop.at Posted January 30, 2014 Share Posted January 30, 2014 Here you will find a suggestion of correct php-ini. http://www.prestashop.com/forums/topic/215803-dica-configuracao-do-servidor-com-phpini-optimizado-para-prestashop/?do=findComment&comment=1065710 Perhaps you added the files with a wrong format and therefore you are having a blank page. Link to comment Share on other sites More sharing options...
selectshop.at Posted January 30, 2014 Share Posted January 30, 2014 the thing with a lot of those php.ini files on many hosts is that you can't access them and have to upload your own. you're unable to backup the original for that reason. i didn't mean for it to sound like it was your fault, sorry. it was my fault for assuming that taking my php.ini file out would revert it back to my host's original settings, which it did not. it's ok, i have it taken care of. Simply make a copy and rename it ? That's how I'm managing it. Old is than php.ini.old or (bak) Link to comment Share on other sites More sharing options...
tdc666 Posted January 30, 2014 Author Share Posted January 30, 2014 my client uses godaddy, and godaddy has their php5.ini file stored away where you can't get to it. to alter the file, you have to create your own and upload it to your root directory with whatever config changes in it that you want. all of that was easy enough, but when it didn't work, i assumed i could just take my file out and it would go back to godaddy's default configuration, but it didn't. after looking around, i discovered the post_max_size and upload_max_filesize you suggested were too low for godaddy apparently. at least that's what i think it was, i changed it to 60M and that fixed it. Link to comment Share on other sites More sharing options...
El Patron Posted January 30, 2014 Share Posted January 30, 2014 i changed the configs as you said in the php5.ini file, which broke everything, hah. i guess i have to find an original version of my .ini file to upload to set my configs back to as they were. i'll give this a whirl, assuming i can fix the damage done by selectshop's suggestions and get my shop back. ...remember...we can suggest loads of stuff...it is up to all of us to 'always' back up original files. doh! for this please drop and give me 20 (push ups, and that is getting off easy) Good luck, look forward to seeing back on topic. Link to comment Share on other sites More sharing options...
selectshop.at Posted January 30, 2014 Share Posted January 30, 2014 Is 60 the max you can get on this webspace ? It is not enough for several Prestashop scripts. 300 is the best for to avoid time outs. Link to comment Share on other sites More sharing options...
tdc666 Posted January 30, 2014 Author Share Posted January 30, 2014 anyway, even with the php settings changed, i'm still getting the error and everything on my clients webhost is crashing. i read somewhere it could have something to do with the way prestashop pre-loads all of the tabs on the product pages, sending a bunch of querys to the server in a short amount of time, complied by me changing one thing on the product and then hitting "save and stay", which again pre-loads all of the tabs. essentially, the server things prestashop is launching a ddos attack every time i save and stay a few times on a product. Link to comment Share on other sites More sharing options...
tdc666 Posted January 30, 2014 Author Share Posted January 30, 2014 ...remember...we can suggest loads of stuff...it is up to all of us to 'always' back up original files. doh! for this please drop and give me 20 (push ups, and that is getting off easy) Good luck, look forward to seeing back on topic. i always back up files, but with no access to godaddy's php5.ini, i had no way to back it up. my mistake was assuming that after i removed the php5.ini file i uploaded it would revert to the settings on godaddy's php5.ini. it did not. 1 Link to comment Share on other sites More sharing options...
tdc666 Posted January 30, 2014 Author Share Posted January 30, 2014 Is 60 the max you can get on this webspace ? It is not enough for several Prestashop scripts. 300 is the best for to avoid time outs. post_max_size and upload_max_filesize has a limit of 128M with godaddy, which is where i have it set now. this is definitely enough, as godaddy's a pretty big webhosting service and a lot of ecommerce is ran on godaddy. Link to comment Share on other sites More sharing options...
tdc666 Posted January 30, 2014 Author Share Posted January 30, 2014 Good luck, look forward to seeing back on topic. i'm not sure how this is off topic, i'll try anything that might stop prestashop from taking down my client's currently live websites. i checked that my _PS_MODE_DEV was set to false, like you said, and it is. what next? Link to comment Share on other sites More sharing options...
El Patron Posted January 30, 2014 Share Posted January 30, 2014 i'm not sure how this is off topic, i'll try anything that might stop prestashop from taking down my client's currently live websites. i checked that my _PS_MODE_DEV was set to false, like you said, and it is. what next? uhm..so you didn't do any push ups? Then you should be hitting the like button often. let's move forward then yes and thank you for contact google valet service. ---------------- From: http://forge.prestashop.com/browse/PSCFV-5576 This could be mod-evasive for Apache that's responsible, at least it was for me. Disabling or edit settings for mod-evasive stopped this error. EDIT: Actually, disabling mod-evasive was the only solution that worked. No matter what settings I used, mod-evasive still got triggered. Link to comment Share on other sites More sharing options...
selectshop.at Posted January 30, 2014 Share Posted January 30, 2014 That's what I meant, I don't think it really solves the problem by turning debug modus to false. Perhaps it speeds-down the execution time and you will than have time out earlier. I don't know, but possible. Let it to false, if you are not debugging. 128 is better than nothing and when you are again having time outs you can inform customer about the problem. Customer should than take into consideration to change the hosting package. Time outs are not really good, because the scripts terminate before they can execute all what they should. Sometimes you will create lacks on database with this problem. Link to comment Share on other sites More sharing options...
tdc666 Posted January 30, 2014 Author Share Posted January 30, 2014 uhm..so you didn't do any push ups? Then you should be hitting the like button often. let's move forward then yes and thank you for contact google valet service. ---------------- From: http://forge.prestashop.com/browse/PSCFV-5576 This could be mod-evasive for Apache that's responsible, at least it was for me. Disabling or edit settings for mod-evasive stopped this error. EDIT: Actually, disabling mod-evasive was the only solution that worked. No matter what settings I used, mod-evasive still got triggered. i use that like button all the time! haha i've done my google homework, but i was mostly finding threads on this site that were never really resolved. turning off mod-evasive might be a solution for my client, they aren't really big or important enough to ever get ddos attacked, but that's kind of a hack job solution. is there a forum where we can make suggestions to the ps devs? because they really should re-think the way the product pages work if they are going to trip mod-evasive every time they are loaded up. Link to comment Share on other sites More sharing options...
El Patron Posted January 30, 2014 Share Posted January 30, 2014 btw: here is free module for phpinfo that is secure from access by outside world, also shows the values set by settings.inc.php and any other back office path (note front office path may differ so possible not all ps ini_sets are seen)..but significantly more accurate than sticking phpingo in root shop. http://www.prestashop.com/forums/topic/278164-free-module-display-php-environment-phpinfo-back-office/ 1 Link to comment Share on other sites More sharing options...
El Patron Posted January 30, 2014 Share Posted January 30, 2014 i use that like button all the time! haha i've done my google homework, but i was mostly finding threads on this site that were never really resolved. turning off mod-evasive might be a solution for my client, they aren't really big or important enough to ever get ddos attacked, but that's kind of a hack job solution. is there a forum where we can make suggestions to the ps devs? because they really should re-think the way the product pages work if they are going to trip mod-evasive every time they are loaded up. We are not in a position to know what you have already researched. After you try this and it does not resolve I do have others but prefer to work with one at a time. I do not mind helping this way. As for the suggestion, we are trying to find out if issue is affected by the change. Then we go from there is it's a reasonable way to resolve. If you would like to make a feature suggestion to development you can open them here: http://forge.prestashop.com/secure/Dashboard.jspa Please know that I like to also add some levity to posts. Link to comment Share on other sites More sharing options...
tdc666 Posted January 30, 2014 Author Share Posted January 30, 2014 alright! so! because my client is on a shared server i am unable to modify my htaccess to disable mod_evasive. what this also means, is that not only am i taking my client's website down every 4 min or so for up to two minutes, i'm also taking down all of our server neighbor websites! i got godaddy on the phone and they are totally fixing this up. they are putting us on a cpanel server at a discount and giving us access to our php and htaccess files and everything else. in the meantime they are whitelisting my ip so that i can keep working without taking down a couple thousand websites every four minutes. HOPEFULLY i can marked this solved here pretty soon. Link to comment Share on other sites More sharing options...
tdc666 Posted February 6, 2014 Author Share Posted February 6, 2014 alright, after fighting this issue for weeks, the guy at godaddy and i figured out that if you're using prestashop on a web host that uses shared servers with any kind of dos attack protection (which is 90% of the web hosting out there), you're pretty much out of luck. well, you are if you are speed-updating product pages, thanks to prestashop preloading all of those tabs each time you refresh a product page in back office. if you are having this issue, it's easy enough to ignore it, especially if you don't have a ton of products, but ignoring it can get you in trouble with your web host. every time your site goes down from this prestashop error, so does every other site on your shared server (usually a few hundred, at least). obviously, web hosts like godaddy aren't too happy about that, and they will take your site down and make life a general pain in the ass. as i said earlier, godaddy is putting us on our own cpanel server, which will take care of the issue. in fact, my godaddy rep has challenged me to take that server down, so i'm going to be pushing prestashop harder to see if i can. i am marking this thread as solved, even though the problem is still there. Link to comment Share on other sites More sharing options...
Recommended Posts