Introduce helper function for XMLRPC checks

[NathanAtmoz]

Similar to #25669, it would be nice if there was a helper function for checking if WordPress is doing a XML-RPC request.

[birgire]

Thanks for the patch @NathanAtmoz

I'm not sure what the consensus is regarding wp_doing_xmlrpc() but we now have wp_doing_ajax() since 4.7 and wp_doing_cron() since 4.8. So it would seem logical to introduce it. Also the discussion in #25669 doesn't seems to be against such a function, if I understand it correctly.

I reviewed 43159.diff​ and here are some notes:

• I don't think we should add wp_doing_xmlrpc() in that line in wp-cron.php, because that file can be requested directly, (see e.g. within spawn_cron() here ) and then wp_doing_xmlrpc() wouldn't be defined and resulting in a PHP error. Some users rely on Unix Cron instead, requesting that file from there.
• It removes the || defined( 'DOING_AJAX' ) check in is_admin_bar_showing(). I think that removal must have been accidental and should be reverted.
• I found an extra defined( 'XMLRPC_REQUEST' ) check in spawn_cron() (src), but I noticed that defined( 'DOING_AJAX' ) and defined( 'DOING_CRON' ) have not been replaced. Most likely a reason for that, but we could look further into that.
• I also found an extra defined( 'XMLRPC_REQUEST' ) check in _publish_post_hook() (src), that seems to be valid for replacement with wp_doing_xmlrpc().

[NathanAtmoz]

@birgire: Thanks for looking at the patch.

Replying to birgire:

• I don't think we should add wp_doing_xmlrpc() in that line in wp-cron.php, because that file can be requested directly, (see e.g. within spawn_cron() here ) and then wp_doing_xmlrpc() wouldn't be defined and resulting in a PHP error. Some users rely on Unix Cron instead, requesting that file from there.

I don't see wp_doing_xmlrpc() in wp-cron.php in the patch? Am I missing something?

• I found an extra defined( 'XMLRPC_REQUEST' ) check in spawn_cron() (src), but I noticed that defined( 'DOING_AJAX' ) and defined( 'DOING_CRON' ) have not been replaced. Most likely a reason for that, but we could look further into that.

I originally didn't use wp_doing_xmlrpc() here because the other constants hadn't been replaced. But this function is loaded really early, and the only place it's called in core is hooked to init.

[birgire]

Replying to NathanAtmoz:

I don't see wp_doing_xmlrpc() in wp-cron.php in the patch? Am I missing something?

This part was meant to be a general note why it wasn't replaced in wp-cron.php, sorry that wasn't made more clear ;-)

I also checked in the tests/ directory and didn't find any use of XMLRPC_REQUEST there.

[jorbin]

Patch no longer applies cleanly. I would support getting this in if someone wants to refresh the patch.

[NathanAtmoz]

Patch refreshed

[abhishekfdd]

Tested 43159.3.diff​ against current trunk (7.2-alpha-63166).

Applies cleanly (offsets only, no fuzz) and covers every remaining XMLRPC_REQUEST check in src/, including the newer ones in wp_die() and the Application Passwords check. All touched files lint clean on PHP 8.3. plugin.php loads before wp_debug_mode(), so the filter is safe at the earliest call site.

A few things before this is commit-ready:

• The new docblock is indented with a leading space, which will fail PHPCS.
• The filter's @param is named $wp_doing_cron; should be $wp_doing_xmlrpc.
• @since 6.7.0 needs updating to the target release.
• The _publish_post_hook() docblock change ("Uses WP_IMPORTING constants") drops information and reads oddly. I'd leave the original line.

Behavior change worth noting: four call sites (admin-bar.php, cron.php, load.php, post.php) previously used a bare defined( 'XMLRPC_REQUEST' ). With the helper, define( 'XMLRPC_REQUEST', false ) now evaluates false there instead of true. Edge case, but it should be called out in the dev note.

Open question: should the two user.php sites go through the filter at all? In _wp_get_current_user(), a plugin incorrectly returning true from wp_doing_xmlrpc would log out every user on every request. The Application Passwords check already has application_password_is_api_request for extensibility. I'd lean toward keeping the raw constant check in both places, but would like a committer's view.

Attached unit tests covering the default, filter, and constant true/false cases (separate process for the constants). They pass locally with the patch applied.

@NathanAtmoz happy to refresh the patch with the fixes above if you'd prefer, otherwise I'll leave it with you. @jorbin since you offered support in comment:4, does keeping user.php on the raw constant sound right to you?