[wp-trac] [WordPress Trac] #39591: Introduce wp_doing_cron()
WordPress Trac
noreply at wordpress.org
Mon Jan 16 12:31:57 UTC 2017
#39591: Introduce wp_doing_cron()
-------------------------+------------------
Reporter: tfrommen | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: 4.8
Component: Cron API | Version:
Severity: normal | Resolution:
Keywords: has-patch | Focuses:
-------------------------+------------------
Comment (by tfrommen):
I'm very happy this is going to get merged sometime soon. :)
Yet I want to address a few things.
Replying to [comment:4 rmccue]:
> It's not querying though: as a constant, it's a constant and is
basically instant; as a function, it's essentially static (small overhead
of filtering, but that is never going to be significant). No point caching
it.
I'm no English native speaker, so sorry for not using the exact same words
you would use here.
That being said, for me, it is querying. It is asking someone else for
information. Multiple times, knowing that I'd be needing the information
multiple times right from the beginning. And even more, that information
isn't going to change (because it is the value of a constant, as we all
know).
Caching that information in order to look it up later (which is instant)
is a good thing, in my opinion.
Also, since the constant is not defined in all situations (in fact, in
WordPress core, it is only defined when doing a CRON task), noone can
simply ''check the constant''. They'd have to check `defined( 'DOING_CRON'
) && DOING_CRON`, which is '''not''' only looking up a constant.
To make that clear, I am not saying, nor assuming, to really boost
anyone's WordPress site by these micro-optimizations. That's just nonsene.
However, caching that kind of data clearly isn't a bad thing at all.
Furthermore, you, Ryan, said it yourself: wrapping the check in a function
will introduce some (tiny) overhead. So I don't see your reasoning in
doing this multiple times, instead of only once, for the ''cost'' of a
local variable.
As to the introduction of that functionin general. Even if the overhead
would be bigger, having a public API (that is not using implementation
details!) is a good thing as well. Currently, the only thing one can do is
to check the constant. If the ''sotrage'' of the CRON status definition
ever were to change (I know, I know: won't happen; but still), all of the
code directly working with the constant would have to be adapted.
If there were a function, which is part of the public API, and thus to be
used in favor of checking the constant, one '''could''', some day far far
away in the future, change how doing a CRON task is defined.
Having the possibility to filter the value, is a big plus, too, yes.
I believe this is one of the major reasons for having `wp_doing_ajax()`,
isn't it?
Just wanted to leave this here. For discussion. :)
--
Ticket URL: <https://core.trac.wordpress.org/ticket/39591#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list