Tag: WordPress (Page 163 of 220)

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

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

For anyone who has does any kind of work with WordPress meta boxes, you know that it generally consists of the following steps:

1. Define the meta box
2. Define the callback functions responsible for displaying the markup

Pretty simple, isn’t it?

Of course if you’re looking to introduce a more advanced functionality into your meta box then you’re likely going to want to introduce stylesheets, JavaScript dependencies, nonce values, and perhaps even tabs to logically separate the options.

Given the fact that I’ve recently looked at some of the various ways to save data in WordPress meta boxes, I thought it might be work sharing one way to help separate the business logic from the presentation logic as it relates to incorporating WordPress meta boxes either in themes or plugins.

Continue reading

Recently, I was having a conversation with a friend about some of the various ways to serialize the values that are present within a collection of meta boxes that are defined for any type of post – be it a post, page, or a custom post type – within WordPress.

For example, imagine that you have a custom post type that has, say, four different meta boxes that are available below the main content area.

These meta boxes can be laid out in one of two ways:

• The meta boxes can be listed individually with each meta box having its own set of values. Think of WordPress’ Excerpt field, Discussion field, and and Sharing Field.
• The meta boxes can all be contained within a single container accessible by individual tabs.

The question is does the way that the meta boxes are displayed influence how the values are serialized in the database?

Continue reading