Category: Articles (Page 184 of 258)

One of the things that has become relatively common within themes that offer a lot of options is the use of tabbed navigation. That is, options that are related are logically grouped into tabs and then the user can navigate through each tab in order to select the options.

Whether or not this is a good thing for themes is outside the scope of this particular post; however, another place in which tabs may also be used is within the context of custom meta boxes.

That is, a custom meta box sits below the post editor and it offers several options or additions to the post meta data each of which is group together in their own tab.

Though I personally find this a bit more effective than using tabs of pages for screen options, that discussion is outside the scope of this post.

Regardless, there are ways to improve the ways in which custom meta box tabs are created such that they are organized in a more maintainable way, and each tab has its own view, partial, or template so that it’s easier to work with over time.

Continue reading

I know that there are different ways that people approach building WordPress themes and I’m not one to argue that there’s a single right way to do it. Sure, some ways are better than others, but that’s true of a lot of things.

Personally, I approach building themes, plugins, and so on as I would as if I was building some type of software. That has to do with my background. Similarly, someone who has a background in design and in front-end development will conceptualize what they are building in a different way.

Like I said, all of that’s fine (in fact, I think it’d be interested to see how different people view building themes, but I digress), but I do know that one common thing we always have to think about as it relates to updated our WordPress themes is the actual front-end design.

Specifically, does it make sense to completely change the design of a theme for a different version of the theme?

Continue reading

Last week, I was having a conversation with a fellow WordPress developer about improving page performance as it relates to JavaScript. Specifically, we were talking about if it makes sense to load JavaScript sources at the bottom of the page.

If you’ve done any client-side development for a moderate length of time, odds are strong that you’re well-aware that it’s considered a best practice to include JavaScript sources before the closing body tag rather than in the head element.

This is because it allows the browser to render the page more quickly without waiting for larger files to download (and JavaScript files are normally heavier than HTML documents because of their file size and the processing they do on the DOM).

There’s a lot that could be said with respect to this in terms of general web development, but in terms of WordPress, opting to enqueue your scripts at the bottom of the page versus the top of the page may require a bit more consideration.

Continue reading