web-dev-qa-db-ja.com

管理標準タグの目的は何ですか？

Googleと WordPressの開発者向けリソース を検索しましたが、何も表示されませんでした。

私はウェブサイトのフロントエンドのrel="canonical"タグの目的を理解しています（それはウェブサイトのSEOの一部です）が、私はWordPress管理領域（バックエンド）でその目的を理解していません。

ローカルのWordPressインストールの例：

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

WordPress管理者領域の目的は何ですか？

wp-adminrel-canonical
3
Binar Web

WordPressのフロントエンドとバックエンドとは何ですか？

サーバーで実行されるPHP CODE、SQLクエリなどは、backendおよびブラウザに来るHTML/CSS/JavaScriptコードです。結果は、フロントエンドです。

そのため、サイトの一部「フロントエンド」の一部はパスワードで保護されたバリアによって制限される場合がありますが、それでもフロントエンドと見なされます。バックエンドではなく、WordPress管理パネルと呼ぶ方がより正確です。

なぜWordPress Admin Panelページにrel="canonical"が必要なのですか？

管理ページを公開する可能性のある非常にまれなユースケースを除き、SEOのメリットはありません。ただし、rel="canonical"は引き続き使用できます（管理パネルページでも）：標準プラクティスの一部として。

Webページの場合、rel="canonical"は次を意味します。

非常に類似したコンテンツまたは同じコンテンツを持つさまざまなページのコレクションのgo to URLとして認識されるWebページのURL。

これは標準的な方法であるため、SEOのメリットがまったく得られない場合でも、それは正しいことです。

それはどこから来たのですか：

WordPressはWordPress 4.2にwp_admin_canonical_url()関数を追加しました。 rel="canonical"部分は最初からあり、WordPress開発者はそれ以降削除する理由を見つけませんでした。

元の変更は、次のタイトルのサポートチケットから来ました。 ブラウザのアドレスバーの管理者URlからメッセージパラメータを削除 。議論を進めていくと、rel=canonicalの部分が標準的なプラクティスの一部として追加されていることがわかりますnothing。

元の開発者から コメント を確認します。

  1. rel=canonicalは標準的な慣行であり、これは適切な使用方法だと思います。

WordPressに<link id="wp-admin-canonical" />タグが必要な理由

上記の説明から明らかなように、rel=canonicalタグの<link>部分は標準的な練習のためだけにありますが、<link>タグは次のとおりです。

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

それ自体が機能します。 使い捨てクエリ変数名からURLとブラウザ履歴をきれいに保つために追加されました。

たとえば、管理パネルの上部にあるプラグインをアクティブにすると、次のようなメッセージが表示されます。

プラグインが有効になりました。

その後、ブラウザを閉じて、後でもう一度開く（または単にページを更新する）と言います。その時点で、WordPress 4.2より前（ブラウザーが最後に開いたタブを開くように設定されている場合）、ページには次のように表示されます。

有効化されたプラグイン

今回は本当に何も起こらなかったとしても。ブラウザの戻るボタンを使用する場合も同様です（ブラウザの履歴からの使い捨てURLパラメータに対する応答でもメッセージが表示されるため）。

これは、WordPressが次のようなURLにリダイレクトするために発生します。

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

プラグインをアクティブにした後。 URLのactivate=trueクエリ文字列に注意してください。これは、「Plugin activate」メッセージを表示する以外の目的はありません。そのため、「Plugin activate」メッセージが配信された後は、URLまたはブラウザ履歴で使用されません。

そのため、WordPress 4.2で wp_admin_canonical_url() 関数が導入されました。ここで、<link id="wp-admin-canonical" />タグは、なしでURLの正規バージョンへの参照を保持します使い捨てのクエリ変数部分と、関数のJavaScript CODEがブラウザの履歴エントリからそれを置き換えます。

これを書いている時点で、23個の使い捨てクエリ変数があり、これらは wp_removable_query_args() 関数から正規URLから削除できます：

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

ただし、removable_query_argsフィルターフックを使用して、プラグインまたはテーマから拡張できます。

9
Fayaz

WordpressはURLからいくつかのクエリ引数を削除するために管理者でこれを使用します。

その関数によって生成された 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
}

wp_removable_query_args() は、例えばデフォルトのものを削除したいクエリ引数を含む配列を返します。

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

そのため、たとえば投稿を編集した場合のURLはhttp://example.com/wp-admin/post.php?post=32&action=editです。

投稿を保存するときに、URLを/wp-admin/post.php?post=32&action=edit&message=1に変更しますが、JSではブラウザの履歴に保存されているURLをwindow.history.replaceStateに変更し、messageクエリ引数を削除します。

URLを変更して戻る場合は、messageの付いたURLではなく、保存されているURLに戻ります。

メッセージは表示されません。 投稿が更新されました。投稿を見る もう一度。

それはあなたがメッセージを見てそれからホームページに行って戻ることができる新しいポストを作成することでテストすることができます。ブラウザの履歴URLがメッセージクエリ引数なしのものに変更されたため、メッセージが表示されなくなります。

それではなぜrel="canonical"を使うのですか？

私が見たところでは、wordpressコアはこのタグを使うために semantics を除いて本当の目的を持っていません。このタグは、あるURLが他のURLと重複していることを知らせるためのものです。

しかし、他のクローラが重複をチェックするためのオプションとしてこのタグを使用していたので、何らかの目的で管理領域に独自のクローラを構築することができ、このタグを使用することができます。

4
Shibi

バックエンドに管理者を持っているのには正当な理由はありません。唯一のものは、rel_canonicalファイルのアクションから追加されたwp-includes/link-template.php内の関数default-filters.phpが常にアクティブになるということです - それがフロントエンドであるかバックエンドであるかにかかわらず。

そして、その振る舞いはコミュニティにとって問題とは思われないので、変更はありません。Wordpressに取り組んでいる開発者は、Wordpressに何の価値も付加しないものよりも重要なものの改善に時間をかけるでしょう。

0
Cedric