scriblio

Somewhere in the WordPress code extra slashes are being added to my query terms.

I’ve turned GPC magic quotes off via a php_value magic_quotes_gpc 0 directive in the .htaccess file (we have far too much legacy code that nobody wants to touch to turn it off site-wide). And I know my code is doing one run of addslashes(), but where are the other two sets of slashes coming from?

I’ve whittled things down to the point where the only baseline change from WordPress 2.0.2 is in the next_posts_link function of the wp-includes/template-functions-links.php file. The change is necessary because WPopac rewrites the SQL search queries in a way that’s incompatible with a piece of this function, but necessary for performance reasons.

Here’s how my version reads:

`

function next_posts_link($label='Next Page »', $max_page=0) {
	global $paged, $result, $request, $posts_per_page, $wpdb, $max_num_pages;
	if ( !$max_page ) {
			if ( isset($max_num_pages) ) {
				$max_page = $max_num_pages;
			} else {
				preg_match('#FROM\s(.*)\sGROUP BY#siU', $request, $matches);

				// added April 5 2006 by Casey Bisson to support WPopac
				// necessary because the preg_match above fails with some queries
				if(!$fromwhere)
					$fromwhere = $wpdb->posts;
				
				// changed April 5 2006 by Casey Bisson to speed the query by eliminating
				// the slow DISTINCT clause
				//$numposts = $wpdb->get_var(“SELECT COUNT(DISTINCT ID) FROM $fromwhere”);
				$numposts = $wpdb->get_var(“SELECT COUNT(*) FROM $fromwhere”);
				$max_page = $max_num_pages = ceil($numposts / $posts_per_page);
			}
	}
	if ( !$paged )
		$paged = 1;
	$nextpage = intval($paged) + 1;
	if ( (! is_single()) && (empty($paged) || $nextpage < = $max_page) ) {
		echo '<a href=“';
		next_posts($max_page);
		echo '”>'. preg_replace('/&([^#])(?![a-z]{1,8};)/', '&$1', $label) .'</a>';
	}
}

`

Between WordPress 1.x and 2.x there was a big change to the way rewrite rules are handled.

In the old days, everything got written out to a <a href="http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html#RewriteRule">.htaccess</a> file. Every condition, every form of permalink could be found there, and I had some comfort knowing I could see and mess with it all. I was a bit surprised to find that with 2.0.2, WP writes out a sparse file that has only one significant rule. Something that looks like this:

RewriteRule . /blog/index.php [L]

That one line takes everything in your request URL and passes it through to index.php for processing. The beauty of this is that WP doesn’t need to write to the file system with every change to the permalink structure (which used to include every new “page” added or renamed).

The only downside to this is that you can no longer expect a $_REQUEST array full of all the query terms your plugin might use. Instead you’ll have to use the <a href="http://codex.wordpress.org/Function_Reference/WP_Query">$wp_query</a> object. All of this was probably mentioned in the API docs before I built a bunch of dependancies on $_REQUEST, but it was easy enough to fix.

Ross Singer gets the prize for submitting the first reader contributed tag, the latest feature in bsuite.

There are arguments about whether user-contributed tags are useful or even valid, or whether they should be stored in my site or aggregated at places like del.ici.ous. But who’s to worry about such questions? Who’s to worry when you can put together the work already done to support author’s tags with WordPress’s pretty good comment system and get user contributed tag support with just a few extra lines of code? Who’s to worry when we can try it and see what comes of it?

It’s all managed using the same tools we use to approve, moderate, and edit comments, which also means the spam filtering that works for comments works for contributed tags too. And because bsuite is already part of WPopac, that means it gains the new tagging features too (well, it will soon).