如何在插件开发中始终如一地执行重写规则

时间：2012-03-26 作者：Volomike

假设我创建了一个客户支持插件，该插件劫持了URL的/支持部分，并将其重定向到插件文件夹的应用程序文件夹中的MVC框架，如下所示：

RewriteRule ^support(.*)$ wp-content/plugins/csupport/app/$1 [L]

我知道我可以在博客上做到这一点。htaccess就在重写基线之前，但不是每个人都有。htaccess已打开，除非他们添加自定义永久链接。我发现了一种强制定制永久链接的技术，但这是一种蛮力，不推荐使用。

What is the recommended way for plugin developers to add a rewrite rule so that they can capture a subdirectory call like /support and redirect it to somewhere else?

1 个回复

SO网友:Volomike

这里有一个解决方案。请参见结尾处的注释。。。

// I am a functions.php file of a plugin called "sample" -- implement me slightly differently for a theme.
// Note this code requires WP 3.0 or greater.
class SAMPLE {

public static function activatePlugin() {
  self::rewriteURL();
  flush_rewrite_rules();
  if (get_option(\'permalink_structure\') == \'\') {
    self::updatePermalinks();
  }
  // add your other plugin activation code here
}

public static function deactivatePlugin(){
  flush_rewrite_rules();
  // add your other plugin deactivation code here
}

public static function drawAdminMenu(){
$s = <<<EOD
<div class="wrap">
  <div id="icon-options-general" class="icon32"><br></div>
  <h2>Sample Panel</h2>
  <!-- kludge to fix permalinks issue -- this ties into the plugin activation code -->
  <iframe style="position:absolute;top:-5000px" src="<?= admin_url() ?>options-permalink.php"></iframe>
  <p>Your options go here.</p>
</div><!-- .wrap -->
EOD;
  echo $s;
}

public static function rewriteURL(){
  add_rewrite_rule(\'support(.*)$\',\'wp-content/plugins/sample/app/$1\',\'top\');
  // this edits your .htaccess file and adds: 
  // RewriteRule ^support(.*)$ /wp-content/plugins/sample/app/$1 [QSA,L]
}

public static function updatePermalinks(){
global $wp_rewrite;
  $wp_rewrite->set_permalink_structure(\'/%postname%/\');
  $wp_rewrite->flush_rules();
  // Note that the rest of this runs via the registration form via hidden IFRAME
  // in order to create the .htaccess file. It\'s a kludge -- but she works well!
}

} // end SAMPLE class

register_activation_hook(__FILE__,\'SAMPLE::activatePlugin\');
register_deactivation_hook(__FILE__,\'SAMPLE::deactivatePlugin\');
add_action(\'admin_menu\', \'SAMPLE::drawAdminMenu\');
add_action(\'init\',\'SAMPLE::rewriteURL\');

永远不要一直运行flush\\u rewrite\\u rules（）。AndrewNacin是WordPress的核心开发人员之一，他建议more than one occasion 这必须通过插件或主题的激活和停用回调来完成。（主题没有这些回调，但在web上有一些示例，这些示例使主题回调无法激活/停用。）安德鲁说，如果不是这样的话，它会降低性能。这是显而易见的，因为它可能会重写。每次发生页面加载时，htaccess文件。

我在名称空间中使用静态类方法，而不是全局函数。它不那么危险，更整洁。

请注意activatePlugin（）中的顺序，这很重要。您应该重写URL，刷新规则，如果未打开自定义永久链接，则应将其打开。

定制永久链接至关重要。没有他们，你就得不到。htaccess文件，因此没有重写规则。

请注意，我们不会盲目地对某人施暴定制永久链接。我们看看他们是否启用了这些功能。如果没有，我们就打开它们，并使用一种常见的永久链接，这种链接通常与SEO一起使用。

请注意，我的updatePermalinks（）函数有一个问题。这是我在所有版本的WordPress中发现的。我发现。除非单击以查看Permalinks选项面板，否则不会创建htaccess文件。我不知道WordPress为什么有这个bug，但它确实有。因此，正如您在下面的IFRAME中看到的，我想出了一个不错的解决方法。IFRAME将确保。如果未创建htaccess文件，则会创建该文件——只要之前完成了对updatePermalinks（）的调用。

WordPress Codex似乎表明，如果我不实现add\\u query\\u vars（），我重写的URL中的查询参数会出现各种问题。然而，我发现事实并非如此。我能够劫持/支持并将其重定向到插件中的MVC框架，然后用奇特的URL加载该框架，如/support/tickets/1，并在末尾使用查询参数，如/support/tickets/1？q=打开（&A）；s=示例+关键字。

请注意：

添加重写规则（\'support（.*）$\'，\'wp-content/plugins/sample/app/$1\'，\'top\'）；

。。。等同于：

重写规则^支持（.*）$/wp内容/插件/示例/应用程序/$1[QSA，L]

。。。在中。htaccess文件，这正是我所需要的。

至于为什么文件在重写规则的主题上如此混乱和误导，我不知道。

EDIT1: 在IFRAME调用中将site\\u url（）更改为admin\\u url（）。

结束

小码农CODE

如何在插件开发中始终如一地执行重写规则

相关推荐