Get it All

One of the most important concepts in the world of WordPress web development is that of the parent/child relationship between themes. The parent/child relationship is a scenario in which a “parent” theme represents the final source of all code: if you cannot find a given file in a theme declared a “child” of one parent, then you should be able to find that file in the parent. The purpose of this relationship is to allow the child theme to extend and enhance the parent theme as suits a given website’s needs, while still maintaining the base level functionality of the parent theme. This failover system further augments WordPress’s excellent Template Hierarchy structure, guaranteeing a suitable template layout file for any request.

When properly understood and executed, this parent/child relationship allows developers to build complex parent themes from which all manner of new websites can be built in the child theme. Doing so is a sure-fire way to maximize the learning curve of your software: new techniques and interfaces can become available to the next project, instead of stuck in a single-site solution.

In my case, my parent theme is really just a toolbox of functionality and layout helpers with almost no usable layout of it’s own: it provides the toolbox and a few baseline layouts like a generic archive and single-post page. All the implementation of that toolbox happens in the child theme. I have even augmented the parent/child relationship a bit by providing failover support for JavaScript files and non-layout files in my theme.

That said, I’m always looking for better ways to make use of this relationship. So I was pretty excited when I found out that Advanced Custom Fields comes with the option to save it’s field declarations as local JSON files. I’d previously been doing all the work of creating Custom Post Types – and their backend interfaces – more or less by hand. But having worked with ACF for a bit, I realized it was a more efficient means of adding meta fields by miles.

Now it seemed, I’d found a way to statically create the fields I needed for my base CPTs and have them extend and be extended by a child theme. Perfect!

Not So Perfect, Yet.

Now, I’m pretty particular about my directory structure for my plugins. I like things organized more like the PSR2 standard prefers and fortunately, the WordPress-Core standard also recommends something similar. With that in mind, ACF’s default location for local JSON does not suit me. I’d rather not have an /acf-json directory in the root of my theme. Instead, I’d prefer to have my ACF-specific JSON files live somewhere in the /Library/ directory of my theme.

But there is a solution for this! Advanced Custom Fields provides filter hooks in that part of the code that saves and retrieves JSON, as they explain in the documentation for local JSON. Those hooks are ‘acf/settings/save_json’ and ‘acf/settings/load_json’. So my first attempt to move the JSON to my desired destination looked like this:

The persistent problem I ran into with this setup was that ACF seemed always to be confused as to which directory it should be saving and recalling from. If you read through that code, it at least attempts to establish the same parent/child relationship as WordPress uses for standard template files. New changes to Custom Fields should always be stored in the current (most often, the child) theme directory. When pulling JSON to populate fields, a child theme’s /Library/Acf-Json folder should be used first, followed by the parent theme.

But in practice, after successfully changing a field name in a child theme, the Custom Fields admin pages would show the correct new name and the Write Post screen would display the old name. Those fields did not present the option to “synchronize” themselves, so there seemed to be no real fix. This was all discussed with the forum help at ACF here.

After a bit of digging and considering and reading the actual ACF files in question (/advanced-custom-fields/includes/wpml.php, if you’re interested), I decided that rather than simply add my own code to the acf/settings/save_json hook, I would remove the default function completely. By doing this and using array_push to be sure I was saving the directories in the correct order, I was able to achieve the the correct functionality. So I commit this blog post for the benefit of those who find themselves similarly challenged by this super-helpful but perhaps less than well-documented feature of Advanced Custom Fields:

The WordPress Customizer is an important part of the toolset of any developer who maintains their own custom base theme, whether we use that theme for projects or offer it up for sale. But I find there is a bit of a bedeviling problem with the Customizer and default theme modifications (theme_mods). Basically: there’s no built-in solution for them.

Consider the following scenario: a theme uses a scaffolding framework like Zurb Foundation to produce completely-custom layouts, and therefore does not have a “base state,” as would be present with most commercial themes. In commercial theme sales, the idea is to create a theme which is hopefully 80% of the way to someone’s perfect website. A developer then buys the theme, making small adjustments in a child theme to cover that last 20%.

But this theme is a toolbox aimed at providing unlimited layout options. If I want a horizontal-stripe layout for one page and a standard blog header/footer/content/sidebar layout on another, this theme will allow it. There are no assumptions as to what you’d want out of the theme. As such, in order for the theme to present ANYTHING on the front end, it’s going to need some default mods. Actually, rather a lot of them. But the solution is pretty simple, in theory: just load a default set of mods if nothing has been saved in the Customizer.

Here’s where it gets tricky: unless you’ve modified a value in the WordPress Customizer, it does not save to the theme mods for the theme. So if you open a WordPress Customizer, change a few values, then hit “Publish”, those mods and ONLY those mods would get saved to the database. That makes life difficult if you’re looking to quickly check to see if anyone has modified the theme as in the above scenario.

Digging around, I discovered that the WordPress Customizer ships with a number of filters. But for our purposes, there is the customize_save hook, where we will insert our own check for default values:

Those of us who remember suffering through Subversion repository woes will remember our elation at finding Git. Things Subversion promised but never quite delivered were handled with ease when we got to Git. Merging changes? Updating branches? Rolling back changes?? All a snap.

But there are some subjects on which I confess I have adopted the “we’ll get to that particular voodoo later” attitude. One of those was figuring out what the difference between git merge and git rebase. I shan’t bore you with that whole story: Google answer-seekers, rejoice! Instead, here goes:

The difference between git rebase vs merge is the commit history.

If you rebase a branch from it’s source (feature branch from master, let’s say), none of the commits from the source branch will show up in the feature branch’s history. If you merge the two branches, you will have both branch’s commits in the source branch.

The result of merging therefore is a commit history that includes a lot of work that did not happen in the current branch. The result of rebasing is a commit history that does not include changes that have recently been added to the current branch from elsewhere. Both of these scenarios have advantages and disadvantages.

Rebase feature branches, merge master

Sure. There’s lots of nuance to this kind of broad-strokes pronouncement. I encourage you to read this article, which has so far been the best tutorial on the subject that I have read. But for brevity’s sake, in probably 90% of cases, the above statement is your best guide.

Feature branches should presumably have lots and lots of commits. Personally, every time I think I’ve got a feature or bug “fixed,” I end up committing that new change right away. Yes, it makes for a lot of logs. But it also means the exact moment when a file got changed is much more reliably pinpointed.

If I were to merge my master branch into my feature branch, I’d also have all the commits to master from other developers mixed up among my branch’s commits. File changes that have nothing to do with my feature would appear as their own logs. For this reason, I’d rather just have my feature branch focus on the work that I did, with commits that match.

When I bring changes from a feature branch into master, I actually do want the small changes and logs to appear in the master branch. I may need to track a specific file change, and the feature branch will soon be either destroyed or archived. Incorporating a feature branch’s commits helps me do that.

Git rebase vs merge: the advantage

I’m assured that feature branches contain logs that only concern that branch by rebasing changes from master into them. I am assured that all that work from all branches will be reflected in the master branch’s logs by merging changes into master.

Hopefully, this discussion of why you would use git rebase vs. merge was helpful. Do you have another theory for managing these two features? Please comment below!!

Hello, non-coder person! If you are not a developer and clicked on this article anyway, thank you! This article is definitely aimed at you. I’m a firm believer in cross-pollination and synergy among different disciplines and to that end, I have written this article to provide a bit of insight into the world of logic as developers see it on a daily basis.

My hope is to illustrate a fundamental concept in development that is important to all of us who rely on our work being correct, timely and self-evaluating. It is my intention to explain something in pseudo-coding terms that provides immediate value to all Agile teams. Understanding the nuances of logical decision trees like those developers create can help improve the way we organize our projects, communicate our needs and execute our tasks on a daily basis. Follow along, won’t you??

And if you like this article, please have a look at my developing Agile article series, Continuous Learning Curve!

Wanted: True or False

The most basic concept in the world of coding is logic, and logic is binary. Statements can either be evaluated as true, or as false. There are no “maybe’s” in logic. It is a world of seeming perfect bifurcation: true and false, one and zero, on and off.

One might think that a binary system’s best expression would be a perfectly-bisected world: a world in which concepts evaluate as true as often as they do false. One would expect code created in this world would work as effectively on both sides of the boolean divide.

But that seeming clarity hides a world of complexity, as new developers quickly discover. Nothing about the duality of logic creates a truly binary system, because the concept of false encompasses a world of bad options much larger than that of true: anything in the world other than true is false.

Should I Stay or Should I Go (a boolean example)?

Consider a simple mathematical equation: 2 + 2 = x. If I were to tell you that x was 4, that would be true. But every other number you can think of is false. So to would be every alphanumeric character, punctuation mark and combination of characters. The number of true statements (1) is vastly outweighed by incorrect statements (∞-1).

The Von Van Venn

Fig. 1 – Save this image and take notes. This is important.

Of course, that is a simple example. As a slightly more complex example, consider the Venn diagram to the left.

How would we construct a logical statement from this diagram that could evaluate to true or false? Well, what if we were to ask “Is a Van musical?” The human answer is “maybe.” And the answer is a maybe, based on other data: is the Van in question a Van Halen, or some other type of Van? Because if it’s a Van Damme, well, that’s not musical at all, according to the chart. A computer will therefore evaluate the answer as “false,” because simply being a Van is not enough to be musical.

Yet in this more complex example, the ranges of potentially true and false statements are much narrower and much closer to equal than in the simple algebraic one. We do not have a single right answer and because we are bound by three domains (European, Musical and Van) we do not have an infinite number of answers, either. We do have answers that are partially correct, and evaluating the veracity of any statement based on this example gets trickier.

Most Musical people and European people are not Vans, but even most Vans are not Musical. Meanwhile all intersections between the Musical and the Van circles – including that section where all three circles intersect – evaluate as true. We’ll call that center bit the “Van Morrison Zone.”

Decisions in the Boolean World

Decision making code illustrates this concept of unequal evaluations. The example below is the most basic logical decision maker, the “if/else” evaluation, and contains within it the central paradox of logic. In this evaluation, we ask the system to evaluate if a statement is true. In that case, we execute the block of code just below the if clause. If the statement evaluates false, we execute the block of code after the else keyword.

This is among the most basic of code concepts. New developers often use this idiom to create logic trees that treat if and else as equals. The developer evaluates a statement and based on its truth or falseness, takes the next step in the process. We could for example evaluate whether x in our first example equalled 4, continuing on with the script if true or generating an error if the answer is false.

But as we see in our second example, not all decisions can be made in a single evaluation. We combine two evaluations into a single clause and only if both evaluations are true can we arrive at a true statement. Critically, we arrive at a clause that treats the if and else clauses differently: the if clause treated not only as the true clause, but also as the more specific clause:

The Principles of Boolean Thinking

So what is the upshot of all this boolean determination? Does the fact that false represents a larger subset than true mean anything practical in the real world? How can we improve the way we approach projects and communication better by understanding this idea? Here are a few very important take-aways:

  • While true and false represent two subsets of an entire range possibilities, if and else clauses yield only two actions with which to treat the subsets.
  • Because we can evaluate a statement true only when we can specifically identify it as true, that subset of possibilities includes statements about which we know a lot.
  • Because anything that does not evaluate to true is therefore false, we know relatively little about this set. We cannot assume anything about this result set, including whether the statement exists within the range at all!

That last bit is important to understand: while our Venn diagram was a closed system, most things in life exist out in the open, in the midst of a nearly-limitless set of possibilities.

This all adds up to a basic tenet: else statements are inherently weak and unreliable. Contrary to our original assumption, code does not work as effectively on both sides of the boolean divide, at all. We cannot know anything with certainty about else statements, therefore what we do with those statements must be limited and generic. The only place for an else statement to lead is either an error or else a new interrogation, altogether. But one way or another, you just can’t trust ’em.

In Agile development, we are trained to tell stories about the work we need to get done. “As a [role], I need [goal] so that [reason].” Taking that idea one step further, we can describe our desired result as a simple if/then logical tree to better understand the relative complexity of our request.

Let’s walk through a set of Story statements to see how this might work.


As much as I love WordPress, I am continually frustrated with the pace at which forms get created. That’s because, while WordPress seems to have thought of everything else, the most basic part of creating interactive websites seems to have been ignored: the forms.

Yes. There are front end form builders like Ninja Forms. But while they all work well within their own context, much of the customization of the forms either requires additional, paid-for plugins or simply isn’t possible due to constraints of the plugins themselves. Besides which: I’m not often building front-end forms, but rather forms to add metadata to posts or set configuration variables for the site.

What I have wanted and needed was something like CakePHP’s FormHelper: an interface that simplifies the process of outputting HTML5-valid forms and inputs. Something that allows me to specify the settings for an input, and puts the aggravating process of laying out the form in it’s own hands. And so I created EasyInputs: A Forms generator for WordPress.

The plugin is still in early stages of development. But so far, I’ve been able to clean up and cut down on code for one of my other projects significantly. And besides speed and accuracy, there are a couple of key advantages to building forms in this way. For a start, if you’re trying to keep your WP code as close as possible to PSR2 standards, adding values to an array is a lot more convenient than sprintf’ing the long HTML code associated with forms. Secondly, the code output from my plugin is significantly clearer than a rat’s nest of escaped and unescaped HTML code.

WP-Scholar’s Person CPT with escaped HTML:

WP-Scholar’s Person CPT with EasyInputs:

This is just a relatively basic example. The plan is to support every HTML-valid input including <datalist>, <keygen> and <output>. Right now, these new elements are missing. I’ll be updating that shortly (perhaps before you even read this!), along with some basic HTML security: every EasyInputs text input will include the maxlength attribute.

I know that the WordPress devs are working on some sort of fields API. But as I’ve observed it, the development process still banks too heavily on bringing those fields into the WP regime, which may satisfy the needs of the WordPress team, seems too rigidly focused. Developers don’t need a complete solution for every little thing, they need simple tools that do simple things well. That’s the aim of this development project.

Please have a look at the latest stable tag and tell me what you think!

I’m not a fan of unstyled content. I don’t think many developers are. Worse, while I like to reuse my dialog divs, I don’t want the old content confusing users when the dialog first opens. And of course, users often rush to try to use dialogs as soon as they open, so we need to give the dialog a chance to load it’s content before that. So I needed to create a generic function for opening a jQuery dialog box, putting a “spinner” in the box until the proper content loads. Here is my solution:

The function presumes you will be loading content from an AJAX call and provides a couple of very handy parameters. First, you can pass the complete option object for the jQuery Dialog API into your function call, making the dialog itself completely customizable. Second, it provides a callback function parameter, which will be run after the content is loaded into the content area of the dialog.

To use this function, simply include the following HTML into your page, somewhere near the footer (I use CakePHP, but you can just use a regular image call to get the spinner:

Use your CSS to hide the #popup div and you’re ready to start implementing dialog boxes the smart way!

So the issue is this: I’m creating a faceted search interface for a client’s application. Rather than clutter a window with textbox after textbox, select after select, most of which they don’t use on a regular basis, my solution is to create dynamic form fields based on the user’s requests. Need to search a SKU? No problem! Need to select from a list of clients? Gotcha covered.

All of this has worked out quite swimmingly overall, but a bug was brought to my attention today that I had to share with the rest of the Internet. Specifically: users were typing their responses into a jQuery Autocomplete field and then clicking “Submit,” only to find that their response was not recorded and not passed on in the query. Annoying!!

With a bit of digging, I discovered the problem. The jQuery autocomplete UI does not allow the value of the field to be updated until one of two events is fired: “change” and “select.” Trouble is: if you go directly from typing a value into the autocomplete field, directly to the submit button, the “change” event does not have time to fire.

The solution to the problem, which I discovered on the always-helpful StackOverflow website, follows below. The gist of it is that you need to first prevent the form from submitting, double-check that autocomplete fields have been properly “change”-d and then submit the form:

I have had the privilege of working with Tom at Holistic Networking at multiple clients over the past 10 years. He has consistently provided web development, digital marketing and e-commerce solutions for many of these organizations while addressing a wide variety of challenges. Tom has always furnished his expertise to serve the needs of diverse types of businesses.

Tom/Holistic Networking helped us to create a dynamic user experience with intuitive navigation, which is critical for a company with both B2B and B2C sales channels. We also needed to build an e-commerce platform with several technical requirements including secure Rx transmission and multi-field checkout, and Tom/Holistic Networking embraced the challenge and executed with ease.

Tom has been great to work with. He was able to transition a custom built legacy system into a clean and modern WordPress installation that is much easier to maintain. He didn’t simply move 25 years of data as we initially instructed. He took the time to learn what our data meant and built the system we needed, rather than the one we asked for.