web-dev-qa-db-fra.com

Comment appliquer systématiquement la règle de réécriture dans le développement de plug-in

Supposons que je crée un plug-in de support client qui détourne la partie/support de l'URL et le redirige vers un framework MVC dans le dossier app de mon dossier de plug-in, comme suit:

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

Je sais que je peux le faire dans le fichier .htaccess d'un blog juste avant la ligne RewriteBase, mais tout le monde n'a pas activé .htaccess à moins d'ajouter un permalien personnalisé. J'ai trouvé une technique pour forcer les permaliens personnalisés, mais c'est une force brutale et non recommandée.

Quel est le moyen recommandé aux développeurs de plug-in d'ajouter une règle de réécriture afin qu'ils puissent capturer un appel de sous-répertoire tel que/support et le rediriger ailleurs?

plugin-developmenturl-rewritingrewrite-rulesadd-rewrite-rule
1
Volomike

Voici une solution. Voir les commentaires à la fin ...

// 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');

  1. Vous ne devriez jamais exécuter flush_rewrite_rules () tout le temps. Andrew Nacin, l’un des développeurs principaux de WordPress, conseille plus d’unoccasion que cela doit être fait à partir des rappels d'activation et de désactivation d'un plugin ou d'un thème. (Les thèmes ne disposent pas de ces rappels, mais il existe des exemples sur le Web qui retiennent les rappels de thème pour l'activation/la désactivation.) Andrew affirme que cela dégrade les performances, le cas échéant. Cela est évident car cela pourrait potentiellement réécrire le fichier .htaccess à chaque chargement de page.

  2. J'utilise des méthodes de classe statiques au lieu de fonctions globales dans l'espace de noms. C'est moins dangereux et plus ordonné.

  3. Notez la séquence dans le activatePlugin () - c'est important. Vous devez réécrire l'URL, vider les règles et, si les permaliens personnalisés ne sont pas activés, les activer.

  4. Les permaliens personnalisés sont essentiels. Sans eux, vous n'obtenez pas le fichier .htaccess et donc pas de règles de réécriture.

  5. Notez que nous ne faisons pas aveuglément la force aveugle de la force brute sur quelqu'un. Nous voyons s'ils les ont activés. Sinon, nous les allumons et utilisons un type commun de lien permanent souvent utilisé avec le référencement.

  6. Notez que ma fonction updatePermalinks () a un problème. C'est quelque chose que j'ai détecté dans toutes les versions de WordPress. J'ai trouvé que le fichier .htaccess n'était pas en cours de création, à moins que vous ayez cliqué pour afficher le panneau d'options Permaliens. Je ne sais pas pourquoi WordPress a ce bogue, mais c'est le cas. Comme vous pouvez le constater avec l’IFRAME ci-dessous, j’ai proposé une solution de contournement décente. Cet IFRAME assurera la création du fichier .htaccess si ce n'était pas le cas - tant que l'appel à updatePermalinks () a déjà été effectué.

  7. Le codex WordPress semblait indiquer que j’aurais toutes sortes de problèmes avec les paramètres de requête dans mon URL réécrite si je n’implémentais pas add_query_vars (). Cependant, j'ai trouvé que ce n'était pas le cas du tout. J'ai pu pirater/supporter et le rediriger vers un framework MVC dans mon plugin, puis charger ce framework avec des URLs fantaisistes comme/support/tickets/1, ainsi que d'utiliser des paramètres de requête à la fin tels que/support/tickets/1? Q = ouvert & s = échantillon + mots-clés.

  8. Notez que:

add_rewrite_rule ('support (. *) $', 'wp-content/plugins/sample/app/$ 1', 'top');

... équivaut à:

RewriteRule ^ support (. *) $/Wp-content/plugins/sample/app/$ 1 [QSA, L]

... dans le fichier .htaccess, ce qui est exactement ce dont j'avais besoin.

En ce qui concerne les raisons pour lesquelles les documents sont si confus et trompeurs sur le sujet de RewriteRules, je n’en ai aucune idée.

EDIT1: site_url () modifié en admin_url () dans l'appel IFRAME.

1
Volomike