This is a follow up to the Post Options API article we published earlier this week. Basically we’ve received some good feedback about the concept in general via Twitter, Facebook and the comments on our site, and today we’ve got some further questions for you.
We continue to work on the concept and as tempting as it might get to start using it, we ask you not to, for several reasons. First of course is security. We’ve planned a security review right before the release which we’ll announce. Secondly is that things may change, arguments may change and function names can change too, so until we freeze that, there really is no guarantee that it’ll remain the same.
Certainly, arguments and function names can be changed in the future as well, but in that case we’ll provide backwards compatibility and deprecate the old stuff piece by piece, just like WordPress itself does, so you’ll hopefully be on the safe side.
Anyhow, today we’re calling out for some more feedback and would love to hear your opinion, not about the concept in general, but on the details of some of it’s parts.
Sections as Meta Boxes vs. All in One
One of the biggest dilemmas that we’ve got here. In the post earlier we didn’t really think about it but getting to test the concept on larger-scale projects, we’re wondering if the post options sections we talked about earlier would be easier enough to manage if they were meta boxes of their own.
The pros of several meta boxes are obvious — you can drag them around, you can register them to the main area or to the sidebar and you can even hide them using the Screen Options panel. The pros of an “all-in-one” approach would be easier to manage, perhaps cleaner and better looking.
My personal feeling is that several meta boxes rock, for the same reason the standard “Categories” and “Post Tags” weren’t combined. And the “Featured Image” (where supported) is a meta box of it’s own. So what are your thoughts on this? Oh, the images above are just sketches.
Helpers vs. Custom Callbacks
We know that helpers (or helper functions) are sometimes useful, in this case they’re form fields constructors. But do we really need them? Andrew Nacin mentioned that the best API to create forms is HTML, so is there a reason to go the Django route?
Of course it would introduce simplicity and a lot of code reuse, unless it’s not flexible enough to meet everybody’s needs. So try to think of all possible form fields that could be used with the Options API, will the current existing fields (checkbox, radio group, select, textarea, input) be enough? Will they be used at all or would you rather create your own callbacks?
Plugin vs. Includable File
This is our third and final dilemma for today. The Post Options API concept currently ships as a plugin for WordPress. Ideally of course it could be implemented in the WordPress core itself, but until that happens (if it ever will) there are two ways we can use it — as a plugin or as an includable file.
The plugin variant certainly sounds cool since you’ll get automatic updates from the WordPress.org repository (at some point) and won’t have to worry about keeping your theme or plugin up to date. But what if your theme or plugin hasn’t been updated in a while and the API plugin has? That would certainly create problems.
Second variant is an includable file, and as the theme or plugin author you’ll have to manage updates yourself. While this ensures that your code works with the version of the API that you shipped with it, it can create name collision problems (perhaps another plugin is using the API as well with their own file) and others.
Anyhow, just wanted your opinion on which of the two methods would you prefer to use. Or perhaps there might be a third one?
Your Turn to Speak
Okay now it’s your turn to speak. We thank you all in advance for contributing to the project, thanks for following it on Github, we really appreciate that. Use the comments section below to share your thoughts. Alternatively you can give us a shout on Twitter or Facebook. Have a great day and thanks so much for reading!