Tag: WordPress (Page 170 of 219)

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

My Workflows For WordPress: Hosted Projects

February 19, 2014 / Tom / 0 Comments

If you’re like me, then there’s a part of you that’s obsessed highly motivated to make sure that you’re streamlining your workflow as much as possible.

When it comes to the process of working on WordPress plugins, WordPress themes, and how to manage everything via source control, support forums, and managing bugs and their associated tickets, all the while making sure that you’re not duplicating repositories in order to make sure you’ve got the leanest workflow possible can be a bit of a chore.

Even writing (and possibly reading that last sentence) is just as indicative as to how tedious it can be.

So, with that said, I thought I’d share my workflow for how I divide up my codebases based on if they are hosted in the WordPress plugin repository and/or the WordPress theme repository, and how I deal with support, as well as how I manage self-hosted projects and their associated support forums, as well.

In this first post, we’ll cover the former.

Programmatically Set a Default Menu in WordPress

February 18, 2014 / Tom / 0 Comments

When it comes to building a theme (or any WordPress project that’s going to feature custom menus), there are several options from which we can choose on how to set a default menu.

We can…

use whatever WordPress provides,
remove the default custom menu,
or programmatically set a default menu

The first two are relatively easy to do (as is the third), but I’ve found that in the majority of my work, clients usually want to have a default menu of options relevant to the project at hand if the user doesn’t set one by default.

Outsource WordPress Support (I Don’t, But What About You?)

February 17, 2014 / Tom / 0 Comments

I recently received a comment on my article on WordPress plugin support (that is, How Much is Too Much?).

Specifically, the comment asked:

So why not just outsource the support e.g. use a service that provides support to plugin end users on behalf of the plugin developers? Seems like that would save the developer a ton of time.

I thought that this was a great question, but as I began to respond, I thought that it may work better as a full post rather than a comment if for no other reason than to more easily share my own thoughts on the matter (but also to gauge other people’s opinions, as well :).

Separation of Concerns with Queries and Helper Functions

February 12, 2014 / Tom / 0 Comments

In the previous post, I shared a little bit about the idea of separation of concerns – a concept that’s usually isolated to software development – and one way in which it can be achieved as it relates to working with WordPress templates.

But there’s always more work that can be done to help make our code as modular, reusable, maintainable, and readable (and any other buzzwords that I forgot ;) as it relates to programming projects.

One of the challenges of working in a system like WordPress is that it doesn’t necessarily promote practices that are typically seen in more classical programming environments, but – the way that I see it – we’re doing many of the same things:

Solving problems through the use of code,
Abstracting reusable components,
Querying for information from a database through the use of provided APIs,
Keeping areas of the code modular and related to the areas of the application and their best related,
…and more.

So why should we avoid trying to apply better programming practices to our code regardless of if it’s a high-end object-oriented application, or – say – a theme with a number of different templates, JavaScript, styles, and queries (and even more things such as post types and taxonomies depending on the nature of your project)?

After all, it’s all code, right?

Separation of Concerns with WordPress Templates

February 11, 2014 / Tom / 0 Comments

One of the biggest pain points in working with WordPress templates – or, really, any PHP and HTML in general – is how we end up jumping from language to language within the context of a single file.

Obviously, this is unavoidable. I mean, the same thing even happens in other frameworks like .NET and Rails, but one of the things that I’ve seen that continually sets WordPress apart (and I don’t mean that in a good way) is that developers often don’t bother to spend time separating their concerns as it relates to the work being done in any given template.

A Vanilla Template File

For those who have been working in WordPress for several years likely know this, and know the frustration this causes.

For those who have recently hopped into WordPress development, there’s a strong chance you’ve likely been overwhelmed with some of what you’ve seen.

It’s a bummer, I know.

But it doesn’t have to be that way.