Learning the World

I recently had to update a Google Mini to use a new stylesheet (built using XSLT) to reflect the college’s new web design. We have two front ends using the same stylesheet, and I applied it to both … but only one displayed it. The other was stuck with the older style sheet and no matter what I tried, it refused to display the new one.  Naturally my thoughts turned to some sort of caching issue, which led me to this Google Troubleshooting page:

• Troubleshooting Search Appliance Problems

There I found the solution to my problem: the proxy reload.  Essentially, by adding the text “&proxyreload=1″ to the end of a Google Mini query string, you can force it to dump its stylesheet cache and reload the XSLT stylesheet. Once I did this, the problem was fixed.

Since the upgrade to WordPress 3.0 things have been running fairly smoothly, but I been seeing sporadic problems with some themes no longer displaying theme options for web site administrators. The three themes in question are Mandigo, Tarski and Viala and in all cases, the superadmins for the WordPress network are able to access these theme options. That’s why this problem never showed up in our testing; we were logged in as network admins.

After doing some digging, I found the problem: a misunderstanding of the “edit_themes” capability.

Based on this discussion thread it seems that the “edit_themes” capability was intended to be given to site administrators who could actually edit the theme itself via WordPress not to grant them access to theme options. I haven’t been using WordPress long enough to know if this capability has morphed over time, or if it was always like this, but in either case it’s creating headaches now.

In a single site WordPress install using the “edit_themes” capability to control theme options access works just fine, because they’re one in the same: the “site administrator” is also the same person who could edit the CSS or HTML of the template in question via the WordPress interface.

In WordPress 3.0 MultiSite however, that won’t work. You can’t let individual site administrators edit the theme files because their changes would affect everything in the network. As a result, site administrators no longer have the “edit_themes” capability; only network superadmins can do that. However themes like Mandigo, Tarski and Viala all depend on the “edit_themes” capability to display their theme options, and since site admins no longer have it, they can’t get to their site options anymore.

I’m assuming this capability change happened as part of the code merge with WP 3.0 and WP 3.0 MU, since the theme options were still accessible under 2.9.

Based on Andrea_R’s response to the thread, the fix is to change the logic so that it uses the “manage_options” capability (which site admins have) instead of “edit_themes”.  Andrew Nacin, responding to my post on the wp-edu list, suggested using edit_theme_options instead. The “edit_theme_options” capability is assigned to administrators, but it offers a bit more granularity because you can assign it without giving someone acceses “manage_options”, which would allow the user to switch the site’s theme.

“edit_theme_options” seems like a better, more specific fit to me, so it’s the one I’m using.

It looks like NextGen Gallery isn’t quite ready for prime time with WordPress 3.0 in MultiSite mode. Blog Directory Path, which is a network-wide option set under the super admin menu, is no longer being respected at the per site level. This gives rise to the following error:

“Directory wp-content/gallery/ didn’t exist. Please create first the main gallery folder !”

If you manually set the site’s directory path using the site’s ID (available from the main site directory list in the super admin view), then things work properly, but the default setting is now incorrect.

The plugin author is aware of the problem, and is working on this and other MultiSite-specific  issues for the next release.

I’m researching Google’s auto-gen sitemap — the list of links that accompanies some (usually high-traffic) web sites in Google’s search results. Here’s what the CNN version looks like:

Now I know that you can specify what these links are by creating a Google SiteMap for the search engine to crawl, but what I’m curious about is the logic that Google uses to create the list on its own.  Based on conversations with folks at work who were looking into this, it looks like Google has its own system for guessing the importance of these links based on site structure and (I’m guessing) PageRank but I’d love to have a better answer (or a better guess).

So for no apparent reason, several WordPress blogs running under WordPress MU suddenly lost their header images, reverting to the default image.  These images were added to a custom theme using the Custom Header API (check out WPMU Tutorials on Custom Headers). Everything was working fine, and then suddenly some of the sites spontaneously reverted to the default.

Obviously, there’s got to be some sort of trigger lurking out there, but thus far I haven’t found it. The site was upgraded two weeks before The Great Forgetting; it was related to the upgrade, then it must be triggered by something that people don’t do frequently. There are reports of this happening (here and here) on WordPress.com, but their answer is “contact support”.

I’m still beating on a test instance to see if I can replicate it, but if anyone comes across the answer, please let me know.

I’ve been using Twitter for years, and almost since I created my first account I’ve debated the need for splitting it in two: once for my work related tweets, and one for everything else.

It’s was a difficult question, because you can’t easily divide my life into “work” and “non-work” related tweets. The apps I work with every day — Drupal, WordPress MU, iTune, etc. — also happen to power the stuff I use at home.

This is because my friends, both online and off, then to be intensely creative and productive people. They’re podcasters and writers, gamers and hobbyists, and they use all the self-same tools as at my day job. Cross-pollination between the two has been essential to my use of Twitter, and for that reason I’ve been hesitant to spin off a separate account.

And yet … when I go to conferences for work, I find a lot of people using some iteration of their real-world name for twitter … where as I use my gamer handle, @nukehavoc. Now that handle’s fine when I’m at Origins, GenCon, Balticon or some other big geek convention … but it feels a little less professional when I’m at a work conference.

There’s also the fact that while I’m sure some folks enjoy keeping up with my geekier side, I think there’s also some that would rather not have to read through my Star Wars tweets to get to my WordPress MU ones.

So to that end, I’ve created a new account on Twitter for my work and webapp related posts: @knewquist. I still have my @nukehavoc account, but that one’s full-on geeky — it has all my posts about web development, geek parenting, gaming, etc. You can expect some cross-posting between the two, especially when it comes to web development and online technologies, because as I said earlier, the cross-pollination between my different audiences is what makes Twitter work for me.

I’ll freely admit this is an experiment, and I don’t know how well it work out. I’m going to maintain the account for six months; if at the end of that time it proves to be more trouble than it’s worth, I’ll disable it.

I’ve run into a workflow snag with WordPress MU (well, technically the issue is in WordPress; MU just inherits it): authors can’t add or edit pages.

The problem is basically this:

• I have an academic division web site with an administrator or two.
• I have a handful of editors representing the department heads within that division.
• I have authors who need to be able to add and edit (but not publish) pages.

It’s the last part that WordPress doesn’t support. Ideally, I’d love for the “author” role to function like the “contributor” role does for posts, e.g.: a contributor can write and edit their own posts, but they can’t publish anything.  I’d like the author to do the same thing for pages, allowing a second-tier workflow within the site.

Unfortunately WordPress MU doesn’t work this way out of the box, and based on the comments I’ve read online, it seems that WordPress core isn’t interested in changing this functionality because it differs from WordPress traditional blog mindset. Which I understand, but don’t agree with — I think WordPress has grown into a respectable, lightweight content management system, and adding this additional granularity of editorial control would complete that transition.

So the question is: How to do we manage this? One option is to split up a larger site into sub sites; e.g. instead a single division site, you end up with sub sites for each department.

The other option is to go with a third party module. There are two that look good, particularly when used in conjunction with one another:

• Role Scoper: “Assign restrictions and roles to specific pages, posts or categories.”
• Capability Manager: “…provides a simple way to manage role capabilities. Using it, you will be able to change the capabilities of any role, add new roles, copy existing roles into new ones, and add new capabilities to existing roles.”

They look promising, but I haven’t tested either with WordPress MU yet. I’m curious to know how other folks are addressing this problem; if you have any suggestions or experiences to share, please leave a comment!

WordPress MU 2.8.4a refuses to upload .ppsx (PowerPoint Show files for PowerPoint 2007/2008) because the extension hasn’t been defined in the functions “wp_check_filetype” and “wp_ext2type” in /wp-content/functions.php

Not having ppsx defined here causes WordPress? MU to throw the warning “File type does not meet security guidelines. Try another.” when uploading the file (even when the ppsx file type itself is blessed in WPMU’s admin options).

I’ve reported the bug to WordPress MU Track here:

• #1118: PPSX not defined as valid file in functions.php

Update

The fix isn’t quite so straightforward as just adding .ppsx to the list of valid PowerPoint extensions, because technically PowerPoint Shows for 2007 have their own MIME type:

• application/vnd.openxmlformats-officedocument.presentationml.slideshow

As does PowerPoint 2007:

• application/vnd.openxmlformats-officedocument.presentationml.presentation

Specifying the wrong MIME type for PowerPoint Show files caused WordPress to add a .ppt extension to the file, which played havoc with subsequent downloads. The fix was to specify the MIME type in wp_check_filetype:

• ‘ppsx’ => ‘application/vnd.openxmlformats-officedocument.presentationml.slideshow’

My bug report at WordPress MU was closed because this is technically something that needs to be changed in core WordPress; I’ll be reporting it there shortly.

WordPress MU 2.8.1 was just released, and I came across a few bugs while kicking the tires on my MU development site:

• #1037 After upgrade, upgrade banner doesn’t disappear (fixed)
• #1048 WPMU 2.8.1 improperly escaping titles of newly created blogs
• #1049 Editing Blog Settings as Admin fails (fixed)

#1049 was fixed within four minutes of me posting the ticket, which is pretty darn cool.

I also encountered an issue with the Admin-SSL plugin and 2.8.1 that sets up an infinite rerewrite of the blog delete URL; I haven’t had a chance to track it down yet, but the author is working on an update of the plugin to get it working properly with 2.8.