Displaying Custom Messages in WordPress, Part 2

In the previous post, I started walking through what we need to do to display custom messages in WordPress. This is specifically in the case of when we are opting to use something other than the Settings API.

Custom Messages in WordPress

In the previous post, I covered the following:

  • Looking at what happens when you use a safe redirect via one of the available WordPress functions,
  • Serializing custom error messages
  • Saving them to the database

To follow-up with what was previously covered, I’ll show how to render these messages – regardless of if they are error messages, notices, or success messages – on the administration page.

Displaying Custom Messages in WordPress

Before going any further, it’s important to note that many times, using admin_notices will suffice when it comes to adding custom messages to WordPress.

But remember: In this case, we’re not only interested in displaying one of the standard messages, but we’re interested in displaying custom messages. For example, let’s say the user has multiple problems with the information they’ve submitted and we want to display information for each field.

As we saw in the previous post, we’re storing messages in an array and then serializing that array to the database into the options array.

In the following examples, I’m using error messages for the demo, but you can use this strategy for any message type.

Defining a Custom Action

Remember, in one of the previous posts, how we talked about creating options pages? In the series of posts, we talked about how to do from an object-oriented perspective.

In this example, I’m assuming that’s done, and you have your administration page ready to go. (If not, please read this particular post.)

With that said, we’re going to be using a custom action to retrieve the messages. To do that, we’ll define a custom action for rendering our messages. In the simplest example I can show, here’s what the markup for the administration page should look like:

Notice in the example above, everything looks about what you’d come to expect. But there’s one except one: Notice the call to do_action. This is where we end up wiring up the display to our custom error messages.

Grabbing the Error Messages

If you’re not familiar with defining your actions, it’s pretty easy.

This function invokes all functions attached to action hook $tag. It is possible to create new action hooks by simply calling this function, specifying the name of the new hook using the $tag parameter.

In the gist above, you can see that I have an action identified by the get_acme_settings_mesages string. This is what we’ll use to wire up a custom function for retrieving the error messages.

The code that I’m going to show is extracted from some object-oriented code, though you could just as easily use this in procedural code. First, here’s how we’ll wire up the custom action to a function that exists elsewhere in the class:

Then I’ll take the get_messages function and use it to populate the array with information that we saved in the previous post.

We do this by reading the values from the options table then deleting the entry (since they’ll be populated another time again if the user fails to provide the correct information when using the form again):

At this point, the messages stored in the database can be used to generate the HTML on the front-end of the site.

And though the string of HTML is dynamically built using information from the database, we’re also using a custom value to escape any disallowed markup via wp_kses.

Other Ways?

Many of the examples between the last post and this post are extracted from an object-oriented project in which an entire custom messaging system is being used.

Through these examples, I hope to have shown how you can use ways to store messages in the database, retrieve them, and then render them on the front-end using a custom action.

The thing is, there’s no single right way to go about doing this. Sure, some ways are different than others, and some are going to be able to leverage the WordPress API more than others.

Whatever the case, make sure the work you’re doing and the way you’re handling messages is best aligned with the requirements of the project in question.

1 Reply to “Displaying Custom Messages in WordPress, Part 2”

Leave a Reply

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