Software Engineering in WordPress, PHP, and Backend Development

Category: Articles (Page 209 of 258)

Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.

WordPress Theme Development: Know Your Customer – The Blogger

When it comes to WordPress theme development, one or the areas that developers often find themselves wrestling with is just how verbose they should make their code.

For example, we’re often taught and strive from principles such as DRY and KISS, but it’s hard to maintain both of these when building WordPress themes from the ground up.

For example (and as according to the Codex):

At the very minimum, a WordPress Theme consists of two files:

– style.css

– index.php

And for anyone who has done extensive work in WordPress development knows this to be true; however, if you’re getting into theme development – that is, specifically for bloggers, or digital publishers – then you know there’s a wide variety of templates that are also supposed by the WordPress Template Hierarchy.

To name a few:

  • style.css
  • rtl.css
  • editor-style.css
  • archives.php
  • author.php
  • category.php
  • comments.php
  • date.php
  • index.php
  • single.php
  • tag.php
  • …and so many more

But here’s the deal: it’s nearly impossible to embrace DRY while simultaneously trying to implement each of these templates.

Instead, we’re left with having to repeat a variety of code all the while doing so when much of the code could be produced though template parts and conditional logic.

Though I’m sure we all fall somewhere in between on this issue, he’s where I’ve landed with respect to the various themes that I’ve developed over the last couples of years.

Continue reading

WordPress Settings API Wrapper? No Thanks.

From time to time, I end up having conversations with other developers about the state of the WordPress Settings API, whether or not there should be wrappers for it, and/or how the current API can be improved.

Each time the conversation begins, it generally stems from the fact that the Settings API is confusing, can be very intimidating to work with the first time, and it’s not as intuitive as some of the other WordPress APIs.

As with anyone who’s worked with WordPress long enough, I have my own opinions about this – and this is certainly not a “patches welcome” post – because this has been already been discussed at great length on Trac.

Instead, this is nothing more than my general stance on the WordPress Settings API, and how I see wrappers fitting into the scope of overall WordPress Development.

Continue reading

How To Add Google Fonts To The WordPress Editor

When it comes to building themes in WordPress, one of the nicest things that you can do for your users is to implement a stylesheet specifically for the editor so that they get a true WYSIWYG experience.

To be more specific, that is you can (and should!) add a stylesheet specifically for the WYSIWYG editor in the WordPress Dashboard. This stylesheet is normally called `editor-style.css`, but can actually be called whatever it is that you’d like permitting that you enqueue it properly.

With the popularity of web fonts rising – such as those from Google – you have to take a slightly different approach when implementing them in the context of the editor rather than the typical way of doing so with server side hooks.

Continue reading

Starting 2014

For many of us who write regularly, it’s hard to fight the urge not to write about what we did last year, what we plan to do this year, and how we’re going to accomplish it.

Though I don’t typically write those types of posts, I absolutely dig reading them for others primarily because:

  • I think that I follow a lot of really interesting people who are doing a lot of really interesting things,
  • It’s inspirational to see what others have achieved,
  • It’s fun to see what’s coming in the next year from said people and watch them make it (or even scrap it!)

And sure, I have my own goals and things that I plan, but I’ve been at this long enough to know that I do best when I forecast for the short term – that is, for the next quarter or so – and then make detailed lists for the given month on what I’d like to accomplish.

Sometimes, items carry over from the previous month; most of the time, the list of full of new things to check off.

In an attempt to cover what I’m planning to achieve in the first part of 2014 (read: January), I thought I’d go ahead and share a couple of notes specifically related to WordPress work – both from a personal stand point and from Pressware’s standpoint.

Continue reading

What I’ve Learned About Open Source Project Management: Releases

This is the fifth and final part in a series on What I've Learned About Open Source Project Management.

Though some may argue, I think that all projects – open source or not – ultimately culminate in releases. That is to say that when it comes to building software, your ultimate goal is to provide a solution for your users that gracefully solves their problem.

I think all developers strive for kaizen in their work, but because of our own nature, we end up shipping things that sometimes feel like a step back, sometimes introduce more bugs, or sometimes simply dissatisfy the user.

Of course, that’s only one side of the story, right?

On the other hand, companies and developers do often ship incremental improvements of their software much to the delight of their users. And though that’s not always the case, it’s something for which we all should aim.

Everything that’s been covered in this series leads up and contributes to releases.

How this works in closed source software may or may not be the same as it works within the confines of open source project management – I’d venture to say that there’s overlap – but nonetheless, here are my takeaways with respect to aiming for releases in open source project.

Continue reading

« Older posts Newer posts »

© 2026 Tom McFarlin

Theme by Anders NorenUp ↑