WordPress Menus and The Customizer

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.

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.

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.

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.

Uncool.

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.