web-dev-qa-db-ja.com

カスタマイザでの投稿メタの操作

私はadminを通してカスタムフィールドのためのプラグインに取り組んでいます、そして私はフィールドのためにできるだけ多くの場所を作成しようとしています。これまでのところ、私はこれらの場所のかなりの数に対してこれを成功させています。

  1. 投稿タイプ
  2. タクソノミー
  3. コメント
  4. ユーザー
  5. オプション(ページ)
  6. ウィジェット
  7. メニュー項目
  8. 添付ファイル
  9. ショートコード
  10. カスタマイザ(の種類)

当然のことながら、私が持っているそれぞれの場所で、私は適切なWordPress API - * _post_meta、* _ term_metaなどを使用しようとしています。

URLを持つアイテムに関連付けられている場所(添付ファイルにもURLが含まれている場合でも、主に最初の4つ)には、ユーザーが現在のアイテムを編集してそのカスタムフィールドを保存できるフロントエンドフォームがあります。これは、引数を必要としない単一の関数/テンプレートタグを使用して行います。項目に関連付けられているすべてのフィールドグループは自動的に表示されます。

私が(証明の)概念を成功させると考える前に私が欲しい最後の要素はカスタマイザのサポートです。デフォルトのAPIを使用することで、オプションやテーマの変更を簡単に扱うことができ、「カスタマイザ」の場所が非常に機能的になるようになりました。私の実装の唯一の欠点は私が単一のコントロールとしてフィールドを持つグループ全体を表示しているということです。これにより、タブ、条件付きロジック、および適切な検証(条件付きロジックによって異なります)を持つことができます。それでも、私は(WP_Customize_Settingのように)異なる設定を使用しているので、postMessageと他のすべてのものは、他に何もハッキングする必要なしに、ほとんど正しく機能しています。

私が欲しいのは、URLを持ちフロントエンドフォームを持つことができる同じ場所をカスタマイザにも簡単に追加できるようにすることです。開発者は投稿メタグループを作成することができます。これは編集画面に通常の投稿ボックスとして表示されます。私の目標は、そのグループを使用できるようにするために - > show_in_customizer()のように呼び出すことです。

私は多くの人がカスタマイザで投稿を編集することに対して忠告することを知っていますし、多くの場合私は彼らに同意するでしょう。しかし、投稿ごとのレイアウト設定、いくつかの色のオプション、さらには特徴的な画像のような単純なものがある場合は、そのドアを開いたままにしておきます。

追いつくために、これは少なくとも以下のものを必要とするので、これは非常に難しいタスクのようです。

  1. 担当セクションをカスタマイザに表示するかどうかを決定します。セクションの "active_callback"プロパティを使えば十分簡単です。
  2. カスタマイザへのデータの供給:これは少し面倒です。ページのプレビュー中に[カスタマイズ]ボタンをクリックしても、カスタマイザは管理者のコンテキスト内から読み込まれ、表示されているものに直接アクセスすることはできません。私がしていることは、ページのフッターに必要なすべてのデータを集めて、ページがロードされたときにparent.someFunctionを通してカスタマイザに送ることです。これは理想的ではありませんが、十分にうまく機能します - 私は何度も値を取得/送信していないので幸せです。完璧な世界では、この機能とactive_callbackを組み合わせることで、ユーザーはページを編集したり、別のページへのリンクをクリックしたり、新しく読み込まれたページをすぐに編集したりできます。しかし、これが行われると、新しいページはリクエストパラメータもヘッダインクルードも受け取らないので、カスタマイザ内にない場合はほとんど動作しているので、これは機能しません。
  3. 通常の(postMessage以外の)要求時に、カスタマイザからの値でget_*_metaの結果を上書きします。この部分は非常に簡単です。
  4. データを保存する:これが私の実装が失敗するところです:(

[保存して公開]ボタンをクリックすると、カスタマイザはwp_ajaxリクエストを実行します。値が変更されたときのリフレッシュとして、リクエストには通常のcustomized JSONがまだ含まれていますが、スクリプトはadmin-ajaxを使用しているため、実際に何が保存されているのかわかりません。

私が今持っている唯一の考えは、wp.customize.previewer.query JavaScript関数を以下の行の何かで上書きすることです。

var query = wp.customize.previewer.query;
wp.customize.previewer.query = function( options ) {
    args = query.call( wp.customize.previewer, options );
    args.my_plugin_name_current_object = 'post_10';
    return args;
}

とはいえ、この時点では、パラメータを追加するときには細心の注意を払う必要がありますが、全体的に見て、実装が汚くなりすぎています。

最後に、私の質問: 誰かがカスタマイザで同様の機能をうまく達成できたか。このことを終わらせるための適切なアプローチについて私にアドバイスしてもらえますか?

これまでのところ、私はカスタマイザのためにカスタムのものを開発しようとしなかったし、(誰かを害するつもりはないが)、カスタマイザのいくつかの部分が過度に複雑になりすぎた。 -焼きました。

私は特定のコードスニペットを含めていないことを知っていますが、問題は少なくとも私にとっては十分に一般的なことのようです。

前もって感謝します!

3

投稿のカスタマイズ プラグインを参照してください。カスタマイザの投稿を表すWP_Customize_Post_Settingとポストメタを表すWP_Customize_Postmeta_Settingがあります。

2
Weston Ruter