More on Upgrading to WPMu 1.3

As I already noted previously here, we have upgraded UMW Blogs to WPMu 1.3. Everything went smoothly on the surface, save for one rogue widget plugin I mentioned in the previous post. Well, as time goes on, other issues have emerged that are easily fixed but raised some interesting questions for me as I searched for the solutions.

Let me start with the relatively straightforward issue first. Certain themes, in this case the venerable MistyLook was encountering the following error after the upgrade:

“Warning: array_key_exists(): The first argument should be either a string or an integer in …/wp-includes/category-template.php on line 176”

Seems that certain changes in the categroy-template.php file are incompatible with this theme. There may be others, so I am doing a pretty thorough search, but so far I have found no other issues. The fix for this issue can be found in this forum thread, and I found that the fix recommended by farseas worked like a charm.

The above issue was pretty straightforward as is the fix, the next issue is a little more problematic for me because it raises some questions that I believe are pretty important to an open source community. I got an e-mail from Martha this afternoon letting me know that the Userthemes plugin (an essential one for us) was throwing a 404 error. I checked this plugin on the upgrade to make sure it was working, but I didn’t actually try and edit a theme, I just looked at the tab in the WPMu site admin area.

My grave mistake, this plugin depends on the theme-editor.php file, which to my great surprise is no longer a part of the source code of WPMu, which I searched on the WPMu trac here. Realizing this and now a bit concerned, I did a google search for the file name “theme-editor.php” and found the following ticket (#480) which suggests that this file is unnecessary for WPMu because it poses a security risk and has therefore been eliminated from the source code. Huh?!

What’s interesting about this ticket, however, is the brief discussion that follows. I think it is important so I will re-post it here:

RavanH: Is the file missing on purpose? If so, people should warned that plugin UserThemes? depends on the file and they should keep the one from a previous install. The 1.2.5 version seems to work, but haven’t tested fully.

Donncha: Yes, it’s missing on purpose. There is no reason why a theme should be edited through it. That User Themes plugin is a security risk if I’m reading the description at it appears to allow any blog admin to edit the themes. As some comments on that page point out, those themes are PHP and you’re just asking for trouble installing that plugin!

RavanH: ok, i will have to stick with the old theme-editor.php then…
I can relate to the risk involved when the system is used for public sign-up. but please, let me assess the risk i take myself. to be clear: i am not working with wp_mu as a public service but only with a limited set of people that can be trusted to operate carefully when maintaining their blogs. is wp_mu only supposed to be used for free and unlimited sign-up???

Donncha is a programming maven, and the work he has done on WPMu is remarkable to say the least. At the same time, I have to say that I agree with RavanH to some large degree here. We are using the Userthemes plugin on a case-by-case basis, and it is really important for many of the sites we are doing in the controlled environment of UMW Blogs. Shouldn’t we be able to take risks with the application if it works for us? I think so.

Nonetheless, the fix is pretty easy, just get an old theme-editor.php file from the WPMu archived version and upload it to the wp-admin directory. Then replace the following line of code:
wp_die( "The theme editor is disabled" );

to this

if((get_option('ut_use_user_theme') == 0) || (get_option('ut_enabled') == 0)){ wp_die('Either you have not been granted permission from the site administrator to access the theme editor OR you do not have a usertheme as your active theme, theme editor will die while a system theme is active.'); }

This should work for the short term, and I hope possibilities like this for WPMu aren’t all dependent upon outdated hacks that are in and of themselves security risks.

This entry was posted in plugins, UMW Blogs, WordPress, wordpress multi-user, wpmu and tagged , , , , , , . Bookmark the permalink.

6 Responses to More on Upgrading to WPMu 1.3

  1. Martha says:


    First, thanks again for taking care of this from afar. Not having userthemes would have been pretty crippling, and I’m glad to hear the fix wasn’t too hard to track down.

    I agree with you wholeheartedly about leaving it up to WPMU administrators to determine the best way to make features like userthemes available to users.

    It seems a bit heavyhanded for the developers to simply decide that they know best on this front.

    In our case, as you’ve pointed out, userthemes is primarily used by those of us who are already well-versed in the ins and outs of editing themes in vanilla WP. What it allows is for you to effectively distribute the administrative capabilities among expert users (and, it would seem to me that “growing” expert users is a good thing).

    The fact of the matter is that WPMU doesn’t seem to provide much in the way of administrative tools/approaches for this kind of distribution, meaning that without userthemes in order to distribute administration you have to take the (I would argue) greater security risk of opening up server access to multiple users.

    Userthemes, if used effectively and intelligently, seems to address this missing feature.

    I wonder if part of this stems from a lack of awareness by the greater WPMU community about how this application is being used by institutions like our own. What do you think their basic “case use” is? What kind of site are they ideally building this application for?

    Perhaps it also points to why we (in education) need to do a better job of making visible the ways in which WPMU is being used by colleges and universities, pushing the issues (like distributed administration) to the forefront of the developers’ conversation.

  2. jimgroom says:

    Well said, Martha.

    I think the logic for WPMu for most folks is one administrator and hundreds and/or thousands of blogs that really couldn’t afford to experiment as we are at UMW. Which, as you say so well, makes the case for making the work we are doing more visible. I know Donncha has come across this blog before, and he himself is a regular blogger, so I wouldn;t be surprised if he saw the argument. And the fix may be as simple as taking the theme-editor.php file from the latest WP releases. But I, like you, would like to get a sense of why the need to avoid all risk.

    In the end, and administrator has to upload this plugin, activate it, hack a core file, then allow individual users to edit their themes. All these steps would suggest that the administrator has considered the risks, or at least is to blame for any problems that ensue. I don;t think it would reflect poorly on the WPMu application.

  3. dsader says:

    I’ve been fiddling with an update to the userthemes1.1 plugin hosted at, wondering if you could share the version of the plugin you have installed, if it differs from

    I have a “beta” version ready and running for WPMU2.5->2.6. Are you interested and do you have time and a WPMU 2.5.1+ test/sandbox blog available so you could “kick the tires”?

    It has fewer bugs, but is by no means bug free.


    D. Sader

  4. Reverend says:

    Hey D. Sader,

    I am a huge fan of your plugin, and would love to kick the tires. I am using the stock plugin out of the wpmudev box. The only thinking a did for WPMU 1.5.1 to make it look better in the edit themes tab, was to copy over the newest edit-themes.php file from the latest single wp install. Is the update on yet? –or would it be better for me to contact you?


  5. dsader says:

    It’s up at

  6. Reverend says:

    Hey dsader,

    Here is my testing of the new Userthemes plugin for 1.5.1 and 2.6 beta 1 (sweet new look by the way, great work!).

    WPMU 1.5.1
    When you go to userthemes it has the following error message for certain plugins it seems to be colliding with (in this case wpmu signup captcha):

    Warning: session_start() [function.session-start]: Cannot send session cache limiter – headers already sent (output started at
    /home/…/wp-content/mu-plugins/1676498319_userthemes_26.php:853) in /home/…/wp-content/mu-plugins/wpmu-signup-captcha.php on line 30

    After deleting these plugins, the error message went away, but after I copied a theme to the themes folder for a particaulr blog and clicked on the edit button I got the following error.

    Warning: Cannot modify header information – headers already sent by (output started at /home/…/wp-content/mu-plugins/1676498319_userthemes_26.php:853) in /home/…/wp-includes/pluggable.php on line 701

    This error, however, does not prevent me from editing the themes

    WPMU 2.6

    When you go to userthemes it has the following error message for certain plugins it seems to be colliding with (in this case post ratings and wpmu signup captcha):

    Warning: Cannot modify header information – headers already sent by (output started at /home/…/wp-content/mu-plugins/1676498319_userthemes_26.php:853) in /home/…/wp-content/plugins/postratings/postratings.php on line 827

    Warning: session_start() [function.session-start]: Cannot send session cache limiter – headers already sent (output started at
    /home/…/wp-content/mu-plugins/1676498319_userthemes_26.php:853) in /home/…/wp-content/mu-plugins/wpmu-signup-captcha.php on line 30

    When you click on edit theme:

    Warning: Cannot modify header information – headers already sent by (output started at /home/…/wp-content/mu-plugins/1676498319_userthemes_26.php:853) in /home/…/wp-includes/pluggable.php on line 776

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.