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.
Post Options API Metaboxes
Post Options API All in One
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!
multiple sections sounds really cool to me.
helper functions to create the HTML also sounds good, anything that can improve productivity…
as for plugin vs included file, I’d say give both options. That’s what they’ve done with the Optiontree plugin at themeforest I think.
And it would be nice to include similar functionality to this Repeater Field plugin http://plugins.elliotcondon.com/shop/
Hi Paul, thanks so much for your input. Providing both options sounds great, although some extra maintenance for us ;) The Repeater Field looks brilliant, definitely something to consider, thanks for the heads up!
This is a fantastic example. If you build something like this would you mind if we incorporated it into our upcoming wordpress marketing framework? Right now we are just finishing a plugin, but our goal is to launch a framework upon which themes can be built.
This is a gorgeous concept.
PS Repeater Field does look brilliant!
Howdy, inbound marketeer :)
Go ahead and grab it from Github, it’s open source after all, just fork it and play around width it however you like. You can’t keep me responsible though if things start breaking in your plugin and future theme framework :) Good luck and thanks for your comment. Next time try using a real name ;)
<– guilty
Maybe we could send you a preview of the plugin in a couple weeks before we launch the kickstarter project for the framework. Our goal is to use the plugin as a GPL giveaway for donations to the framework.
Should be a monumental effort, but I think sites like themeforest could greatly benefit from having a framework that standardizes layout, structure, widgets, and backend features. From there – making the switch from one theme to another becomes a matter of just skinning it differently.
If our analysis is correct our approach could make childthemes fully copyrightable because they become just CSS & images – the core code all lies in the parent theme.
It will be interesting to see how the project evolves.
Hey Chris, sure thing! We’d love to know what you’re up to! Feel free to send it our way whenever you’ve something to show off :)
I agree with Paul:
Multiple sections is a good idea (although not that big of a deal if it’s all in one section similar to the themeforest’s options tree).
I also like the idea of having both options, as most of the time I’d like to include it with the theme I’m building. Actually if I had to pick one or the other that’s the way I’d go, as an includable file instead of a plugin.
Paul – have you used the repeater plugin of Elliot’s? Is it any good?
Thanks for the input Aaron, it’s so valuable. We’ll just have to figure out the neat and clean way to distribute and update. Enjoy your day!
Great questions. I have played with the plugin, but I didn’t think of that.
While I prefer an all in one solution for my projects, I guess by separating things you would make sure the API answers everybody’s needs. It is OK to have too many boxes, but it is not OK to have 2 completely different features in the same box.
As per your third question: I faced the same dilemma with one of my plugins, and I chose to go for the included file: users hold you responsible for your plugin, so it should work at all times, even when they don’t do their updates regularly.
Just my personal opinion of course.
Hey Jeremy, your feedback makes perfect sense, thank you so much!
Hi Konstantin
Thanks for sharing your work, here is my 2 cents.
1. Sections would work best ideally there would be more then so you can choose where the created fields go.
2. I prefer helpers but it would be nice to have both.
3. I would prefeer a plugin and you could tell people to install it in the mu-folder so it becomes part of WordPress. This way if you use a 2 plugins use it. then you already have it enabled. And the latest version of the files would be included.
Hi Enej, your feedback is very valuable, especially the multi-blog part. Thank you!
I’m working on building a script that puts a bunch of taxonomies in a madlib style format. As of right now that script would sit inside of a post meta box. I really like the post options idea though… It would be awesome if there were some hooks where a developer could extend the box and insert other content. The goal being ease-of-use to the end-user.
I can understand the argument for making it both a plugin and a drop-in function. I would go with the plugin option because a developer can always remove the plugin header and drop the script in a theme’s functions file.
Thanks for your input Matt. I like the idea of hooks to extend the sections to really take advantage of the HTML inside it. Cheers!
What’s your time frame for deciding on the final feature set? I’m really excited to dig into your code. :)
We haven’t set any strict timelines or deadlines for this yet, but my thinking is that we’ll roll out another update before August 12th and then finalize on the features and helpers, prepare for production use, etc until the end of the month.
Glad to see you’re excited and if you’ve anything to add feel free to create a pull request on Github ;)
What happens if i want to have Post Options on certain category posts to be visible and not everywhere?
That is a good idea!
And does it support custom options, into Custom Post Types’?
Great work, already watching it @ GitHub!
Basilakis, thanks for your comment and support. Your question is fair enough but tricky. My guess is that with a little bit of javascript or jQuery magic you can show and hide certain fields when the user checks or unchecks different categories but then again, what if they rename that category? Or delete it and add another one instead? This is more of a CMS approach.
As to custom post types, definitely. This is one thing we kept in our heads from day 0 and is currently implemented when adding sections to post types.
Cheers and thanks again!