There are two UI User interface component changes in 4.2 aimed at better experiences moving forward that may affect plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme authors. The first is the spinner element, which does come with a non-critical visual breaking change. The second is admin (and super admin) notices, which are an enhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. and do not affect current implementations.
Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s spinner is implemented using the
.spinner class. Up until now, spinners have been hidden using
display: none and then toggled using jQuery’s
.show()/.hide() methods. While this works, it has two fundamental problems: it ties us to jQuery-specific helpers, and more importantly, does not reserve the space for the spinner when hidden, leading to elements moving around on the screen whenever the spinner would toggle. The more appropriate solution would be to use CSS Cascading Style Sheets.’s
visibility property, which does reserve the visual space, and control that visual behavior via a class so that any future changes to CSS are inherited by anybody using that component.
To that end, to show a spinner, you should now add a class of
.is-active to the spinner element, and remove that class when it’s no longer active. This state-communicating naming convention is a part of some of our longer-term goals when it comes to semantic markup, so also take note of that. The breakage here is that spinners will no longer show using jQuery’s
.show() method, as all it does is set an inline CSS display property, and so you will need to account for that going forward. The best thing to do would be to update to toggling the class as noted, and if maintaining compatibility in the short term with older versions of WordPress is a concern, detect the version and inject CSS into
admin_head that applies
display: inline-block to
.spinner.is-active. There are other methods for handling version compatibility as well, but this is likely to be the method that is most maintainable and easy to immediately understand. Work on this was handled in #22839.
Any notice can now be made dismissible by ensuring the it has the classes
.is-dismissible (recognize that naming convention?). Core handles adding the close button and removing the notice for you. However, for the best possible user experience, you should ensure that those notices will not come back on a page refresh or when navigating to another page. There are two different paths for this. The first applies to notices that are added when a query arg is present in the URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, such as
'message', 'settings-updated', 'saved', 'update', 'updated','activated', 'activate', 'deactivate', 'locked', 'deleted', 'trashed', 'untrashed', 'enabled', 'disabled', 'skipped', 'spammed', and 'unspammed'. To add (or remove) items to this array to accommodate your needs, use the
removable_query_args filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..
The second path, for notices that persist across different page loads, is to bind to the click event on the
.notice-dismiss element in your own notice and trigger whatever it is your plugin may need to do to remember that the notice has been dismissed, such as storing a site or user option using Ajax. A note of caution that in an ideal scenario, core would eventually provide a framework for persistently dismissible notices that are not tied to query args, so be prepared for future changes if you choose to use this method.