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:
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.