WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 3 years ago

#31000 new defect (bug)

Multiple calls to settings_errors() result in duplicate display of notices

Reported by: jrf Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.9
Component: Administration Keywords:
Focuses: Cc:

Description

settings_errors() is called by default on options pages and numerous plugins and themes whose pages aren't under the options submenu will also call it.

Good, maybe even great, as so many have obviously adopted to using this.

The issue arises when, for instance, a plugin uses a call to settings_errors() hooked into admin_notices to display their notices across all pages. In that case, their message will be displayed twice on any pages also calling settings_errors().

Now a plugin can check if they are on an options page and - knowing that the messages will be displayed there anyhow - forgo the call to settings_errors( 'my-messages' ) there. But there is no way for a plugin to test if another theme/plugin outside of the options pages is also making the settings_errors() call.

I would suggest unsetting any messages which are displayed from within the settings_errors() call to avoid duplicate messages ever being shown.

Change History (3)

This ticket was mentioned in Slack in #core by jorbin. View the logs.


3 years ago

#2 @jorbin
3 years ago

Summary of the above chat: I think the solution for this for now is to add in some documentation cautioning against the use of settings_errors. One thing that this helps identify is that this entire api could really use some love and direction.

#3 @jrf
3 years ago

I think the solution for this for now is to add in some documentation cautioning against the use of settings_errors.

The thing is, quite a number of plugins have more than one settings page and therefore add their own menu item with submenu to the WP admin menu. Those admin pages use the Settings API and the Options API, but as they are not under the "Settings" menu item, they - IMHO correctly - add the settings_errors() call to their admin page to allow for displaying of the settings errors.

So - again IMHO - cautioning against using it will have the undesirable effect that plugins will each have to come up with their own solution to display errors and to move away from using the Settings and Options APIs.

One thing that this helps identify is that this entire api could really use some love and direction.

+1 ;-)

Note: See TracTickets for help on using tickets.