Tag: WordPress (Page 31 of 219)

Articles, tips, and resources for WordPress-based development.

WordPress Widgets: Refactoring, Part 3

December 12, 2018 / Tom

In terms of updating the WordPress Widget Boilerplate (all of which is tracked in the develop branch), we’ve come a long way in terms of refactoring how it’s organized.

Thus far, we’ve:

looked at how the WordPress Widget API provides an example of object-oriented programming,
how we can use this API to determine object-oriented programming in other areas of WordPress,
installed tools to help us evaluate the quality of the code,
found errors that currently exist in the code in terms of modern programming standards,
and began re-organizing the code base so that it fits with more modern practices.

Now we’re ready to start refactoring this code in a much more object-oriented manner.

So if you’ve yet to catch up with the previous posts (any of them, really), I recommend doing so because it’s going to take a little while to bring this up to date. There’s a lot of code to write an explain.

Let’s get started.

WordPress Pagination: A Simple Utility (And Why)

December 6, 2018 / Tom

When building templates for WordPress, you generally have pagination functions that come from the application itself.

WordPress Pagination: Get Next Post

These incude things like:

And there are a few other posts that give you greater granularity around taxonomies such as get_adjacent_post().

I recommend reading all of the above links because they are useful if you’re building a theme, working with custom post types, or are simply looking for a deeper understanding of some of the common template tags.

If, however, you’re looking for an easy way to write your WordPress pagination utility (which I’ll explain the rationale for momentarily), then the rest of this post will cover exactly that.

WordPress eCommerce, Past, and Future

December 5, 2018 / Tom

Rewind a few years, and early e-commerce in WordPress was a bit of a hack (as it was in most blogging software).

There was a time when “WordPress is just for blogging” was a valid argument. Products were simply blog posts. Programmatic gymnastics took place to work around this, but in the end, everything was saved in the database as a post with attributes just like any other blog post.

Then, in WordPress 3.0, Custom Post Types came to be, and this opened a vast array of possibilities. Suddenly everything fit in the posts table. Anything you could think of, from social network content to e-commerce products, could all fit in the posts table, with the postmeta table to back it up.

A post could now be thought of as an entity or a model with attributes or properties described by information in the post metadata table.

But it’s not like that anymore.

WordPress Widgets: Refactoring, Part 2

December 5, 2018 / Tom

After all of the preliminary content, we are finally at a place where we are ready to begin resolving the coding standard problems thrown by our IDE and by our code quality tools.

In doing this, I’m going to be breaking down the content into two posts:

the first post is going to focus solely on refactoring the existing code,
in the next post, we’re going to look at refactoring the structure of the plugin to enhance the organization and architecture.

Screen Capture on 2018-11-20 at 12-50-27.gif

For now, though, let’s take a look at the errors the code sniffer is throwing and see if we can’t bring it up to more modern standards.

Quick Tip: Optimizing Loading Assets in WordPress

November 29, 2018 / Tom

Whenever I think of assets in WordPress, I generally think of JavaScript files and stylesheets; however, I know that fonts and images can also count, too.

One of the things that are all too common, though, especially as it relates to the administrative area, is loading assets in WordPress on screens where they aren’t needed.

It’s completely possible to make an argument that given the file sizes or the functionality that each present, the files are only impacting a minimal amount of load time at best, right?

But match this mentality with who-knows-how-many plugins, and you’ve got more than a heavy impact happening on a given payload.

So what can we do?