I have a client who has many blog customers. Each of these WordPress blogs calls a plugin that provides a product link. The way that link is composed looks like this:
{website}/wp-content/plugins/prodx/product?id=432320
This works fine on all blogs except two. On those two, when you try to call the URL, you get a 404.
So, I disabled all plugins except prodx and reverted the theme to default (Kubrick), thinking perhaps a plugin intercept with add_action() API was doing this, such as intercepting URLs and redirecting them. However, this did not help.
So, I upgraded the WordPress to the latest version. Again, didn't fix.
So, I checked permissions, comparing with a blog that worked just fine. Again, didn't fix.
So I replaced the .htaccess, using one from a working blog. Again, didn't fix.
So I replaced all the files using some from a working blog that was identical to this one, and then restored the wp-config.php file back so that it talked to the right blog database. Again, didn't fix.
Again I checked permissions meticulously, comparing to a perfectly working blog. Again, didn't fix.
So, I created a test.php that looks like so:
<?php
print_r($_GET);
echo "hello world";
I then copied it into another plugin folder and used my browser to get to it -- again, 404. So I copied it into the root of wp-content/plugins and tried to call it there -- again, 404. So I copied it into wp-content -- again, 404. Last, I copied it into the root of the WordPress blog website, and this time, it worked!
Doesn't make sense.
I started to think that perhaps something was going on with /etc/httpd/conf/httpd.conf for this customer, but the only thing I saw different in their开发者_高级运维 for this customer was the IP address was different than the customer's blog that worked. Each customer gets their own IP in this environment my client has built.
My client sysop is baffled too.
What do you think is going on? Is there something wrong in the WP database for this customer? Is there something wrong in httpd.conf?
You could check for bad URLs in plugins' options in the WP options table using phpmyadmin (and compare other aspects of each blogs' options) which might be already available at your host, or as a plugin: WordPress › Portable phpMyAdmin « WordPress Plugins. Or delete the plugins' options with Clean Options to completely "reset" the plugin (if the plugin uses options): Clean Options « WordPress Plugins
You should look into your server's error log, there should be an explanation. If not, turn up debugging levels etc. That said, the plugin really shouldn't link to the file in the plugin dir, it should use the wordpress rewrite class http://codex.wordpress.org/Function_Reference/WP_Rewrite
I think the problem was that the URL was too long. Here's some great info about that:
http://www.boutell.com/newfaq/misc/urllength.html
And for some reason the blog was getting a 404 instead of a 413.
The fix was that I used gzcompress to shorten my long product ID (which was a cloaked URL), then bin2hex. So I made the URL like so:
http://myblog.com/item/789ccb282929b0d2d72f2f2fd7cb4ac92fcc4faed44bcecfd54fcec94cced63536373334b730d7353430333334b530b60f0df2b1cd00ea503576543572032290befcb2d4a2e292fce46c904e90b0b15b1a50854b9aaa915980a3bb2b901910e4ef12ea1c0214f00f0ef60e058a181a199b5b18999b0100194725b4
From there, I had my plugin add an init handler to hijack the URL, inspect it, and redirect. That function looks like this:
add_action('init','hijackURL');
function hijack_URL() {
$sURL = $_SERVER['REDIRECT_URL'];
if (empty($sURL)) {
$sURL = $_SERVER['REQUEST_URI'];
}
if (strpos(' ' . $sURL, '/item/')>0) {
$sID = str_replace('/item/','',$sURL);
$sID = trim($sID);
if (empty($sID)) {
require('../../../wp-blog-header.php');
$sBlogURL = get_bloginfo('wpurl');
header('HTTP/1.1 302 Moved Temporarily');
header("Location: $sBlogURL");
exit(0);
}
$sID = pack('H*', $sID);
$sURL = gzuncompress($sID);
header('HTTP/1.1 302 Moved Temporarily');
header("Location: $sURL");
exit(0);
}
}
精彩评论