Generally speaking, I’ve no desire to get into the back and forth that’s happening right now (and that has been happening) regarding WordPress Menus and the Customizer, so I realize in writing this post that I need to tread carefully.

To be clear, I’ve no interest in stating my opinion one way or the other on the upcoming changes in WordPress 4.3, not because I’ve anything to hide or anything to share, but because I don’t think it’s productive. There are other aspects of all of this that I’d rather discuss.

Additionally, many of the people who read this blog are likely already familiar with it, though if you’re not there’s plenty of thoughtful reading on the Make blogs, on blogs from others like Chris Lema, and on blogs like WP Tavern.

Make WordPress

And for the record, don’t read into the specific links that I’ve shared – these are purely meant to bring some of you up to speed on the issue, they don’t necessarily reflect (or deflect, for that matter) my own personal opinions on the matter.

So this raises the question:

Why bother writing about this at all?

Just because I may not be taking a stance about the upcoming changes to the next version of WordPress doesn’t mean that there aren’t other things that can’t be discussed rather than “Yes, this should happen” or “No, this shouldn’t happen.”

Not everything has to be some polarizing issue that divides an audience. Sometimes, there are considerations and other points to be made that sit more on neutral ground than anything else, that gets lost in the heated debate on a hot topic, and that’s what I’d like to discuss.

WordPress Menus, The Customizer, and Change

First, some background: When The Customizer (previously known as The Theme Customizer) was released, I really liked the feature. The API was easy to understand, it helped us build themes that really focused more on defining few options, and it gave the user instant feedback on how their site would look given the changes.

A Guide to the WordPress Theme Customizer

Sure, some developers and companys abused it, but anytime you have any type of software that can be extended via an API, this is going to happen. It’s nothing new (and just because you are experiencing it the first time in decades worth of software doesn’t mean this is the first generation to do so, but I digress).

Ultimately, I really liked the direction in which it was heading.

In future versions, more was added to The Theme Customizer, the word ‘Theme’ was dropped, and additional features were added such that we could now, for example, manage Widgets from within the Customizer, as well.

Depending on how you view the theme experience, this may or may not align with your conceptual model of how what The Customizer should be. To some degree, I think this may be the problem that some people have with changes that are coming but, again, that’s neither here nor there given this context.

Developing for the Customizer

Instead, the ultimate point I want to make is that although I understand the pushback that has been so fervently voiced, echoed, blogged, shared, tweeted, and so on regarding these changes, they are still happening.

Should the changes happen based on this feedback? If I opt to answer this question, then I end up diverging from the main point of this post, so I’m not going there. (“It’s a trap!”)

Instead, amidst all of the happiness, rage, and even some of the FUD that exists around all of these changes that are happening for WordPress 4.3, I’d like to remind developers that we do have options beyond simply accepting something that we may (or may not) like.

1. There Are Existing APIs

One thing about WordPress that cannot be said is that we have a shortage of APIs. That’s one of the things that attracted me to the software to begin with – it’s easy to achieve so many things through the use of the various APIs that it exposes.

Sure, we normally think of these in terms of how it allows us to query the database, manage data, and introduce our own new features for our users, but it also allows us to maintain other features that may not be as prominent or that may be introduced in future versions of the software that we dislike.

Remember not to discount changes that you disagree with as something permanent that can’t be removed, change, affects, or modified. There are APIs that help to manage this.

Then again, sometimes there aren’t, right?

2. Software is Malleable

And that brings me to the next point: Although software may not have an API for everything, it’s still malleable.

It’s not like hardware where it’s a challenge to open up the device with which we’re working, solder some components together to get it to do what the previous version of our device did, swap out a couple of boards, cram it all back into a case, and then hope to get back the functionality that we loved, but lost.

No way.

Not only to we have the source code, we have the ability to modify it through plugins, extensions, and other modules. That’s honestly a really, really cool aspect of what we do for a living, isn’t it?

Dislike something? Sure, we can vote with our comments, our tweets, our emails, and so on. But, in the end, if something is introduced that we dislike, we just do something about it by writing code.

In what other industry is it possible to re-introduce or customize the very thing with which we’re working?

3. Change is Inevitable

The last thing I want to sound like is that we simply roll over and accept whatever changes come down the pipeline.

Philosophically, I don’t think open source software should be that way, but the fact of the matter is that there are people who end up making calls on what makes it into core (be it WordPress, Linux, or whatever your favorite open source software is) and what doesn’t.

Does this mean that we just stop discussing changes that are being introduced and accept it without weighing all sides of an argument? Of course not.

Nothing that operates under a form of democratization should operate that way. And I know – I’ve not been living under a rock – people have their reasons as to why they feel WordPress isn’t operating that way right now. That’s a completely different topic, though.

Instead, remember that for every change that’s introduced into the software that you use, and for every customer that’s going to be affected by said change (and I absolutely understand this point), there are opportunities for us to restore functionality with which they’re familiar and with which they’re comfortable so that they can continue on with their work.

We have previous versions of source code, we have plugins, and we have the skill to maintain backwards compatibility with software. Conversely, we also have the ability to train them on new ways of doing the same thing, as well.

Not The First, Not The Last

Again, to be clear, this is not me taking a stance either way on this issue. That’s not the purpose of this post nor do I know if it matters if I post about it or not – honestly, I fail to see a case for why my opinion matters on it in a public forum.

Plenty of people are being vocal about this on one side of the argument or the other. I think having civil discussion around these types of things is great! Unfortunately, there’s also been a lot of sarcasm and vitriol within the community about it.


Anyway, remember that software is exactly that – it’s code that can be changed. So although changes are going to be introduced that we love and that we hate, we have the opportunity to adapt the software to our own needs through the use of various API or raw code.

And, above all else, I think that’s something that we – as developers – should remember.


Join the conversation! 4 Comments

  1. Tom:

    As usual, I love the way you expressed your idea-du-jour. The customizer IS a problem as well as a great idea, and when I wrote just a bit about it a few weeks ago (, this was exactly what I had in mind.

    I’m glad you’ve used your pulpit to talk about this, and especially so that the idea seems to be “MAN, I’m not even sure what to say at this point”, because that’s the type of dichotomy the Customizer has become.

    And yup, with so many API’s becoming germane to the conversation it might be the largest single issue determining the continued growth/success of the entire WordPress platform.

    Thanks, sir.

    • As usual, I love the way you expressed your idea-du-jour.

      Thank you, sir!

      The customizer IS a problem as well as a great idea, and when I wrote just a bit about it a few weeks ago 

      I read your post and based on what you shared in the post – or how you vocalized it – I think we may have different opinions. 

      In short, I’m a big fan of The Customizer and I like what it offers as far as instant user feedback. I also think that it does a good job at forcing thoughtful designers and developers to think through the options they’re exposing as far as the presentation of data (that is, their theme) is concerned. 

      In your post, you mention:

      But the WordPress Theme Customizer isn’t much of an example of making WordPress easy if you need to understand what’s behind varied menus and tabs as you move from one theme to another. And it gets worse: many of the options for controlling each of these themes hides a different control panel

      For what it’s worth, I think it does make things easier as it saves a number of steps that users used to have to go through from toggling back and forth between the dashboard and the front-end.

      But even in this discussion, there’s obviously a difference of perspective (which is fine!)

      For me personally, the gist of the post isn’t so much about that menus are moving to The Customizer (that’s another discussion for another time for me), but much of how the discussion around the introduction of the feature has been handled.

      As a community as a whole, it’s a bummer – at least as far as I’m concerned.

      • Tom, we may approach it differently and see the problem from different perspectives, but I don’t think we disagree; your last line “for the community as a whole … bummer” is what really matters.

        To clarify my side, my issue with Customizer is its inconsistency (and) that if its purpose is to create consistency the fact that is doesn’t (largely? somewhat?) invalidates its real usefulness. So forcing in on the community under those conditions is just a mistake.

        It happens that later yesterday the folks at released a tool that might be a real game changer and takes a different approach. If you haven’t looked at Themify Flow yet (, you might like to.

        I’m not a fan of page builders, really, and I have issues with the way WP sites based on the Themify Builder store data. Get past those two things, though, and this tool makes it possible to tweak EVERY element of theme design/appearance, all from one interface (i.e., “consistency delivered”). It’s pretty incredible.

        Is Flow the right choice for users? Err … probably not. But from a high-level perspective it addresses my issue with Customizer. 

        I think that if the folks on the WP team working on Customizer’s development took “make everything always act the same and be reached the same way” on as their mantra they can do great things. And that’s all I’m concerned with.


  2. Ooo boy.

    This is really a non-deal deal in as far as my head goes.

    I think one of the problems in the WP community of developers and perhaps users is the “Dont fix it if its not broken”. I can understand that.

    What developer want to go back to a code base they already have completed and tuned (or not!) and have to flip it all around to make it sit within new defined boundaries? Sometimes having to do a hack or completely restructure code so it doesnt result in unmanageable soup.

    The answer is no developer enjoys doing that. But, as developers expect it. Not only might it happen, it will happen. I’ve been through this on Windoze many a time. Heck, even Javascript, jQuery, CSS. Heck, if that stuff all came into being with the first website I’d ever made I’d been flippin’. I’d have 1/3rd less hair than I have today being fashionably sorta balding. LOL.

    Most here dont know of the battles over The Windows Presentation Foundation that went down. Was pretty big.

    Users like things to work, “Dont fix it if it isnt broken”. Thats a bad analogy (<- Notice the first four letters, also applicable). That mindset would mean I should be sitting at a DOS command line, completely bald, with as many command line commands as Unix. Some love command lines. Then again, some people throw away banana’s and eat just the skin. “It’s healthier”. Indeed. But I am not a insect.

    In software Tom is right. Change is inevitable. You can be sure if change does not occur than a product will 99% of the time fall due to its competition who is changing.

    Some change we like, some change we dont. But if one actually looks at it from a different perspective of embracing change often, not always, but more often than not opportunity also is there.

    I have not done a GREAT deal with customiser. In fact, when I first messed with it I was unimpressed. I looked at the source code and its good code IMHO.

    I support the usage of customiser across the entire platform as a common user interface is user centric. Windows is user centric. Mac is user centric. Linux is… hmmm… often eccentric. :)

    I do think the “name” is wrong. Customiser sounds very Hot Wheels 1975.

    Personal opinion is the entire back end user interface of WP should be replaced and thats doable with Customiser. Make it either Windows or Mac like UI. That instantly brings it into a application area that those with little to no web expertise can get started quick.

    Help system, already spoke to that in another post.

    In order for WP to move into the future a consistent UI is important. Thats wrong. Its not important. Its imperative.

Leave a Reply