web-dev-qa-db-ja.com

修正されたCodexメソッドで親テーマと子テーマのスタイルシートをエンキューする問題

この投稿では、 this thread および this thread で取り上げられたスタイルシートのエンキュー方法に関する最近の変更に関して、私が遭遇したいくつかの質問を取り上げています。

私が遭遇した問題は、WP 4.0インストールですぐに使用できる子テーマである、広く使用され、よく管理されている親テーマを使用する一般的なユースケースシナリオで発生しました。私の子テーマのfunctions.phpにはwp_enqueue_style関数のみが Codexで詳述 として含まれています。

以下で参照するコードはこのテーマに固有のものですが、その多くは親テーマで使用されている現在のコーディング規則を使用していることに注意してください。さらに、私の関心のある領域は、現在野生にある多数の確立された親テーマで複製可能である可能性が最も高い。また、これらの質問は、使用されている親テーマに関係なく、普遍的なレベルで適用されます。

問題1：Twoqueueing

推奨セットアップ：

親テーマは、wp_enqueue_scriptsフックを使用してスタイルとスクリプトをキューに入れています。関連する部分は次のとおりです。

add_action('wp_enqueue_scripts', 'parent_theme_function_name');
function parent_theme_function_name() {
    wp_register_style( 'avia-style' ,  $child_theme_url."/style.css", array(),  '2', 'all' );
    wp_enqueue_style( 'avia-base');
    if($child_theme_url !=  $template_url) { wp_enqueue_style( 'avia-style'); }
}

私の子テーマfunctions.phpは、最近のコーデックス変更ごとにスタイルをキューに入れます：

add_action( 'wp_enqueue_scripts', 'enqueue_parent_theme_style' );
function enqueue_parent_theme_style() {
    wp_enqueue_style( 'dm-parent-style', get_template_directory_uri().'/style.css' );
}

参照コードで使用されている次のIDに注意してください。

  • id='dm-parent-style-css'は、私の子テーマ関数によってキューに入れられた親テーマのスタイルシートです
  • id='avia-style-css'は、親テーマ関数によってキューに入れられた子テーマのスタイルシートです
  • id='dm-child-style-css'は、私の子テーマ関数によってキューに入れられた私の子テーマのスタイルシートです

結果：

一見、すべてが順調で、<head>は次の順序を示しています。

<link rel='stylesheet' id='dm-parent-style-css' href='testinstall.dev/wp-content/themes/enfold/style.css?ver=4.0' type='text/css' media='all' />
<!-- Multiple individual parent theme styles here -->
<link rel='stylesheet' id='avia-style-css' href='testinstall.dev/wp-content/themes/child-theme/style.css?ver=2' type='text/css' media='all' />

プラグインをインストールした後、エンキューの順序は次のように変更されました。

<link rel='stylesheet' id='dm-parent-style-css' href='testinstall.dev/wp-content/themes/enfold/style.css?ver=4.0' type='text/css' media='all' />
<!-- Multiple individual parent theme styles here -->
<link rel='stylesheet' id='avia-style-css' href='testinstall.dev/wp-content/themes/child-theme/style.css?ver=2' type='text/css' media='all' />
<!-- Pesky plugin styles -->

最終的に、プラグインの後に子テーマのcssを読み込む必要があるため、子テーマの関数に優先順位番号を追加する必要がありました （優先順位番号に関する前の説明を参照） .

ただし、私の関数は親テーマのcssのみをキューに入れるため、結果は親テーマ cssが最後に移動し、子テーマのcssは以前よりもさらに苦境に陥ります。

<!-- Multiple individual parent theme styles here -->
<link rel='stylesheet' id='avia-style-css' href='testinstall.dev/wp-content/themes/child-theme/style.css?ver=2' type='text/css' media='all' />
<!-- Pesky plugin styles -->
<link rel='stylesheet' id='dm-parent-style-css' href='testinstall.dev/wp-content/themes/enfold/style.css?ver=4.0' type='text/css' media='all' />

今、私は子テーマのスタイルをキューに登録することを余儀なくされ、スタイルが行の先頭に戻るようにし、子テーマを 上記の問題 of twoqueueing（新しい用語？笑） css。

廃止予定のセットアップ：

子テーマの改訂された機能：

add_action( 'wp_enqueue_scripts', 'enqueue_parent_theme_style', 99 );
function enqueue_parent_theme_style() {
    wp_enqueue_style( 'dm-parent-style', get_template_directory_uri().'/style.css' );
    wp_enqueue_style( 'dm-child-style', get_stylesheet_directory_uri().'/style.css' );
}

結果：

<head>で次の順序を生成します。

<!-- Multiple individual parent theme styles here -->
<link rel='stylesheet' id='avia-style-css' href='testinstall.dev/wp-content/themes/child-theme/style.css?ver=2' type='text/css' media='all' />
<!-- Pesky plugin styles -->
<link rel='stylesheet' id='dm-parent-style-css' href='testinstall.dev/wp-content/themes/enfold/style.css?ver=4.0' type='text/css' media='all' />
<link rel='stylesheet' id='dm-child-style-css' href='testinstall.dev/wp-content/themes/child-theme/style.css?ver=2' type='text/css' media='all' />

私の関数に子スタイルシートを含めると2回キューに入れられますが、親テーマが適切に子スタイルシートをキューに入れるという仮定の下でのコーディングよりも望ましいIMHOです。エンキューされた各スタイルに割り当てられたIDに基づいて、WP Coreにあるものではなく、親テーマがそれをキューに入れているように見えます。

My Shivm：

私はこれが推奨される手段であることをほとんど提案しませんが（そして、私はこのソリューションでうめくよりもコーディング経験のある開発者を確信しています）、私は自分のエンキューのすぐ上に親テーマのID（子テーマのスタイルをキューに入れるために使用されます）をデキューしました私の子テーマの関数ファイルに示されているように：

add_action( 'wp_enqueue_scripts', 'enqueue_parent_theme_style', 99 );
function enqueue_parent_theme_style() {
    wp_enqueue_style( 'dm-parent-style', get_template_directory_uri().'/style.css' );
    wp_dequeue_style( 'avia-style' );
    wp_enqueue_style( 'dm-child-style', get_stylesheet_directory_uri().'/style.css' );
}

結果：

これにより、当面の問題が解決され、次のようになりました。

<!-- Multiple individual parent theme styles here -->
<!-- Plugin styles -->
<link rel='stylesheet' id='dm-parent-style-css' href='testinstall.dev/wp-content/themes/enfold/style.css?ver=4.0' type='text/css' media='all' />
<link rel='stylesheet' id='dm-child-style-css' href='testinstall.dev/wp-content/themes/child-theme/style.css?ver=2' type='text/css' media='all' />

もちろん、これには、親テーマで使用されるIDを知る必要があります。標準の子テーマ開発方法論として、より一般的なものを使用する必要があります。

問題2：子スタイルシートの再配置

（これが別のスレッドに登場していないとは思えないが、見たときに特定のスレッドは見られなかったが...もし見逃した場合は、お気軽にお持ちください私の注意。）

私never私のテーマスタイルには、子テーマのルートディレクトリにあるデフォルトのstyle.cssを使用します-もちろん、そこにある必要がありますが、スタイルは、SCSSから/ css /ディレクトリ内の縮小された.cssファイルとしてコンパイルされます。これは"the expected norm"ではないことを理解していますが、子テーマ開発の普遍的なレベルでは、最も深刻なWordPress開発者は似たようなことをしています。もちろん、これは私のスタイルでそのスタイルシートを手動でキューに入れる必要がありますregardless親テーマがそれをキューに入れたかどうか。

まとめると...

  1. 子テーマの標準の観点から、親テーマが子テーマスタイルを適切にキューに入れるという仮定を含めることは安全ですか？
  2. 優先度を削除すると、子テーマのスタイルがプラグインによって上書きされ始めたときに、WordPressコミュニティの一部で混乱が生じる可能性があります。テーマはスタイルを上書きしますが、プラグインではそれほどではありません。
  3. 実際の子テーマスタイルにカスタムスタイルシートを使用する場合（定義済みのstyle.cssに配置することになっている）、そのファイルを手動でキューに入れる必要があります。幅広い開発者にわたって継続性を維持するという点で、可能な複製に関係なく、子スタイルシートを手動でキューに入れることを奨励するのは理にかなっていますか？
child-themewp-enqueue-styleparent-themecodex
9
dMcClintock

質問1

子テーマ標準の観点から、親テーマが子テーマスタイルを正しくエンキューするという仮定を含めるのは安全ですか？

一般的な経験則、はい。 しかし、あなたは決して仮定しないでなければなりません。ほとんどの災害やライブでの失敗は、仮定または仮定に基づく事実に起因します

仮定なしの事実 _

  • 子テーマのfunctions.phpが最初にロードされ、次に親テーマのfunctions.phpがロードされます。これにより、コーデックス内の更新されたコードから、親テーマのメインスタイルシートが子テーマのメインスタイルシートの前にロードされます。

  • バンドルされているテーマ、12を見てみましょう。魔法はwp_enqueue_style( 'twentytwelve-style', get_stylesheet_uri() );で起こります。これがメインスタイルシートのエンキュー方法です。テーマが親テーマとしてアクティブになっている場合、get_stylesheet_uri()は親ディレクトリのstyle.cssを指すので、style.cssは親テーマからロードされます。

  • 子テーマに切り替えると、get_stylesheet_uri()はそのパスを子テーマのstyle.cssを指すように「変更」します。つまり、wp_enqueue_style( 'twentytwelve-style', get_stylesheet_uri() );は親style.cssをロードするのではなく、子style.cssをロードします。

  • 親テーマからの他のすべてのスタイルは、それらが書いた順序で通常通りロードされます。

POTHOLES

  • ヘッダテンプレートに直接追加されているインラインスタイルとスタイルシート。私はこの問題についていくつかテストをしました。親スタイルシートがwp_enqueue_scriptsを使用してエンキューされておらず、直接ヘッダーにロードされている場合は、子テーマのメインスタイルシートが最初にロードされます。ここでの回避策として、親のheader.phpを子テーマにコピーしてそれらの呼び出しを削除することを以前に推奨しました。その後、OP 廃止予定の関数に記述されているように、header.phpに直接ロードされた親と子のテーマスタイルと他のスタイルシートの両方をエンキューする必要があります

  • スタイル（およびスクリプト）がヘッダーに直接ロードされていることが1回または2回発生したため、wp_headの呼び出しを省略しました。これにより、アクションをサイレントで失敗させるようにエンキューされます。そのため、スタイルは単に表示されません。

  • 間違った優先順位が設定されています。エンキュー関数をフックするときに、優先順位を親アクションと子アクションのどちらに設定する必要もありません。両方に同じデフォルト優先順位がある場合は、先着順のルールが適用されます。これにより、ロード順が正しいことを確認できます。

親テーマ作者へのメモ

テーマにスタイルやスクリプトを追加するための適切な方法としては、wp_enqueue_scriptsアクションフックがあります。 Neverヘッダーテンプレートにスタイルとスクリプトを直接追加し、関数をフックするときにアクションに優先順位を設定しない

次のように必ずメインスタイルシートもロードしてください。

wp_enqueue_style( 'twentytwelve-style', get_stylesheet_uri() );

これにより、子テーマが使用されているときに子のメインスタイルシートが確実に読み込まれるようになります。

お子様のテーマ作者としてのあなたの責任

  • あなたの時間をかけて親のテーマを通して働きなさい。あなたの親テーマを知って、あなたがテーマ構造と機能とフックがテーマでどのように使われるかについて快適であることを確認してください。親テーマがどのように機能するかについての内部知識がない場合、成功した子テーマを作成することはできません。コードが期待どおりに機能するように、スタイルとスクリプトが正しくロードされていることを確認するのはあなたの責任です。

  • 親のテーマの作者に、あなたが満足していないコードを常に知らせるようにしてください。たとえば、作者が自分のスタイルをヘッダに直接追加した場合は、そのことを知らせ、これが間違ったやり方であることを気付かせ、将来のリリースでこれを修正するように依頼します

質問2

優先順位を削除すると、子テーマのスタイルがプラグインによって上書きされ始めたときに、WordPressコミュニティの一部に混乱を招く可能性があります。テーマはスタイルを上書きすることを期待していますが、プラグインではそれほどではありません。

残念ながら、これに対して安全な方法をとる直接的な方法はありません。ここでの事実のポイントは、エンドユーザーの同意なしにプラグインスタイルがデフォルトのテーマスタイルを決して上書きしてはいけないということです。私の意見では、これは単なる悪い習慣であるか、プラグインの作者からの無視です。私はこのような場合、プラグインの作者に連絡して彼にこれについて警告させることをお勧めします

また、不要なスタイル（およびスクリプト）をデキューして登録解除するオプション、または上記のコードのように優先順位を変更して再登録および再登録する必要があるオプションもあります（これで問題ありません）。 shivmについてのメモです。スタイルとスクリプトの登録を解除するには、andをデキューすることをお勧めします。

質問3

実際の子テーマスタイルにカスタムスタイルシートを使用する場合（それらを定義済みのstyle.cssに配置することになっているため）、そのファイルを手動でキューに入れることが必要になります。広範囲の開発者に渡って継続性を維持するという点で、重複の可能性があるかどうかにかかわらず、子スタイルシートを手動でエンキューすることを推奨するのは意味がありませんか？

私はこの問題に直接的な白黒の答えがあるとは思わない。私は言って答えるでしょう、それが行動を支配する特定のガイドラインの範囲内である限りあなたが快適であることをしなさい。

スタイルシートは機能を追加するためのものではありませんが、ユーザーに視覚的なエクスペリエンスを追加するためのものです。スタイルは、処理されるとそのままブラウザに直接送信されます。 Wordpressはここでは何の役割も果たしません。

この事実に基づいて、私は本当にスタイルシートを二度ロードすることにおいていかなる危険な赤い旗も見ません。ただし、これには数ミリ秒かかる可能性があります。正直なところ、これとは別に、重複したブラウザがどのように異なるブラウザで処理されるのか、私にはよくわかりません。これは、読者としてあなたが行ってテストできることです。

私見、重複は決して良いものではなく、常に避けるべきです。あなたが本当に何かの理由で手動で子のメインスタイルシートをエンキューしたいのであれば、あなたのshivmであなたのコードを利用すべきであることを私は提案するでしょう。デフォルトで追加された複製をデキューおよび登録解除してから、通常どおりスタイルシートを再キューイングします。

覚えておくべきことが1つだけあります。enqueueおよびregister関数には$dependancyパラメータがあり、これも使用できます。そのため、二次スタイルシートをロードして、それを子テーマのメインスタイルシートに依存させることは簡単です。

結論として

最近のコーデックスの更新以降、フィードバックは素晴らしかったので、皆さんのフィードバックに感謝します。私はみんなに、特にこの質問に対するあらゆる種類のフィードバックに参加することを勧めたいと思います。あなたが追加またはコメントする何かがあるならば、してください。

5
Pieter Goosen