Simmons Consulting » WordPress

Integrating WP in external PHP pages

Toby Simmons — Thu, 24 Jun 2010 16:00:11 +0000

I have several external pages that use the WP theme engine to wrap the content. I use the method found here, which worked great under WordPress 2.9.2. After upgrading to WP 3.0, these pages no longer worked as expected but instead generated 404s; it turns out the fix is rather simple.

The code to include the WP theme in external pages used to look like this:

< ?php

require('./wp-blog-header.php');
get_header();
?>
<h2>This is the external content.h2>
< ?php
get_sidebar();
get_footer();
?>

The newest version of WP merged the old WordPress Multi-User (WPMU) and the standalone version of WordPress. Since this merger, the new way to include WP in external pages is to change the require() statement to pull in wp-load.php (instead of wp-blog-header.php) like this:

< ?php

require('./wp-load.php');
get_header();
?>
<h2>This is the external content.h2>
< ?php
get_sidebar();
get_footer();
?>

Now your external pages work just like they used to! I found the answer on a BBPress forum post from nine months ago.

WordPress Can Guide Missiles?

Toby Simmons — Mon, 14 Jun 2010 17:35:26 +0000

This is just so funny!

http://www.viper007bond.com/2010/06/12/so-apparently-wordpress-can-guide-missiles/

WordPress and duplicate sites in stats plugin

Toby Simmons — Fri, 18 Jul 2008 17:45:03 +0000

I use the WordPress.com Stats plugin on my blog. It is great for generating basic traffic statistics. When I upgraded my WordPress version to 2.6, something happened during the process to create a duplicate site in my stats drop down. The biggest problem is that all my old stats are associated with the original site, while all my new stats (from 7/15/2008 forward) are being pushed into the new site.
Based on searching through the support groups, I don’t think I’m the only person to have seen this or similar issues with the stats plugin and WP 2.6.

While upgrading, I disabled all my plugins. After the upgrade, when I re-enabled all my plugins, I was prompted to re-enter my API key for the stats plugin. I entered (what must have been) the wrong API key because when I entered it, it threw an error. I then doubled-checked the key and re-entered it (apparently correctly this time) and it was accepted but duplicate site was created.

I’m not sure how to go about merging the stats and deleting the duplicate site, but it sure would be nice to be able to do that.

I’ve opened a trac ticket to hopefully find out what can be done to fix this. if you have experienced this, please go and add your comments to the ticket as well.

Here’s what the drop down with the duplicate sites looks like:

Updated @ 2008-07-29 02:14:10 p.m: There might be a workaround here.

Running a WordPress blog in site root using IIS

Toby Simmons — Mon, 21 Apr 2008 16:59:13 +0000

Up until recently, I had never been able to setup a WordPress blog as the root of a web site under IIS. But I have discovered the secret and have recently changed my own site so that my content no longer shows up under a “/wordpress” directory but instead in the root.

The problem stems from the way PHP is installed. On Windows IIS, you can run PHP in two modes: ISAPI and CGI/FastCGI. I had always installed it using ISAPI because, at least in the past, the performance gain was substantial. When running as ISAPI, the PHP processing engine gets loaded when the first PHP page is requested, then it stays in memory. Each subsequent PHP page request is then processed through that pre-loaded image which results in a bit of a speed up.

It turns out that recent versions (5.2.5) of PHP are pretty unstable under IIS when running as ISAPI. For example (and this is why you couldn’t run a WordPress blog in the root of a site) the current working directory is inconsistent (see bug #42460 and bug #44777)

The symptom is the main index.php cannot find the first required file, ./wp-blog-header.php:

/**
* Front to the WordPress application. This file doesn't do anything, but loads
* wp-blog-header.php which does and tells WordPress to load the theme.
*
* @package WordPress
*/
/**
* Tells WordPress to load the WordPress theme and output it.
*
* @var bool
*/
define('WP_USE_THEMES', true);
/** Loads the WordPress Environment and Template */
require('./wp-blog-header.php');

When index.php tries to load wp-blog-header.php, it looks in the “current” directory (the ./ indicates “the current directory”). The problem is that the current working directory is unpredictable every time the page loads when the PHP page is called from the root of a web site so it can never find the wp-blog-header.php.

The fix is to install PHP using CGI/FastCGI. This is usually as simple as changing the script map to use php.exe or php-cgi.exe (depending on the version of PHP you are running) instead of php4isapi.dll.

WordPress 2.5 file uploader and IE7

Toby Simmons — Sat, 29 Mar 2008 18:44:19 +0000

So, you just upgraded your WordPress blog to 2.5 and you excitedly go to the admin screen to check out the new vaunted multi-file upload with progress bar. You click on the Write tab then click on any of the “Add Media” icons. The screen dims a bit then you are presented with … not the super-sexy, swfupload-based multi-file uploader but instead a dull, a simple, single file upload form and a script error. Why? It’s because you are running IE7. Fortunately, there is a pretty easy fix (that appears to be planned for 2.5.1) There are just two commas that need to be deleted, in two different files.

The first fix is in the file wp-admin/includes/media.php … down at line 817, delete the comma …

Change this:

debug: false,

To this:

debug: false

The next file to edit is wp-includes/js/swfupload/handlers.js … down at line 99, delete the comma right after the number 36 …

Change this:

.animate({minHeight:0,height:36,}, 400, null, function(){jQuery(this).children('.describe').remove()})

To this:

.animate({minHeight:0,height:36}, 400, null, function(){jQuery(this).children('.describe').remove()})

That’s it! The fancy multi-uploader now works in Internet Explorer 7!

Daylight saving time and WordPress XMLRPC

Toby Simmons — Fri, 29 Feb 2008 20:27:17 +0000

Zempt is a desktop blogging client and writing tool that is especially useful for those that have multiple blogs. It enables you to write, edit and spell check new blog posts as well as edit previous blog entries by downloading, editing and reposting them. Having been involved with the Zempt project for five years (and being the only developer for the last two or three) I am pretty familiar with some of the issues that can come up with remote editing of blog posts.

One of the most puzzling issues has been how to handle daylight saving time offsets with WordPress. Every time I think I have the issue solved, I discover that I’ve broken something else. This might be an issue particular to WP and how it handles timezone offsets.

Using Zempt to create brand new posts using the default date (which is “right now, whenever you post it”) works fine, every time. And editing previous posts from your blog that were written during the current daylight saving time state also works fine. In other words, if right now it is daylight saving time and the post you are editing was written during daylight saving time, that post’s time will stay the same. By the same token, If it is currently standard time and the post you are editing was written during standard time, again, the post’s time stamp will remain unaffected.

The problem comes when editing a post that was written in a different daylight savings state. Stay with me here.

Let’s suppose you keep your WordPress blog settings up to date … when daylight saving time kicks in, you update your blog’s timezone offset promptly. Same thing when daylight time ends, you change your blog’s timezone offset the same day. Take my blog for example. I am in the Central timezone, so my timezone offsets are -0500 during daylight time and -0600 during standard time.

Now let’s say it is currently NOT daylight saving time (-0600 for me) and my blog settings are up to date and I want to edit a post that was written while daylight time was in effect. The post I am editing has a time stamp of 9:00 am on Oct. 31, 2007 (CDT).

When I download that post and edit it with Zempt, it knows that Oct. 31 was during daylight time. When I save that post back to my blog, Zempt will dutifully convert that time stamp to University Time Coordinate (UTC) based on the post’s date, which means in this example, it will add five hours, which is 2:00 pm on Oct. 31, 2007 (UTC).

Unfortunately, WordPress thinks that any post it receives (regardless of the date) must be -0600 hours off from UTC because that’s what its timezone offset is, so it makes the post’s time 8:00 am on Oct. 31, 2007 (which is UTC minus six hours) so my original post shows that it is an hour earlier than it really was.

If I edit this post again with Zempt, the same thing happens, which means it becomes 7:00 am on Oct. 31, 2007. If you do this enough times, the time stamp gets really screwed up.

A similar problem occurs if you edit a post during daylight time that has an original post date that was standard time, except the post gets pushed forward an hour each time you save it to your blog.

I’ve tested Ecto (on Windows) and it has the same problem.

So here is my question: What should an offline blog writing tool like Zempt do to accommodate this problem? One thing I’ve considered is to have Zempt check the local machine’s current daylight setting vs. the post’s date and either add or subtract the appropriate amount from the post date’s UTC to have it work out but this seems to be a poor workaround. What would be nice is if there was a way through XMLRPC to tell WordPress to use a specified timezone offset for a particular post.

WordPress, IIS, timezone auto updating!

Toby Simmons — Mon, 04 Feb 2008 22:35:59 +0000

Most folks running WordPress use some flavor of Unix/Linux and Apache. If you are like me and run WordPress on IIS, it can be frustrating at times because you tend to feel a bit like a stepchild. There are several cool plugins for WP out there, but many just don’t run on Windows, at least not without heavy modifications.

One particular issue about WP that had driven me crazy was the issue of having to manually update your timezone offset every time daylight savings time started or ended. There is a plugin that is supposed to make this adjustment automagically for you based on either the server settings or the specified timezone setting you give it. The problem is that the plugin didn’t work on Windows. However, you can make it work by editing one line of the plugin.

The problem is due to the different way the strftime() function works on *nix vs. Windows. However, with one small edit you can make the plugin work on Windows.

Go to line 150 (of version 2.3 of the plugin, the latest as of this writing) and replace:

$offset = strftime('%z', time());

with

$offset = date('O');

You can now specify your timezone and it should automatically (as if by magic!) change the offset from GMT for you. Now stop feeling sorry for yourself!

Upgraded to 2.1, Zempt works swell

Toby Simmons — Sun, 11 Feb 2007 21:01:46 +0000

I finally updated my blog to WordPress 2.1 and Zempt works just swell. I thought I might have more problems than I actually have had. One thing about the 2.1 out of the box, though, is that WordPress returns invalid XMLRPC response to edit an existing entry. The problem was that WordPress was returning the categoryId as an instead of a as the XMLRPC spec says. This would make Zempt crash. Fortunately, someone committed a patch to the WordPress Trac which fixes it perfectly.

Apostrophe in title causes IE script error in WordPress admin

Toby Simmons — Fri, 07 Apr 2006 02:59:15 +0000

If you go to your admin panel and click on Manage, you might notice that occasionally Internet Explorer throws a script error.

The error will likely be:

Error:Expected ')'

The script that throws the error is the confirmation dialog box that WordPress creates for when you click to delete a post or page entry. The script runs a javascript function called deleteSomething(). One of the parameters passed to this function is the title of the post or page. If the title of your item has an apostrophe in it, when the title is passed to the function as a quoted string, the apostrophe would terminate the string early resulting in a script error. Thankfully, WordPress converts any apostrophes in the title to the numeric HTML entity '. This works great in Firefox.

Unfortunately, IE still sees it as a single quote mark and throws a script error.

WP upgrade (1.5.2 to 2.0.1) — so far, so good

Toby Simmons — Tue, 14 Feb 2006 21:26:32 +0000

Well, I’ve updated my WP to 2.0.1. The upgrade wasn’t without hitches, but it seems to be pretty stable right now. Permalinks under IIS was the main issue, but the 404-handler is working so far. On my test machine (Windows XP) the 404-handler doesn’t work consistently, but under Windows server it works fine.