无法调用 wp-content 下的 WordPress 插件文件

发布于 2024-08-31 02:31:11 字数 1042 浏览 7 评论 0原文

我有一个拥有很多博客客户的客户。每个 WordPress 博客都会调用一个提供产品链接的插件。该链接的组成方式如下所示:

{website}/wp-content/plugins/prodx/product?id=432320

这在除两个博客之外的所有博客上都可以正常工作。在这两个上,当你尝试调用 URL 时,你会得到 404。

因此,我禁用了除 prodx 之外的所有插件,并将主题恢复为默认值(Kubrick),认为可能是使用 add_action() API 的插件拦截正在执行此操作,例如例如拦截 URL 并重定向它们。然而,这并没有帮助。

因此,我将 WordPress 升级到了最新版本。又没修好。

因此,我检查了权限,并与运行良好的博客进行了比较。又没修好。

因此,我使用工作博客中的一个替换了 .htaccess。又没修好。

因此,我使用与此相同的工作博客中的一些文件替换了所有文件,然后恢复了 wp-config.php 文件,以便它与正确的博客数据库进行通信。又没修好。

我再次仔细检查权限,与完美运行的博客进行比较。又没修好。

所以,我创建了一个 test.php,如下所示:

<?php

print_r($_GET);
echo "hello world";

然后我将其复制到另一个插件文件夹中,并使用我的浏览器访问它 - 再次,404。所以我将其复制到 wp-content/plugins 的根目录中并尝试在那里调用它 - 再次,404。所以我将其复制到 wp-content - 再次,404。最后,我将它复制到 WordPress 博客网站的根目录中,这一次,它成功了!

没有意义。

我开始认为该客户的 /etc/httpd/conf/httpd.conf 可能出了问题,但我看到该客户的唯一不同之处是 IP 地址与有效的客户博客不同。每个客户在我的客户构建的环境中都获得自己的IP。

我的客户管理员也很困惑。

你认为发生了什么事?该客户的 WP 数据库是否有问题? httpd.conf 有问题吗?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

挽心 2024-09-07 02:31:11

您可以使用 phpmyadmin 检查 WP 选项表中插件选项中的错误 URL(并比较每个博客选项的其他方面),这些 URL 可能已在您的主机上可用,或作为插件使用: WordPress › 便携式 phpMyAdmin « WordPress 插件。或者使用 Clean Options 删除插件选项以完全“重置”插件(如果插件使用选项): 清理选项 « WordPress 插件

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

冷默言语 2024-09-07 02:31:11

您应该查看服务器的错误日志,应该有解释。如果没有,请调高调试级别等。也就是说,插件确实不应该链接到插件目录中的文件,它应该使用 wordpress 重写类 http://codex.wordpress.org/Function_Reference/WP_Rewrite

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

溺孤伤于心 2024-09-07 02:31:11

我认为问题在于 URL 太长。以下是一些关于此的重要信息:

http://www.boutell.com/newfaq/misc /urllength.html

由于某种原因,博客收到了 404 而不是 413。

解决方法是我使用 gzcompress 来缩短我的长产品 ID(这是一个隐藏的 URL),然后使用 bin2hex。 So I made the URL like so:

http://myblog.com/item/789ccb282929b0d2d72f2f2fd7cb4ac92fcc4faed44bcecfd54fcec94cced63536373334b730d7353430333334b530b60f0df2b1cd00ea503576543572032290befcb2d4a2e292fce46c904e90b0b15b1a50854b9aaa915980a3bb2b901910e4ef12ea1c0214f00f0ef60e058a181a199b5b18999b0100194725b4

From there,我让我的插件添加一个初始化处理程序来劫持 URL、检查它并重定向。该函数如下所示:

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);
  }
}

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);
  }
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文