From the ongoing saga in which I am building my school’s new web site using WordPress MU, and attempting to get 100 teachers to use it…
Since DreamHost pretty much couldn’t tie its own shoes for the first month or two we had their service, we decided to jump ship to Joyent. They were generous and accommodating about getting us set up, and the PTSA agreed to pay the bill, so it’s been non-stop theme development and widget wrestling for the past month or so. We’re almost ready for this summer’s launch.
The teacher training (How to Use WordPress 101?) starts next week, and I met Friday with my two colleagues who are helping me give the training sessions. I believe that this training will be a huge determining factor in how well this new service gets adopted. As of Friday, there were just a couple of bugs remaining — few in number, but pretty much show-stoppers in terms of convincing teachers that this is a better system than what we have. People’s first impressions often center on the interface and how it demos, as opposed to the underlying power or long-term use implications. Not that these are always completely different. Anyway, the point is that I was pretty motivated going into the weekend to solve these bugs. Good thing, because they were annoying.
The first bug was that uploading files did not work. I tore everything apart looking for problems with permissions, problems with paths, problems with PHP configuration… nothing. Eventually it came down to one line in the wp_config.php:
For some reason, ABSPATH was getting set to .. instead of the full path, and so WordPress couldn’t figure out where to copy the file once it was uploaded. I put that one line of code in its own file, and it worked correctly on the command line and when hit from the web. I could even hit the whole wp_config.php file directly from the web and it worked. But when included or require_once’d into another file, it would return dots (or, maybe dots and slashes). After enough time playing with that to determine it was hopeless, I hardcoded the absolute path. Next bug.
The next bug was that the WYSIWYG editor simply did not appear. This was the sad window:
This turns out to be a terrible thing to try to track down and none of my messing with realpath or the gzip settings or permissions solved it. Finally, out of desperation, I installed the Miwa Editor Plugin. Not only did it magically solve the problem, but I know the WYSIWYG table functionality will be welcomed by teachers who don’t know HTML. The only catch is that I didn’t want every single teacher to have to activate the plugin just to have a functional blog. Fortunately, there’s a wonderful facility in WordPress MU designed to help with exactly this situation: mu-plugins. Placing a plugin there instead of the regular plugins directory activates it for all users. The only problem is that it didn’t work.
The happy ending of this story comes through a search for make a plugin work in mu-plugins. I considered including some expletives in there, but didn’t think they would actually help my results. Google brought me to the answer on blog from Australia. All I needed to do was move the miwa-editor.php file out of its own folder and into the mu-plugins folder, since for some reason mu-plugins works differently than plugins and won’t descend into subdirectories to find the plugins. (I of course, had tried to place the entire miwa-editor folder into mu-plugins. Silly me.) Since miwa-editor.php hardcodes the path to the version of TinyMCE that it uses, I just left the rest of its folder in the regular plugins location. And it worked. And all was well.