Get it All
Together

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!!

Logic is binary. Statements can either be evaluated as true, or as false. There are no “maybe’s” in logic. As such, one could be forgiven if they thought 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 developers figure out sooner or later that nothing could be further from the truth. Nothing about the duality of logic creates a truly binary system. In fact, the word “false” encompasses a world of bad options much larger than the word “true.” And counter to our natural sense of the world, that multiplicity makes “false” a weaker rather than stronger concept.

Decision making code epitomizes this idea. This most basic logical decision maker, the “if/else” evaluation, 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 another block of code. If the statement evaluates false, we execute a block of code after the “else” keyword.

[php]
if( statement ) {
// code block
} else {
// another code block
}
[/php]

This is among the most basic of code concepts. And as they begin writing scripts that do simple things, most students end up using this structure to create code that is more-or-less balanced, if versus else. Values for which there are only two desired values get used to make assumptions about how the code should continue on.

[php]
if( $person is "female" ) {
// things that concern women
} else {
// things that concern men
}
[/php]

But wait. Is sexual identification really binary? No, of course it is not. And therefore, while the code contained in the “if” block can be entirely “true” and the code block it reveals confidently executed with that knowledge – a person could identify as “female” – any one of a number of other possibilities would all evaluate to “false” – they may not be female, but they don’t identify as male, either – making code contained within this second block highly suspect.

Ok, setting aside the hot-button social issues, let’s consider a real-world example of actual code for why this duality is not a reliable way to execute code. Consider an application you might build to respond to web requests for data. You’re providing a listing of calendar events to an entire city’s-worth of bloggers through a web API. When they want to know which acts are playing locally, they’re going to request that list from you, giving you their location and list of acts they want to know about.

But wait. Are they sending that list? They’re supposed to, but you can’t be certain that the information they send to you is correct, or even that it exists at all. In this context consider this code:

[php]
if( username identified in system ) {
// Do things for an identified user
} else {
echo "Oops! Looks like you aren’t logged in!"
}
[/php]

If the user passes a username over and if that username is found in the system, we can execute code that would be acceptable for registered users. But can we make a similar assumption for every other alternative to an identified user? There could have been an error transferring data. The user might not have included the username. They might have passed values in the wrong order, so an email address gets passed where the username should be. They could have passed an integer value when you needed a string of characters; they may have passed a CSV-formatted value where you expected JSON.

Returning a user the generic, non-specific message above when an entirely other problem exists is confusing. And inasmuch as your job as a developer isn’t to code someone else’s software, it also isn’t your job to make their job harder by sending them on a wild goose chase.

Be the If, never the Else

“If” blocks represents certainty. “Else” is simply the catch-all condition for everything you don’t know and can’t control. That’s not to say we don’t need Else: while If evaluates true for a single condition, the possibilities for what a user might pass an application are infinite from the perspective of the code.

But what happens in your Else ought to be brief and informational. Respond to user requests with detailed errors. Commit error details to an error log. Redirect a user to an earlier part of the code, and then be done. Else is an offramp to safety, not a continuation of a Twist-a-Plot book.

foundation6-logo

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.

 

aboutus1

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:

customize-bar

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.

HolisticNetworking is looking to hire a part-time, outsourced sales partner to sell our line of WordPress website and custom hosting solutions. This position could lead to a full-time position down the line, but for now, we just need to book 2-3 new clients a month.

The right candidate will be able to speak intelligently to our perspective clients about:

  • Why WordPress is the preferred platform for small businesses.
  • Why Responsive Web Design is the cost-effective choice for web design.
  • Why a managed website is preferable to go-it-alone web sites.

Familiarity with web design and development technologies, social media management and search engine optimization – at least conversationally – is a huge bonus. HN properties come with a suite of important technologies, and conveying the benefit of those products to low tech people is the biggest challenge.

Compensation is a healthy commission from sales. Sales could technically be pretty brisk – I can generally complete a theme in 8-12 hours – but because I’m currently working for a client taking up 30-40hrs a week, I have to keep the list of active clients to a minimum, hence I need a part time salesman.

Send me a love note if you’re interested in getting a good relationship started. I’m looking forward to meeting you!

Part Time Sales Partner

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 WordPress.org 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 WordPress.org 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.