WordPress wp-latex plugin without dvipng

I wanted to install the excellent wp-latex plugin for WordPress, which allows the inclusion of LaTeX equations in posts and comments but my ISP did not have dvipng installed, one of its prerequisites, nor some libraries I would need to build my own copy there. I patched the plugin to instead use dvips and convert, which are both part of the standard LaTeX distribution. If anyone in a similar situation needs the plugin and the author doesn’t accept my patch into the official version, you can contact me for it. The patch is only a few lines. [Update: The author has accepted the patch. Until version 1.0 is released you can get the latest svn version.] Most people who have or can get LaTex on their web server should be able to get dvipng installed (and I expect that my ISP will respond to my request to install it), and dvipng is probably a bit faster, but the patch is an alternative for those who need it.

As an example of what wp-latex can do, here is the equation for the protein translation component of my simulation, part of the formula for protein rate of production, not including terms for death and diffusion.

\sum_{i=1}^{N_{G}} \sum_{l=1}^{N_{P}} \prod_{k=1}^{N} p_{l} g_{i} f^{\prime}_{\mathit{RES}}(R(x))\xi_{ikl}^{(1)}f(l,c_{ik},a_{jk})

Much thanks to John Hedditch who worked out the equations and translated them into a numerical simulation during a couple of intense days of collaboration we had at his office in Brisbane recently.

WordPress upgrade

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.

Safe mode and WordPress registration mail

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.

[DokuWiki | blikithoughts]

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.

Theme Switcher Shim plugin

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.

Installing Spell Checker plugin in safe mode

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.

  1. Disable the test in spellcheck-plugin.php that blocks installation when running in safe mode.
  2. Bypass the exec(“which aspell”) call, which will not work in safe mode. Instead set the result variable of the call to be “aspell”. The location of the aspell command on the server is not relevant because safe mode restricts execution to files in the safe_mode_exec_dir directory.
  3. Create a shell script wp-contents/spell-plugin/aspell that is set to be executable and contains

    #!/bin/sh
    /bin/sh -c "/usr/bin/aspell $*" 2>&1

    This can’t be a simple softlink because of the way that safe mode escapes the redirection in the command line.
  4. Replace the two calls to 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 ) {

Installing Plugin Manager in safe mode

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.