Get it All

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.

if( statement ) {
// code block
} else {
// another code block

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.

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

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:

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

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.

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.

Without [Holistic Networking]’s expertise, The Rochesterian would not be where it is today. The blog was voted best in Rochester in its first year by readers of City Newspaper. [Holistic Networking] helped me with design, advertising, plugins and numerous other features that are important to a website. He did all of this work efficiently and skillfully.