REST API: Log doing_it_wrong notices to debug.log by ilclaudio · Pull Request #10537 · WordPress/wordpress-develop

ilclaudio · 2025-11-21T14:04:54Z

Fixes #64260. The doing_it_wrong_trigger_error filter was preventing all doing_it_wrong notices from being logged during REST requests. This change ensures notices are written to debug.log while still preventing trigger_error() from interfering with REST responses.

Now the error is filterd but in the debug.log file you can see a meeesage like this:

[21-Nov-2025 14:01:41 UTC] REST API - Doing it wrong: register_rest_route - The REST API route definition for test/v1/example is missing the required permission_callback argument. For REST API routes that are intended to be public, use __return_true as the permission callback. (This message was added in version 5.5.0.)

Trac ticket: https://core.trac.wordpress.org/ticket/64260

github-actions · 2025-11-21T14:05:03Z

Hi @ilclaudio! 👋

Thank you for your contribution to WordPress! 💖

It looks like this is your first pull request to wordpress-develop. Here are a few things to be aware of that may help you out!

No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description.

Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this GitHub repository mirrors. Please feel free to open pull requests to work on any contribution you are making.

More information about how GitHub pull requests can be used to contribute to WordPress can be found in the Core Handbook.

Please include automated tests. Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the Automated Testing page in the handbook.

If you have not had a chance, please review the Contribute with Code page in the WordPress Core Handbook.

The Developer Hub also documents the various coding standards that are followed:

Thank you,
The WordPress Project

github-actions · 2025-11-21T14:05:04Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @claudiobat.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

Core Committers: Use this line as a base for the props when committing in SVN:

Props ioclaudio, westonruter, juanmaguitar.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

github-actions · 2025-11-21T14:23:46Z

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

The Plugin and Theme Directories cannot be accessed within Playground.
All changes will be lost when closing a tab with a Playground instance.
All changes will be lost when refreshing the page.
A fresh instance is created each time the link below is clicked.
Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

ilclaudio · 2025-11-21T19:07:02Z

It looks like one of the GitHub Actions jobs failed due to a transient network issue (curl error 7 while downloading from packagist.org) and not because of my code changes.
Could someone please re-run the failed job? Thank you!

westonruter · 2025-11-26T03:53:57Z

Could someone please re-run the failed job? Thank you!

Re-run!

juanmaguitar · 2026-02-26T17:55:55Z

@ilclaudio There's some feedback provided in this PR.
Do you think you'll have time to address it in time for WP 7.0?

ilclaudio · 2026-02-27T09:14:41Z

Hi @juanmaguitar I have only proposed a patch but I'm not responsible to include it into the official code. I honestly don't know what else to do.

juanmaguitar · 2026-02-27T10:55:14Z

@ilclaudio, first of all thank for proposing this patch for the ticket :)

There's some feedback on the PR provided by @westonruter that still needs to be addressed

why not just remove the doing_it_wrong_trigger_error filter altogether?

A response to that comment would be helpful to move forward with this PR

…part 2

claudiobat · 2026-03-25T18:22:04Z

@ilclaudio, first of all thank for proposing this patch for the ticket :)

There's some feedback on the PR provided by @westonruter that still needs to be addressed

why not just remove the doing_it_wrong_trigger_error filter altogether?

A response to that comment would be helpful to move forward with this PR

Sorry for the late reply, feedback addressed.

…() error log

…ng-it-wrong-log

Use debug_backtrace() to find and append the first plugin or theme file responsible for the incorrect usage to the error_log() message.

REST API: Guard against missing line in backtrace frame Co-authored-by: Weston Ruter <westonruter@gmail.com>

REST API: Address review feedback on doing_it_wrong logger Co-authored-by: Weston Ruter <westonruter@gmail.com>

ilclaudio · 2026-05-15T07:44:19Z

Thanks for the feedback @westonruter.
Both points addressed in the latest commits and tests are passing.
Sorry for the confusion with my work account @claudiobat: my account for WordPress contributions is @ilclaudio, linked to my WordPress.org profile @ioclaudio.
This is my first contribution attempt, I guess it shows.

westonruter · 2026-06-02T10:08:42Z

+				break;
+			}
+		}
+		error_log( 'PHP Notice: ' . wp_strip_all_tags( $string ) . $caller );


I don't think we need wp_strip_all_tags() here. This is going straight to the error log, so it is not being displayed anywhere. I don't feel strongly about this, however.

Suggested change

error_log( 'PHP Notice: ' . wp_strip_all_tags( $string ) . $caller );

error_log( 'PHP Notice: ' . $string . $caller );

westonruter

🤖 Automated code review from Claude Code (high-effort recall pass), requested by @westonruter.

No crashing bugs found — the change is additive. Below are correctness edge cases and a couple of altitude/consistency concerns left as inline comments. These are suggestions from an automated reviewer; please use judgment.

westonruter · 2026-06-02T10:09:52Z

+		header( sprintf( 'X-WP-DoingItWrong: %s', $string ) );
+	}
+
+	if ( WP_DEBUG_LOG ) {


🤖 Claude Code: Incomplete/inconsistent fix. Only rest_handle_doing_it_wrong() gains debug-log output. The sibling handlers rest_handle_deprecated_function() and rest_handle_deprecated_argument() are registered identically in rest_api_default_filters() (lines 243–246) with the same __return_false suppression, but still drop their notices from debug.log entirely.

With WP_DEBUG_LOG on, a deprecated function/argument used during a REST request logs nothing, while a _doing_it_wrong() call in the same request now logs — an asymmetry that will confuse debugging and invites copy-pasting this same backtrace/format block into two more places.

westonruter · 2026-06-02T10:09:52Z

+		header( sprintf( 'X-WP-DoingItWrong: %s', $string ) );
+	}
+
+	if ( WP_DEBUG_LOG ) {


🤖 Claude Code (altitude): Consider whether this is the right depth for the fix. The reason these notices never reach the log during REST is line 248's add_filter( 'doing_it_wrong_trigger_error', '__return_false' ), which short-circuits the native wp_trigger_error() logging path. Re-implementing logging here bypasses the canonical message format, sanitization, and hooks of _doing_it_wrong().

Note that display_errors is already forced to 0 for REST requests in wp_debug_mode() (load.php ~642–647), so the suppression filter may be relaxable instead of bolting on a parallel logger. As written, future changes to how core formats/logs _doing_it_wrong won't apply to REST.

westonruter · 2026-06-02T10:09:52Z

+		header( sprintf( 'X-WP-DoingItWrong: %s', $string ) );
+	}
+
+	if ( WP_DEBUG_LOG ) {


🤖 Claude Code: This logging runs on the doing_it_wrong_run action and does not consult the doing_it_wrong_trigger_error filter, so it can't be silenced and may double-log. A site that adds its own doing_it_wrong_trigger_error filter to quiet a known-noisy third-party notice will still get it written to the log on every REST request. Conversely, if any code restores triggering during a REST request, the same incident is recorded twice (native + this entry).

westonruter · 2026-06-02T10:09:52Z

+	}
+
+	if ( WP_DEBUG_LOG ) {
+		$backtrace = debug_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS );


🤖 Claude Code (reuse): The bespoke debug_backtrace() + "first frame under WP_CONTENT_DIR" loop reinvents caller-location logic that core already provides via wp_debug_backtrace_summary(). Reusing the existing helper (or at least factoring this out) avoids a one-off heuristic that no other part of core relies on and must be re-audited whenever PHP backtrace semantics or path constants change.

westonruter · 2026-06-02T10:09:52Z

+		$caller    = '';
+		// Find the first caller outside of WordPress core (plugin or theme).
+		foreach ( $backtrace as $frame ) {
+			if ( isset( $frame['file'] ) && str_starts_with( $frame['file'], WP_CONTENT_DIR ) ) {


🤖 Claude Code: str_starts_with( $frame['file'], WP_CONTENT_DIR ) silently drops the caller location in two real cases:

Windows — backtrace file paths often use backslashes (C:\\site\\wp-content\\plugins\\foo.php) while WP_CONTENT_DIR may be forward-slash normalized, so the match fails and $caller stays empty.

Custom layouts — plugins/themes outside wp-content (custom WP_PLUGIN_DIR, symlinks) won't match either.

In both cases the log omits the offending file/line, which is exactly the information this feature exists to surface. Also note there's no path-separator boundary on the prefix match, so a sibling dir like /srv/site/wp-content-backup/... would be misattributed as a plugin/theme caller.

westonruter · 2026-06-02T10:09:52Z

+				break;
+			}
+		}
+		error_log( 'PHP Notice: ' . wp_strip_all_tags( $string ) . $caller );


🤖 Claude Code: error_log() with a single argument writes to PHP's configured error_log ini setting. That setting is only applied by wp_debug_mode() (load.php ~630–633) when debug-mode checks run. If a mu-plugin returns false on the enable_wp_debug_mode_checks filter, wp_debug_mode() returns early (lines 609–611) before ini_set( 'error_log', $log_path ), yet WP_DEBUG_LOG is still truthy here — so the notice goes to the SAPI default error log (e.g. stderr / the web-server log), not the admin's configured debug.log.

(For what it's worth, I verified the 'PHP Notice: ' prefix is correct: wp_trigger_error() defaults to E_USER_NOTICE, so this matches native severity.)

westonruter

🤖 Claude Code — one more issue (raised by @westonruter): this logging does not honor error_reporting().

westonruter · 2026-06-02T10:12:45Z

+				break;
+			}
+		}
+		error_log( 'PHP Notice: ' . wp_strip_all_tags( $string ) . $caller );


🤖 Claude Code: error_log() is not filtered by error_reporting() — it writes unconditionally. The native logging path (_doing_it_wrong() → wp_trigger_error() → trigger_error( $message, E_USER_NOTICE )) does respect error_reporting(), so a site that masks out notices (e.g. error_reporting( E_ALL & ~E_USER_NOTICE ), or a php.ini that excludes notices combined with an enable_wp_debug_mode_checks filter that stops WP from forcing E_ALL) would normally see nothing logged.

With this direct error_log() call, the notice is written to the log even when the operator has explicitly configured error reporting to exclude notices — i.e. logging output that wasn't requested. If the logging stays hand-rolled, it should gate on error_reporting() & E_USER_NOTICE (and arguably on ! headers_sent()-independent state) to match the behavior callers expect; routing through wp_trigger_error() instead would get this for free.

westonruter · 2026-06-02T10:14:01Z

+		header( sprintf( 'X-WP-DoingItWrong: %s', $string ) );
+	}
+
+	if ( WP_DEBUG_LOG ) {


This should ensure the notices only get logged out if such logs are desired.

Suggested change

if ( WP_DEBUG_LOG ) {

if ( WP_DEBUG_LOG && ( error_reporting() & E_USER_NOTICE ) ) {

westonruter reviewed Nov 21, 2025

View reviewed changes

Comment thread src/wp-includes/rest-api.php Outdated

ilclaudio force-pushed the fix/64260-rest-doing-it-wrong-log branch 2 times, most recently from 84fe789 to 563e9f6 Compare March 24, 2026 22:16

Fixed rest_handle_doing_it_wrong to manage debug messages properly - …

0a06f41

…part 2

ilclaudio force-pushed the fix/64260-rest-doing-it-wrong-log branch from 563e9f6 to 0a06f41 Compare March 25, 2026 00:19

Fixed rest_handle_doing_it_wrong: added headers check

6c3e353

westonruter requested changes Mar 26, 2026

View reviewed changes

Comment thread src/wp-includes/rest-api.php Outdated

ilclaudio added 3 commits March 26, 2026 10:21

REST API: Use with 'PHP Notice:' prefix in rest_handle_doing_it_wrong…

610ac74

…() error log

Merge remote-tracking branch 'upstream/trunk' into fix/64260-rest-doi…

6c7c2d4

…ng-it-wrong-log

REST API: Add caller location to rest_handle_doing_it_wrong() error log

8bb3815

Use debug_backtrace() to find and append the first plugin or theme file responsible for the incorrect usage to the error_log() message.

ilclaudio requested a review from westonruter April 8, 2026 20:52

Merge branch 'trunk' into fix/64260-rest-doing-it-wrong-log

40c4f98

westonruter reviewed May 14, 2026

View reviewed changes

Comment thread src/wp-includes/rest-api.php Outdated

Comment thread src/wp-includes/rest-api.php Outdated

ilclaudio and others added 2 commits May 15, 2026 09:22

Update src/wp-includes/rest-api.php

0a98d18

REST API: Guard against missing line in backtrace frame Co-authored-by: Weston Ruter <westonruter@gmail.com>

Update src/wp-includes/rest-api.php

922b735

REST API: Address review feedback on doing_it_wrong logger Co-authored-by: Weston Ruter <westonruter@gmail.com>

ilclaudio requested a review from westonruter May 15, 2026 15:28

Merge branch 'trunk' into fix/64260-rest-doing-it-wrong-log

043f126

westonruter reviewed Jun 2, 2026

View reviewed changes

	error_log( 'PHP Notice: ' . wp_strip_all_tags( $string ) . $caller );
	error_log( 'PHP Notice: ' . $string . $caller );

	if ( WP_DEBUG_LOG ) {
	if ( WP_DEBUG_LOG && ( error_reporting() & E_USER_NOTICE ) ) {

Conversation

ilclaudio commented Nov 21, 2025

Uh oh!

github-actions Bot commented Nov 21, 2025

Uh oh!

github-actions Bot commented Nov 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Unlinked Accounts

Uh oh!

github-actions Bot commented Nov 21, 2025

Test using WordPress Playground

Some things to be aware of

Uh oh!

ilclaudio commented Nov 21, 2025

Uh oh!

Uh oh!

westonruter commented Nov 26, 2025

Uh oh!

juanmaguitar commented Feb 26, 2026

Uh oh!

ilclaudio commented Feb 27, 2026

Uh oh!

juanmaguitar commented Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

claudiobat commented Mar 25, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ilclaudio commented May 15, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

westonruter left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

westonruter left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions Bot commented Nov 21, 2025 •

edited

Loading

juanmaguitar commented Feb 27, 2026 •

edited

Loading