it-swarm.com.de

Was ist der Zweck von admin canonical tag?

Ich habe die Ressourcen von Google und WordPress-Entwicklern durchsucht, aber es ist nichts aufgetaucht.

Ich verstehe den Zweck des rel="canonical" -Tags im Frontend einer Website (es ist Teil der Website-SEO), aber ich verstehe den Zweck nicht im WordPress Admin-Bereich (Backend).

Beispiel in einer lokalen WordPress-Installation:

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

Was ist ihr Zweck im WordPress Admin-Bereich?

3
Binar Web

Was ist Frontend & was ist Backend in WordPress?

Der PHP CODE, die SQL-Abfragen usw., die auf Ihrem Server ausgeführt werden, ist der Backend & jeder HTML/CSS/JavaScript-CODE, der als Ergebnis an den Browser gelangt, ist der Frontend .

Auch wenn einige Teile des "Frontends" Ihrer Site möglicherweise durch eine kennwortgeschützte Barriere eingeschränkt sind, gilt dies dennoch als Frontend. Es ist genauer, wenn Sie es WordPress Admin Panel aufrufen, anstatt es das Backend aufzurufen.

Warum benötigen WordPress Admin Panel-Seiten rel="canonical"?

Sofern nicht für einen sehr, sehr selten Anwendungsfall, in dem Sie die Admin-Seiten öffentlich machen, kann es keine SEO-Vorteile geben. rel="canonical" kann jedoch weiterhin verwendet werden (auch für die Admin-Panel-Seiten): Im Rahmen der Standardpraxis .

Für eine Webseite bedeutet rel="canonical":

Die Webseiten-URL, die als Ziel-URL für eine Sammlung verschiedener Seiten mit sehr ähnlichem oder gleichem Inhalt erkannt wird.

Da dies die Standardpraxis ist, ist es immer noch das Richtige, auch wenn Sie keinen SEO-Nutzen daraus ziehen.

Woher kommt das:

WordPress fügte wp_admin_canonical_url() Funktion in WordPress 4.2 hinzu. rel="canonical" part war von Anfang an dabei & WordPress-Entwickler fanden keinen Grund, es seitdem zu entfernen.

Die ursprüngliche Änderung stammt aus dem Support-Ticket mit dem Titel: Entfernen Sie die Nachrichtenparameter aus den Administrator-URLs in der Adressleiste des Browsers . Und wenn Sie die Diskussion durchgehen, werden Sie feststellen, dass der Teil rel=canonical als Teil der Standardpraxis hinzugefügt wurde, nichts weiter .

Überprüfen Sie den Kommentar des ursprünglichen Entwicklers:

  1. rel=canonical ist eine Standardpraxis, und ich denke, dies ist eine gute Verwendung davon.

Warum benötigt WordPress das Tag <link id="wp-admin-canonical" />?

Wie aus der obigen Erörterung hervorgeht, ist der rel=canonical-Teil des <link>-Tags nur für die Standardpraxis vorhanden, der <link>-Tag jedoch:

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

selbst ist funktionsfähig. Es wurde hinzugefügt, um den URL- und Browser-Verlauf von Einweg-Abfragevariablennamen freizuhalten.

Wenn Sie zum Beispiel ein Plugin oben in Ihrem Admin-Bereich aktivieren, erhalten Sie eine Meldung wie:

Plugin aktiviert.

Sagen Sie danach, Sie schließen den Browser und öffnen ihn später wieder (oder aktualisieren Sie einfach die Seite). Zu diesem Zeitpunkt, vor WordPress 4.2 (wenn der Browser so eingestellt ist, dass der zuletzt geöffnete Tab geöffnet wird), würde die Seite immer noch sagen:

Plugin aktiviert

obwohl diesmal wirklich nichts passiert ist. Gleiches gilt, wenn Sie die Schaltfläche "Zurück" des Browsers verwenden (da die Nachricht auch als Antwort auf die Einweg-URL-Parameter aus dem Browserverlauf angezeigt wird).

Dies geschieht, weil WordPress Sie zu einer URL umleitet, die wie folgt lautet:

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

nachdem du ein Plugin aktiviert hast. Beachten Sie die activate=true Abfragezeichenfolge in der URL. Dies hat keinen anderen Zweck, als Ihnen die Meldung " Plugin enabled " anzuzeigen. Daher hat es keine Verwendung in der URL oder im Browserverlauf, nachdem die Nachricht " Plugin enabled " an Sie gesendet wurde.

Aus diesem Grund wurde in WordPress 4.2 wp_admin_canonical_url() function eingeführt, wobei <link id="wp-admin-canonical" /> tag den Verweis auf die kanonische Version der URL ohne die Einweg-Abfragevariable part und dann den JavaScript-CODE aus der Funktion beibehält Ersetzt es aus dem Verlaufseintrag des Browsers.

Derzeit gibt es 23 solche Single-Use-Abfragevariablen , die aus der kanonischen URL von wp_removable_query_args() function entfernt werden können:

'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'

Es kann jedoch mit dem Filter-Hook removable_query_args von Plugins oder Themes erweitert werden.

9
Fayaz

Wordpress verwendet dies im Admin, um einige Query Args aus der URL zu entfernen.

Es wird von der Funktion wp_admin_canonical_url() generiert.

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
}

Die wp_removable_query_args() geben ein Array mit den Abfrageargs zurück, die wir zum Beispiel entfernen möchten.

$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',
);

Wenn wir also zum Beispiel einen Beitrag bearbeiten, lautet die URL http://example.com/wp-admin/post.php?post=32&action=edit

Wenn wir den Beitrag speichern, ändern wir die URL in /wp-admin/post.php?post=32&action=edit&message=1, aber mit JS ändern wir die in unserem Browserverlauf gespeicherte URL mit window.history.replaceState und entfernen das Abfrageargument messagename__.

Und wenn wir dann die URL ändern und auf "Zurück" klicken, kehren wir zu unserer gespeicherten URL zurück und nicht zu der URL mit dem messagename__.

Und wir werden die Nachricht nicht sehen: Beitrag aktualisiert. Beitrag anzeigen again.

Es kann mit dem Erstellen eines neuen Beitrags getestet werden. Sie können die Nachricht sehen und dann zur Startseite gehen und zurück klicken. und sehen Sie, dass die Nachricht nicht angezeigt wird, da sich die URL des Browserverlaufs ohne das Argument für die Nachrichtenabfrage geändert hat.

Warum also den rel="canonical" verwenden?

Soweit ich weiß, hat WordPress Core keinen wirklichen Zweck außer Semantik , um dieses Tag zu verwenden. Dieses Tag soll uns mitteilen, dass einige URLs mit anderen URLs dupliziert sind.

Da andere Crawler dieses Tag jedoch als Option zur Überprüfung auf Duplikationen verwendeten, können wir für einen bestimmten Zweck einen eigenen Crawler für unseren Administrationsbereich erstellen und dieses Tag verwenden.

4
Shibi

Es gibt keinen gültigen Grund, einen im Backend zu haben (aka admin). Die einzige ist, dass die Funktion rel_canonical in wp-includes/link-template.php, die aus der Aktion in default-filters.php-Datei hinzugefügt wurde, immer aktiviert ist - unabhängig davon, ob es sich um ein Frontend oder ein Backend handelt.

Und da das Verhalten für die Community kein Problem zu sein scheint, bleibt es unverändert: Die Entwickler, die an Wordpress arbeiten, würden ihre Zeit besser damit verbringen, etwas Wichtiges zu verbessern, als etwas, das Wordpress keinen Mehrwert bringt.

0
Cedric