Tag: WordPress (Page 162 of 219)

Regardless of your level of experience with WordPress, everyone is familiar with seeing the messages that display whenever an action has completed within the dashboard:

• We have success messages for when something has completed, ahem, successfully,
• We have notification messages which are neutral pieces of information that give a heads up something has happened,
• And we have error messages that let us know that something has gone wrong.

For anyone that’s read past articles, you know that when it comes to introducing functionality into the WordPress dashboard, I firmly believe that the work we do should look as native as possible. That is to say that I am not a fan of custom styles, custom controls, or extraordinary styles to give your theme or plugin that “extra edge.”

And for those who are familiar with the Settings API and/or the Options API, then you’re likely familiar with introducing new sections, settings, controls, and options, but what about error messages?

Generally speaking, success messages and notification messages are reasonably easy to come by, but let’s say that you need to validate some piece of information that’s coming into the server and return an error if it fails.

Continue reading

The more time anyone spends with WordPress and all associated products (that is, themes, plugins, and so on), the more likely they are to also pick up on all of the commentary – both good, bad, and neutral – that surrounds the core application.

Obviously, I’m a fan of WordPress and make my living building things for it and trying to give back to the core application when I can so I know that what I’m going to say is going to come off as biased just as anyone else who writes about their preferred technology stack.

I’m well aware of the common complaints people have about the WordPress codebase and I’m not here to defend, to make statements about how it’s getting better, or to spark a discussion on how hard it is to maintain legacy features for a decade.

But if you’re a developer who is just getting into WordPress – specifically, products built on top of it – then I think that a significant portion of your first impression has to do with your experience on the first product that you use.

Continue reading

This is the final post in a series on how to achieve simplicity with WordPress meta boxes.

The whole point of this entire series has been to demonstrate how to logically separate the various pieces that go into components a project by breaking them down into related components. Though I’ve been using them as a means to an end, the purpose of all of this is not about how to use WordPress meta boxes.

Anyway, to round out the series, the last thing to do is to take a look at exactly how to leverage the work that we’ve done thus far to bringing it to the front end so that the code that works on the backend actually does something on the front.

It’s not going to be anything particularly special or unique, but it should showcase the point nonetheless.

Continue reading

This is the second post in a series on how to achieve simplicity with WordPress meta boxes.

In the previous post, I talked a bit about how working with WordPress meta boxes can be a bit of a hassle especially if you’re used to doing so in such a way the keeps all of the logic contained within a single file and a handful functions.

For example, if you’re working on a theme, then it’s likely that you’ve got a set of functions declared either in your functions.php file or file referenced by said file that is responsible for making a call to add_meta_box and all of the necessary arguments for rendering the meta box.

If you’re working on a plugin, it’s likely that this isn’t all together different; however, you may be approaching this from an object-oriented perspective. If that’s the case, then you may have a similar setup as above which isn’t really that different except you’re using classes and functions.

Continue reading