-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it easier to determine if we are 'inside' a queue processor #1024
Comments
Hi!
That's right. By default, there are up to three different contexts through which Action Scheduler may be triggered:
In most cases, it's a mix of the first two: it doesn't always run via WP Cron (and so
If you are finding you need something like this, then possibly? Can I just highlight though that we already have some related functionality within the library: This is generally called immediately prior to processing waiting actions. However, there isn't really any way to ensure this takes effect: restrictions in a given hosting environment take precedence, in many cases. |
Thanks @barryhughes, good to know about these 3 contexts. I think the PHP timeouts you were referring to are different from the WordPress HTTP API timeouts. WordPress uses a standard timeout of |
I'm sorry, I misunderstood.
I'm not sure how useful this would be in your case, but the
The second of those provides the information you are looking for (and even without it, you could still use the action itself as a signal that you are 'inside' the scheduled action queue). Might that work? If not, we could explore alternatives. For instance, it would seem reasonable to also share the context via the |
Thanks, for now we handled it this way:
It would be nice if this library introduced it's own |
Re-opening so we don't lose sight of this idea (a little unsure if defining a constant is the best approach for us, but the general idea makes sense). |
timeout
in case of "Action Scheduler" background tasks via e.g. wp_doing_cron()
/ DOING_CRON
It could be useful to other developers if we make it easier to detect when code is executing in the context of the Action Scheduler queue. There are various patterns/strategies to determine this already, but it's not quite as straightforward as it might be. We should at least consider the proposal in this comment. Original description follows.
We know that WordPress sometimes increases the timeout of HTTP requests when initiated via the WordPress cron.
See for example:
We'd like to do something similar for tasks initiated through this library. However, it seems that
wp_doing_cron()
does not always returntrue
when running "Action Scheduler" tasks. In the codebase of this library there is also nodefine( 'DOING_CRON', true );
as in WordPress:https://github.com/WordPress/WordPress/blob/f4b5da285990e948e7b40ba53be5037aed2ae07b/wp-cron.php#L37-L42
Now we might be able to catch this with a piece of code as follows:
However, we wonder whether this is wise and/or correct, so we are curious about the opinion of the developers of this library. Should
DOING_CRON
be set totrue
when running "Action Scheduler" tasks? Or is it useful/better to introduce anas_doing_cron()
function or something like that? Or are we looking at this completely wrong?CC @rvdsteege
The text was updated successfully, but these errors were encountered: