web-dev-qa-db-fra.com

Quel est le but de la balise admin canonique?

J'ai effectué une recherche dans Google et ressources de développement WordPress , mais rien n'a été fait.

Je comprends l'objectif de la balise rel="canonical" dans l'interface d'un site Web (cela fait partie du référencement du site Web), mais je ne comprends pas son objectif dans la zone d'administration de WordPress (backend).

Exemple dans une installation WordPress locale:

<link id="wp-admin-canonical" rel="canonical" href="http://localhost/wordpress/wp-admin/plugins.php" />

Quel est leur but dans la zone d'administration de WordPress?

wp-adminrel-canonical
3
Binar Web

Qu'est-ce que frontend & backend dans WordPress?

Le PHP CODE, les requêtes SQL, etc. exécutés sur votre serveur est le backend & tout code HTML/CSS/JavaScript qui parvient au navigateur. , est le frontend.

Ainsi, même si certaines parties du "frontend"de votre site peuvent être restreintes par une barrière protégée par mot de passe, elles sont toujours considérées comme frontales. C'est plus précis si vous l'appelez Panneau d'administration WordPress, au lieu de l'appeler le backend.

Pourquoi les pages du panneau d'administration WordPress auraient-elles besoin de rel="canonical"?

Sauf pour un très très rarecas d'utilisation rendant public les pages d'administration, il ne peut y avoir d'avantage en termes de référencement. Cependant, rel="canonical" peut toujours être utilisé (même pour les pages du panneau d'administration): Dans le cadre de la pratique standard.

Pour une page Web, rel="canonical" signifie:

L'URL de la page Web qui est reconnue en tant qu'URL d'accès à une collection de pages différentes ayant un contenu très similaire ou identique.

Comme il s’agit là d’une pratique courante, même si vous n’obtenez aucun avantage en termes de référencement, c’est toujours la bonne chose à faire.

D'où est ce que ça vient:

WordPress a ajouté la fonction wp_admin_canonical_url() dans WordPress 4.2. La partie rel="canonical" était présente depuis le début et les développeurs WordPress n’ont trouvé aucune raison de le supprimer depuis lors.

La modification initiale provient du ticket de support intitulé: . Supprimez les paramètres de message de l'URL d'administration dans la barre d'adresse du navigateur . Et si vous parcourez la discussion, vous verrez que la partie rel=canonical a été ajoutée dans le cadre de la pratique standard, rien de plus/.

Vérifiez le commentaire du développeur d'origine:

  1. rel=canonical est une pratique standard, et je pense que c'est un bon usage.

Pourquoi WordPress a besoin de la balise <link id="wp-admin-canonical" />?

Comme il ressort de la discussion ci-dessus, la partie rel=canonical de la balise <link> n’est là que pour la pratique courante; toutefois, la balise <link>:

<link id="wp-admin-canonical" rel="canonical" href="__URL__" />

lui-même est fonctionnel. Il a été ajouté pour que l'historique de l'URL et du navigateur reste propre à partir des noms de variable de requête à usage unique.

Par exemple, si vous activez un plugin, en haut de votre panneau d'administration, il vous envoie un message du type:

Plugin activé.

Après cela, dites que vous fermez le navigateur et le rouvrez plus tard (ou actualisez simplement la page). À ce stade, avant WordPress 4.2 (si le navigateur est configuré pour ouvrir le dernier onglet ouvert), la page indiquait toujours:

Plugin activé

même si rien ne s'est vraiment passé cette fois-ci. Il en va de même lorsque vous utilisez le bouton Précédent du navigateur (car le message s'affiche également en réponse aux paramètres d'URL à usage unique de l'historique du navigateur).

Cela se produit parce que WordPress vous redirige vers une URL telle que:

http://example.com/wp-admin/plugins.php?activate=true&plugin_status=all&paged=1&s=

après avoir activé un plugin. Notez la chaîne de requête activate=true dans l'URL. Cela n'a d'autre but que de vous montrer que le message " Plugin est activé". Il n’a donc aucune utilité dans l’historique des URL ou du navigateur après que le message " Plugin activé" vous a été envoyé.

C'est pourquoi, dans WordPress 4.2 wp_admin_canonical_url() la fonction a été introduite, où la balise <link id="wp-admin-canonical" /> conserve la référence à la version canonique de l'URL sans le La variable de requête à usage uniquepart, puis le code JavaScript de la fonction le remplace à partir de l'entrée de l'historique du navigateur.

Au moment de la rédaction de ce document, il y a 23 variables de requête de ce typepouvant être supprimées de l'URL canonique à partir de wp_removable_query_args() une fonction:

'activate', 'activated', 'approved', 'deactivate', 'deleted',
'disabled', 'enabled', 'error', 'hotkeys_highlight_first', 
'hotkeys_highlight_last', 'locked', 'message', 'same', 'saved',
'settings-updated', 'skipped', 'spammed', 'trashed', 'unspammed', 
'untrashed', 'update', 'updated', 'wp-post-new-reload'

Cependant, il peut être étendu à partir de plug-ins ou de thèmes à l'aide du crochet de filtre removable_query_args.

9
Fayaz

Wordpress l’utilise dans l’administrateur pour supprimer certains arguments de requête de l’URL.

Il est généré par la fonction wp_admin_canonical_url()

function wp_admin_canonical_url() {
    $removable_query_args = wp_removable_query_args();

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

    // Ensure we're using an absolute URL.
    $current_url  = set_url_scheme( 'http://' . $_SERVER['HTTP_Host'] . $_SERVER['REQUEST_URI'] );
    $filtered_url = remove_query_arg( $removable_query_args, $current_url );
    ?>
    <link id="wp-admin-canonical" rel="canonical" href="<?php echo esc_url( $filtered_url ); ?>" />
    <script>
        if ( window.history.replaceState ) {
            window.history.replaceState( null, null, document.getElementById( 'wp-admin-canonical' ).href + window.location.hash );
        }
    </script>
<?php
}

Les wp_removable_query_args() renvoient un tableau avec les arguments de la requête selon lesquels nous souhaitons supprimer ceux par défaut.

$removable_query_args = array(
    'activate',
    'activated',
    'approved',
    'deactivate',
    'deleted',
    'disabled',
    'enabled',
    'error',
    'hotkeys_highlight_first',
    'hotkeys_highlight_last',
    'locked',
    'message',
    'same',
    'saved',
    'settings-updated',
    'skipped',
    'spammed',
    'trashed',
    'unspammed',
    'untrashed',
    'update',
    'updated',
    'wp-post-new-reload',
);

Alors maintenant, par exemple, si nous modifions certains articles, l'URL est http://example.com/wp-admin/post.php?post=32&action=edit

Lorsque nous sauvegardons l'article, nous modifions l'URL en /wp-admin/post.php?post=32&action=edit&message=1, mais avec JS, nous modifions l'URL stockée dans l'historique de notre navigateur avec window.history.replaceState et en supprimant la requête message.

Et puis, si nous changeons l’URL et que nous cliquons en arrière, nous reviendrons à l’URL stockée au lieu de l’URL avec message.

Et nous ne verrons pas le message: Post mis à jour. Voir le message à nouveau.

Il peut être testé avec la création d'un nouveau message, vous pouvez voir le message, puis aller à la page d'accueil et cliquer à nouveau. et voyez que vous ne verrez pas le message car l’URL de l’historique de notre navigateur a été modifié pour ne plus contenir la requête message arg.

Alors pourquoi utiliser le rel="canonical"?

D'après ce que je vois, wordpress core n'a pas de véritable but, sauf la sémantique d'utiliser cette balise. Cette balise est censée nous indiquer que l'URL de certains est dupliqué par d'autres.

Mais comme d'autres robots ont utilisé cette balise comme option pour vérifier les doublons, nous pouvons construire notre propre robot dans notre zone d'administration à des fins spécifiques et nous pouvons utiliser cette balise.

4
Shibi

Il n'y a pas de raison valable d'en avoir un dans le backend (aka admin). Le seul est que la fonction rel_canonical dans wp-includes/link-template.php ajoutée à partir de l’action dans le fichier default-filters.php est toujours activée, qu’elle soit frontale ou dorsale.

Et comme le comportement ne semble pas poser de problème à la communauté, il reste inchangé: le développeur travaillant sur Wordpress passerait son temps à améliorer quelque chose d’important que quelque chose qui n’ajouterait aucune valeur à Wordpress.

0
Cedric