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.



I’ve been a big fan of Zurb Foundation for quite a while. So much so, that every WordPress project I’ve created in the last six months (about 40, all tolled) have been built using my Foundation 5-based theme, HN Reactive. The new version of Foundation has had me itching to start developing, but I’m presented now with a problem:

The production server where I house my clients’ projects has tons of projects that rely on Foundation 5. But Foundation 6 is significantly different from 5 that they’re not at all compatible. Worse, since both versions want to use the name “foundation” as their function name, they step on each other. So, how can we use Foundation 5 and 6 together?

It is true that the only reason to use the “foundation” command with 5 is usually to create a new project. You could probably continue to use Compass to compile existing Foundation 5 projects while using the Foundation 6 version to create new projects. But that is a wholly unsatisfactory position to put myself in, on the off chance that an installation of 5 needs to be rebuilt for some reason or another. And there’s no way I’m putting myself in that position on a production server where a lot of people are paying me money not to have such problems.

Zurb Foundation 5 and 6 together:

After searching for a solution and finding none, the solution ends up being aliases. By creating an alias record in your shell profile (.bashrc or .bash_aliases in Ubuntu), you can all live together in one happy, productive family:

Late Update: it appears based on further research that a recent update of Foundation 5 ended up putting that executable in the same place as F6. So with this in mind, I recommend:

  • Install Foundation 5
  • Move the foundation executable from /usr/local/bin to /usr/bin
  • Install Foundation 6
  • Setup your aliases.



Come on in, Mr. Client. Have a seat.

I wanted to have a word with you about your website. You know, the massive data structure that combines text, audio, video and images all in the pursuit of explaining what it is you do and how your customers can find you. Yeah, that thing.

Does it not strike you as wholly silly to have an “About Us” page on such a thing? Isn’t the entire site, you know, about you? Is there something you really need your audience to know about you that isn’t somewhere else on the site? And is that a good idea?

Some conventions of the Internet exist almost completely without cause. They’re just things we’ve grown accustomed to seeing and feel weird about not having. The “About Us” page is top of that list, in my opinion. Unless you run something like a media site – and maybe not even then – there is nothing about you that doesn’t deserve equal time with the rest of your marketing content. In fact, your marketing content should be shot through with all those most important things about you that make you different. Or special. Or just happy to be alive. But it doesn’t belong on one lonely page that nobody will bother with.

Frequently, when designers I work with spec out pages, I’ll tell them to just kill the About Us page. Make an About link in the navigation if you have it, but link that to the front page. Why waste the effort on a vestigial page?

Let HolisticNetworking Help You Organize Your Site Today!

If you’re looking to use Zurb Foundation for WordPress layouts (hint: you should totally be using Zurb Foundation for WordPress layouts), you’ll probably want to create a fluid, responsive footer that is horizontal for desktop but vertical for everyone else. How do you go about such a thing? Bon apetit:

Change is hard. After 14+ years of WordPress development, change is also a constant thing. But the change to using the WP Customizer, as required by the WordPress repository, had me kicking and screaming rather than complying.

Mind you: I don’t actually submit to the repository for themes. But when the WordPress devs start laying down the law like that, it doesn’t take much imagination to recognize that more pressure will be building up soon. And development of the core will definitely be going in that direction, so you may as well find a way to love change because change is coming.

I understand perfectly the need WordPress devs are confronting: what used to be a relatively well-organized, small community is becoming unmanageably large and the result is a whole lot of bad code. People put options wherever they feel like, making the use of WordPress – because in the end, users will only ever blame WordPress, not private developers – an arduous and unsatisfactory process.

But I am also experienced enough of a WP developer to remember some of the bad roll-outs and misbegotten innovations past. Post formats were basically a half-assed attempt at building something CMS-like out of WordPress. Taxonomies were introduced with huge fanfare and literally no documentation on why the hell anyone would use them. The truth be told, taxonomies would continue to be teets-on-a-bull until custom post types were rolled out several years later.

And then there was the ultimate bugaboo: the Settings API. I’m confident that the rollout of the Settings API was as quiet as it was because everybody knew it sucked. One day, it didn’t exist. Then all at once, there’s the documentation… documentation which was predictably incomplete and completely unintelligible.

Functions in the Settings API were misleading and confusing. Their function seemed to point the way to some other, here-to-fore unmentioned other requirements. Whatever those were, they weren’t the things developers needed. This was doubly frustrating because, having worked with CakePHP for a while, I had really hoped WP would adopt the universal form functions that CakePHP used. I still believe there are people making money off forms – contact and the like – that should always have been a core feature of WordPress, but I digress.

The point is: I’m a bit punchy about just adopting the new propaganda wholesale. WordPress’s rollout history is checkered, at best.

Right. But you were saying you were “on board?”

Yes, yes. Sorry.

Like I said, I know that the pressure to adopt the Customization API is due to get stronger as we go. So, it pays to stay ahead of the curve, to the extent that such a thing is possible. And with the latest update to 4.3, there seem to have been some major updates to the Customize layout that make a difference.

The biggest thing I have objected to in the past – beyond my gun-shyness about WP updates – was the fact that, with only one narrow column to work with, I just could not see a world where dozens of plugin- and theme-derived customization settings existed in an ever-increasing Scroll Bar of Doom.

The WordPress gurus have solved this problem by making each section a drill-down, giving each options section the full height of the window to operate on:


Well, that’s much better, isn’t it??

Right off the bat, I can begin to see my content and modifications fitting inside the Customizer. Well done!

But even better – and I cannot stress how happy this makes me – the Settings API has been completely subsumed and improved with the Customize API. In fact, it’s about as basic as my needs are: create a section (if you want), create a setting, create a control that handles that setting, then place the control in the section you want. Boom! No messy saves, no ambiguous functions, no labyrinthine inter-functional hubba-bubba. Just tell WordPress what you want to save and consider it done.

More to go…

As wonderful as the Customize API is, it’s not a stopping point. The documentation could probably stand a brush-up, but there are also somewhat ambiguous points to the code itself. Like for example, if I have a group of checkboxes, I clearly want to be able to associate them all with a single setting. Sure, I could go with “icon_font_fontawesome,” “icon_font_zocial” and so on, but this seems to be a great way to clutter up the database with very little upside. It also makes getting/setting these options a bit cumbersome, as I solved with this little doozie:

But to me, this could have been solved by allowing us to save arrays to the database, which at present, does not happen. Lots of other optional settings might require array saves, or a developer might just prefer to save a multitude of related, oft-coexisting settings in one setting array to save on extra database pulls. To the extent that WordPress is still willing to accomodate differing coding styles, this really aught to be an allowable process.

But there’s no question that, on the go-forward, I will be using the Customizer over individual settings pages all day.

Sooner rather than later, you’re going to get asked. No matter how you slice it, people are going to insist they need it. But… how do you go about grouping a list of posts by taxonomy?

I’ll give you an example, referred to in the title of this post: the menu. While menu items are normally listed by a specific menu or category – breakfast, lunch and dinner, for example – many menus require a further subdivision of menu items. Wine lists, for example, need to be broken down by red, white and blush or rose. Beer might get split up between domestic, imported and microbrew. So, if you use a custom taxonomy to organize your menus, you’ll need to be able to further subdivide in this manner.

With my current client, I do a lot of menu work. And yes, you could just list out each menu and submenu with their own loops. But that’s inefficient and just not in the character of a good developer. There has to be a way to make this easier. And there is.

The below code is based on code further derived from a blog post. But while that code worked for a limited set of options, I wanted something more abstracted that could apply to many different types of scenarios. Here it is:

You’ll notice, of course, that this example is highly-specific to menus at the moment. That’s at least in part because I couldn’t get WordPress to load a template part with the right variables. You’ll also note that the call to the second function looks like it’s OOP. That’s because it is. I write my WordPress theme functions.php file as OOP. But otherwise, this should be a very easily-compatible bit of code to fit your own particular needs. Enjoy!

I’m mostly just placing this snippet of code here because I don’t want to lose it. Regardless, if you’ve been searching for a way to filter your list of posts (or CPTs) by a custom taxonomy (like you can filter through posts with native Categories), then this is your solution. It began with a forum post, which while close, didn’t quite get the job done.

After a bit of tinkering, I know I’ll be using this filter quite a little bit. So, bon apetite. Please note that I use an object-based functions.php file, so this is a snippet directly from my object. Your mileage may vary.