Opened 5 months ago
Last modified 5 months ago
#61743 new enhancement
Capture and inform users when plugins or themes are `_doing_it_wrong()`
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Awaiting Review | Priority: | normal |
| Severity: | normal | Version: | |
| Component: | Site Health | Keywords: | |
| Focuses: | Cc: |
Description
Part of a healthy website is having plugins and themes that use WordPress core's features correctly, to ensure they keep working in the foreseeable future (thanks to WordPress' dedication to backwards compatibility).
The _doing_it_wrong() function, and its siblings, generally always fire a E_USER_NOTICE level error, this means it will be hidden away in a log file that the user may never see, or hosts may have disabled, since only WARNING or ERROR are of true value.
The Site Health Checks can help here, by capturing when these are thrown and surfacing them in a user friendly manner.
Why add this to core, and not just as a plugin?
The improper use of core functionality can lead to bad optics, where it looks like WordPress broke your site because they modified a function and a plugin wasn't using it
in an expected way.
In addition, this would allow core to deprecate things, and make authors more aware that if they just keep using them because "WordPress would never break this any way", it will reflect poorly on them as their users would be made aware that they are doing something wrong, making it safer for core to make changes of any kind (necessary deprecations for example).
How do we implement this in a user friendly manner?
This is the big question, as a site health check, it should always have something actionable attached to it, I envision it surfacing a table of plugins or themes that throw these notices, each of them with a link to their WordPress.org forums (if they're hosted on WordPress.org of course), and a notice to contact whomever they purchased it from if not.
Additionally, an actionable item may be to make it forget what things it has discovered already (if you've done updates for example, and the issues may now be resolved).
A self-actuating thing is that any plugin or theme update should remove it's memory of that plugin or theme, so that it may capture any new issues, and the memory should only persist a week at most in the first place, in case they use deployments that do not trigger the normal upgrade flows.
Related: #18453