Setting time limit for updates doesn't always work.

[NekoJonez]

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

I usually comment out these lines since on my host one.com 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?

[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?

[NekoJonez]

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 One.com

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?

[mrinal013]

@pbiron, thanks for your discussion here ​https://wordpress.slack.com/archives/core-upgrade-install/p1684952314022389

As I find out, a similar problem is also discussed on the WordPress forum: ​https://wordpress.org/support/topic/cannot-set-max-execution-time-limit-due-to-system-policy/

Also, somehow similar problem is discussed on nextcloud forum
​https://github.com/nextcloud/server/issues/16752,
​https://github.com/nextcloud/server/issues/16752

Also, on prestashop
​https://www.prestashop.com/forums/topic/958636-warning-set_time_limit/

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

[NekoJonez]

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

<?php
​
/**
 * 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:  https://make.wordpress.org/core
 * License:     GPLv2 or later
 * Version:     1.0.0
 */
​
add_action(
    'admin_notices',
    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.

[costdev]

Thanks!

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.

[audrasjb]

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.

[oglekler]

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?

[oglekler]

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
9:21
Although this is usually done via set_time_limit() rather than ini_set( 'max_execution_time', '123' )
9:21
At the moment, I still think that our current options are those mentioned in comment 11
9:23
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.

[jorbin]

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

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

[swissspidy]

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

[nhrrob]

We have reviewed this ticket in today's bug scrub.
We will wait 1 more week to see if it has any movements.
Then we may punt it to the Future Release.

It still requires 2nd opinion and no patch yet.

[oglekler]

This ticket was discussed during bug scrub.

No movement, no patch, I am punting this to 6.7 and the next one it should go into the Future releases.

Add props to @afragen

[khoipro]

This ticket was discussed during the bug scrub.

No movement, no patch, I am punting this to 6.8 and the next one it should go into the Future releases.

My personal comment:
Mostly it has a problem with the server environment, and the wrapper function does not need that. They should contact a hosting provider to see how friendly a server is with WordPress requirements.

[chaion07]

Thanks @NekoJonez for reporting this. Adding props to @mukesh17 & @khoipro for reviewing this Ticket during a recent triage session.

Cheers!

[desrosj]

This one hasn't received the attention it needs during the 6.7 cycle. Going to punt.