On large WordPress MS installations where site admins are allowed to manage their own plugins, the list of plugins tends to get crowded over time. Sometimes you introduce a plugin to the network and admins start using it, but some time down the road – a year or two later, even – you decide that you want to deprecate that plugin (maybe to replace it with another one, etc). However, migrating users of one plugin to another plugin is a logistical and technical tangle, and sometimes the best medium-term strategy is to allow existing users of the plugin to keep using it, but to prevent admins from activating it in the future.
Here’s how we’re doing it on the CUNY Academic Commons. In the gist below,
$disabled_plugins are the plugins that we don’t want people to activate in the future. In most cases, however, we do want people to be able to deactivate the plugins, so by default, we don’t filter plugins if they’re active. However, we also have an array of
$undeactivatable_plugins, which cannot be activated or deactivated.
Props to dev team member Dominic Giglio for writing part of this.
I’ve just released version 1.3 of BuddyPress Docs, my WordPress plugin that powers collaborative document editing on a BuddyPress site. The main feature of Docs 1.3 is theme compatibility, which means that top-level Docs templates (archives, single docs, and the Create screen) are no longer necessarily top-level. Using the theme compat feature of BuddyPress 1.7 (currently in beta), this top-level content is put directly into the content area of your theme’s
page.php template, ensuring that Docs pages will keep your header, footer, sidebar, and other global elements.
The theme compatibility feature only kicks in if you’re running BP 1.7. Existing installations of Docs on BP < 1.7 will continue to work as before.
Are you a BP Docs user? Are you already testing BuddyPress 1.7? I'd be glad to get your feedback on Docs 1.3. Report any problems on the issue tracker.
wp_nav_menu() fetches a custom menu, as built using the Menus GUI, for display in a theme. I had a project where I needed to add some items to this menu dynamically – the links would be different for each user, and wouldn’t appear for logged-out users, so they couldn’t really be added using the GUI. After a bit of futzing, I was able to insert my menu items, tricking WP into thinking that they were native.
Details: For logged-in users, I needed to add three subnav items underneath the top-level ‘Activity’ item, if it was present. So at the beginning of the function, you’ll see that I’m doing some BuddyPress-specific stuff, to find the Activity menu. If you need to use a
menu_item_parent like I did, you’ll have to supply your own method for finding it (or just hardcode it). The heavy lifting is done in the second foreach loop, where I build
stdClass objects just robust enough that WordPress will interpret them as true nav menu items.