Make WordPress Core

Opened 12 months ago

Last modified 6 weeks ago

#58380 accepted enhancement

Setting time limit for updates doesn't always work.

Reported by: nekojonez's profile NekoJonez Owned by: pbiron's profile pbiron
Milestone: 6.6 Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: needs-dev-note 2nd-opinion needs-patch
Focuses: Cc:


Warning: set_time_limit(): Cannot set max execution time limit due to system policy in /customers/7/5/e/*/wp-admin/includes/class-wp-upgrader.php on line 475

I usually comment out these lines since on my host I ALWAYS get this additional warning line after succesfull updates.

Is there something that can be done, so I don't have to do this for each new WP site...? Maybe a sort of option where you can enable/disable this?

Change History (20)

This ticket was mentioned in Slack in #core-upgrade-install by pbiron. View the logs.

12 months ago

#2 @pbiron
12 months ago

  • Milestone changed from Awaiting Review to 6.3
  • Owner set to pbiron
  • Status changed from new to accepted

This ticket was mentioned in Slack in #core by mrinal. View the logs.

11 months ago

#4 follow-up: @mrinal013
11 months ago

  • Keywords reporter-feedback added

This ticket is discussed in a recent New contributor meeting. @NekoJonez, would you please provide the description of the server settings and steps to reproduce?

#5 in reply to: ↑ 4 @NekoJonez
11 months ago

Replying to mrinal013:

This ticket is discussed in a recent New contributor meeting. @NekoJonez, would you please provide the description of the server settings and steps to reproduce?

I wish I could tell you the server settings... But I dont host the server myself. It happens on

Also to reproduce... Any plugin, theme or translation update shows that message underneath. I usually test it by throwing out all my translation files and letting them redownload.

But IIRC, @pbiron had a solution in one of the upgrade-install meetings?

#6 @mrinal013
11 months ago

  • Keywords needs-dev-note added

@pbiron, thanks for your discussion here

As I find out, a similar problem is also discussed on the WordPress forum:

Also, somehow similar problem is discussed on nextcloud forum,

Also, on prestashop

Can we use ini_get('disable_functions'); to get the disable functions list?

Last edited 11 months ago by mrinal013 (previous) (diff)

#7 @mrinal013
11 months ago

  • Keywords reporter-feedback removed

This ticket was mentioned in Slack in #core-upgrade-install by costdev. View the logs.

11 months ago

#9 @NekoJonez
11 months ago

So, @costdev gave me this PHP code to test as a plugin for the result:


 * Plugin Name: Check whether <code>set_time_limit()</code> is available.
 * Description: Checks whether <code>set_time_limit()</code> is available.
 * Author:      WordPress Core Contributors
 * Author URI:
 * License:     GPLv2 or later
 * Version:     1.0.0

    function() {
        $result = '';

        if ( function_exists( 'set_time_limit' ) ) {
            $result .= '<code>set_time_limit()</code> is available.';
        } else {
            $result .= '<code>set_time_limit()</code> is not available.';
            if ( ! function_exists( 'ini_get' ) ) {
                $result .= ' Could not retrieve the <code>disable_functions</code> directive.';
            } elseif ( str_contains( ini_get( 'disable_functions' ), 'set_time_limit' ) ) {
                $result .= ' <code>set_time_limit()</code> is disabled.';
            } else {
                $result .= ' <code>set_time_limit()</code> is not disabled.';

        echo '<div class="notice notice-info"><p>' . $result . '</p></div>';

This places a notice in the admin dashboard whether or not the module is available.
I tested this on three accounts I have with that hoster and all gave as result back:

set_time_limit() is available.

--> I think that at the core of this issue is most likely due to system policies, the module is present on the server but can't be interacted with by end users or customers of that host.
I think we should add an additional check if the module can be interacted with? But writing or investigating that is above my PHP skills. I can print hello world and that's it.

This ticket was mentioned in Slack in #core-upgrade-install by nekojonez. View the logs.

11 months ago

#11 @costdev
11 months ago

  • Keywords 2nd-opinion added


I also modified the code above to check for SUHOSIN and ini_get( 'disable_functions' ) and sent it. @NekoJonez got the following results:

SUHOSIN is not loaded. set_time_limit() is not disabled.

So the wrapping of the set_time_limit() call in question with if ( function_exists( 'set_time_limit' ) ) as done by [55258] won't solve the issue as this returns true in this case, and that's confirmed by checking the disable_functions PHP directive which doesn't bear fruit either.

The only two paths forward I can see at the moment are:

  • We suppress the warnings of all set_time_limit() calls in Core with @, possibly wrapping in an if ( WP_DEBUG ) which if true, doesn't suppress the warnings.
    • However, this goes against a Core effort to reduce/remove the use of the @ operator (#24780).
    • That said:
      • #49014 is a very closely related ticket in which the host added set_time_limit() to the disable_functions directive and the requested solution is to use @ or error_reporting( 0 ).
      • set_time_limit() warnings are suppressed in wp_get_http(), albeit a deprecated function, so precedent in Core is debatable.
  • We issue an update to WordPress Core requirements that the PHP native set_time_limit() function must either be available, or be disabled by the disable_functions directive so we can detect this with function_exists().

Neither of these are ideal paths forward, but I'd veer on using @ for set_time_limit() throughout Core until such time as an alternative is found.

I'm adding 2nd-opinion to gather more thoughts, and pinging @SergeyBiryukov and @audrasjb for their views. If the first of the two paths mentioned above is selected, we can definitely patch this for 6.3.

#12 @audrasjb
11 months ago

  • Milestone changed from 6.3 to 6.4

Given WP 6.3 beta 1 is scheduled tomorrow, and as this ticket still needs a patch, let's move in to the next milestone.

#13 @oglekler
9 months ago

This ticket still needs a patch and to make it, it needs to figure out how to find is max_execution_time can be overridden or not. Who knows how to make this check?

#14 @oglekler
9 months ago

  • Keywords needs-patch added

This ticket was mentioned in Slack in #core-upgrade-install by costdev. View the logs.

9 months ago

#16 @oglekler
8 months ago

  • Milestone changed from 6.4 to 6.5

Notes from a Slack conversation (link above) from @costdev:

Noting Olga's comment regarding whether max_execution_time can be overridden, the answer is: Yes, but not in safe mode
Although this is usually done via set_time_limit() rather than ini_set( 'max_execution_time', '123' )
At the moment, I still think that our current options are those mentioned in comment 11
My (begrudged) preference is still to suppress set_time_limit() warnings throughout Core, possibly doing so conditionally based on WP_DEBUG.

There is no patch and no time before Beta 1 to make and test one, so, I am moving this ticket into the 6.5 milestone.

This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.

6 months ago

#18 @jorbin
6 months ago

I think that if we are going to have a wrapper around each set_time_limit, it would be best to have a function like wp_set_time_limit that could do that and have the suppression. Maybe something like

function wp_set_time_limit( $seconds ){
 if ( WP_DEBUG ) {
  return set_time_limit( $seconds);
 } else {
  return @set_time_limit( $seconds);

#19 @swissspidy
3 months ago

  • Milestone changed from 6.5 to 6.6

Moving out of the 6.5 milestone due to lack of traction and beta 1 approaching.

This ticket was mentioned in Slack in #core-upgrade-install by afragen. View the logs.

6 weeks ago

Note: See TracTickets for help on using tickets.