New Framework Helps WordPress Plugin Developers Create Persistently Dismissible Admin Notices

photo credit: A sign - (license)
photo credit: A sign(license)

Nearly every WordPress user has experienced the frustration of dismissing an admin notice and having it pop up again on page refresh or upon navigating to a new page. WordPress 4.2 made it possible for plugin and theme developers to create dismissible admin notices using the classes .notice and .is-dismissible, but left it up to the developer to ensure that the notices do not return.

Collins Agbonghama, a web developer from Nigeria, decided to create a framework to make it easy to create dismissible admin notices that persist across page loads.

“Although a lot of plugin authors have been able to fix this by adding say a ‘dismiss’ link, this requires extra code to pull off,” Agbonghama said. “This library attempts to fix this with less effort.”

His “Persist Admin Notice Dismissals” library has a plain and sensible name, but it provides an elegant solution for extension authors to use in their themes/plugins. The framework can be autoloaded via Composer or included in a vendor/ directory with the plugin.

Andy Fragen, a contributor on the framework, described how he got involved with the project.

“I opened an issue about 3 weeks ago, asking if the project, which was previously a plugin, could be made into a framework for inclusion into other projects,” Fragen said. “Collins thought it was a good idea and transformed the project from a plugin to a framework.”

Fragen said that Matt Gibbs, a contributor on the GitHub Updater plugin, mentioned dismissing the admin notices that the plugin generates, preferably for some period of time.

“I’ve been looking for a solution since then and when I came across Persist Admin Notice Dismissal I was intrigued,” Fragen said. “I liked the method that Collins was using for his dismissal, as it incorporated well with how I think core works with admin notices.” He decided to jump in and help clean up some code by testing to ensure that the library worked when used in multiple plugins, with multisite, and with autoloaders.

Both Agbonghama and Fragen believe that the framework could be incorporated into core to make it easier for developers to create persistently dismissible admin notices. Agbonghama said he would have commented on the relevant Make/WordPress post but it is now closed to new comments.

“Something like this would definitely make for a feature project and having this built into core would be great,” Fragen said.

Persist Admin Notice Dismissals makes it easier for developers to provide a better experience in the admin while still communicating with users through important notices. Check out the library on GitHub and let us know in the comments if you think this might be a good candidate for a feature project.

4

4 responses to “New Framework Helps WordPress Plugin Developers Create Persistently Dismissible Admin Notices”

  1. The idea of having notices dismissed for a given period of time is interesting. However, the process seems a bit fastidious in the sense that it is still necessary to manually create the notices.

    Also, having to add long class names, and also not forget the is-dismissible class, looks like an easy way to forget something.

    I have a similar library, available on GitHub since March, that automates most of the process. It also adds a couple more options for defining who sees what: https://github.com/julien731/WP-Dismissible-Notices-Handler

  2. When I originally developed dismissible admin notices with Helen my first patch added the ability to hide the notice for a period of time with JS cookies. Unfortunately, we were in beta and could only fix bugs and this functionality was an enhancement. I probably should have followed up with my original patch and then it could have been in Core already. I would likely still use only JS though. Making an Ajax call to PHP to store a transient about a notice to me seems overkill. Regardless of the difference of opinion if anyone wants this sort of functionally in Core they can always open a new Trac ticket with a patch, or comment on the original and include the patch there. Also, the earliest it would be in Core is version 4.7 because 4.6 is currently in beta.

    https://core.trac.wordpress.org/ticket/31233

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Discover more from WP Tavern

Subscribe now to keep reading and get access to the full archive.

Continue reading