[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