It's now available for download from this page: Post Teaser 2 - An Essential WordPress Plugin.

The Bug

When I click the Update Options button on the Manage Post Teaser page, I got this: "Cannot load post-teaser.php." as shown in the snapshot:

Locating the bug

It's annoying abit, but it's also easy to fix. I notice the following URL after the button is clicked:

http://binh.name/wp/wp-admin/options-general.php?page=post-teaser.php&saved=true

And this is the URL before the button is clicked:

http://binh.name/wp/wp-admin/options-general.php?page=post-teaser/post-teaser.php

The different here is noticable.

• The failed query is: post-teaser.php&saved=true
• The unfailed query is: post-teaser/post-teaser.php

So the correct query for saving the options should be: post-teaser/post-teaser.php&saved=true

Debugging it

Open file "post-teaser/post-teaser.php" in the Plugin Editor (found in the Plugins page in Admin panel).

Search for the string "post-teaser.php&saved=true" in the file , and found the following lines:

• 101: header('Location: ' . get_settings('siteurl') . '/wp-admin/options-general.php?page=post-teaser.php&saved=true');
• 103: header('Location: ' . get_settings('siteurl') . '/wp-admin/options-general.php?page=post-teaser.php&saved=true');

Replace "post-teaser.php&saved=true" with "post-teaser/post-teaser.php&saved=true" and we get:

• 101: header('Location: ' . get_settings('siteurl') . '/wp-admin/options-general.php?page=post-teaser/post-teaser.php&saved=true');
• 103: header('Location: ' . get_settings('siteurl') . '/wp-admin/options-general.php?page=post-teaser/post-teaser.php&saved=true');

Alternatively you could edit the plugin file locally then upload it.

A screenshot where it is located:

Problem Fixed:

Conclusion

The author of this plugin actually wrote it up to version 2.3 of WordPress. Or maybe because he just didn't mean to have the user keep the post-teaser.php file under the post-teaser folder. Either way, I hope when writing the plugin and packaging it the author should consider the end user first.

I, a web developer still didn't realise I had to extract the php file into the plugins folder instead of the whole folder which contains the php file? Most of the plugins come packaged with readme.txt, plugin-name.pot, etc. How does the user know what to do without reading pages of documentation? We should make it simple for the end users. KISS principle is appreciated.

Since this wonderful plugin has a public license I would like to continue supporting it. If you have any problem please feel free to leave a comment on this page. And... sorry I couldn't fix the translation files. So if you are using another language, please bear not having it, or modify the original file as directed by this debugging tutorial.

You can directly download Post Teaser 2 now.

The Bugs

The following are the bugs:

1. Redirect "/feed" URI to "/feed/" using 302 redirect. Ignoring the "/%postname%" rule having no trailing slash.
2. Redirect "/?paged=x" to "/page/x/" (where x is paging number) ingoring the fact ugly default URL is used, causing 404 message when paging.

There is no doubt about these bugs, because I test it by enabling and disabling Permalink Redirect plugin.

Fixing the bugs

Indeed being a programmer gives me some advantages, I could fix the bugs on the fly.

Feed redirect trailing slash

For the /feed to /feed/ redirect problem, I found these lines:

208 if (is_feed()) {
209 $link = trailingslashit($link) . 'feed/';
210 }

Solution:

1. If want no trailing slash, remove the "/" on line 209.
2. If it's WordPress 2.3.1+ simply remove the 3 lines because it's built-in.
3. If you don't want to touch code, include the following in the Options > Permalink Redirect > Paths to be skipped: ".+/feed.*" (without the quotes)

Page redirect ignoring permalink rule

For the /?page=x to /paged/x/ problem, I found this line:

204 if ($paged)
205 $link = trailingslashit($link) . "page/$paged/";

Solution:

1. If WordPress 2.3.1+, remove the lines because it's done better.
2. If you don't want to touch code, include the following in the Options > Permalink Redirect > Paths to be skipped: ".+/?paged=.*" (without the quotes)

Conclusion

Even being buggy, and not recommended by WordPress 2.3.1 which claim having internal redirect, Permalink Redirect still provide some benefit that built-in redirect doesn't offer, such as:

1. Redirect permalink from old structure to new structure
2. Redirect broken, or wrong URL, providing the post id is correct, or enough matching words in post slug.
3. Redirect feed url from "/?feed=rss" to "/feed" or "/feed/" depending your customization.

This plug-in is indeed getting a lot of my attention. I have more liking for it than the bult-in redirect. So, whenever I have time I will investigate deeper into the code and optimize it for better usage.

On Tuesday the 25th of September 2007 I was having this annoying bug. I was testing my website using FireFox (my main browser). I found out I couldn't send my page description to Digg using the following Digg JavaScript variable:

digg_body = document.getElementsByName("description")[0].content

While Internet Explorer, my 2ndary browser worked fine with it.

Debug Process:

The debug process was done using the alert statement to show the object.

alert (document.getElementsByName("description")[0].content);

When the page is loaded in Internet Explorer 7, the alert statement shows a pop up message containing the page description. While in FireFox it return NULL. I couldn't see anything wrong with the syntax. After many hours trying to fix, the problem was actually too simple. In the HTML page I got

<meta name="Description" content="some text...">

Instead of

<meta name="description" content="some text...">

Debug Result:

The only different here is the "D" in the actual code, as apposed to the "d" as what the FireFox JavaScript was looking for.

The cause of the problem is that, the meta Description tag was placed automatically by the ASP.NET code, so I had to modify the JavaScript instead.

Lesson learned:

FireFox is very strict in JavaScript casing. So watch out for the bug similar to this and save you some time wondering what's wrong with the "perfect" code.