In yesterday's posting I applauded James Farmer's success in getting the multi-user version of the open source WordPress (WordPressMU) weblog engine working. I bemoaned the apparent lack of mainstream support for WordPressMU from the WordPress community and my own lack of success in installing and testing the former locally. There's news, at least on the latter front. I've now managed to install WordPressMU and so with the inclusion of a sample (alpha level) registration script provided by Donncha 0 Caoimh (the lead developer of WordPressMU) users can create their own blogs within 30 seconds or so. In the latter part of this article I'll describe my installation gotchas!, which may help others avoid them.
I think what Donncha has done is really fantastic and he is to be congratulated.
I have, however, now moved on to a couple of key questions.
Although now it's possible for us to enable everyone to have an 'insta blog', a la Blogger.com, what happens when people leave the organization or finish their course? How to I manage/delete the blogs so created? At the moment each new blog is allocated its own tables prefix in the designated WordPressMU database, so I guess, pro-tem and with small numbers of users, it would be fairly easy to amend and delete blogs. But it would be dead easy for an institution to find itself with 5, 10, 15, 20 thousand users or more; at that level of uptake and turnover the management interface and processes become absolutely critical. The development of such is going to require the participation of pretty motivated and competent open source developers; but, as I asked yesterday, is WordPress.org buying in to the importance of this variant of their open source 'brand'?
Also, if each new blog creates say 12 tables then multiply that by the number of users. Are there performance implications in a single MySQL database handling such large numbers of tables or do we just throw hardware at it? I don't know but perhaps some MySQL gurus out there may know the answer.
Now to these installation gotchas! (N.B. this section will give technophobes indigestion and so they should jump to the last paragraph in this article 🙂
It really seems to matter that all the admin/config balls are in line before starting the install. Donncha's install is really efficient when everything's set up … but if the balls aren't in line … 🙁
The first gotcha! arose because the .htaccess file contains the mod-rewrite rules which drives the generation of the virtual urls. Our computing admin had turned off .htaccess so once I had that permitted for my WPMU directory things began to move forward.
The second gotcha! for was I had prepared a wp-config.php for my MySQL config (as the install page indicated I should) but the next install page then went on to state that such a file existed and then stopped the install until I removed it, so that it could create it.
The third gotcha! was the install gathered the database information and then produced a wp-config.php file with a mangled database name. Once I found out that this is what it was doing I just edited the produced wp-config.php manually and the install then proceeded smoothly.
The fourth gotcha! was when I edited the .htaccess file with the path to wp-inst Donncha's new RewriteRule. I inserted the full filesystem path but this generated multiple errors. I found that only the directory portion leading to my WPMU root was necessary, in my case /subdirectory/wpmu/ was necessary instead of /fullfilesystempath/sudirectory/wpmu.
As a quick, and probably very dirty, install guide I offer the following (at your own risk and with no guarantees it's relevant to your situation):
- Download the lastest WordPressMU snapshot from http://mu.wordpress.org/download/
- Unzip the file, change that name of the folder to wpmu.
- Create (or get your system admins to create) a MySQL database.
- Make sure you know the database name, user, password, database host.
- Transfer wpmu to your webserver.
- Make sure .htaccess is enabled by your system admin on wpmu and another one in its subfolder wp-inst
- Open that location in your browser through your webserver … the install should start
- Follow the instructions but don't create a wp-config.php manually, let the install ask you for the information and create the file (but check the content of the file created before proceeding with the rest of the install). Read/Write permissions are necessary on the following directories: wpmu, wp-inst, wp-content>smarty-templates as well as the .htaccess files in wpmu and wp-inst. These permissions can be amended after the install.
- Download the alpha registration script from Donncha's site and follow the instructions there (note my fourth gotcha!).
Having remedied these gotachas! and worked out the installation sequence, the installation process of the base system took only a few minutes and, as stated earlier, users can have their own customizable blog in 30 seconds or so. Note that I mean customizable in a technical sense. It needs a competent/confident person to make the necessary adjustments to move beyond the default appearance of a blog's home page. However, such a person could set up a new default style fairly easily, e.g. for a faculty. Posting articles and comments is, of course, a 'no brainer', even in the default state.
