WordPressTracでのカスタマイザーショットダウンを無効にするフィルター
公開: 2015-07-01
WordPress 4.3は、カスタマイザーを介したメニュー管理を導入し、メニュー項目を追加、削除、および注文するためのライブプレビューをフロントエンドに提供します。 ユーザーはまだ管理インターフェースを使用してメニューを管理するオプションを持っていますが、この機能に熱心でない開発者は、カスタマイザーを無効にしてWordPress全体でそのリンクを削除する簡単な方法を探しています。
クライアントの作業を伴う特定のシナリオでは、カスタマイザーはその価値よりも厄介な場合があり、カスタムメイドのWordPress管理者にとって有益な追加ではない場合があります。
@pollyplummer非常に興味深い。 私は新しいアップデートに反対していませんが、カスタマイザーはエージェンシーの世界では地獄です。
—エドワード・マッキンタイア（@twittem）2015年6月24日
Risdallのアプリケーション開発者兼UIエンジニアであるGabeShackleは、先週WordPress tracでチケットを作成し、カスタマイザーを無効にするフィルターを要求しました。 彼のパッチは、開発者にbodyタグ内の「no-customizer-support」クラスを有効にする簡単な方法を提供します。
'customizer-support'クラスはページレンダリングでJavaScriptを介して追加されるため、現在、コアフィルターまたはアクションを使用して操作することはできません。
フィルタ値をfalseに設定すると、カスタマイザは基本的に管理者から非表示になり、現在カスタマイザを指しているリンク（ウィジェット、テーマなど）は以前のダッシュボードの宛先に戻されます。
現在、カスタマイザーを無効にしたい開発者は、カスタマイザーが管理者に導入するすべてのものを効果的に削除するために、さまざまな方法の組み合わせを採用する必要があります。
「このフィルターは、このプロセスを単純なブールフィルターに変換するため、カスタマイザーを必要としない開発者は簡単に削除できます」とShackle氏は述べています。
WordPressのリード開発者であるDionHulseはチケットに返信し、カスタマイザーを自分であまり使用していませんが、WordPressユーザーが簡単にオフにする方法でメリットが得られるとは思わないと述べました。
個人的には、カスタマイザーをあまり使用しないので、それを無効にするフィルターを提供することは、WordPressユーザーにとっておそらく最善の利益ではないと思います。
カスタマイザーは、嫌いな人もいますが、WordPress UXの将来の主要なコンポーネントです。それが良いか悪いかはまだ分からないのですが、好きでも嫌いでも、ここにあります。
Hulseは、別の方法として、それを無効にするためのより良い方法は、ロールからcustomize機能を削除することであると提案しました。
Shackleはさらに、管理バーの前例に従おうとしていると説明しました。これは、同様のタイプのUXコンポーネントであると彼は考えています。
「管理バーは、フィルターだけでなく、グローバル変数、コア機能、およびユーザープロファイル設定によって無効にすることができます」と彼は言いました。 「カスタマイザーにはこれらのオプションはありません。」
4.3にマージされているMenuCustomizerプラグインの開発者であるNickHalseyは、Shackleが機能を無効にするためにフィルターを要求する理由についての仮定に基づいて応答しました。
私はまだこのようなものの正当な理由を見ていません。 ほとんどの場合、ユーザーにカスタマイザーへのアクセスを許可しないことに関する懸念は、ユーザーに適切な機能を提供していないという事実から生じます。 また、本当に必要な場合は、カスタマイズ機能を使用してカスタマイザーをオフにすることができます。
カスタマイズメタ機能を削除する（または再マップするなど）ことはできますが、ユーザーをトレーニングしたくない、またはカスタマイザーを使用したくないという理由だけで削除すると、自分自身とユーザーに多大な不利益をもたらします。 dd32が述べたように、カスタマイザーはWordPress内でのみ重要性を増していきます。 さらに、ユーザーテストでは、カスタマイザーエクスペリエンスは一般に、管理者よりもユーザーが把握しやすいことが示されています。これは主に、ライブプレビューを利用できることの価値に由来します。 カスタマイザーは、リリースごとにかなりの時間をかけて改善を続け、使いやすさを最適化するために頻繁にユーザーテストを実施しています。
ハルシーはこの交換の後、すぐにチケットを閉じました。 私はShackleをフォローアップして、 customize機能を削除するために提案された代替案が彼の目的に不十分である理由を見つけました。
「ほとんどの場合、カスタマイザーを、無効にするための3つ以上のメソッドがある管理バーのように扱うことができることを望んでいました」とShackle氏は述べています。 「明確にラベル付けされたフィルターを使用することは、ユーザーの機能を変更するよりも読みやすいと思います。 WordPressの知識がほとんどないPHP開発者は、「map_meta_cap」ではなく「enable_customizer_support」という名前のフィルターで何が起こっているのかをはるかに早く理解できる可能性があります。」
明らかに、すべてのチケットとパッチがWordPressコアコンポーネントのメンテナーによって有効であると見なされるわけではありませんが、Shackleは議論に対する防御的な反応に失望しました。
「正直なところ、返信が「同じ効果を達成するには、 customize機能を使用する必要があります」という線に沿ったものであれば、実際には問題はありませんでした」と彼は言いました。
「残念ながら、それは「すべてのもののためのカスタマイザー」以外のアプローチのようです。 つまり、クライアントにどれだけの不利益をもたらしているのか、そしてクライアントのサイトの外観を管理する方法をクライアントに再トレーニングするだけでなく、怠惰な開発者であるということを何度も言われることを意味します。
「カスタマイザーチーム自体がプロジェクトに対してオールオアナッシングのアプローチを取っているように感じます。理由に関係なく、これを疑問視する人は誰でも間違っているようです」とShackle氏は述べています。
この交換は、コアコントリビューターがカスタマイザーをWordPressの将来の主要な部分と見なしているため、これは、カスタマイザーをよりモジュール化するための取り組みをサポートする意欲がほとんどない機能の1つであることを示しています。 カスタマイザーのサポートを無効にするには、カスタマイザーの「すべてのパーツを削除」プラグインの作成者が採用したのと同じ方法である「map_meta_cap」を引き続き使用する必要があります。