![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 8 months ago
Last modified 5 weeks ago
#64260 reviewing defect (bug)
Default filter `doing_it_wrong_trigger_error` for REST request cause no notice at all.
| Reported by: | okvee | Owned by: | westonruter |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.1 |
| Component: | REST API | Version: | 4.4 |
| Severity: | normal | Keywords: | has-patch changes-requested |
| Cc: | Focuses: | rest-api |
Description
File: wp-includes/rest-api.php inside function rest_api_default_filters() has this code.
if ( wp_is_serving_rest_request() ) {
// ...
add_filter( 'doing_it_wrong_trigger_error', '__return_false' );
}
With this filter, all wrong calling code will not showing the notice anywhere including in wp-content/debug.log.
For example:
Function register_rest_route() ( https://developer.wordpress.org/reference/functions/register_rest_route/ ). There are many detection to call _doing_it_wrong() to notice developer to know that they are doing it wrong and let them fix it. These notices are useful and some can improve security.
When I call function register_rest_route() without permission_callback argument, it should showing the notice about doing it wrong somewhere such as in debug.log.
But inside function _doing_it_wrong(), your if condition:
if ( WP_DEBUG && apply_filters( 'doing_it_wrong_trigger_error', true, $function_name, $message, $version ) )
calls to filter doing_it_wrong_trigger_error while this filter always return false. This cause function _doing_it_wrong() completely useless.
Please consider change this default filter value or make it at least write the "doing it wrong" notice to wp-content/debug.log file.
Tested with WordPress development version (6.9-RC1-61214).
Attachments (1)
Change History (17)
This ticket was mentioned in PR #10537 on WordPress/wordpress-develop by ilclaudio.
8 months ago
#2
- Keywords has-patch added; needs-patch removed
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 <code>test/v1/example</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>return_true</code> as the permission callback. (This message was added in version 5.5.0.)
@ioclaudio commented on PR #10537:
8 months ago
#3
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 commented on PR #10537:
8 months ago
#4
Could someone please re-run the failed job? Thank you!
Re-run!
@juanmaguitar commented on PR #10537:
5 months ago
#5
@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?
@ioclaudio commented on PR #10537:
5 months ago
#6
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 commented on PR #10537:
5 months ago
#7
@ilclaudio 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
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
4 months ago
#9
@
4 months ago
- Milestone 7.0 → 7.1
As per today's 7.0 pre-RC1 bug scrub:
The PR is still being discussed. Moving to 7.1.
claudiobat commented on PR #10537:
4 months ago
#10
@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.
#11
@
2 months ago
Hi all,
the fix has been updated to address all review feedback (moved logging into rest_handle_doing_it_wrong(), added PHP Notice: prefix, included caller location via debug_backtrace()).
https://github.com/WordPress/wordpress-develop/pull/10537
@ioclaudio commented on PR #10537:
2 months ago
#13
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.
@ioclaudio commented on PR #10537:
6 weeks ago
#15
Thanks @westonruter, addressed in the latest commits:
- Added
error_reporting() & E_USER_NOTICEgate. - Fixed path comparison for Windows and non-standard layouts:
wp_normalize_path()on both sides +trailingslashit()to prevent false matches on sibling directories (e.g.wp-content-backup/). - Added depth limit of 20 to
debug_backtrace(). - Re-added
wp_strip_all_tags(): without it the log contains raw HTML tags from the message strings (e.g.<code>). Happy to drop it again if you prefer.
Examples:
- Withouth wp_strip_all_tags:"""
[06-Jun-2026 16:44:51 UTC] PHP Notice: register_rest_route (since 5.5.0; The REST API route definition for <code>test/v1/example</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>return_true</code> as the permission callback.) in /var/www/src/wp-content/plugins/rest-api-test/reast-api-test.php on line 8
"""
- With wp_strip_all_tags:"""
[06-Jun-2026 16:51:08 UTC] PHP Notice: register_rest_route (since 5.5.0; 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.) in /var/www/src/wp-content/plugins/rest-api-test/reast-api-test.php on line 8
"""
@ioclaudio commented on PR #10537:
5 weeks ago
#16
Here's a summary of everything addressed in the latest commits:
- Extended debug logging to rest_handle_deprecated_function() and rest_handle_deprecated_argument(), matching the pattern in rest_handle_doing_it_wrong()
- Extracted backtrace logic into _rest_get_debug_backtrace_caller(); a private helper reused by all three handlers, which now also includes the offending function name (e.g. called from MyPlugin->init())
- Added error_reporting() gate (E_USER_NOTICE / E_USER_DEPRECATED) to mirror native PHP behavior
- Fixed Windows path comparison: wp_normalize_path() on both sides + trailingslashit() to prevent false matches on sibling directories + strtolower() for case-insensitive comparison
- Re-added wp_strip_all_tags(), without it, message strings containing <code> tags produce raw HTML in the log
After launching a Claude Code review there are a few things intentionally left as-is, in case a future automated review flags them, this is a summary: "
- deprecated_hook_trigger_error not suppressed: this is a pre-existing gap in rest_api_default_filters(), which this PR doesn't touch. do_action_deprecated() / apply_filters_deprecated() are a separate concern and would need their own handler and suppression filter, feels like a separate ticket.
- error_reporting() gate silencing WP_DEBUG_LOG: intentional; mirrors native PHP behavior as suggested.
- Symlinked plugins outside WP_CONTENT_DIR: dev-only edge case not covered by the original loop either. Not a regression introduced here.
- Three identical error_log() blocks: left inline for readability. Extracting a private helper felt like over-engineering for three call sites.
- The doing_it_wrong_trigger_error filter question is still open; happy to add a separate filter (e.g. rest_doing_it_wrong_trigger_log) if you think it's worth it.g
"
The code in question was added way back in r34928 (b392114) when the REST API was first introduced in core. The intention was for the deprecation message to be sent back via the
X-WP-DeprecatedFunctionresponse header. But I don't see why it can't also be sent to the error log.