Thanks for your kind words.
You are correct that the plugin contains code that removes unneeded meta boxes. This is done for 2 reasons:
1) To remove clutter and avoid confusion. Eg. if you selected an expiration date with the plugin you mentioned, it would most likely not work because of the way sidebars are conditionally fetched from the database.
2 To avoid plugins adding incompatible scripts. I think over 90% of issues I get on the support forums are caused by other plugins unfortunately.
However, this exact feature is planned to be included in the next version, so stay tuned 🙂
Thanks for your input. I’ve used a metabox whitelist function in my own plugins before as well. I get it. I think in your case though, you’re limiting your users ability to extend a Custom Post Type. Would you entertain adding a filter to your whitelist function to allow developers to enable metaboxes from other plugins as well? That would be a good consideration as well… or maybe that’s already there. If so, can you point me in the right direction?
Thanks!
I completely agree about whitelisting limits extensibility. However, because many plugins add meta boxes to all post types (using the default post type screens), the features aren’t specifically for Sidebars and often won’t work – and even break the JavaScript.
I am currently rewriting the admin screens from scratch, going away from the default post type screens, so in the future whitelisting will not be needed and it will be much easier for developers to add extra features specifically for Sidebars.
For now, you should look in /admin/sidebar-edit.php and comment out the in_admin_header action with the meta_box_whitelist callback. You might also want to look at the $script_whitelist variable in app.php.
Thanks for the direction on where to look for the whitelist.
It’s definitely your perogative, but personally I see a lot of benefit in keeping these sidebars as CPTs and just providing docs to developers to filter the whitelist for their purposes. Extending the sidebar features via other plugins is really easy that way… but making the sidebars NOT a CPT any longer sounds like a lot more work for extensibility, plus, how will you handle backward compatibility?
I’m a plugin author as well, so I’m just talking out loud a bit. Your plugin, your business for sure. I appreciate what you’re doing and thanks for humoring me!
Version 3.4 includes scheduled deactivation of sidebars.
It still uses a custom post type, but the admin screen have been completely rewritten, and it’s now possible for developers to add tabs/sections and meta boxes to the sidebar edit screen 🙂
