[wp-trac] [WordPress Trac] #21211: Alter how settings_errors are output in options.php

[WordPress Trac]

#21211: Alter how settings_errors are output in options.php
--------------------------+-------------------------------------------
 Reporter:  griffinjt     |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Themes        |    Version:  3.4.1
 Severity:  normal        |   Keywords:  2nd-opinion reporter-feedback
--------------------------+-------------------------------------------
 The `*_settings_error(s)` and `settings_error` functions are used mainly
 as part of the Settings API, but with the way that options.php currently
 handles the settings errors, it assumes that people will use this
 functionality exclusively with the Settings API. Notice options.php,
 starting at line 153:

 {{{
         /**
          * Handle settings errors and return to options page
          */
         // If no settings errors were registered add a general 'updated'
 message.
         if ( !count( get_settings_errors() ) )
                 add_settings_error('general', 'settings_updated',
 __('Settings saved.'), 'updated');
         set_transient('settings_errors', get_settings_errors(), 30);
 }}}

 This simply assumes that no other outside source has registered any sort
 of setting error other than the current options page. TwentyEleven does
 this, and so if any other source has registered any notices via these
 functions, the "Settings saved." message will not be output because the
 first bit of logic will fail. I don't think this assumption can (nor
 should) be warranted, so there needs to be another way to handle this so
 that themes like TwentyEleven who only call `settings_errors` at the top
 of their options page don't get unknowingly hijacked by other sources.

 I always suggest registering your own errors at the end of the
 sanitization callback for your setting, and then output those specific
 errors within settings_errors to avoid any internal conflicts like this.

 Just looking for some ways to approach this. :-)

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21211>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software