500 Internal Server Error

[facethefuture]

Hi

I am running prestashop 1.6.0.14

I have an issue when trying to generate PDF invoices. If there are less than 100 invoices to generate, there is no problem, however if there are over 100 then I get a 500 Internal Server Error.

I have tried enabling PS_MODE_DEV, however no information is provided (still get the 500 error page).

The error also generates when trying to do something in bulk, e.g. regenerate all images / delete lots of products.

I have changed the memory_limit on my server to 1024M within the PHP configurator, and changed the max_execution_time to 3000, this still didn’t work.

Whilst doing further tests I changed the memory_limit to -1 for unlimited without success.

Can anyone else suggest anything to change? I believe it has to be the server configuration as it has only been an issue since we switched servers last month.

I have been searching for hours but can’t find a solution on these forums.

My new hosting company are looking into it but thought someone on here may have come across this before with a solution?

Thank you.

[NemoPS]

It really looks like a timeout or resource limitation, is it taking long before you get error 500?

[facethefuture]

Hi NemoPS

 

When trying to generate the invoices, it generates the error after approx 40 seconds.

 

The size of the file wouldn't be overly large either only a couple of mb max.

 

Any assistance would be apprecaited.

[CareBearStare]

As Nemo said, it does look like a time-out error (or possible resource issue) but wouldn't think it's down to the memory limits.

Try setting both

max_input_time & max_execution_time

Another thing to try, since you run 1.6.0.14, is to add those values to your /config/config.inc.php under: /* Improve PHP configuration to prevent issues */

[facethefuture]

The max_input_time & max_execution_time are both currently set to 3000 via the php configuration.
 
How exactly would I set it in the config, would it be:

 

ini_set('max_execution_time', 3000);

ini_set('max_input_time', 3000);

 

Also, how could I change the resource issue / limitation? Our new server is more powerful than our previous server.

 

Thank you

[NemoPS]

you mean how to change it in php.ini? Should be like

max_execution_time 0

max_input_time 0

To remove the limit

[facethefuture]

No, I am asking how to add the values to what the previous poster said:

 

--

Another thing to try, since you run 1.6.0.14, is to add those values to your /config/config.inc.php under: /* Improve PHP configuration to prevent issues */

--

 

I don't need to add them to a php.ini file as I can change them directly on the server via the php config tool.

[CareBearStare]

How exactly would I set it in the config, would it be:

 

ini_set('max_execution_time', 3000);

ini_set('max_input_time', 3000);

 

 

Yes, that would be how you set it in config/config.inc.php even if it's set in your php.ini as for memory_limit, I haven't seen any advantage of adding it to config.inc.php.

Another thing to check, if you are running Prestashop on a server with cPanel options such as:

1. MultiPHP INI Editor - make sure your Prestashop directory uses the correct php version.
2. PHP Selector with extensions - check so your PDF/TCPDF are compatible with the php version you are running. If you are running it on a dedicated server or VPS, note that there has been some issues with TCPDF and php7. There is in(famously) a major security flaw with a Wordpress plugin called Pro Sites where an error in TCPDF causes lots of vulnerabilities if running php7. Interested in how severe of a flaw if TCPDF and/or php7 is configured poorly? Google "pro-sites-files/tcpdf/tcpdf.php" (for educational purposes only obviously).

No idea, absolutely none... if this is relevant but I stumbled upon it on php.net while searching for integer issues and php7: Warning Prior to PHP 7, if an invalid digit was given in an octal integer (i.e. 8 or 9), the rest of the number was ignored. Since PHP 7, a parse error is emitted.

[CareBearStare]

Found this, might be of interest also:

 

If you render your HTML using a secondary PHP process (e.g. using exec()) the execution time and memory limits are eased. When rendering in this method you save the rendered PDF to a directory on the web site and redirect the user to the download (or even email them a link if you want to run a rendering queue). Generally I've found that this method does offer modest improvements in speed and memory use.

That doesn't, however, mean the render will perform significantly faster in your situation. Rendering tables with dompdf is resource intensive at present. What might work better, if you can, is to break the document into parts, render each of those parts separately (again using a secondary PHP process), combining the resulting collection of PDFs into a single file (using something like pdftk), then saving the PDF where the user can access it. I've seen a significant performance improvement using this method.

Or go with something like wkhtmltopdf (if you have shell access to your server and are willing to deal with the installation process).

Source: http://stackoverflow.com/questions/16202461/php-and-dompdf-how-to-generate-a-large-pdf-without-having-my-server-come-to-a