WPlite-MU – Hide Menu Items in WPMU

I’ve recently begun doing more and more work with WPMU, and one of the hurdles I’ve most encountered is that of customizing the Admin menus. In the scenario I’m working in, clients are given the administrator role for their blog, however, in most scenarios, there are elements that they just don’t need to touch. D. Sader has an excellent Toggle Admin Menus plugin that will cover most of the default Admin pages, however due to some limitations in how the dashboard is tied to widgets, you can’t hide that page from users with that plugin. This is what set me off looking for such a plugin.

I discovered WPlite, which at first glance looked exactly what I wanted. However, due to different permissions issues with roles, it actually wouldn’t block anything for blog admins, which in my case I needed. It also didn’t allow to hide itself, which would have defeated the sole purpose of the plugin. So I did a quick change to hide the menu items from everyone except Site Admins, and allow the blocking of this plugins menu item as well.

As I point out in the Read Me file, this plugin does not physically prevent a user from accessing the page if they normally have permission, it simply hides it in the menu, so if you are using the at a glance widget and want to hide the widgets menu completely, you’ll need to customize this as well. For more stricter control, definitely rely on D. Sader’s plugin, but unsuspecting users not familiar with WP, they will be none the wiser, and you can hide some of the other menu items that might normally appear for blog admins, or others roles for that matter. Note, because I specifically was looking for a way to hide widgets, and didn’t see anything out of the box for Role Manager, I didn’t go that route. For my needs, the combination of this and the Toggle Admin Menu’s I’m completely satisfied with the solution.

Also, currently this plugin must be uploaded to wp-content/plugins, and activated. You can use the built in activate site wide, or use something like Plugin Commander if you are looking for even more control over plugins. Also, this currently requires a site by site configuration, as I wanted more granular control over which blog admins see what. I will eventually look into setting some defaults, possibly via an admin interface, that would be set each time the plugin is active. If anyone wants to help contribute to that effort, I’m all ears.

Any questions or feedback for the WPMU version should be directed towards this post, Muhammad clearly pointed out he doesn’t have time to address the WPMU version. I offered him the changes I had made if he wanted to release a WPMU version himself. That said, all credit for the plugin goes to him, and if you find yourself wanting to donate anything to the development of the plugin, you should seek out the original plugin and show him some love.

This is my first attempt at releasing any kind of WPMU plugin, so certainly, any feedback or suggestions are greatly welcome.

Download WPlite-MU.

Update So I stumbled upon another plugin similar to WPlite that gives even greater control over customization, which seems to work quite well with WPMU, as you can hide items from Admins and Site Admins are not affected. It still is a plugin that has to be configured on a site by site basis, but as I said, gives a far more granular control over many more elements. I will continue to work on WPlite-MU once I get the current project I’m working on finished, but wanted to share my discovery until then. You can check out the Adminimize plugin at WordPress – Extend. The author’s site is in German, but there are English instructions, and configuration is fairly straight forward for people familiar with WordPress.

WPMU 2.8.5.2 Ready to Roll

2.8.5 & 2.8.5.1 were released yesterday, unfortunately a bug crept in that prevented non site admins from publishing posts. However, Donncha quickly rectified the bug, and tagged the latest release version. 2.8.5 was dubbed a “hardening” release, and upgrading is recommended. Donncha outlines the details.

I’ll also be releasing soon a WPMU version of the WPlite plugin. WPlite allows you to hide admin menu items from non-admin users, the modified version will hide menu items from blog admins, but not site admins. It doesn’t lock down the page, the URL is still accessible, but for the unsuspecting user they’ll never know a setting is available to them. For potentially destructive pages for inexperienced users you can use the Toggle Admin Menus plugin to secure blog admins from doing something they would regret (like delete their blog).

Crowd Sourcing Plugin Compatibility

Mark Jaquith posted on the WordPress blog about a new feature on wordpress.org, plugin compatibility a couple of days ago. The idea behind it is simple, let the community give feedback on whether or not the latest version of a plugin works with the latest stable release of WordPress. Mark points out that the number one reason people don’t upgrade is because of plugin compatibility. Considered one of WordPress’s greatest assests, it also can be it’s greatest drawback. Sure, you can extend your site to do all kinds of amazing things, but what happens when that awesome plugin lingers without updates, while WordPress releases a couple times a year? Eventually, something is going to break.

Since WordPress has made the decision that security means staying up to date with the latest release, that becomes a greater issue as time goes by. Potentially, this data will give developers insight into what is breaking popular plugins, so they can either address that in the code, or (purely speculation on my part) adopt the plugin and bring it up to date.

My only concern with the data is that I think most people will tend to find plugins that are broken, and then report that, rather than think, “hey, I should go through my three hundred plugins and go report that they are working fine with the latest release.” The article does mention that eventually they’d like users to be able to report directly from the plugin page, but then that opens the whole “phone home” can of worms.

From a site developer stand point, I think the whole thing should drive home the point of trying to use the core tools as much as possible, and not relying on as many plugins to develop a site. Certainly there are ones you can’t get away from for certain projects, but often times, people will employ a plugin for convenience, which will later bite them on the behind when that plugin breaks an upgrade.

Relocation of WordPress Subversion Repository

While on the subject of upgrading, one of the best tips I could offer to someone is to install WordPress via Subversion. I think most people think of using Subversion with trunk, or the “bleeding edge”. Which can be the case, however, it’s just as easy to use a tag. Previously, to check out any version of WordPress via SVN the repository URL was http://svn.automattic.com/wordpress. This always rubbed me the wrong way, as I, like a lot of people, always cringed at the blurring of the line between .org and .com WP entities. Having an automattic URL certainly blurred that line.

However, I noticed today that you can checkout from the .org URL now, specifically, http://core.svn.wordpress.org. If you have been using SVN, and want to change repos, but aren’t familiar with that command, it’s actually quite simple.

Let’s say for example you last checked out the 2.8.3 tag, and want to both switch repos and update. First you need to switch your repository

svn switch --relocate http://svn.automattic.com/wordpress/tags/2.8.3 http://core.svn.wordpress.org/tags/2.8.3, then you simply need to switch to the latest tag, svn switch http://core.svn.wordpress.org/tags/2.8.4

If anyone would like more information on how to do the initial checkout, including switching from a traditional installation to using SVN, please leave a comment and I’ll put together a post.

WordPress Security

As I’ve ventured back into doing a lot of WordPress development these days, and will be taking on a housekeeper type role for a company that manages hundreds of WP sites, I figure as I begin to more closely follow WP development, I figured it would be a good time to resurrect this site.

On that note, I found that there’s been quite a bit of buzz this weekend about some new found exploits in out of date installations. One in particular it seems manages to create a hidden admin account. Hidden in the sense that when you look at your list of users, you won’t actually see the account. From what I’ve read, part of the genuine pain that this exploit causes users is that even after updating to the latest version, the exploited account will still exist and potentially still wreak havoc.

If you haven’t caught the link from the dashboard (or if like a lot of people, you change/disable the planet feed), Dougal Campbell has provided a SQL query to check for all users who have administer privileges.

As I follow up on these exploits, I may post more information, but in the meantime, if you aren’t running the latest version, I highly recommend taking the time to dust off your backup notes and tackle the sometimes easy, sometimes PITA task of upgrading your site(s).

WordPress 2.6.5 in detail

westi on wordpress

WordPress 2.6.5 has been released, addressing a few small bugs, and a few fringe security issues it seems. At first glance, I thought this was an odd thing, considering 2.7 is around the corner, but after a little thought, it makes sense. One, a security issue was found and fixed, and two, some people (this author for one) dislikes immediately upgrading to the latest and greatest release, so having a secure (as possible) 2.6.x release with a few nagging bugs taken out allows for sites to wait, test out, and take their time to upgrade to the 2.7 release.

WordPress 2.7 b2 Now out

WordPress › Blog.

A slew of fixes since b1 are in this release, perhaps too many, suggesting to me that it went beta too quickly, though I’ve never quite grasped beta/alpha/release candidate structures. Every project seems to have their own ideas.

I’ve not tested 2.7 myself, but the comments on twitter and via a few feeds have been positive, what are your impressions?

Interesting…

While reading up on the upcoming changes in WP 2.7,I came across an article aboutThe New 2.7 Dashboard. Tucked towards the bottom was this little ditty:

rather than including something rushed and clunky, we’re holding off until a later version

They were speaking of some “inbox” feature that was temporarily in trunk, but has been removed. I must say, that’s one of the first times I’ve seen that acknowledgment in WordPress development, and more often than naught, it has been the contrary. New features have been thrown in at the last minute, and result in confusion by users, too many bugs to count, and dissatisfaction by long time users. It’s nice to see the prudent approach being taken for a change, particularly in a release that seems to already have quite a bit of change included.

Think You’ve Got the Coolest Blog?

WP Freedom Blog is sponsoring a contest to find the “coolest blogs”. First prize includes $500 cash (via paypal) and $500 in services. 2nd place half that, and 3rd $250 total cash and prizes.

Winners will be selected by voting, after a selection by the host blog of the eligible entrants. To get rules and specifics visit the hosting site, or go visit one of the cooler blogs I subscribe to , Deziner Folio.

WordPress 2.6.3

A vulnerability in the Snoopy library was announced today. WordPress uses Snoopy to fetch the feeds shown in the Dashboard. Although this seems to be a low risk vulnerability for WordPress users, we wanted to get an update out immediately.

WordPress › Blog » WordPress 2.6.3.

Not sure what “low risk” really means, but I never recommend skipping security releases. The official post goes on to provide the affected file, so a full upgrade isn’t necessary, which is nice. Not sure I’ve seen that done in a long time. Guess it’s a case of 2.7 being close, and no desire to roll any other bug fixes in with this release. And because of that, it would seem that doing this upgrade is a no brainer.