When it comes to working with long running scripts and WordPress, you’re usually at the mercy of one of two things:
- PHP configuration file
- The server’s PHP configuration
Granted, the case could be made that these are one and the same, and in a sense they are, but if you’re working with PHP on your local machine, you clearly have more control over the environment than when you’re working on a web server.
Technically, if you’re working on a dedicated server, you should have full control over the configuration of the environment.
If that’s not the case, this is article won’t be of much use; however, if you’re in the business of working with PHP scripts on your local machine and a shared server, and you’ve hit the maximum execution timeout message, then there are a few of ways to go about handling the problem.
PHP Timeouts in WordPress
First, let’s say that you have a script that’s responsible for, say, processing n-number of items based on user input. This could be parsing an input file, writing to the database, looping through records to make updates, or so on.
Whatever the case may be, you’re running the script, everything grinds to a half, and your display (or your error log, depending on your configuration) reads:
Maximum execution time of 30 seconds exceeded.
There are a few of ways to combat this:
- Update the value in your `php.ini` file
- Define the value in your script
- Define a `set_timeout_limit` (if safe mode is off)
Any of these options will work fine, though I’m partial to the final option for this reason (according to the PHP manual):
When called, set_time_limit() restarts the timeout counter from zero. In other words, if the timeout is the default 30 seconds, and 25 seconds into script execution a call such as set_time_limit(20) is made, the script will run for a total of 45 seconds before timing out.
I like this particular function because if you’re running a static script, you can define this in, say, the the constructor or an initialization function of your script. Additionally, if you’re running a process via Ajax, then you can set this value in the function in that’s being called every so often via Ajax because it restarts the timer.
Secondly, I like this because it only adjusts the timer for a specific need. That is, it doesn’t change the values for the overall environment, just the script with which you’re working. This means that, say, the scope of the timer is relative only to your code rather than the entire environment in which the application is running (and in which timeouts may be enforced).
A Small Example
So what might this look like practically speaking?
First, we define the PHP script that includes an action that’s called via Ajax. Ideally, this function will be polled at certain intervals until the process is complete:
It’s also possible to define this value in the constructor of the class and have it work just as well.
That Thing About Shared Hosting?
If you’re running your work on a shared host, then changes are high that the above code will not work because they lock down the timeout process so that your script- no matter how well intended it may be – can’t impact the rest of the sites that are running on the server.
In other words, if someone was malicious, they could set a script to run forever which would proverbially bring down the entire shared machine and all the sites with it. So it’s not a matter of being stubborn or just poor decisions – it’s a protection mechanism.
But if you’re on a dedicated host or on a machine in which you have far more control, then you can use the above strategy (or simply just change the values in the PHP configuration file) and be good to go.