The cause of the problem turns out to be a confluence of issues:

• The site is hosted on a Windows+IIS server, a rare platform for WordPress (and even more so for BuddyPress) and one that probably doesn’t receive full attention during quality assurance testing.
• How WordPress performs redirects on IIS is a bit quirky. BuddyPress issues a lot of redirects so this redirect quirk comes into play quite often. The issue is that when WordPress needs to perform a redirect on IIS it returns a “refresh” header pointing to the new page rather than a “location” header.
• IE’s attempt to make the Internet more friendly; specifically IE’s use of “friendly error pages.” These friendly error pages replace the content delivered by the server (if that content falls below a certain size in KB).

Normally none of these issue are a problem by themselves and a web browser (including IE) will load the page indicated by the redirect. However, all three of the above issues taken together result in a situation where IE never sees the header refresh and so doesn’t redirect the user to the correct location.

The fix is fairly simple: change the headers that WordPress sends to include the standard “location” header. To do this you modify wordpress/wp-includes/pluggable.php@wp_redirect() so that it reads as follows (line 14 is new):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

function wp_redirect($location, $status = 302) {
	global $is_IIS;
 
	$location = apply_filters('wp_redirect', $location, $status);
	$status = apply_filters('wp_redirect_status', $status, $location);
 
	if ( !$location ) // allows the wp_redirect filter to cancel a redirect
		return false;
 
	$location = wp_sanitize_redirect($location);
 
	if ( $is_IIS ) {
		header("Refresh: 0;url=$location");
		header("Location: $location", true, $status);
	} else {
		if ( php_sapi_name() != 'cgi-fcgi' )
			status_header($status); // This causes problems on IIS and some FastCGI setups
		header("Location: $location", true, $status);
	}
}

Luckily, one of the nice things about coding is that you’re often dealing with plain text files. And you are typically searching for a particular string. As they say, there’s an app for that. Both *nix and Windows are capable of searching through the contents an entire hierarchy of files using command-line programs. Each OS has a variety of commands that can do the job, but I’ll highlight the two I use most often here.

In Windows you would use findstr.exe, and it’s as simple as running the following from the containing directory:

findstr.exe /MIS "searchtext" filetype

On *nix systems the grep command is your friend:

grep -lr "searchtext" filetype

Of course, a quick google search will get you all the help you need in refining your search.

Thanks, Windows, that’s helpful. I had no idea what was happening, especially since I was logged in as an administrator with full control of the file.

As usual, the web was my friend in solving the problem. Windows 2003 Server has a security feature where executables copied from remote systems are blocked for execution unless allowed by an administrator. The feature appears to have been present for a while (since SP2?), but I don’t recall running into it before. As mentioned above, the file in my case was copied from my workstation over SMB; I don’t know if other transfer methods are also affected. I don’t have a problem with the feature, but I do have a problem with how it’s implemented. An indication in the pop-up of why the file could not be accessed would have resulted in a resolution of seconds not … er … minutes.

The resolution is simple enough, go into the properties for the file and you’ll see at the bottom a security warning and a button that allows you to unblock the file.

Click the “Unblock” button and you can execute the file as you normally would.

References:

• Windows 2003: problem with running exe files | Blinded by the lights
• “Windows cannot access the specified device, path, or file” thread from the chicagotech.net forums

I recently noticed the following alert in the system log:

ALERT – configured POST variable limit exceeded – dropped variable ‘included_packet_ids[]‘ (attacker USER_IP_ADDRESS, file REPORT_FILTERING_PAGE)

One of the reasons I use POST variables on this page is to avoid the relatively small data size limit of GET. Suhosin adds additional limits, including in the number of times you can reference an individual variable.  Our limit was set at 1000, meaning there were over 1000 packets selected. This points to a need to adjust how the filter “selects all” … but for now I’ve adjusted the suhosin limit upward by modifying the suhosin.post.max_vars setting.

References:

• ALERT – configured POST variable limit exceeded ::Suhosin configuration blocks script | Tudor Barbu’s professional blog

ALERT – script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker SERVER_IP_ADDRESS, file WP_MAIN_ADMIN_PAGE, line 96)

The source of the issue is WordPress. The application is trying to raise the memory limit and suhosin won’t let it. Apparently WordPress will try to set a 256MB memory limit before executing certain functions. The necessity of adjusting this setting seems questionable to me, but I also understand that it’s often better to play it safe when developing software for public consumption.

I don’t particularly like applications attempting to specify their own resource usage in a web environment. In my mind applications should specify a required/recommended memory limit in the system requirements and stay away from adjusting this setting behind-the-scenes. Tell me during setup if the current setting may result in non-optimal performance or even a halt in script execution. That’s not how it’s done here, but really no harm is done in the long run beyond the annoyance of suhosin throwing errors at the system logs.

There are two easy fixes to the problem:

1. Set the PHP memory limit to 256MB
2. Modify the suhosin.memory_limit parameter to 256MB

In our particular situation it’s just as easy to set the PHP memory limit. There’s always a risk of overloading the physical resources, but this site receives little enough traffic that I’m not concerned about the right confluence of request occurring to cause a crash.

References:

• Mysteries about the WordPress Memory Limit | hakre on wordpress
• Hardened-PHP Project – PHP Security – Configuration

Microsoft doesn’t include mod_rewrite-style functionality in IIS by default, though it has created an extension for IIS7. Since we are currently using IIS6 the extension isn’t an option for us. Fortunately there are a few other options available, including an open-source project called Ionics Isapi Rewrite Filter (IIRF). IIRF is an ISAPI filter that is very similar to mod_rewrite in terms of functionality. After some testing I’ve found this filter works almost perfectly for enabling CakePHP’s friendly URLs.

Getting Started

Installation is painless and requires only a few steps. The following is based on the IIRF 2.0.1.15 release which does not include an installer:

1. Extract the files from the IIRF archive to a folder on the server.
2. Open the properties of the IIS root “Web Sites” folder or the specific site that needs IIRF.
3. In the “ISAPI Filters” tab create a new entry for IIRF; name the new filter (e.g. “IIRF”); specify the IIRF DLL located with the extracted IIRF files at \bin\IIRF.dll.
4. Ensure that the IIS user has read/execute access to the IIRF DLL and read/write access to any directories that will be used for logging.
5. Restart IIRF.

IIRF should now be installed, but I’ve found that sometimes the filter won’t appear to be active in the “ISAPI Filters” tab until it has been used the first time. To enable IIRF all you have to do is create a file called IIRF.ini and place it in the web site root folder or in the root of a virtual directory. This file contains any local configuration directives (such as log directory) and URL rewriting rules.

The obligatory gotcha

I mentioned before that the filter works almost perfectly. The only situation where I’ve had problems up to now is if the URL contains one or more space characters. The IIRF log indicates that a URL with a space is being parsed correctly and returning a valid URL. And yet the web server reports a 404 error.

I’ve only done testing when the final URL references a physical file, but based on a conversation in the support forum I suspect this problem also affects parameters in the querystring. I haven’t yet had a chance to fully investigate the issue, so I don’t have a work-around yet when the issue affects physical files. There does, however, appear to be a work-around for spaces in the querystring.

For now I have decided to ensure that any URLs parsed by IIRF that will point to a physical file/directory does not contain spaces.

References

CakePHP usage:

• CakePHP, IIRF REQUEST_FILENAME problem
• Sample IIRF.ini for CakePHP  installation

Space-in-URL problems:

• Url rewrite and whitespaces
• Space character in URL: rewrite appears correct, 404 returned

When our code is maintained in a subversion repository there are two options for including third-party code: externals and vendor branches.

Externals

For third-party code that will require little modification an externals property definition is preferred. Subversion externals are pointers to subversion sources outside the current path (either within the current repository or that are stored in entirely different repositories). Whenever a copy of our own project is checked out from the repository the third-party code is also checked out. One benefit of this approach is that a local copy of the third-party code does not have to be maintained. If an update to third-party code is available you only need to update the externals reference to the third-party repository.

For example, we want to add an externals definition for FCKEditor to our project. For the sake of this example we’ll use the 2.6.4-tagged version of FCKEditor and we’ll link this to the /includes/fckeditor path of our project. The steps are as follows:

1. Ensure that /includes/fckeditor does not exist;
2. From the root of the working copy of the project run the following command:

   svn propset svn:externals 'fckeditor http://svn.fckeditor.net/FCKeditor/tags/2.6.4' includes

3. Update the local working copy of the project

That’s all there is to it.

When using externals I recommend that we only point to stable (tagged) versions of third-party projects. By pointing to a stable version we can test for bugs and for compatibility between our code and the third-party code prior to implementing updates on our own systems.

Vendor Branches

Vendor branches are locally-maintained copies of third-party code. Vendor branches are treated much like any project developed in-house. Using vendor branches is less desirable mainly due to the extra work required to update the code in the repository when significant additions and deletions have been made by the third-party. However, it is advisable to use a vendor branch when third-party code will require significant modification in order to be useful in own project.

To set up a vendor branch, first create a new project in the subversion repository as described in the post Using Subversion for Application Development and Deployment. Note that it is standard to place vendor branches in a subdirectory of the “/vendor” directory of the repository. Once this is done we can tag stable versions and create branches just as we do with any other project in the repository. To add the vendor branch to another project within our repository I would recommend using an externals link much as we would for any third-party code. This should ease maintenance as the code is updated.

When third-party code is updated there are two methods you can use to update the vendor branch. The first method is best used when there are only a few files added to or removed from the third-party code. In this situation you can manually update a working copy of the trunk with the new release and commit the modifications. Any in-house changes to the code will have to be re-created (either by editing the code again or merging with an older branch).

When a significant number of file changes have been made to the third-party code it’s easiest to use svn_load_dirs.pl. This file will perform all the operations of adding, removing, and updating the files in the repository. And with the -t option you can automatically create a tagged (stable) version. For example, to update a vendor branch of the Yahoo! UI Library to version 2.6.0 you would issue the following command:

svn_load_dirs.pl -t tags/2.6.0 svn+ssh://svnrepo/vendor/yui trunk /src/yui-2_6_0

There are four parts to this command:

• -t tags/2.6.0 : creates a tagged version of the imported code
• svn+ssh://svnrepo/vendor/yui : the location of the vendor branch
• trunk : the subdirectory of the vendor branch where the updated code should be imported
• /src/yui-2_6_0 : the path to the updated YUI library code downloaded from the YUI site

Once you’ve executed this command you would continue with modification of the vendor branch just as you would if you had updated it manually.

Wrap-up

Working with both externals and vendor branches should ease the process of integrating third-party code. For more detailed information on these topics see the documentation from the SVN book.

• Version Control with Subversion: Externals Definitions
• Version Control with Subversion: Vendor Branches

I updated the log format for flora.p2061.org (but not the other sites on flora). Some information is not included in the default “combined” format that could help with debugging (such as user cookies). I set up a new format that is similar to the IIS W3C extended format. Two values not included that could prove useful are bytes received (%I) and bytes sent (%O). The logio_module has to be enabled to record this information. It would probably be worthwhile to add this functionality once we start placing more public content on the server. For now the following format suffices:

#Fields: date    time    c-ip    cs-host    cs-version    cs-method    cs-uri-stem    cs-uri-query    cs(Referer)    cs(User-Agent)    cs(Cookie)    sc-status    time-taken
LogFormat "%{%Y-%m-%d    %H:%M:%S}t    %h    %V    %H    %m    %U    %q    %{Referer}i    %{User-Agent}i    %{Cookie}i    %>s    %D" webapp

PHP is ideal for a task such as this: parsing directories and subdirectories for images is easy; resampling using the built-in library (GD) is a breeze; specifying the destination as a subdirectory is simple. The one minus was processor usage. Performing image manipulation eats up the CPU in a big way.

Luckily linux systems have a built-in utility for addressing a situation like this: nice. nice will “run a program with modified scheduling priority.” I’m running the image manipulation script using the following command:

nice --adjustment=19 php script.php

If nothing else is going on the script will use whatever resources are available. When anything with a higher priority executes, that program will take precedence over the script with regard to system resources. The script should thus not affect the responsiveness of the web server. This is the reason I was searching for this kind of functionality.

Workflow

Since we’re not using an IDE that has integrated subversion capability, and because I wanted to keep the process as simple as possible, I decided to try a combined approach to development. A working copy of project files are checked out from subversion to the development server. Dreamweaver uses the working copy for its remote. Code development will continue as usual in Dreamweaver. When a development milestone is reached the changes are committed to subversion. When the project is ready for deployment, we use tagging to mark a stable copy in the repository and check it out to the production server.

The main problem I’ve found with this setup right now is that there is no way to hide the subversion structure from Dreamweaver. Subversion creates a directory to house control files for each directory in the working copy. The subversion control directories can be cloaked, allowing Dreamweaver to function as if these directories don’t exist, but this is not as feasible for a project with lots of directories.

I found an extension that can automatically cloak any subversion directories, but it only works for the local copy. So if you’re willing to go through the process of downloading the entire site you can use the extension to cloak all subversion directories automatically. Read about the extension on Adobe Exchange; I’ve saved a copy of the extension on the techlog.

I have set up subversion to ignore the typical Dreamweaver development files (lock files, notes, backups). This allows the benefits of using the Dreamwever environment to its fullest without mucking up the subversion repository with unnecessary data.

We should also implement configuration options in a single file that is not part of the project files. We would still want to provide a sample configuration file, but the actual configuration file should be created during initial deployment by copying the sample and modifying the parameters. Using a sample file instead of actual configuration in the repository will allow us to upgrade the production server without having to worry about overwriting local settings. Overwriting the configuration is actually not much of a concern so long as the configuration file is not updated in the repository. But implementing this kind of setup does give us a little more security in that regard.

Subversion setup

First step in the process is to create a subversion repository. We’ll create this on the production server because we can see the production server from the development server, but not vice versa. To set up the subversion repository in /inet/svn, run the following command on the production server:

svnadmin create /inet/svn

Next we’ll populate the repository with a project. Since we’re just getting started with subversion we’ll utilize a well-known repository layout: project, project/branches, project/tags, project/trunk. Create the directory structure on the development server and place the current development files in project/trunk. There are a number of ways to access a subversion server, but for now we’ll use file-based access over ssh. If I create the project directory in /tmp, I would run the following command to import the project:

svn import /tmp/benchmarks svn+ssh://production.server/inet/svn

Working with project files

Now that we have the data in the repository we need to set up a working copy for Dreamweaver. First change to the directory where you want to store the working copy. Then run the following command to check out a working copy:

svn checkout svn+ssh://production.server/inet/svn/benchmarks/trunk .

Set up this directory as your remote in Dreamweaver and edit as usual.

At some point in the future you’ll want to record the changes in the subversion repository. This can be at any time in the development process, but at the very least it’ll need to be done when a project has reached a stable state and is ready for deployment. Run the following command from the working copy directory:

svn commit

Once the project has reached a stable state we need to have a way of maintaining that stable copy in the face of future modifications. This is where the branches/tags/trunk structure really comes in handy. The in-development files are always in /trunk. To create a stable release we merely need to create a copy in the /tags directory (where ver.no is the version number, such as 1.0):

svn copy svn+ssh://production.server/inet/svn/benchmarks/trunk svn+ssh://production.server/inet/svn/benchmarks/tags/ver.no

Deploy the project

Whether we’re talking about a home-brewed application or one from an external organization, the steps for deployment are the same. Check out a working copy or export a clean copy to the appropriate directory on the production server. I prefer to check out a working copy because it enables greater flexibility in deployment. If we need to modify a file in the production environment, a working copy enables non-destructive upgrades in the future. Only the files that have been modified in the repository will be updated during a version upgrade. Any conflicting updates will be noted by the subversion client so that they can be addressed. (Of course, this is only really a benefit if significant modifications have not been made to the project between versions.)

Updating a working copy to a new version is as simple as the following command (executed from the working copy directory):

svn switch repository_address .

Belt and suspenders

To avoid loss of our subversion repository we should consider creating a copy on our development server. This would only be used to restore the subversion repository in case of loss or corruption. This can be done using the svnsync command and should be done automatically (via cron). This may not be a necessity as much as a convenience, however, since the repository should be included in the nightly backup.

General Reading

What I attempted to provide here was the core commands needed to get started. There’s a lot more to working with subversion than what I covered and I would recommend .

• Version Control with Subversion (all you need to know)
• Tracking PeopleAggregator releases with Subversion vendor branches
• Subversion Vendor Branches Howto
• Vendor Branches in Subversion

I found the vendor branch concept a bit confusing; so a few extra links for that.