I have begun setting up a web site for OzWin for refugees from the late lamented OzWin Forum on CompuServe. That site will have information and downloads. The community will continue in our own section in the Tapcis Forum. If you are one of the people who know what any of that means, head over there and say hi.
I was just about to post a belated note about upgrading to WordPress 1.5.1.1 when I noticed that there is a security upgrade to WordPress 1.5.1.2. It appears to be a one line patch, so what I’m actually running right now is the patched 1.5.1.1.
I’ve upgraded WordPress to version 1.5.1. It was as easy as the installation instructions make it out to be. The only extra step was running my script that sets all the file permissions for secure PHP operation, as described in Securing PHP applications at Sonic.net.
This new version includes the fix for the problem with sending email when running in safe mode.
Coincidentally, my web hosting ISP, sonic.net, has turned off safe mode in their PHP installation, making all the safe mode workarounds I’ve been blogging about no longer necessary. Life has become simpler.
WordPress failed to send email, such as when registering a name or trying to retrieve a password. The problem turned out to be in the wp_mail function in wp-includes/functions.php.
It takes an optional argument $more, which it passes on to mail() as its fifth argument. The php mail() function is documented not to accept that fifth argument when in safe mode. The fix is to call mail() without that $more argument either when in safe mode and/or when $more == ”.
I have since found that this change is already in the development source of WordPress. See changesets 2365 and 2415.
[Update, May 12, 2005] WordPress 1.5.1 has been released and contains the fix to this problem.
It appears that the author has updated Theme Switcher Plugin to version 1.1 and now includes the functionality I put into Theme Switcher Shim Plugin. So I’ll see if I can delete the shim from the Plugin Manager database.
I have noticed that Theme Switcher Plugin really slows down my WordPress page display. When I install all 140 or so plugins from the theme site, it takes about 5 seconds to display my WP home page. With the plugin disabled it takes 0.78 seconds, according to the timing stats in the footer.
The problem is that the plugin calls get_themes in order to have the theme file names for the links, because all it stores in the plugin options are the theme names. get_themes reads all the theme information in the themes subdirectory, reading not only the directory contents but some information from files in every theme in the directory whether or not it is selected for the Theme Switcher list.
The solution is very simple: Store the file name in the plugin options along with the theme name.
The few line change to the plugin reduces the load time of my front page from 5 seconds down to under a second. Even better, it makes the time independent of the number of themes in the themes directory.
I’m going to email the changes to the author.
You can download this zip file containing the patch in diff format.
This post is an experiment with the WordPress dwBliki plugin and a rambling about blog/wiki integration in general.
Even though the title and categories make it look like one of the DokuWiki entries, I’m creating it in WordPress. I’ve seen that the plugin will take a new DokuWiki page and put it in the WordPress blog. Now let’s see if works in reverse to put this in the DokuWiki. If it does, that will be be pretty cool. If it doesn’t I’ll see what happens if I then create a page with this name in the DokuWiki.
So, what does it mean to integrate a blog and a wiki? The dwBliki plugin seems to ignore that question in favor of simply implementing the cool hack of embedding the full blown DokuWiki inside a WordPress plugin so that wiki pages become blog entries. The difficulties I’m seeing with that have to do with the mismatch of purposes.
A blog consists of a series of frozen snapshots ordered by time. A blog grows in two directions, through the addition of new posts and through the comments and trackbacks. Editing old posts undermines the blog by rewriting history without informing interested past readers. A blog is the creation of an individual. It is a personal journal, or at least a vehicle for the creative work of a particular author or a small collaboration of authors. Even when a blog is used as a discussion forum, posts are the creation of a blog owner, replies are the static creations of their authors linked in a temporal chain.
A wiki consists of a web of linked expressions of topics. The expressions and the links change over time. There is no “author” for a page. Even though it is possible to follow the revisions of a page and see who the authors were, a wiki does not provide a view that would make that history visible as a form of discussion thread.
So what does it mean to combine a blog and a wiki? I have some ideas about that, but I’m going to save it for a later post. Right now I want to see the results of the experiment and get some sleep.
[update:] I created a page in the wiki named blikithoughts, which would have created a blog entry with this name. This blog page did not change.
[[start]] ported by dwBliki from DokuWiki
I have just installed [[http://wiki.splitbrain.org/wiki:dokuwiki|DokuWiki]] and the strangely named [[http://www.ezpdo.net/blog/?p=26|dwBliki]] plugin that makes DokuWiki a WordPress plugin. As I have no idea how a bliki is supposed to work, I’m creating this wiki page to find out what happens.
Ackk… This creates a backdoor into the login system of the blog — Anyone can create a wiki page and it creates a blog entry. I’ll have to fiddle with the DokuWiki’s ACL system and see what makes sense.
This brings up the question of what a bliki ought to do… If a blog is a journal authored by one person to which people can add comments or trackbacks, and a wiki is a web site with communally authored pages, then how do wiki pages map onto things on a blog? Can each wiki page have an “owner” who is the original author, and on whose blog the page is placed? I guess I’ll bring this up on the dwBliki blog. (Or maybe my link to it has caused a trackback already).
Well, I’ve managed to get DokuWiki to use the user names and passwords from the WordPress MySQL database. All it took was the proper configuration entries in DokuWiki’s local.php file. I’ll document the details in a later entry. Someone suggested that the problem of multiple blog users of one wiki could be solved by mapping DokuWiki namespaces to user blogs. This brings up the further issues of how to support multiple bloggers in one installation of WordPress. I’ll go into that, with some links, in that future entry.
Here’s a plugin that lets the themes in the Theme Contest repository work with the Theme Switcher plugin you find in Plugin Manager.
This is really confusing. The WP Plugin Manager refers to a central database of plugins. It has a Theme Switcher Plugin. To use it you add a call to get_theme_switcher() in sidebar.php where you want the list of themes to appear. If you have Plugin Manager installed, with one click you can install or update Theme Switcher. Then all you need to do is edit every one of the themes you download to put the correct snippet of code in sidebar.php.
The WP Themes contest that I’ve mentioned before refers to a different Theme Switcher plugin. It works pretty much the same way, except it uses a different name for the function to be called from sidebar.php. If you install that Theme Switcher plugin, then all you do is download the themes from the contest site. They all have the correct code in their sidebar.php to work with this Theme Switcher.
Oops. That isn’t the Theme Switcher you get when you update in Plugin Manager.
The solution: Theme Switcher Shim, a plugin that I am submitting to the WP Plugin Manager database.
If you have WP Plugin Manager, you can get it with a one click install. There is no configuration involved in using it. When you have Theme Switcher plugin installed from Plugin Manager, then Theme Switcher Shim will just work. If you don’t have the Theme Switcher plugin installed, the shim detects that and does nothing.
You can install Theme Switcher Shim manually by unzipping theme-switcher-plugin.php into your wp-contents/plugins/ directory, but it doesn’t make a whole lot of sense to do so: Its usefulness is in regards to WP Plugin Manager and the one-click install.
I’m trying to add the Spelling Checker Plugin. It doesn’t work in safe_mode. I’m trying to change that. Let’s see if this can be spell-checked and posted.
Yes, it works!!
Here is a summary of the changes I made to the original code version Beta 1.17 14-March-2005. I hope the author of the plugin will be able to make this post obsolete by folding the changes into his plugin.
First, the conditions under which this was tested:
My hosting ISP provides PHP running in safe mode with safe_mode_exec_dir set to “.” and PHP built –with-pspell. That means that aspell is installed on the server. It is in/usr/bin/aspell.
I installed WordPress using PHP built as a cgi and called with CGIWrap using the techniques described in Securing PHP applications at Sonic.net. That may have affected which directory is “.” at time of the call, and therefore which directory I had to install the shell script named aspell that acts as a shim for the call to the system aspell.
This will only work for you if safe_mode_exec points somewhere that you can put your own shell script.
#!/bin/sh
/bin/sh -c "/usr/bin/aspell $*" 2>&1
shell_exec() with calls to exec(). In the one place that uses the return string from shell_exec use the second argument to exec and the join function to get the same result.Here are the diffs for the code changes I made:
diff -r ~/spell-plugin/spell-plugin.php ./wp-content/plugins/spell-plugin.php
169c169
< if(ini_get('safe_mode'))
---
> if(ini_get(’xxxsafe_modexxx’))
260c260
< exec( "which aspell 2>&1″, $out, $err );
—
> $out[0] = “aspell”; $err = 0;
diff -r ~/spell-plugin/spellInclude.php ./wp-content/spell-plugin/spellInclude.php
114c114
< shell_exec( $cmd );
---
> exec( $cmd );
diff -r ~/spell-plugin/spellchecker.php ./wp-content/spell-plugin/spellchecker.php
95c95,97
< if( $aspellret = shell_exec( $cmd )) {
---
> exec( $cmd, $execout );
> $aspellret = join(”\n”, $execout);
> if( $aspellret ) {
This was almost too easy!
The problem: Plugin Manager uses exec() to call the unzip command to extract files from plugin archives. This does not work in safe mode. On my hosting ISP, PHP is run in safe mode with safe_exec_dir set to “.”, which restricts exec() to calling only executables in the current directory.
The solution: Create a symbolic link for unzip in the main WordPress directory, pointing to /usr/bin/unzip
My hosting site has allow_url_fopen set, so I did not have to work around a similar call to wget that Plugin Manager uses in the absence of allow_url_fopen.
I posted a comment about this at the Plugin Manager blog site.