cron_request filter should pass $doing_wp_cron as an argument to callbacks

[ericlewis]

The request made to the cron endpoint ​is filterable. doing_wp_cron is a timestamp created when the cron is spawned on a request, and embedded in the request sent to the cron endpoint. This is used on the cron endpoint to avoid multiple processes looping over the same events (see #17462).

I'm about to filter this request as I have a read-only datacenter, so I need to send the request to the writeable one.

Although I can grab the $doing_wp_cron value out of the 'key' in the cron_request array, that seems delicate. More elegantly we could pass the $doing_wp_cron value as an argument to the filter.

[F J Kaiser]

Why is fetching the value from the key "delicate"? The key actually is ... key.

[ericlewis]

Replying to F J Kaiser:

Why is fetching the value from the key "delicate"? The key actually is ... key.

If a value is filterable then a developer should make no assumption about what the value they are filtering is, as a previous filter could've done anything it wants to the data.

Anything that's critical to the context should be passed along as arguments into the apply_filters() invocation.

[ericlewis]

Can we add parameters to apply_filters() calls without breaking stuff?

[DrewAPicture]

Replying to ericlewis:

Can we add parameters to apply_filters() calls without breaking stuff?

We add new parameters all the time (with corresponding changelog entries). Due to the architecture of requiring explicit argument counts in add_filter|action(), adding additional args should have no effect on legacy code.

[ericlewis]

attachment:31307.2.diff​ adds hook docs.

[ericlewis]

attachment:31307.diff​ adds since hook docs.

[ericlewis]

In 36228:

Cron: Add the cron lock timestamp to the 'cron_request' filter arguments.

Fixes #31307