Google+
Shineyrock web design & consultancy

Shineyrock

blog

  • dislike -8 08

    Persisted WordPress Admin Notices: Part 4

    So far in this series, we've covered two separate ways to dismiss persistent WordPress admin notices. We'll build on that in this fourth and final part of the tutorial series by looking at two more specific methods to permanently dismiss your admin notices. We'll round things off by showing how to create your own custom admin notice types and add decorations such as icons.

    Sticky Admin Notice

    We already know how to display an admin notice that can be dismissed. All we have to do is add the is-dismissible CSS class to the containing div element. However, this is only temporary and will only dismiss the notice for the current page. As soon as the page reloads, it reappears again.

    To make it permanently dismissible involves more code than we've seen so far, but it isn't too difficult to implement. Let's take a look at what's involved, starting with an overview.

    We'll use a custom option to store the display status of our admin notice. On plugin activation, this option will be created/updated and set to true. The admin notice will then only display if the option is currently true.

    The key to this method is using Ajax to allow us to set the option to false when the dismiss button is clicked. Once successfully set to false, the conditional code that checks the option status will fail, and the admin notice will no longer be displayed.

    Let's begin by adding the admin notice itself, which will be a plain notice to begin. In Gwyer_Dismissible_Admin_Notices::init(), add a new add_action call:

    Then add the dismiss_admin_notice() callback function to the same class:

    This adds an admin notice that displays only on the plugin admin page and is very similar to what we've seen in previous tutorials. The only slight difference here is that we've also added a CSS ID to the admin notice div container. This will be used to specifically target the admin notice we're interested in.

    Standard admin notice with custom CSS ID

    We'll need to add JavaScript code to make the Ajax call work, so add a js folder in the root admin-notices plugin folder and inside create a file called admin-notices.js. Add code to the new file to test it's loading properly by outputting a console message.

    In Gwyer_Plugin_Options::init(), add a new add_action call to enqueue our script file:

    We only want this JavaScript file to be loaded on the plugin options page, so we need a way to conditionally enqueue it. We can do this by checking what admin page we're currently on to see if it's our plugin options page.

    We can get a handle to our plugin options page by storing the return value of add_options_page() in a class property. We had no need of this value previously, so we just called add_options_page() without storing the return value.

    Add a class property to Gwyer_Plugin_Options:

    Then, in create_admin_menu_page(), use this new property to store the handle to our plugin options page:

    We can finally enqueue our JavaScript file so that it loads only on the plugin options page:

    If all went well then you'll see an admin-notices.js loaded! message outputted to the browser console.

    Admin notice JavaScript loaded

    Update the JavaScript code in admin-notices.php to the following:

    Here, we're listening for a click event on the an1 CSS ID we added to our admin notice earlier. As soon as it's clicked, an Ajax request is fired. Let's handle that request next.

    In Gwyer_Dismissible_Admin_Notices::init(), add a new add_action call:

    This will run the callback function once the display_dismissible_admin_notice Ajax request fires. Remember that this originally was defined as the data.action property in our Ajax request.

    Now add the display_dismissible_admin_notice callback function to Gwyer_Dismissible_Admin_Notices:

    Save your changes, reload the plugin options page, and click the admin notice dismiss button to see the Ajax request in action!

    The Ajax request in action

    If the request was successful then you'll see a Processing Ajax request... DONE! message displayed in the browser console.

    The final piece of the puzzle is to create a custom option initially set to true but which is then set to false when the dismiss button is clicked. Then, when the plugin options page loads, the admin notice only displays if the custom option value is true.

    In Gwyer_Dismissible_Admin_Notices::init(), add a second call to register_activation_hook():

    And add the create_custom_option callback function to the class:

    Now, when the plugin is activated, a custom option called gwyer-dismiss is created and set to true.

    Update display_dismissible_admin_notice() to update our custom option when the Ajax request fires:

    Now all that's left to do is update dismiss_admin_notice() to check for the value of the custom option and only render the admin notice if it is set to true.

    Deactivate and reactivate the plugin to test the code we've added. Visit the plugin options page, dismiss the admin notice, and refresh the page. The notice should no longer be visible. Yay!

    Because the custom option is set to true every time the plugin is activated, you can repeat the above steps to test the dismissible admin notice as many times as you like.

    To keep things simple, this was a bare-bones example of using an Ajax request to set the custom admin notice option. In practice, you'd want to use a nonce (number used once) value to validate the Ajax request as a minimum security measure.

    This was a lot of work to just permanently dismiss an admin notice, but the final effect works well and is something you can use to good effect in your own plugins.

    Custom Action Admin Notice Dismissal

    It's time to look at a slightly different method for dismissing admin notices now. This is a nag type of admin notice that displays on all admin screens and can't be dismissed until some action has been performed.

    Note: Use this method with caution or you'll risk alienating your plugin users very quickly!

    The specific action we'll focus on in our example will be to display an admin notice until a required plugin or list of plugins have been installed and activated.

    Unlike the previous method where we had to jump through hoops to get an admin notice to be permanently dismissible, the solution for this method is refreshingly simple!

    First, comment out all the function calls in Gwyer_Dismissible_Admin_Notices::init(). Then, add a new add_action() function:

    And define the callback as follows:

    That's all there is to it! I told you it was simple, didn't I?

    The only thing we did differently this time was to use the is_plugin_active() WordPress function to test if the Hello Dolly plugin is installed and activated. If not, is_plugin_active() will return false, and our admin notice will be displayed.

    Example of a nag admin notice

    Try activating the Hello Dolly plugin to verify the admin notice goes away.

    This works well for single plugins, but what if you wanted to remind users to activate multiple plugins? Instead of hard-coding in the Hello Dolly plugin information, we could create an array to whitelist our required plugins.

    Replace install_plugin_to_dismiss_admin_notice() with:

    The required plugins are now stored in an array which is looped over to check if each plugin has been activated. For any plugin not currently active, the name is added to a $requires_activating array which is outputted via the admin notice as a comma-separated list of required plugin names.

    List of required plugins

    Custom Admin Notices

    Before we finish, let's have a little fun by creating our own custom admin notice types. Let's see how to add some custom admin notice types of our own. By now you'll be fully familiar with the four built-in admin notices WordPress provides by default, but it's not that difficult to come up with some of our own.

    First, though, comment out all function calls in Gwyer_Dismissible_Admin_Notices::init() so we start out on a clean slate.

    We'll need to add CSS for our custom admin notice types, so in the root plugin folder add a css folder, and inside create a file called admin-notices.css. To enqueue it on all admin pages, add a new add_action call in Gwyer_Plugin_Options::init().

    Then, for the enqueue_styles() callback, add this method to the same class:

    Now let's set up a new method to output our custom admin notices. In Gwyer_Admin_Notices::init(), add:

    Then add a callback to display a series of custom admin notices:

    Finally, add CSS to admin-notices.css to style our custom admin notices:

    After you save the changes, load any admin page to see our custom admin notices.

    Some examples of custom admin notices

    Judging by the results, it's probably a good idea to use custom admin notices sparingly, otherwise you'll run the risk of them looking garish. 

    I won't go into details about the custom CSS used. It's just for a bit of fun, and most of the styling is pretty self-explanatory.

    We used dashicons font icons for our custom admin notices for convenience as they are available in the WordPress admin by default. But you could import and use any icons you like for extra decoration.

    Try the Code for Yourself

    All the code from this tutorial series has been wrapped up in a WordPress plugin for you to download. Take a look at the code, extend it, and implement new ways to display (and dismiss) admin notices. Be sure to let me know in the comments if you create something cool! I'd love to see what you come up with.

    Conclusion

    Thank you for joining me in this four-part tutorial series. Hopefully you'll now have a lot more confidence in how you implement admin notices in your own projects.

    We've covered many different aspects of WordPress admin notices, including multiple ways of permanently dismissing them, which isn't possible without custom code.

    Creating your own custom admin notices is pretty easy too, but in practice you'd want to use them sparingly in your own projects. Most of the time it's best to keep to the default WordPress styles for a consistent user experience.

    WordPress has an incredibly active economy. There are themes, plugins, libraries, and many other products that help you build out your site and project. The open-source nature of the platform also makes it a great option from which you can better your programming skills. Whatever the case, you can see what we have available in the Envato Market.

    And don't forget to download the plugin and play around with the code. It's a great way to get more familiar with how all the pieces fit together. And please let me know your thoughts on the tutorial via the comments below.

    martijn broeders

    founder/ strategic creative bij shineyrock web design & consultancy
    e-mail: .(JavaScript must be enabled to view this email address)
    telefoon: 434 210 0245

Per - categorie

    Op - datum