HTMLCenter Web Development Blog » PHP Tutorials

Zeus and WordPress Part 3: SSL Issues

Curtiss — Sat, 04 Feb 2012 02:56:03 +0000

While working to get WordPress functioning properly on a Zeus Web server, one of the issues I came across was the fact that I couldn’t seem to get any SSL functions working properly. I tried 2 or 3 different plugins, and all of them started causing infinite redirect loops as soon as they were activated.

Eventually, after quite a bit of investigating and testing, I found the cause of the issue: that particular server (and, presumably, all Zeus servers) doesn’t use any of the same indicators that SSL is being used that apache does. On apache servers, PHP usually has a handful of indicators that SSL is currently being used to serve the page. For instance, there’s a server global variable called “HTTPS” that gets set to “on” for many PHP configurations; SSL is generally served over port 443 instead of port 80; etc.

The WordPress HTTPS plugin runs four different checks to see if SSL is running, but all of them fail on Zeus. Following is the check that WordPress HTTPS runs:

public function is_ssl() {
    $https_url = parse_url($this->https_url);
    // Some extra checks for proxies and Shared SSL
    if ( is_ssl() && strpos($_SERVER['HTTP_HOST'], $https_url['host']) === false && $_SERVER['SERVER_ADDR'] != $_SERVER['HTTP_HOST'] ) {
        return false;
    } else if ( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && strtolower($_SERVER['HTTP_X_FORWARDED_PROTO']) == 'https' ) {
        return true;
    } else if ( $this->diff_host && !is_ssl() && isset($_SERVER['HTTP_X_FORWARDED_SERVER']) && strpos($this->https_url, 'https://' . $_SERVER['HTTP_X_FORWARDED_SERVER']) !== false ) {
        return true;
    } else if ( $this->diff_host && !is_ssl() && strpos($_SERVER['HTTP_HOST'], $https_url['host']) !== false && (!$this->ssl_port || $_SERVER['SERVER_PORT'] == $this->ssl_port) && (isset($https_url['path']) && !$https_url['path'] || strpos($_SERVER['REQUEST_URI'], $https_url['path']) !== false) ) {
        return true;
    }
    return is_ssl();
}

Like I said, at least on the Zeus server I was dealing with, all four of those checks failed, so it kept reporting that the page wasn’t running over SSL, so it caused an infinite redirect loop.

After a while, I did find a variable (actually, 3 of them) that, while it doesn’t seem to have any consistent value, always seems to be set when running SSL, and never seems to exist when running without SSL. That variable is the $_SERVER['HTTP_SSLCLIENTCERTSTATUS'] variable. Checking for the existence of that variable seems to consistently report whether or not SSL is running for the page.

For my purposes, I ended up editing a plugin called WPSSL (simply because it was simpler than making sure I’d edited all of the correct places within WordPress HTTPS) to check the existence of that variable.

Have you come across this same issue on a Zeus server? Is this common, or is this an issue unique to the particular host that’s being used for this project?

Zeus and WordPress Part 2: Fixing Query Strings

Curtiss — Sat, 28 Jan 2012 02:44:51 +0000

If you’re trying to get WordPress working on a Zeus Web server, and you’ve gotten as far as using a good rewrite script to make permalinks work properly, you might have noticed that query strings don’t work at the ends of your permalinks. At first, it seemed like this wouldn’t be too big of an issue; it just meant that users wouldn’t be able to preview posts/pages, and there would be one or two other issues they’d have to live with. However, after using the site that way for a little while, we started coming across more and more issues that this caused, and it finally reached a tipping point.

To solve the issue, I wrote a simple function that runs any time a 404 error occurs on the site. Essentially, it parses the path of the requested page, cuts off the query string temporarily, and then searches the database for a post or page that has the slug at the end of the path.

You may be wondering why I didn’t just parse the request/get variables sent with the page. The problem is, those were empty in each of the cases I tested.

Anyway, following is the function I ended up writing.

function zeus_reply_fix() {
	if ( ! isset( $_SERVER['PATH_INFO'] ) ) {
		return;
	}
	if ( ! is_404() ) {
		return;
	}

	$path = $_SERVER['PATH_INFO'];
	$parts = explode( '/', $path );
	$qs = array_pop( $parts );
	$parsed = array();
	if ( strstr( $qs, '&' ) || strstr( $qs, '?' ) ) {
		parse_str( $qs, $parsed );
	} else {
		return;
	}
	if ( is_array( $parsed ) ) {
		global $wpdb, $post, $wp_query;
		$post_ID = $wpdb->get_var( $wpdb->prepare( "SELECT ID FROM {$wpdb->posts} WHERE post_name=%s", array_pop( $parts ) ) );

		if ( empty( $post_ID ) ) {
			return;
		}

		$wp_query = new WP_Query( array( 'page_id' => $post_ID ) );
		$wp_query->is_404 = false;
		foreach ( $parsed as $k=>$v ) {
			if ( ! empty( $k ) && ! empty( $v ) )
				set_query_var( $k, $v );
		}

		$_GET = $_GET + $parsed;

		$use_template = 'index.php';
		$post = $wp_query->get_queried_object();

		load_template( trailingslashit( get_template_directory() ) . $use_template );
		die();
	}
}
add_action( 'wp', 'zeus_reply_fix', 99 );

Have you found a better way of dealing with this issue? Do you see anything that could be done better? I’d love to see other solutions to this particular problem with Zeus & WordPress.

WordPress and Zeus Part 1: Getting Permalinks Working

Curtiss — Sat, 21 Jan 2012 02:31:00 +0000

For those of you that might not know (and I was one of you about a month ago), Zeus is a Web server package that’s used instead of apache by some Web hosts. If you’re planning to use WordPress, and you have a choice between apache and Zeus, I would definitely recommend choosing apache. However, sometimes you don’t have a choice in the matter; and you have to do what you can to make things work.

WordPress will work out of the box with Zeus, but a lot of things won’t behave the way you might expect. One of those things is the permalink structure.

Instead of getting nice, clean URLs like “http://example.com/blog/2012/01/my-first-blog-post/”, you get “index.php” shoved in there (like “http://example.com/index.php/blog/2012/01/my-first-blog-post/”). You can correct this issue, but it’s not quite as simple as updating an .htaccess file (in fact, without some jiggery-pokery by your Web host, Zeus doesn’t support .htaccess at all). Instead, you have to apply a rewrite script to your server configuration.

After quite a bit of searching and trial & error, I finally found a working rewrite script configuration for WordPress. A hosting company called ZipHosting posted the scripts below in their knowledgebase. The first script is set up for you to use if WordPress is hosted in a subdirectory, and the second is for use with WordPress in the root directory.

WordPress in a Subdirectory

RULE_0_START:
    # Get the document root path and put value into the SCRATCH array.
    # This is the server path not the web URL.
    # i.e. /clientdata/clients/p/h/php.testing.au.com/www/

map path into SCRATCH:DOCROOT from /

    # Get the URL without the domain.
    # e.g. /test&colour=red
    # e.g. /an-example-post/?color=red

 set SCRATCH:ORIG_URL = %{URL}
 set SCRATCH:REQUEST_URI = %{URL}

    # See if there are any queries in our URL.

 match URL into $ with ^(.*)\?(.*)$

    # If there are...

 if matched then
    # Set a var to path without the domain part.
    # e.g. /an-example-post

     set SCRATCH:REQUEST_URI = $1

    # Set a var to the passed queries.
    # e.g. colour=red

     set SCRATCH:QUERY_STRING = $2
 endif
 RULE_0_END:

RULE_1_START:
    # This is setting a var to the server path and sub folders.
    # e.g. /clientdata/clients/p/h/php.testing.au.com/www/wordpress/an-example-post/

 set SCRATCH:REQUEST_FILENAME = %{SCRATCH:DOCROOT}
 set SCRATCH:REQUEST_FILENAME . %{SCRATCH:REQUEST_URI}

    # Check to see if the file exists.

 look for file at %{SCRATCH:REQUEST_FILENAME}
 if not exists then

    # The file wasn't found so is it a folder?

     look for dir at %{SCRATCH:REQUEST_FILENAME}
     if not exists then

    # No folder either. So now check the URL for special hosting folders.

         match SCRATCH:ORIG_URL into % with ^/stats|^/logs
         if matched then

    # If a special folder was requested end the script.

             goto END
         else

    # There were no files, folders or special folders so set the new URL.
    # -- Sub directory -------------------------------------------------------------
    # If the blog is in a sub directory...replace the words in bold  with your directory name.
    # e.g. /wordpress/index.php/an-example-post

             match SCRATCH:REQUEST_URI into $ with ^/wordpress(.*)
             if matched then
                 set URL = /wordpress/index.php$1
             endif

    # -- Sub directory ends --------------------------------------------------------
    # or...
    # -- Top level -----------------------------------------------------------------
    # If the blog is in the top level of the site...
    # e.g. /index.php/an-example-post
    # set URL = /index.php%{SCRATCH:REQUEST_URI}
    # -- Top level ends ------------------------------------------------------------
    # Go to the next rule.

             goto RULE_2_START
         endif
     endif
 endif

    # If files or folders were found end the rewrite script.

 goto END
 RULE_1_END:

RULE_2_START:

    # Check for queries in the requested URL.

 match SCRATCH:ORIG_URL into % with \?(.*)$
 if matched then

    # If queries were found add them to the new URL.
    # e.g. /index.php/an-example-post/&colour=red

     set URL = %{URL}&%{SCRATCH:QUERY_STRING}

 endif

    # -- Sub directory -------------------------------------------------------------
    # If you only want to rewrite the sub directory uncomment this bit.
      match SCRATCH:ORIG_URL into % with ^/wordpress
 if matched then
    # -- Sub directory ends --------------------------------------------------------

    # End the script.

     goto END

    # -- Sub directory -------------------------------------------------------------
 endif
    # -- Sub directory ends --------------------------------------------------------
 RULE_2_END:

WordPress Installed in the Root Directory

RULE_0_START:
    # Get the document root path and put value into the SCRATCH array.
    # This is the server path not the web URL.
    # i.e. /clientdata/clients/p/h/php.testing.au.com/www/

map path into SCRATCH:DOCROOT from /

    # Get the URL without the domain.
    # e.g. /test&colour=red
    # e.g. /an-example-post/?color=red

 set SCRATCH:ORIG_URL = %{URL}
 set SCRATCH:REQUEST_URI = %{URL}

    # See if there are any queries in our URL.

 match URL into $ with ^(.*)\?(.*)$

    # If there are...

 if matched then
    # Set a var to path without the domain part.
    # e.g. /an-example-post

     set SCRATCH:REQUEST_URI = $1

    # Set a var to the passed queries.
    # e.g. colour=red

     set SCRATCH:QUERY_STRING = $2
 endif
 RULE_0_END:

RULE_1_START:
    # This is setting a var to the server path and sub folders.
    # e.g. /clientdata/clients/p/h/php.testing.au.com/www/wordpress/an-example-post/

 set SCRATCH:REQUEST_FILENAME = %{SCRATCH:DOCROOT}
 set SCRATCH:REQUEST_FILENAME . %{SCRATCH:REQUEST_URI}

    # Check to see if the file exists.

 look for file at %{SCRATCH:REQUEST_FILENAME}
 if not exists then

    # The file wasn't found so is it a folder?

     look for dir at %{SCRATCH:REQUEST_FILENAME}
     if not exists then

    # No folder either. So now check the URL for special hosting folders.

         match SCRATCH:ORIG_URL into % with ^/stats|^/logs
         if matched then

    # If a special folder was requested end the script.

             goto END
         else

    # There were no files, folders or special folders so set the new URL.
    # -- Sub directory -------------------------------------------------------------
    # If the blog is in a sub directory...replace the words in bold  with your directory name.
    # e.g. /wordpress/index.php/an-example-post

    # match SCRATCH:REQUEST_URI into $ with ^/wordpress(.*)
    # if matched then
    #     set URL = /wordpress/index.php$1
    # endif

    # -- Sub directory ends --------------------------------------------------------
    # or...
    # -- Top level -----------------------------------------------------------------
    # If the blog is in the top level of the site...
    # e.g. /index.php/an-example-post
     set URL = /index.php%{SCRATCH:REQUEST_URI}
    # -- Top level ends ------------------------------------------------------------
    # Go to the next rule.

             goto RULE_2_START
         endif
     endif
 endif

    # If files or folders were found end the rewrite script.

 goto END
 RULE_1_END:

RULE_2_START:

    # Check for queries in the requested URL.

 match SCRATCH:ORIG_URL into % with \?(.*)$
 if matched then

    # If queries were found add them to the new URL.
    # e.g. /index.php/an-example-post/&colour=red

     set URL = %{URL}&%{SCRATCH:QUERY_STRING}

 endif

    # -- Sub directory -------------------------------------------------------------
     # If you only want to rewrite the sub directory uncomment this bit.
    # match SCRATCH:ORIG_URL into % with ^/wordpress
 if matched then
    # -- Sub directory ends --------------------------------------------------------

    # End the script.

     goto END

    # -- Sub directory -------------------------------------------------------------
 endif
    # -- Sub directory ends --------------------------------------------------------
 RULE_2_END:

Unfortunately, that won’t solve all of your permalink issues, but it will get you started. One serious issue you might encounter is the fact that query strings aren’t recognized at the end of your permalinks; instead, WordPress shows a 404 error page whenever a query string is attached. In my next article, I’ll explain how I fixed that issue.

Upcoming Panel on The Future of PHP

Allen — Thu, 10 Nov 2011 00:32:34 +0000

On November 17, Engine Yard will host a discussion around the future of PHP. Engine Yard describes the event, “If you are a PHP developer using PEAR and Pyrus, we invite you to join us this week as we explore the future of PEAR and Pyrus. We’ll be discussing issues such as where PEAR/Pyrus will be going in the next few years, what obstacles may be on the horizon, and how they’re going to get where they’re going.”

One of the panelists is Till Klampäckel who many of you know as one of the people who worked with HTMLCenter for many years. Till also just published a book (in German) about the database service CouchDB which you can purchase on Amazon.de.

The panel is free, will be streamed live and the panel will take questions via Twitter. If you are interested, you can register for the event here.

WordPress: A Tip About WP Super Cache

Curtiss — Wed, 12 Oct 2011 19:11:30 +0000

First of all, let me apologize for having been so absent over the last few weeks. As you may or may not have heard already, we just launched the new website at University of Mary Washington, and things have been hectic trying to put the final pieces into place.

One of those final pieces was to get WP Super Cache up and running on the site, in order to keep our server from overloading. When we first launched, I didn’t realize that we didn’t have the plugin configured properly, and our various plugins and theme functions really started to drag things to a crawl.

After doing a lot of digging and debugging, I found that WP Super Cache was ignoring cached files throughout our server because they all included GET variables.

The next step was to find out what GET variable(s) was/were causing the problem, so I headed on over to our development server and threw in some debug code to output the contents of $_GET in the footer of every page. It turned out that the code I’d created to implement the Google Custom Search Engine on our site was setting a default choice for which search engine to use, and was setting that default choice as a GET var. I fixed that minor issue and WP Super Cache started working like a champ.

Within Google’s Webmaster Tools, I ran a test on the production server to see how long it took Google to retrieve our home page before and after I made this tiny little change. Before (when pages were not being cached properly), it took approximately 4,400 milliseconds (that’s over 4 seconds) for Google to retrieve the home page. After the change (with pages being cached properly now), it took 97 milliseconds to retrieve the page (that’s less than one-tenth of a second). That’s a ~98% reduction in the amount of time it takes to serve the pages.

Conclusion

So, if you’re using WP Super Cache on your WordPress site, you should do the following things:

Use the Cache Tester that’s built into the “Simple” tab on the WP Super Cache options page to make sure your page is being cached properly.
If you find that it’s not, enable the Debug option (in the “Debug” tab on the WP Super Cache options page) to see if you can find out why it’s not being cached.
If you see anything about WP Super Cache exiting because of a GET variable, use a script to dump your $_GET array into your pages somewhere (I hooked into the wp_print_footer_scripts action, since that way I could make sure I’d already run through just about everything there was to run through), and see what turns up. Hopefully you’ll recognize the GET var that’s being set, and be able to figure out where to change it.

Also, since we’re using Analytics to track cross-domain requests, I made some changes to the way those requests are tracked; but I will post about that in another post.

Setting up WordPress MU Domain Mapping on GoDaddy

Curtiss — Tue, 20 Sep 2011 18:37:51 +0000

I recently worked with a client to help move a GoDaddy “WebsiteTonight” website into WordPress. In the process, I recommended that she turn her existing WordPress website into a multisite installation, set up her second site as another site in that install, and then set up domain mapping to give each of the websites a separate domain name.

This setup allows her to login a single time, and be able to switch back and forth between the sites to perform edits. It also makes it simpler to manage plugins, update WordPress and keep the theme consistent between the two sites.

The problem was, the website is hosted on GoDaddy. After searching Bing for a while to see what the potential problems might be, and to see what solutions other people had found, I started to get a little worried. A lot of articles indicated that they’d had to purchase a dedicated IP from GoDaddy, some even said they’d completely failed to get it set up properly.

As it turned out, though, I was worried for nothing, really. It was a frustrating process, simply because of how unfriendly GoDaddy’s account control panel is; but it was basically straight-forward.

To get WordPress MU Domain Mapping set up, I first went through the steps to convert the original installation into multisite. Then, I followed these steps (filtered a bit to leave out the steps that were unsuccessful or had no impact):

Set up the new site in WordPress.
Imported all of the content for the new site.
Made sure that everything was working fine on the new site.
Installed the WordPress MU Domain Mapping plugin using the plugin installer built into WordPress.
Copied sunrise.php from the plugin’s folder into my wp-content directory.
Went to Settings -> Domain Mapping in the Network admin area for WordPress; entered the IP address of the host server (I found out that this setting doesn’t really do anything, so don’t be afraid to fill it out – you can even put random numbers there if you want – the setting is strictly used to show site administrators what the IP address should be when they use their hosting control panel to map the domain). I also chose the options “User domain mapping page” and “Redirect administration pages to site’s original domain (remote login disabled if this redirect is disabled)” and unchecked all of the others.
Went to Tools -> Domain Mapping in the Admin area for the new WordPress site and added the domain name that I wanted to map. I did not set it as Primary, yet, as I wanted to make sure the old address worked until I actually had the domain mapped properly. Setting up the domain before I mapped it, though, helped to make sure it did map properly once the DNS settings propagated.
Went into the GoDaddy account control panel (My Account -> My Products).
Followed the steps to associate a different domain name with the Website Tonight website (in this client’s case, they owned 5 domain names that were all similar, 4 of which were not being used for anything, so I was able to assign one of those to the WT site). I needed to perform this step, because GoDaddy wouldn’t let me complete step 12 until this was done.
After waiting a few hours for all of GoDaddy’s servers to catch on to the fact that I had disassociated the desired domain with WT, I went back to My Products -> Web Hosting in the GD control panel and clicked “Launch” for the account that hosts WordPress.
On that page, opened the Settings tab and clicked on Domain Management.
I clicked the “Add Domain” button in the top right of the domain management screen and entered the domain name that I wanted to map to WordPress. After about 2 or 3 hours of waiting (and, oddly, of the domain name pointing to 3 different places in the process), it finally started pointing to WordPress.
Went back into Tools -> Domain Mapping in the WordPress admin area for the new site and updated the domain so that it would act as the Primary (causing any other domains mapped to that site to redirect to it).

While the first three steps aren’t necessarily part of the setup process for WordPress MU Domain Mapping, you really should make sure they’ve been done before you try to setup the plugin. Otherwise, any issues you encounter will be much harder to diagnose (because you won’t know if the issue is related to WordPress or the plugin).

I am fairly certain that this process used to be a lot more complicated (in the early days, I think it might have even required edits to core WPMU files); but it is extremely simple, now. Since the instructions have changed so drastically over the years, be careful which articles and tutorials you read on the subject.

The plugin does not require any sort of wildcard subdomains to be set up (even when using WordPress Multisite in subdomain-mode, it doesn’t actually require wildcard subdomains; you just need to create each subdomain manually in your host’s DNS settings), nor does it require a dedicated IP address. It really only requires that your host knows where to point each domain name once it’s sent to the DNS.

Some WordPress Gallery Features You Might Not Know About

Curtiss — Fri, 16 Sep 2011 21:56:17 +0000

The other day, I was playing around with the WordPress [

] shortcode, and came across the need to exclude an image that was attached to the page. The image I needed to exclude was kind of like a featured image, and I didn’t want it to appear again in the gallery itself. So, I searched for information about excluding images from the WordPress [

] shortcode, and came across the related WordPress Codex article.

While reading that article, I noticed a handful of features I’d never known about in that particular shortcode. After all, I always basically assumed that the options WordPress gives you when inserting a gallery were probably the only options that were available.

Turns out I was wrong. In addition to the “Order By”, “Columns” and “Links” options that the WordPress interface offers, the [

] shortcode accepts the following extra options:

id – In case you want to show the gallery from a page other than the one you’re currently editing. By default, WordPress simply shows the images that are attached to the current page, but you can override that by providing another page’s ID.
size – Choose from any of the defined (named) image sizes in WordPress. By default, WordPress displays the “thumb” size (which might not be ideal, since that is usually a cropped image).
itemtag – The HTML element that’s used to wrap each item (which includes the image and the caption together) in the gallery. By default, WordPress uses a
tag, making each gallery item a separate definition list.
icontag – The HTML element that’s used to wrap each image inside of the gallery. By default, WordPress makes each image a
captiontag – The HTML element used to wrap each caption in the gallery. By default, WordPress uses
include/exclude – You can provide a comma-separated list of attachment IDs that WordPress should either include explicitly (leaving all others out) or exclude (causing WordPress to use all other items that are attached to the page) in the gallery.

Please Stop Using cURL in WordPress Plugins

Curtiss — Sat, 10 Sep 2011 03:23:07 +0000

Unfortunately, I keep finding WordPress plugins that try to call cURL functions directly. Unfortunately, not only do these plugins fail to work if cURL isn’t installed, it throws a fatal PHP error in the process.

The problem with using cURL in WordPress plugins is that WordPress solved that problem more than 2 years ago by implementing the WP_Http class. WP_Http is a class included in the WordPress core that has multiple options. One of those options is cURL, but it gracefully reverts to other PHP functions if cURL isn’t available.

Basically, anything you can do with cURL can be done with the WP_Http class, and it will allow your plugin to be much more versatile and compatible with more server setups.

Unfortunately, though, it seems that a lot of plugin developers are completely unaware of the class. Each time I find a plugin that requires cURL (one of my servers does not have cURL compiled into PHP), I point them to a great article on the WP_Http class that Ozh wrote back in August 2009, and each one tells me they’ve never heard of WP_Http before.

So, if you are even tangentially connected to a WordPress plugin (or theme) developer, please help shout this from the rooftops. If you are performing any sort of file request in your plugin, please use WP_Http instead of relying entirely on cURL.

WordPress: Adding “Get Shortlink” to Custom Post Types

Curtiss — Fri, 12 Aug 2011 22:29:24 +0000

For some reason, by default, WordPress only includes the “Get Shortlink” button when editing posts; not when editing any kind of custom post type or when editing pages. Honestly, I’m not sure why, since pages and custom post types all use the same basic short URL as standard posts (example.com/?p=[post_id]).

The solution is simple, though. You just need to hook into the get_shortlink filter. Following is a simple function that will help you add the button to all “publicly_queryable” post types in your theme.

if( !function_exists( 'my_theme_cpt_shortlinks' ) ) {
	/**
	 * Allow shortlinks to be retrieved for pages and custom post types
	 */
	function my_theme_cpt_shortlinks( $shortlink, $id, $context, $allow_slugs=true ) {
		/**
		 * If query is the context, we probably shouldn't do anything
		 */
		if( 'query' == $context )
			return $shortlink;

		$post = get_post( $id );
		$post_id = $post->ID;

		/**
		 * If this is a standard post, return the shortlink that was already built
		 */
		if( 'post' == $post->post_type )
			return $shortlink;

		/**
		 * Retrieve the array of publicly_queryable, non-built-in post types
		 */
		$post_types = get_post_types( array( '_builtin' => false, 'publicly_queryable' => true ) );
		if( in_array( $post->post_type, $post_types ) || 'page' == $post->post_type )
			$shortlink = home_url('?p=' . $post->ID);

		return $shortlink;
	}
}
add_filter( 'get_shortlink', 'edui2011_cpt_shortlinks', 10, 4 );

WordPress: Adding “Page Links To” to Custom Post Types

Curtiss — Wed, 10 Aug 2011 05:04:11 +0000

If you use WordPress (especially as a content management system) and you haven’t heard of Mark Jaquith’s “Page Links To” plugin, you should definitely check it out. Basically, the plugin allows you to set up a WordPress page or post to redirect to a different URL. It can be very handy for setting up redirects, adding menu items for pages that wouldn’t normally appear in those menus, etc.

One issue with the plugin, however, is that it does not (as of version 2.4.1) support custom post types. It only supports WordPress posts and pages. If you want to set a custom post type to redirect to a URL other than its permalink, you can’t do so with this plugin.

However, there is a pretty simple way to add support for custom post types to this plugin; and the changes do not require you to edit the plugin itself. Instead, you can make all of the necessary changes in your theme’s functions.php file.

To begin with, you will need to write your own copy of the plugin’s add_meta_box() function and hook it into the do_meta_boxes action. The current version of Page Links To includes the following do_meta_boxes() function:

	/**
	 * Adds the meta box to the post or page edit screen
	 * @param string $page the name of the current page
	 * @param string $context the current context
	 */
	function do_meta_boxes( $page, $context ) {
		if ( ( 'page' === $page || 'post' === $page ) && 'advanced' === $context )
			add_meta_box( 'page-links-to', 'Page Links To', array( &$this, 'meta_box' ), $page, 'advanced', 'low' );
	}

You need to make your own copy of that function, giving it a unique function name (for instance, something like my_theme_add_plt_mb) and add your custom post types in place of “page” and “post” in the new function. That would look something like:

/**
 * Adds the meta box to the post or page edit screen
 * @param string $page the name of the current page
 * @param string $context the current context
 */
function my_theme_add_plt_mb( $page, $context ) {
	if ( ( 'custom_post_type_1' === $page || 'custom_post_type_2' === $page || 'custom_post_type_3' === $page ) && 'advanced' === $context )
		add_meta_box( 'page-links-to', 'Page Links To', array( 'CWS_PageLinksTo', 'meta_box' ), $page, 'advanced', 'low' );
}
if( class_exists( 'CWS_PageLinksTo' ) )
	add_action( 'do_meta_boxes', 'mspan_add_plt_meta_box', 10, 2 );

Next, you will need to tell WordPress to replace the standard permalink for the custom post type with the link specified by Page Links To. To do that, you need to hook into the post_type_link filter. Because Page Links To doesn’t actually instantiate a variable when creating a new CWS_PageLinksTo object, you’ll need to do so before filtering the permalink (otherwise, you’ll get a PHP reference error, because the link method in the CWS_PageLinksTo class calls another method in the same class). Therefore, you should add something like the following to your functions.php file:

if( class_exists( 'CWS_PageLinksTo' ) )
	add_filter( 'post_type_link', 'my_theme_init_plt_obj', 20, 2 );
function my_theme_init_plt_obj( $link, $post ) {
	$tmp = new CWS_PageLinksTo;
	return $tmp->link( $link, $post );
}

The code above hooks the my_theme_init_plt_obj() function into the post_type_link filter. Then, the my_theme_init_plt_obj() function declares a variable and assigns a new CWS_PageLinksTo object to that variable; and finally calls and returns the CWS_PageLinksTo::link() function.

Because the CWS_PageLinksTo::__construct() function adds a handful of hooks, etc.; you should not instantiate the variable any earlier than you need to use it (otherwise, you might end up with 2 Page Links To meta boxes on your post edit screen, or the links might get filtered twice, etc.).