Gutenberg: コードでグーテンベルクエディターを無効にする方法は？

参照：

• https://github.com/WordPress/gutenberg/blob/master/docs/faq.md#will -i-be-able-to-opt-out-of-gutenberg-for-my-site
• https://wordpress.org/plugins/classic-editor/

こんにちは@aduthはより意味のあるタイトルを更新しました-コードオプションを探しています:)ありがとう

これは多くの開発者にとって非常に便利な機能だと思います。 実際、Gutenbergは、コアへのマージが発生したときに、WordPressバージョン5.0にアップグレードするサイトではなく、バージョン5.0のWordPressの新規インストールでのみアクティブにする必要があると私は考えています。

これをコードでアクティブ化/非アクティブ化する方法と組み合わせると、開発者は準備ができたときにオンにすることができます。

コードを介してこれを実現する必要がある理由について詳しく説明していただけますか？

クライアントの可視性/制御の問題である場合は、上記のプラグインを「必須プラグイン」としていつでもインストールできます： https ：

コードの変更は迅速かつ簡単であるため（プラグインを有効にすることは1）私のコードではなく、2）コードを追加するほど単純ではないため、依存関係のリストに追加することは、この問題に取り組むための実用的でも賢明な方法でもありません。

定数を定義することはあなたのコードかもしれませんが、その定数を操作するロジックは、公式に維持されている「クラシックエディタ」プラグインと同じくらいあなたのコードではありません。

私は議論をしようとしているのではなく、これらのアプローチが魅力的である理由をよりよく理解し、十分なオプションが存在することを確認し、維持するのに過剰なほど多くを提供しないようにしていることを明確にする必要があります。

プラグイン機能をコアの一部にできないのはなぜですか？ 私が興味を持っているので尋ねるだけです:)

グーテンベルクエディターのオン/オフを切り替える機能の必要性を反映したいと思います。 私の特定の状況は、私のWordPressサイトの1つが、カスタムエディターを持つテーマ（例：EnfoldテーマのAviaエディター）に基づいて構築されていることです。

グーテンベルクを有効にすると、エディターのワークフローが変わります。 [すべての投稿]または[ページ]に移動し、[クラシックエディター]をクリックしてから、高度なレイアウトエディターのボタンを押す必要があります。これにより、編集するページで[編集]を押すのではなく、テーマの組み込みエディターが呼び出されます。 、またはプレビューページから。 サイトのルックアンドフィールは、このエディターで作成したテンプレートを中心に標準化されているため、このエディターが必要です。

このプロセスはほとんどの人にとって些細なことのように思えますが、数十人の編集者のワークフローを変更すると、サポート上の問題が発生します。

私の2セント。

違いは「心理的」だけだと思います。 Coreにあるということは、それが無期限にあることを意味し、グーテンベルクの採用を傷つけます。プラグインとして持っているということは、しばらくの間（Mattが数年言ったと思います）サポートし、ある時点で停止することを意味します。

これを別の問題に分割する必要があるかどうかはわかりませんが、WordPress 5.0の新規インストールに対してのみGutenbergを有効にするという@wpmarkのアイデアに対する支持を表明し、

あなたがそれを読みたいのであれば、これについての私の理論的根拠は私が書いた

グーテンベルクは、WordPressを初めて使用する人にとって、新しいブログをインストールして始めるのに最適だと感じています。 そして、アップグレードして「Yay-新しいエディター-お願いします」と考える人にとっては素晴らしいことです。 しかし、他の人にとっては大きなショックになるでしょう。 また、一部のユースケースでは、GBがカスタム投稿タイプを編集するための適切なインターフェースではない場合や、「ブロック」が編集中の情報の適切なデータモデルではない場合があります。

また、このトピックについては、開発者や中小企業のオーナーの声を聞く必要があるように感じます。 私はたくさんの小さなWordPress開発ショップを知っています、そしてこの変更は私のブログ投稿で概説されたすべての理由のために苦痛になるでしょう。 ある開発者や小さな代理店が、更新されたサイトでGBを自動有効にするのは良い考えだと言っているのを聞いたことがありません。 私はその考えに多くの反動を聞いた。

この種のWordPressユーザー（そして私のような開発ショップはWordPressの大きな支持者であり支持者なので、ぜひ聞いてください）はユーザーをよく理解しており、WordPressで何を構築したか、そしてそれが変更なしでGBユーザーインターフェイスにうまく適合し、クライアントに代わってこの変更を管理する機能が必要です。

Classic Editorプラグインをインストールできることはわかっていますが、クライアントがGB自体を有効にする可能性を排除するためにインストールする必要がある場合があります。 また、アップグレードされたサイトでGBがオプションであることが判明した場合、当然、コアでGBを無効にするコードが必要になります。 したがって、 @ smp303 （およびコアでそれを無効にする方法を必要とする他の人）も幸せになります！

コアに統合する計画が立てられるにつれて、開発者や私のような小さなWordPressビジネスの意見が聞かれることを願っています。 私たちの生活はこの変化の影響を受ける可能性があり、一部の人々はこの変化があまりにも早く彼らに強制されていると感じています。 移行を管理するためのより多くのオプションを提供してください。GBが最初にコアに追加されたとき、GBがすべての人にとって正しいものになるとは限らないことを考慮してください。

WPコアのフィルターまたはwp-config.phpの定数は、2つの確実なオプションのように見えます。

@rosswintleと上にリンクされた彼の優れたブログ投稿をエコーし​​ます。私たちはカスタムフィールド、メタボックス（特にACF）を使用して本当に豊かな編集体験を提供する多くのエージェンシーの1つです。 「プラットフォームとしてのWordPress」は約束でした、そしてそれは私たち全員が過去数年間やってきたことです。

グーテンベルクを必要とする人には有効にする方法が必要ですが、そうでない人には強制しないでください。 これがコードで発生するのかプラグインを介して発生するのかについてはかなり簡単です-実際、管理コンソールを使用して50以上のWordPressサイトを維持している人として、グーテンベルクを無効にするためのプラグインの一括インストールはより実用的です（オタクの意味が少ない場合）、しかし、それができる限り、まあ。 ダッシュボードの設定オプションでも問題ありません、IMO-デフォルトの「グーテンベルク：オフ」はさらに良いです...

グーテンベルクとの後方適合サイトに関するロスの指摘も有効です。 事実上、クライアントのために構築する人なら誰でも、大多数が立ち上げに予算を費やし、その後は予算がないことを知っています。 グーテンベルクの改造、クライアントの再トレーニング、別のインターフェース-開発者や事業主以外の誰もがこれにお金を払うと考えるのは幻想的な土地です。

ただ、@ smp303、@dmjeと@rosswintleの感情をエコーしたいです。

関数.phpに簡単なアクションを入れてグーテンベルクを無効にできることは、最も簡単で最も明白なことのように思えます。

グーテンベルクを迂回する必要があるよりも少し難しくするためにプラグインアプローチが採用されていると感じずにはいられません。

コアチームがグーテンベルクに多大な努力を払ったことは知っていますが、その成功は、それを回避する能力を削減することではなく、そのメリットによって決定されるべきです。 さらに、WP開発者がまったく新しいエディターのために開発し、反応を学び、それでもレガシーのものを開発および維持する必要があることを考えてください-オーバーヘッドは巨大です。

これもエコーしたいと思います。プラグインではなくコードを介してグーテンベルクエディターを無効にするオプションも必要です。

作成され、現在wontfixとしてクローズされているこのTracチケットも参照してください： ＃WP43068

https://core.trac.wordpress.org/ticket/43068#commentの@ dd32ごと：6

このための定数をサポートすることはないと思います。代わりに、既存のプラグインが単なるスイッチではないという理由だけで、プラグインとおそらくmu-pluginラッパーにユーザーを誘導します。使用されているコアにないコードを含めるため。

WordPressは定数から離れようとしています。定数は後で変更するのが非常に難しいためです。「ああ、グーテンベルクが無効になっているのはなぜですか？ああ、私のランダムなSEOプラグイン（または元開発者）は私がそうしないと思っていましたそれが欲しいと強制的に無効にした、素晴らしい..今、誰が私のためにこれを修正することができますか？」（エンドユーザー）

一部の人が無効にしたい理由はわかりますが、そのような方法で行う必要はありません。

これをwontfixとして安全に閉じることができると思いますが、後で変更される可能性があります（そして、後でこれを再検討します）が、そうなるとは思いません。

みなさん、フィードバックありがとうございます。 私が必要とするという決定にはいくつかの論争があります理解クラシックエディタ、私はさまざまなオプションが何であるかについてチャットしたいと思いますので、完全にブロックエディタを無効にするためのプラグインが。

今後数年間で、サイトデータを管理するための「ブロック」の概念は、データについて考え、レイアウトし、対話し、編集するための主要な方法になります。 WordPress 5.0に登場するブロックエディターは、その方向への最初の主要なステップです。今年のグーテンベルクカスタマイズの焦点は、グーテンベルクのテーマとともに次のステップです。

もちろん、WordPress 5.0が出荷されたときに、すべての人がブロックエディターの準備が100％できるわけではありません。 これは誰もが知っている現実的な現実であり、WordPress5.0にアップグレードするための実行可能な方法がないままにしておくことは望んでいません。 それを念頭に置いて、特定のユースケースに応じて、グーテンベルクを無効にするいくつかの異なる方法があります。

ブロックエディタで機能しないメタボックスを登録すると、そのメタボックスを互換性のないものとして簡単に

同様に、CPT（＃2457）に同様のフラグを追加して、ブロックエディター機能を必要としないCPTがオプトアウトできるようにすることについての議論があります。

これらは、ブロックエディタを無効にするための主な2つの長期的なユースケースです。つまり、ブロックエディタが機能しない場合、または使用パターンに適合しない場合です。

これらのことを念頭に置いて、WordPressがどのように進化する可能性があるかについて考えてみましょう（ここでは水晶玉を非常に見つめています-このリストの内容は、必ずしもこの順序、時間枠、またはたとえあったとしても、それはWordPress 5.0リリースがどのように行われるかに大きく依存する潜在的なシナリオにすぎません）。

• カスタマイザーは、すべてにブロックの概念を使用します。 新しいサイトの99％では、サイト全体を作成するために必要なのはブロックだけです。 ブロック操作は、サイトの構築方法です。
• 新しいテーマは、完全にブロックからサイトを構築することを中心に進化します。 標準のWordPressユーザーエクスペリエンスはブロックで構築されています。
• 同時に、wp-adminは、Gutenbergが提供するJavaScript-appインターフェースの採用を開始します。 もちろん、クラシックエディターへの切り替えは可能ですが、WordPressインターフェースの他の部分とは一致しません。

これは数年の間に繰り返されます。古いインターフェースを復元するためのClassicEditorのようなプラグインがありますが、それらのインターフェースをCoreで維持できるとは限りません。 WordPress 5.0でブロックエディターを無効にすることは合理的なオプションですが、WordPress 5.5または6.0に到達し、まだクラシックエディターを使用している場合は、クライアントに大きな不利益をもたらすことになります。 一例を挙げると、サイトレイアウトのベストプラクティスがテーブルレイアウトからCSSレイアウトのいくつかの反復に進化し、現在はグリッドレイアウトになっているのと同様に、WordPress開発のベストプラクティスも進化しています。

したがって、元の質問に戻ると、ブロックエディターを無効にする単一のコードベースのオプションは実行可能な長期的な解決策ではなく、将来のWordPress Core開発に適切なオプションを提供するために拡張することはできず、実際に不利益をもたらしますこのオプションを作成する場合は、ここにいるすべての人に。 ただし、Classic Editorプラグインは、将来のパラダイムに合わせて進化し続けることができます。 WordPressの世界全体のより一般的なニーズに合わせる必要はなく、それを必要とする人々のニーズを満たすために特別に開発できる、よりリラックスした環境を提供します。

グーテンベルクエディターの問題は、ブロックやブロックの概念ではありません。エディター自体が適切ではないということです。 現在、既存のエディターよりも何倍も混乱しています。これ自体は完璧にはほど遠いものです。 そして、私たちが行く時間に近づき（4月に予定されていると思いますか？）、人々がますます懸念を表明するにつれて、フィードバックは決して「あなたは正しいです、これが私たちがそれに対処する方法です」ということはありません。上記の「まあ、これは起こっているので、乗り込んだほうがいい」

グーテンベルクを非アクティブ化することへの関心、少なくとも私の関心は、ブロック対ウィジェットの未来やカスタマイザーの長期ロードマップではありません-それは実際のエディターが本当にひどいことです。 使いたくない。 私のクライアントは使いたくないです。 使うのはいいことではありません。 そして、それがあまり良くない理由は、すべての段落とテキストの一部が「ブロック」であり、私たち全員がそれを嫌うという基本的な概念です。

これがオフにしたい理由です。 グーテンベルクに行くことは、多くの人にとって非常に不快な経験であり、クライアントと開発の両方にとって深刻な問題です。

将来のロードマップは気にしません。 私はクライアントとビジネスを失うことを気にかけていますが、これまでのところ、グーテンベルクチームの誰もその懸念を共有していないようです。 私たちの収入のコアプラットフォームが私たちが行きたくない方向に全力で前進しているとき、私たちは何をすべきでしょうか？ そして、「将来のロードマップ」の名の下に私たちの懸念が払拭されたとき、私たちは何をすべきでしょうか？

私はすべて、ウィジェット、挿入、およびショートコードをユニバーサルブロックシステムに置き換えることに尽力しています。 それは良い考えだと思います-私はその背後にいます。 ユーザーがサイトのレイアウトをより細かく制御できるようにするのが好きです。なぜですか？

実際のコンテンツ作成ツールは、現在、私のクライアントの1人（300人以上）が使用したくない、熱狂的な混乱であるため、私は心配しています。 彼らは実際にそれを恐怖で見ています、そして素敵な小さなYouTubeデモとビデオ、そして記録されたWordPressの話はすべて、彼らがどれだけそれを嫌っているのかを示しているだけです。

彼らはブロックで書きたくないのです！ 彼らはブロックベースのエディターを望んでいません！ 彼らは皆それを嫌っています-彼らはそれがMSWordやGoogleDocsのように機能することを望んでいます。なぜならそれは彼らが通常何かを書くために使うものだからです。 それが彼らが望んでいることです。

WordPressがやりたいのは、ブロックを喉に突き刺すだけの場合、どうすればそれを彼らに与えることができますか？

私が持っている唯一の選択肢は、グーテンベルクをオフにすることです。 だから、私はそうするための信頼できる方法が欲しいのです。 少なくとも、この開発トレインが理解され、実際に使用する価値のあるものを作成するまでは、ブロックメカニズムとしてではなく、実際の編集者として使用してください。

テキストがブロックに基づいていない機能的なエディターが必要です。 グーテンベルクはいつそれを提供しますか？ それに答えれば、グーテンベルクを無効にする方法はもう必要ないということをお伝えします。 それまでは、何百万ものWordPressユーザーや企業に実際に共感し、気を配り、信頼できるグーテンベルクをオフにする方法を提供してください。つまり、別のプラグインではなくコードを意味します。

コードレベルからグーテンベルクを非アクティブ化する方法が必要です。 その礼儀をしてください。 別の礼儀正しい答えを与えないでください-それがすべて横向きになった場合、ただいまいましいことをオフにする方法を私たちに与えてください。

@pento 、何年もの

グーテンベルクの一部としてそのオプションを削除することを提案する人はまだいませんでした。現在の小さなものを使い続けることができなくても、グーテンベルクからテキストベースのエディターに移行できることは私にはあまり意味がありません。 tinymceはテキストウィジェットとwp_editorAPIの一部として引き続きサポートされる必要があることを念頭に置いて、アクティブに維持されているコアAPIを公開するためにプラグインをインストールするように強制する開発やUIの意味はありません。

何らかの理由でそのユーザーオプションを変更してグーテンベルク関連の設定を含めたくない場合でも、グーテンベルクのオフをサポートする限り、ソフトウェア開発POVから、グーテンベルクの一部であり、次のように維持されるAPIである必要があります。その開発の一部。 インポータープラグインが示すように、「コア」プラグインでさえ同期がとれなくなり、主に実際のコア開発の一部ではないために使用できなくなります。

このようなAPIをコアの一部として維持することを拒否するということは、おそらく2018年にリリースされる5.1でも、グーテンベルクを無効にするというコミットメントがないことを意味します。このようなAPIを使用して中期的な計画を立てることは期待できません。不確実性。

@pento長くて詳細な回答をありがとう。 これは、グーテンベルクを無効にする方法だけでなく、デフォルトで有効にするかどうか、またどのように有効にするかについての問題ではないと思います。 あなたの答えは両方をカバーしていると思いますが、それは私を悩ませます。

私は、ここと他の場所の両方で、クラシックエディターがWPから削除され、「クラシックエディター」プラグインがそれを再び追加することを意味していることに非常に驚いています。これは正しい理解ですか？ これは私には本当に悪い考えのように思えますが、今のところ理由を明確にすることはできません。

@markkapは、テキストウィジェットとwp_editor APIについても良い点を示しています。TinyMCEが削除された場合、これらはどのようにコアに保持されますか？

そして、グーテンベルクの読み込みを防ぐためにmeta_box / CPTコードを編集することは問題ありませんが、実際には、私はおそらくクライアント向けに60〜80のサイトを構築している唯一のフリーランサーです。 私はそのすべてのコードを編集するつもりはなく、それらの小さなクライアントの多くは私にそうするためにお金を払うことを望まないでしょう。 私はこれをオプトアウトよりもオプトインにすることを強く望んでいます。グーテンベルクは、サポートを宣言するときにオンにする必要があります。 ここでも、デフォルトは逆方向です。 あなたは、物事が変化したり壊れたりするのを防ぐために、人々に変更を強制しています（必要に応じて、これについて別の問題を提起できてうれしいです）。

WordPress 5.5または6.0を使用していて、クラシックエディターを使用している場合は、クライアントに多大な損害を与えることになります

（私の水晶玉も使っています）私は必ずしもこれに同意するとは思いません。 グーテンベルクとブロックが今後のすべてのユースケースでより良い編集体験になるとは言えないと思います。

また、ここでは「ブロック」の性質について少し混乱しています。 これはおそらく用語ですが、次の1つ以上が当てはまることを意味します。

• 私が作るのに苦労している、または何かを誤解しているパラダイムシフトがあります
• 新しいパラダイムはあまりうまく伝えられていません
• 私のような開発者がクライアント向けのコンテンツ管理ツールを構築するためにWordPressを使用する方法はよく理解されていません
• 私のような開発者がクライアント向けのコンテンツ管理ツールを構築するためにWordPressを使用する方法はよく理解されており、無視されています

あなたは言った：

今後数年間で、サイトデータを管理するための「ブロック」の概念は、データについて考え、レイアウトし、対話し、編集するための主要な方法になります。

これは私を少し怖がらせます、そして私はそれに戻ります。

https://wordpress.org/gutenbergのグーテンベルクのページはこの説明に同意していないようです。 ブロックを「コンテンツブロック」と呼び、次のように説明します。

[ブロック]はコンテンツをスタイルするための統一された方法です

_注：私はバックエンド開発者であり、データに関して非常によく考えています。システムに存在するデータ、データアイテムのプロパティ、データアイテムの関連性、データのクエリと操作の方法です。_

私の理解では、「ブロック」は、投稿やページなどを構成するために使用できるコンテンツのセクションです。 これらは主に、下位互換性のためにHTMLコメントを使用してデータベースの投稿コンテンツ内に保存されますが、post_metaなどの他の場所にデータを保存するようにブロックを構成することもできます。 （注：これは、私のような人々がメタデータをブロックに入れることに満足し続けるためのハックのように感じます-ブロックの性質についてよく考えられた設計上の決定のようには感じません）

あなたが言うことにおけるあなたの含意は、ブロックが_すべて_を駆動することであるということです。 これらは「サイトデータ」の管理方法です。 これとあなたが言った他のことは、ブロックが単なるコンテンツのセクションではなく、サイトオプション、カスタマイズ、投稿に関するメタデータ、ウィジェット、メニューなど、あらゆるものに接続できるある種のユーザーインターフェイスデバイスであることを意味します。ユーザープロファイルフィールド、すべて。

したがって、「ブロック」の性質について明確にする必要があると思います。

あなたが示唆していることが正しければ、これは私のような人々がWordPressをどのように使用しているかについての根本的な誤解を表していると思います。 そして、このアプローチが、WordPressの列車から飛び降りて、いくつかのプロジェクトの代替CMSを見つけるように私を駆り立てるものになると思います。 WordPressはブログや雑誌向けですが、カスタム投稿タイプによって提示される機会の多くはなくなります。

WordPressのメタデータは、説明されているとおりです。データに関するデータです。 これは、コンテンツのアイテムに追加のプロパティを与える情報です。 メタデータはコンテンツではありません。 そして、IMOは、私が理解しているように「ブロック」に配置するのには適していません。私が作成する投稿タイプの中には、タイトル以外のコンテンツがないものがあります。プロパティ/フィールド/メタデータのみがあります。

あなたがここで説明していることが本当なら、なぜ投稿ステータスがブロックされないのだろうか？ カテゴリとタグがブロックされないのはなぜですか？ 抜粋がブロックにならないのはなぜですか？

個人的には、コンテンツではなく、コンテンツに関する情報であるため、理解しているので「ブロック」とは思いません。 UIでのそれらの位置は重要です。 ユーザーがこれらの情報をどのように操作するかが重要です。

私が作成するpost_metaのいくつかは同じです。

私はグーテンベルクと投稿やページを作成するためのブロックが好きです。 しかし、私が「ブロック」を誤解しているか、プロジェクトが「ブロック」に適さないデータを人々がどのように使用しているかを誤解しています。

これを明確にできてうれしく思いますし、説得しても構わないと思っています。 しかし、「データについて考え、レイアウトし、操作し、編集するための主要な方法」としてブロックを使用することは、私がWordPressで構築したものに適合しないようです。

そして、これをここでの主要な問題に戻すと、これがクラシックエディターをコアから削除する必要があるとは思わない理由です。また、v5にアップグレードするときにユーザーが自動的にグーテンベルクをオンにしたくない理由です。 .0。

@rosswintleは、あらゆる点で完全に要約しており、私が話したほとんどすべての開発者は同じように感じています。 誰かがこれらの懸念に耳を傾け、私たちが皆のための解決策を見つけることができることを願っています。

グーテンベルクを新規インストールのみのデフォルトの編集エクスペリエンスにするための+1を追加します。

@rosswintleが言ったように、クラシックエディタに戻るための時間の支払いに興味がないクライアントを持つ数十万のWP開発者がいます。 既存のサイトをそのまま継続し（もちろん、新しいエディターを使用可能にしますが、期待どおりでない場合は元に戻します）、Gutenbergを新しいインストールでロールアウトします。

WPサイトを持つすべての中小企業の所有者について考えてみてください。 何年も前に開発されたサイトで、新しい開発はなく、順調に進んでいます。 突然、これらのユーザーはグーテンベルクを強制され、新しいインターフェースを学ぶ必要があるだけでなく（これらのユーザーはそもそも技術に精通していない可能性があり、グーテンベルクは彼らにとってより直感的である場合とそうでない場合があります）、それは防ぐかもしれません彼らは彼らのサイトコンテンツを編集することから。

考慮すべきWordPressの評判もあり、WPはセキュリティの脆弱性に満ちているという意見を払拭しようとしています。 @wpmarkと私は、週の初めに誰かとランダムな会話をしました
ユーザーが自分のサイトが壊れていたり、操作が難しいと感じるリスクはありますか？ これは、今後数年間でWPの評判にどのように影響しますか？

新しいサイトはグーテンベルク対応にする必要があると思います。これは、5分間のインストール中に屋上から叫ばれる大きな機能になる可能性がありますが、レガシーサイトはそのまま継続してください。

新しいインストールのためにグーテンベルクをオンにするだけの質問が、無効化のしやすさに関するこの有効な懸念で失われることを望んでいませんでした。 これがその特定の問題ですhttps://github.com/WordPress/gutenberg/issues/4423

あなたの考え、投票、フィードバックをそれに追加してください。 @joffff @wpmark @rosswintle @markkap @dmje

@rosswintleにスポットを当てます。

グーテンベルクのサポートを宣言するときは、グーテンベルクをオンにする必要があります。 ここでも、デフォルトは逆方向です。 あなたは、物事が変化したり壊れたりするのを防ぐために、人々に変更を強制しています（必要に応じて、これについて別の問題を提起できてうれしいです）。

私が試してみたら、これ以上同意できませんでした。 グーテンベルクを押す男と女はこれを理解していないと思います。

ロスが企業の観点から言ったことに加えて（彼は物事の小さなフリーランサーの側面をうまくカバーしました）：私が多国籍PLCのために管理しているサイトは石油タンカーのようなものです。 このような基本的な変更は、実装に非常に長い時間がかかります。 テストを通じて実施する必要があり、それでも、詳細なコードレビューおよび承認プロセスの一部である毎週のリリーススケジュールに組み込む必要があります。

これは私自身と私のチームに大きな頭痛の種を引き起こすでしょう。 実際、5.0.0の最終RCがリリースされた後、グーテンベルクの影響を徹底的にチェックできるようになるまで、おそらく4.9.xのままになる可能性があります。 これには数週間から数か月かかる場合があります。 これは簡単な修正ではありません。

また、ここでは「ブロック」の性質について少し混乱しています。 これはおそらく用語ですが、次の1つ以上が当てはまることを意味します。

•私が作るのに苦労している、または何かを誤解しているパラダイムシフトがあります。
•新しいパラダイムはあまりうまく伝えられていません。
•クライアント向けのコンテンツ管理ツールを構築するために私のような開発者がWordPressを使用する方法はよく理解されていません。
•クライアント向けのコンテンツ管理ツールを構築するために私のような開発者がWordPressを使用する方法はよく理解されており、無視されています。

絶対に後​​者だと思います。 グーテンベルクチームのメンバーは、ほとんどのプロの開発者がWordPressを使用してサイトを構築する方法を知っていて理解していることは間違いありません。

ただし、そのアプローチは完全に互換性がなく、WordPressをサイトビルダーアプローチに移行します。Automatticは、WordPress.comがSquarespace、Wixなどと競争し続けるためにそれを必要としています。

WordPressは、サイトビルダーとプロのCMSを同時に持つことはできません。 それはできません。 それは2つの間を細かく歩き、ユーザーがプラグインを介してどちらの方向にも移動できるようにしました。 （Beaver Builder、Divi et alを使用したサイト構築に向けて、およびACFやCMBなどのプラグインを備えたプロフェッショナルCMSに向けて）。 ただし、CMSがサイトビルダーの方向にしっかりと動いていることは明らかです。 カスタムフィールドを使用するサイトは気にしないでください。

最後に、ブロックとデータベースについてのあなたのポイントは的を射ています。

グーテンベルクのようなものを見る前に、WordPressチームが最初に取り組むべきであることが多くの問題を示していると思います。

• PHPの最小バージョンを更新する
• （カスタムフィールドを介して）ネイティブセマンティックデータを実装し、それを説明するためにDB構造を修正します。

最後に、Statamicのスタッフは、新しいBardフィールドタイプでこれをどのように処理する必要があるかを示しました。 グーテンベルクと同じ問題を解決するオプションのエディターインターフェイスですが、はるかにインテリジェントで混乱の少ない方法です。

私の意見を繰り返す意味はありません、彼らはすでに上で表明されています。 私は一般的なコンセンサスに同意します-4.xから5.0への移行でグーテンベルクを必須ではないようにすることは考慮されたオプションであるべきです。

ここのほとんどの開発者は多くのクライアントにサービスを提供しているので、技術に精通しているクライアントもいればそうでないクライアントもいますが、この方向にプッシュすると、大多数の人が混乱するだけだと思います。

壊れそうなものに関しては、 クライアントの観点から、彼らはすでに提供されたソリューションの予算を作成して費やしました。彼らは、サポートのために、または自分や私の作成ではない何かによって引き起こされた問題を修正するために別の予算が必要になる可能性があることを理解しません。

慎重に検討されたソリューションの開発者/設計者またはプロバイダーの間で、クライアントとプロバイダーは、そのような大きな変更をいつ有効にするかを選択する必要があります。

そこに捨てるだけです。 WordPressはセマンティックバージョニングアプローチに厳密に従っていませんが、バージョン5.0.0は重大な変更です。

Automatticがグーテンベルクに関する戦略を変更することを望まない場合（そして正直に言うと、それは正しいことです）、他の唯一のオプションは4.9をLTSバージョンにすることです。

そうすれば、セキュリティパッチを今後5年間で4.9に適用できます。 これは、Webサイト開発者がサイトをグーテンベルクに移行するか、WordPressから完全に移行するのに十分な時間です（これが最も人気のあるオプションになると思います）。

まあ、誰もが確かにここに長いコメントを書くのが好きです。 😉私にとっては夕方なので、すべてに取り組むことはしませんが、いくつかの問題に触れたいと思います。

私は、ここと他の場所の両方で、クラシックエディターがWPから削除され、「クラシックエディター」プラグインがそれを再び追加することを意味していることに非常に驚いています。これは正しい理解ですか？

それは正しくありません。 以前のコメントで、メタボックスとCPTは自動的にクラシックエディターにフォールバックできると述べました。クラシックエディターのコードが削除された場合、それらはそれを行うことができません。 🙂

TinyMCEは、編集可能なテキストブロックを強化するためにグーテンベルクによって使用されます-それはどこにも行きません。 wp_editor()ような関数は、プラグインに移動することなく、Coreで比較的簡単に保守できます

あなたが言うことにおけるあなたの含意は、ブロックがすべてを動かすことであるということです。 これらは「サイトデータ」の管理方法です。 これとあなたが言った他のことは、ブロックが単なるコンテンツのセクションではなく、サイトオプション、カスタマイズ、投稿に関するメタデータ、ウィジェット、メニューなど、あらゆるものに接続できるある種のユーザーインターフェイスデバイスであることを意味します。ユーザープロファイルフィールド、すべて。

それはまさに私が言っていることです。 まあ、メタデータはブロックではありませんが、ブロックがどのように使用または表示されるかを通知する場合があります。

したがって、「ブロック」の性質について明確にする必要があると思います。

承知しました。 ブロックは、他のブロックと一緒に収まるHTMLの塊です。 ブロックの操作を素晴らしく簡単にするAPIはたくさんありますが、それが結局のところです。

ブロックは_ではありません_：

• post_contentに保存されたHTMLの塊（一部のブロックはその保存方法を使用しますが）。
• 静的（一部のブロックはそうですが）。
• 動的に生成されます（他のいくつかのブロックはありますが）。

@rosswintle 、メタデータについて何度か言及されましたが、そこで何を参照しているのかを明確にしたいと思います。 メタデータと思われるものの例をいくつか教えてください。

あなたがここで説明していることが本当なら、なぜ投稿ステータスがブロックされないのだろうか？ カテゴリとタグがブロックされないのはなぜですか？ 抜粋がブロックにならないのはなぜですか？

単なる提案であり、それがテーマオプションであるかどうかはわかりませんが、最も新しく開発された機能は過去にあったので、なぜadd_theme_support（）の下にないのですか？

そうすれば、セキュリティパッチを今後5年間で4.9に適用できます。

WordPress 3.7が3年ちょっと前にリリースされ、最新のセキュリティリリースが6週間前だったことを考えると、WordPress4.9が今後長い間セキュリティパッチを取得すると想定するのは妥当だと思います。

@eirichmond ：Gutenberg Customizationフォーカスには、 add_theme_support()が必要になる場合がありますが、ほとんどのテーマは、変更なしでブロックエディターベースのコンテンツをサポートします。

グーテンベルクのカスタマイズフォーカスにはadd_theme_support（）が必要になる場合がありますが、ほとんどのテーマは、変更なしでブロックエディターベースのコンテンツをサポートします。

@pentoグーテンベルクカスタマイズの焦点は正確には何ですか？ どういう意味ですか？ _ほとんどの_テーマがブロックベースのコンテンツをサポートするとおっしゃっていますが、テーマがそれをサポートしない理由を示していただけますか？

ブロックが全角であることを示しているため、サイドバーが特定のブロックをサポートしていないテーマが表示されます（例：カバー画像）。

グーテンベルクのカスタマイズの焦点は正確には何ですか？ どういう意味ですか？

マットは言葉の状態でそれについて話しました-今年の3つの焦点は次のとおりです：

• グーテンベルク編集者
• グーテンベルクのカスタマイズ
• グーテンベルクのテーマ

グーテンベルクエディターはWordPress5.0に搭載されているものです。 グーテンベルクのカスタマイズは始まったばかりであり、サイトのカスタマイズと、それがブロックパラダイムでどのように機能するかを検討しています。 グーテンベルクのテーマは今年のデフォルトのテーマであり、年内に開始される可能性があります。

したがって、テーマがそれをサポートしない理由を示すことができますか？

うまくいけば、すべてのテーマがうまくいくでしょう。 🙂一部のブロックにはCSSが関連付けられているため（カバー画像が良い例です）、何かが正確に正しく表示されない可能性があります。 ただし、テーマが機能しなくなる原因となるものは何もありません。

グーテンベルクはAutomatticプロジェクトではなく、貢献する非Automatticianの努力と仕事を切り下げてはならないことを人々に思い出させることができますか

プラグインが不十分である理由についてもまだはっきりしていません。私が見たすべての議論は、人々がグーテンベルクを好きではない、またはワークフローがすでに設定されている、以前に言及されたすべての問題、およびすべてが修正されたと主張していますクラシックエディタプラグインをインストールして有効にする。

リンクプラグインにも前例があることに注意してください。

しかしとにかく、建設的にしましょう：

WP 5.0にアップグレードし、グーテンベルクがカスタムエディターを置き換えました/気に入らない/クライアントとの時間がもっと必要です

私は何をしますか？

クラシックエディタプラグインをインストールして有効にし、問題を解決しました。 これで、グーテンベルクは4.9のクラシックエディタに置き換えられました。

欠点？

グーテンベルクの新しい機能は利用できず、将来の新機能はクラシックエディタでは意味をなさない可能性があります。 たとえば、行と列のブロックが5.1で到着した場合、それが従来のエディターでどのように意味があるのか​​わかりません

クライアントサイトがたくさんありますが、すべてのサイトにインストールしてアクティブ化するわけではありません。クライアントが非アクティブ化した場合はどうなりますか？

MUプラグインとして使用します。

• プラグインフォルダをwp-content/mu-plugins置きます
• 以下を含むファイルをmu-pluginsフォルダーに置きます。

<?php
require( 'classic-editor/classic-editor.php' );

これで、プラグインは常にロードされ、非アクティブ化することはできません。 ファイルを配置する以外の追加の手順は必要ありません。 その後、ファイルとフォルダーをすべてのサイトに一度アップロードすれば、再度心配する必要はありません。

クラシックエディタプラグインからの教訓

このプラグインには、グーテンベルクがアクティブ化されているかどうかを検出するなどの便利な機能がたくさんあり、その大部分は実際にフックを削除して置き換えることです。

また、「クラシックエディターリンク」にオプトインするオプションを備えた設定領域を追加して、グーテンベルクを置き換えるのではなく、投稿画面の「クラシックエディター」リンクでアクティブ化されたグーテンベルクプラグインで表示されるものを取得できるようにします。 2つのオプションではなく3つのオプションがあります。

プラグインを実際に見て、テストして、どのように構築されているかを確認することを強くお勧めします。

私たちはコミュニティであり、Automattic製品チームの主題ではないことを忘れないでください。 それが壊れた場合、それをテストして修正するためのWPリリースサイクル全体があります。 このスレッドには、プラグインを修正するための技術的なスキルを持っている多くの利害関係者がいます。 それが本当に大したことなら、コアに取り組んでいる人々がステップアップしたように、誰かがステップアップすると確信しています

@rosswintle 、メタデータについて何度か言及されましたが、そこで何を参照しているのかを明確にしたいと思います。 メタデータと思われるものの例をいくつか教えてください。

@pento確かに：

国の例：

名前（タイトル）、説明（コンテンツ）、そして次のような「国」の投稿タイプ。

• 人口
• 旗の画像のURL
• ランキング（および他の要因、おそらく何らかの方法でエンコードされている）
• 関連する「コミュニティ」（別のタイプの投稿との関係）

参照： http ：

不動産の例：

次のような「プロパティ」タイプ：

• 価格
• タイプ
• 室数
• 建設日
  等

イベントの例：

次のような「イベント」タイプ。

• 日付
• 時間
• 再発の詳細
• ロケーション
  等

沢山あります。

それを有効にして少し遊んだ後、私はいくつかの大きな懸念を持っています...私は今のところ主要なものに集中します：

WooCommerceは完全に壊れます...製品を編集するときにそこにさえないように。 そして、もっと多くのプラグインも完全に壊れると思います。 では、コミュニティの互換性を支援するための計画は何ですか？ そして、どれくらいの期間を取得しますか？

@tomjn

私が見たすべての議論は、人々がグーテンベルクを好きではない、または彼らはすでにワークフローを設定していると主張しています

「嫌い」はおそらく間違った用語です。 人々はグーテンベルクがWordPressのユースケースの多くに適していないことについて良い議論をしていると思います。 それは好みや好みの場合ではなく、適合性の場合です。

そして、開発者はこれを行うためのオプションを望んでいます。 wp-config.phpで、デバッグ、コードエディター、マルチサイト、自動更新、改訂後の投稿など、他の主要な機能を切り替えることができます。 一部の機能は、 add_theme_supportを使用してそれらをサポートするテーマによってのみ有効になります。 開発者がそのような大きな変更に適したワークフローを使用できるように、同じ種類の方法でグーテンベルクを切り替えるコード内オプションがないのはなぜですか？

ここでの問題の1つは、開発者（必ずしも私ではありませんが、他の人）がグーテンベルクについて懸念を表明しているため、彼らが耳を傾けていると感じていないことです。 これをトークンジェスチャとして追加して彼らを助けると、彼らをもう少し味方につけるのに役立ちます。 あなた自身の哲学的な理由でそれが正しいことであることに同意しない場合でも、それを満足していない開発者に提供できるオリーブの枝と見なしてください。

リンクプラグインにも前例があることに注意してください。

リンクプラグインはここでは悪い例です。 コア内の既存の機能を使用している場合は保持し、新規インストールの機能のみを削除しました（または使用していなかった場合）。

私はこの前例が好きです。

これが＃4423で議論されていることです

本当に私を惹きつけているのは、コア開発者とマットが、全世界が「ブロック」の概念とグーテンベルクエディターを間違いなく完全に採用しようとしていると想定していることです。 それはすべてうまくいっていると思いますが、彼らがグーテンベルクで使用しているこの「私たちの方法または高速の方法」のアプローチは、ユーザーフレンドリーであるだけでなく、WordPress全体の状態に深刻な影響を与える可能性があります。

単に大衆に採用されなかったために固執しなかった、本当に素晴らしいアイデアが時代を超えてたくさんありました。 ベータマックスははるかに優れたフォーマットでしたが、それは固執し、VHSが勝ちました。 グーテンベルクとブロックがくっつかない場合はどうなりますか？ では、WordPressはどうなりますか？

次に、信頼要素があります。 WordPressユーザーの大多数は、WordPressが何であるかさえ理解していません。 彼らはWordPressが人気があるというブランドのためにそれを使用します、そしてあなたがそれをどのように見てもほとんどの人にとってWordPressはただのブランドです。 ブランドは消費者の信頼によって生きたり死んだりします。

5.0アップデートがようやく公開され、何百万ものWordPressサイトが突然これを劇的に変えたとき、WordPressの世界について何もフォローしていないエンドユーザーはどのように反応するのでしょうか。

私のクライアントのほとんどは、「コンピューターの電源を入れることはほとんどできない」と言っているか、彼らが支払った金額を約束どおりに機能させたいと思っています。 これらは、WordPressが約束したことを実行することを信頼した人々です。 ある日、サイトのコンテンツを管理するためのまったく新しいフォーマットが原因でその約束が破られた場合、突然変更されます。 そうすると、WordPressに対する彼らの信頼は失われ、人々はそれを信頼しなくなった場合、ただ立ち上がって何かを落とすでしょう。

これは、開発者が抱える懸念のほとんどがそこから来ていると私は信じています。 私たちは、クライアントが望むとおりに機能する優れたカスタムWordPressサイトを構築していますが、グーテンベルクのせいですべてが「壊れて」しまい、大災害を防ぐ選択肢がありません。

グーテンベルクの唯一の目的はWordPressMarkeのシェアを増やすことですが、それは非常に簡単にその逆を行うことができます。 それは実際に人々をWordPressから遠ざけることができます。 グーテンベルクはWordPressの新しいコーラになる可能性があり、WordPressはコーラほど大きくはなく、コーラのように回復することができます。 人々は他の何かに移り、振り返ることはありません。

あなたは「グーテンベルクの養子縁組の将来に影響を与えるだろう、何とか、何とか、何とか」について続けますが、それは本当にこれほど単純です。 誰もがそれを気に入るはずであり、コードやプラグイン、または無関係になるものを介してそれを削除する必要があるか、GutenbergはPressThisのように誰も実際に使用しない奇妙な機能になります。

現在のところ、グーテンベルクが成功するか、WordPress全体が失敗する可能性があるという方向性がとられています。 私たち開発者は、コンテンツ管理のための優れたツールを完全に台無しにしないように努めています。 私たちは、クライアントがWordPressにどのようにアプローチし、使用するかを誰よりもよく知っています。 コア開発者とマットは統計と市場シェアのみを調べていますが、それが私たちに何をもたらしたのか知っていますか？ ゴーストバスターズが再起動します。

私たちは本当にこれを実現するためにあなたと協力したいと思っていますが、疑いを持たないユーザーに強制するのではなく、これが世界にどのように導入されるかを制御できればもっと良いでしょう。 私たちが求めているのは、クライアントが新しいエディターに簡単にアクセスできるようにする方法だけです。 求めることは本当に多くありません。

グーテンベルクが本当にそれが約束した革新になるのであれば、それは素晴らしいことです！ 誰もがグーテンベルクの電車に乗ります。 そうでない場合は、大災害にならないようにするオプションを求めます。

好評を得られないことを知っていて、これをひどく起こさせたいので、それが成功する可能性がある唯一の方法は、それがすべての人に強制された場合であると感じるようなものです。 それは、実際には超富裕層だけが実際に恩恵を受けるのに、誰もがそれを通過させるのに役立つ税法案について、政治家が大胆な嘘をついているようにあなたに言うようなものです。

それは偉大なコックス博士がかつて言ったことのようです。

私があなたを助けるのを手伝ってください。私があなたを助けるのを手伝ってください。私があなたを助けるのを手伝ってください。私があなたを助けるのを手伝ってください。

WooCommerceは完全に壊れます...製品を編集するときにそこにさえないように。 そして、もっと多くのプラグインも完全に壊れると思います。 では、コミュニティの互換性を支援するための計画は何ですか？

@ smp303これについて議論する場所ではありませんが、現在WooCommerce + Gutenbergの互換性に取り組んでいます。 WooCommerceの開発ブログに注目してください。

おそらく、「NewCoke」よりも優れた例えはWindows8です。

それは、あまりにも多くの基本的な使用の仮定を変更したためにひどく裏目に出た、よりモバイルコンピューティングの考え方に対する大胆な新しいビジョンでした。 はい、設定の奥深くで、ユーザーは以前のWindowsエクスペリエンスの多くを取り戻すことができましたが、技術ジャーナルに載っていない限り、ユーザーはそれを行う方法を知りませんでした。 その結果、Windowsは大惨事になりました。

グーテンベルクは同じ道を非常に速く進んでいます。 それは、コミュニティではなく会社によって完全に推進され、巨大な変化をもたらしています、そしてそれはそれらのための伝統的なエディターに戻るために外部プラグインを介してかなりあいまいな道を残しています（私はこれについての詳細はほとんど見えないと思います）この新しい方法論が気に入らない人。

Automattic / WordPressが設定で何百万ものカジュアルなWordPressユーザーに対してグーテンベルクを無効にする手段を提供しない場合、彼らはそれを深く後悔するだろうと思います。 グーテンベルクは大きな変化です。 ユーザーからの反発がたくさんあるでしょう。

このスレッドでは、これに対して警告し、外部プラグインでは不十分であるとアドバイスしようとしています。 調整期間を許可するためだけであっても、ユーザーにグーテンベルクへの「アウト」を提供する必要があります。 コードを介して既存のテーマにアクティブ化できれば、災害を回避できる可能性があります。

私たちは必死になってここで助けようとしています。 外部プラグインでは不十分です。 クラシックエディターに戻すオプションを組み込む必要があります。リリースの一部としてそれを行うか、テーマに組み込むことができるコードを介してそれを行う方法を提供します。

ロジックの観点から、add_meta_box（）内で開発者がメタボックスを宣言してグーテンベルクをサポートしないようにするという哲学を理解しようとしています。これにより、メタボックスが使用されている場所ならどこでも、エディター画面に「クラシックバージョン」が表示されます。エディター画面の。 では、なぜ一部の開発者はwp-config.phpファイルで定義された定数に反対しているのでしょうか。 グーテンベルクのものがコードの1つの領域で使用されないことを宣言できる場合、現在定義ステートメントを設定しているように、他の領域で使用されることを宣言できないのはなぜですか？

一定の場合、クラシックエディタープラグインはカスタムローダーを備えたWordPressにバンドルされ、永続的に存在する必要があることに注意してください。 グーテンベルクに取って代わられるものが何であれ、それは10、15年後もまだそこにある可能性があります。

それでも、両方のエディターが必要または必要な場合は、とにかくプラグインが必要です。

グーテンベルクの到着を見越して、v4.9でもプラグインをインストールしてセットアップできることを忘れないでください。

Automattic / WordPressが提供しない場合

@robmcclel AutomatticはWordPress、WordPress.orgではありません！= WordPress.com、1つはオープンソースコミュニティ、もう1つは有料のサードパーティサービスです。 AutomatticはWordPressのバージョンをリリースしていません。また、WordPressはAutomatticの内部製品ではなく、Gutenbergでもありません。 Automattic以外の貢献者、リリースリードなど、Automattic以外のことをしている人はたくさんいます。

「それでも、両方のエディターが必要または必要な場合は、とにかくプラグインが必要です。」

実際、ここや他の場所で説明したことから、カスタム投稿タイプまたはメタボックスがグーテンベルクをサポートしないと宣言した場合、エディター画面は自動的にフォールバックします...「クラシックエディター」プラグインは必要ありません。 これは、グーテンベルクプロジェクトの現状に関して多くの人が抱えている問題の1つであり、特定の状況で何が起こるかについて多くの意見/声明があり、それらの声明/意見は他の声明とは異なることがよくあります。

一定の場合、クラシックエディタープラグインはカスタムローダーを備えたWordPressにバンドルされ、永続的に存在する必要があることに注意してください。

@tomjn待って！ それで、メタボックスシステム全体がコアから取り除かれていると言っているのですか？

いいえ、メタボックスについてはまったく触れていません。 ただし、メタボックスはグーテンベルクに存在することに注意してください。メタボックスが削除されていることを示唆することは、グーテンベルクをテストしていないことを意味し、エコシステムの大部分がメタボックスに依存していることを無視します。 それはwordcamp.org、wordpress.orgなどにとって大きな問題になるでしょう

参考までに、私はグーテンベルクチームのメンバーではありません。常識を守り、適用するだけです。 Automatticで働いているからといって、グーテンベルクに特別な力があるわけではありません。 私はここにいる他のみんなと同じように発言権を持っています。それを変更したい場合は、他の人と同じように、コードを提供して問題を修正することでそれを行います。

@tomjnそれで、あなたが言ったことは私には意味がありません。 「クラシックエディタ」は基本的に、メタボックスと保存機能などを備えた単なる管理ページです。 つまり、グーテンベルクとクラシックを切り替えるには、2つのオプションを許可するコードがコアに組み込まれている必要があり、クラシック機能のすべてのコードがそのまま残ります。

つまり、Classicプラグインはスイッチをトリガーする方法に他なりません。 プラグインをビルドして維持するよりも、コアで定数またはテーマサポートタイプのものをビルドする方がはるかに簡単なようです。

Classicのすべてがまだコアにある場合、なぜそれをアクティブ化するためだけにプラグインを作成するのですか？

そして、それが所定の位置に留まらなければならない場合はどうなるでしょうか。 WordPressコアにはすでにたくさんの古くて非推奨のコードがあります。 組み込みのClassicトリガーは、物事の壮大な計画にまったく違いはありません。

ここでトムを不誠実にしないようにしましょう。 Automatticは、グーテンベルクの背後にある原動力です。 Automatticの従業員からの「量はありませんが、そうではありません」は、晴れた日の空の太陽と同じくらい明白であるという事実を変えるでしょう。

グーテンベルクはマットの赤ちゃんです。 Automatticもそうです。 彼はプロジェクトを推進しました。 彼はその最大のチアリーダーでした。

Gutenbergは、Automatticに重大な運用上の利点をもたらします。つまり、最大の競合他社とのプレイ感を平準化する製品を提供します。 コミュニティの他の部分についても同じことは言えません。

はい、多くのWordPressユーザーはプラグインを介してページビルダーを利用しています。 ただし、別の大部分は、ACFやCMB（およびその多くのフォーク）などのプラグインを介してカスタムフィールドを多用します。 コミュニティのその部分は、WordPressプロジェクトがカスタムフィールドをネイティブ機能として実装することを何年もの間叫んでいます。

しかし、それを実現するための資金がなかったため、実現に失敗し、それが持ち上がるたびに、委員会による死の議論という非常に一般的なオープンソースの問題に苦しんでいます。

他の多くの差し迫った問題も同じ運命をたどっています。たとえば、min-PHPバージョンを7年以上サポートが終了していないものにぶつけた場合などです。

これらは、プロジェクトの主要な資金提供者がそれをサポートしていないためにまだ達成されていない、何年も前に行われるべきだった事柄のほんの一握りの例です。

Automatticは、主にマットが運転席にいる直接の結果として、グーテンベルクの後ろにその重みを投げかけました。 それを実現するために、膨大な数の営業時間が費やされてきました。 これは、WordPressプロジェクトの主要な資金提供者であるAutomatticからの直接資金提供に相当します。

これがチケットにどのように関連しているかわかりませんか？

@rosswintleこれは非常に関連性があります。 グーテンベルクをオフにすることを選択する簡単な方法を望んでいる開発者はたくさんいます。 の勢力が私たちにこれを与えたくないこと、そしてグーテンベルクをオフにすることを可能な限り不便にすることを望んでいないことはかなり明白です。

この決定の背後にある原動力は、DIYWebサイトスペースでの市場シェアを拡大​​するためのMattとAutomatticのアジェンダです。 MattとAutomatticがプロジェクトに影響を与えているため、コミュニティの懸念に対処していないことは明らかです。 これは、グーテンベルクに対するコミュニティのフラストレーションの100％が原因です。

グーテンベルクプロジェクトの方向性はマットとオートマットの影響を大きく受けているため、プロジェクトに関するすべての議論と同様に、この議論にも関連しています。

@tomjn

グーテンベルクとこの次のリリースの時点で、WordPressはAutomatticの製品です。 他のものを信じることは愚かです。 .Comまたは.Orgは関係ありません-WordPressプログラムはAutomatticの製品になりました。 現在、開発者などがそれに取り組んでいるのは、Automatticの無給のインターンにすぎません。

コミュニティはグーテンベルクをプラグインとして望んでいます。 マットはしません。 マットはAutomatticの責任者です。 マットは、このリリースの自己任命されたリードです。 グーテンベルクの開発を主導しているのはAutomatticの従業員です。 マットはこれを強制しています。 他に決定や議論はありません-彼は投票の51％を持っており、彼はそれを行使しています。

WordPressが何らかの形で民主的またはコミュニティの製品を形作っている、または形成していると思い込まないでください。 現在はAutomatticの製品ですが、過去にフレーム化または販売されており、現在は開発の焦点、ペース、決定を指示しています。

@rosswintle 、コミュニティがグーテンベルクをオフにする方法を求めているという点でチケットに関連しており、グーテンベルクチームは、コミュニティが非常に重要であるかどうかに関係なく、プラグインがそれを行う唯一の方法になると応答しています大規模な全体が求めています。

MattとAutomatticは、これに対する権限を行使しています。 私たちの声は、同情を伝え、私たちに逃げる場所を与える以外にはもはや関係がないので、あなたはこのチケットとそれを好む他のすべてのチケットを閉じたほうがよいでしょう。 このチケットは存在しないかもしれません。

Automatticがこれを担当し、コミュニティではありません。 これが起こっており、唯一のオフランプはクラシックエディタプラグインであり、それでも少し慈善であるため、私たちはそれに直面し、影響に備える必要があります。 他には何もありません。

個人的には、ここで誰が決定を下しているのかを話し合うことが、問題を前進させるのにどのように役立つのかわかりません。 オープンソースプロジェクトとして開発されているので、声を出すことができます。オプションの開発とこのオプションを実装する理由を支援することで、建設的に声を使用することをお勧めします。

行われているリクエストのトピックに関する最後の投稿は@tomjnによる@wpstudioと@jawittdesignsからのいくつかの関連する質問が続きました。

一定の場合、クラシックエディタープラグインはカスタムローダーを備えたWordPressにバンドルされ、永続的に存在する必要があることに注意してください。 グーテンベルクに取って代わられるものが何であれ、それは10、15年後もまだそこにある可能性があります。

定数が廃止されたことはありませんか？ （本物の質問）WPLANGはv4.0にあったように見えますか？ これは定数の性質についての哲学的なことですか？ フィルターの方がいいでしょうか？ フィルタは@ smp303に受け入れられますか？

それでも、両方のエディターが必要または必要な場合は、とにかくプラグインが必要です。

何故ですか？

@jawittdesigns正しく尋ねます：

Classicのすべてがまだコアにある場合、なぜそれをアクティブ化するためだけにプラグインを作成するのですか？ そして、それが所定の位置に留まらなければならない場合はどうなるでしょうか。 WordPressコアにはすでにたくさんの古くて非推奨のコードがあります。 組み込みのClassicトリガーは、物事の壮大な計画にまったく違いはありません。

そして@pentoはそれのほとんどの削除をほとんど除外しました：

TinyMCEは、編集可能なテキストブロックを強化するためにグーテンベルクによって使用されます-それはどこにも行きません。 wp_editor（）のような関数は、プラグインに移動することなく、Coreで比較的簡単に保守できます。これらの関数は、無期限に機能し続けると思います。

最終的に：

グーテンベルクの到着を見越して、v4.9でもプラグインをインストールしてセットアップできることを忘れないでください。

私たちは皆これを知っています。 私たちは、さまざまなワークフローを持つ開発者にオプションを提供するさまざまな方法を提唱しようとしています。

@rosswintle –誰が決定を下しているのかを最終的に知ることで、私たちの要求が受け入れられる可能性と、可能な限り影響力があると表現する方法が明らかになるため、それについて話し合うことが重要です。

しかし、はい、あなたはこの特定の問題がそれを議論するのに適切な場所ではないという点で正しいです。 しかし、私たちの要求に応じることを拒否することは、私たちが決断を下す人々と比較して弱い立場にあるという事実を示しています。

とにかく。 あなたは最後の投稿でいくつかの良い点を述べています。 実際、あなたの見積もりを取り上げさせてください。

一定の場合、クラシックエディタープラグインはカスタムローダーを備えたWordPressにバンドルされ、永続的に存在する必要があることに注意してください。 グーテンベルクに取って代わられるものが何であれ、それは10、15年後もまだそこにある可能性があります。

グーテンベルクに取って代わるものが出てきたら、まったく同じ議論をすることはないと思いますか？ WordPressの大きなUSPは常に、競合他社と比較して下位互換性に専念してきました。 それは今までうまくいきました。 私たち全員が指摘したように、グーテンベルクはそれを破ります。 私たちが現在持っているものにとどまる選択肢はほとんどありません。事実上、公式に認可されたハックであるものを禁止します。

実際のところ、コードはすべてまだコアにあります。 プラグイン上で定数（1行のコード）を使用できるようにすることは、はるかに賢く、より適格なアプローチであり、プラグインは個別に保守する必要があり、最終的には数百行のコードになります。

実際のところ、コードはすべてまだコアにあります。 プラグイン上で定数（1行のコード）を使用できるようにすることは、はるかに賢く、より適格なアプローチであり、プラグインは個別に保守する必要があり、最終的には数百行のコードになります。

これは完全に私のポイントです...これを必要とするのはニッチな数の人々だけではありません。 グーテンベルクが現在正しく機能していないため、プラグインやテーマなどが大量に壊れています。別のプラグインは修正ではなく、ハックであり、依存関係です。 最高のWordPressサイトを作っている人々のコアを追い払ってしまう可能性のある問題を修正する正しい方法ではありません。

私を最も怖がらせるもう1つのオプションは、人々が4.9に固執し、サイトをアップグレードしないことです。 その後、これらは不安定になり、ハッキングに対してオープンになり、WordPressの名前を失います。

これに十分な考慮が払われているとは思えないので、プラグインが最終的な解決策である理由はわかりません。

TinyMCEが特定のブロックでグーテンベルクの「下」にあり続ける場合は、次のような状況にアプローチしてみませんか。
5.0より前（WordPressを利用した現在のサイト）では、デフォルトでGutenbergが無効になっており、フィルター/定数を使用してGutenbergを簡単に有効にできます。
5.0以降（5.0以降にインストールされているWordPressサイト）では、デフォルトでGutenbergが有効になり、フィルター/定数を使用して簡単に無効にできます。

このように、グーテンベルクを使用したい人は誰でも簡単にその選択をすることができ、グーテンベルクを使用する準備ができていないか（何らかの理由で）喜んでいない人も簡単にその選択をすることができます。 より実用的な（短期的には）解決策があるように見えるときに、グーテンベルクの丘の上に死にかけている立場を作りたいと思う人もいるようです。

@wpstudioこれは、＃4423が求めているものとほぼ同じです。

@rosswintleのように、この問題を解決した人たちのために、この問題を軌道に戻すことが重要だと思います。最後のいくつかのコメントがそうであるように思われることを喜んでいます。 敬意を持って話し合っている方、ありがとうございました。

とはいえ、会社とその動機についてどのように感じても、多くの人々がさまざまな会社でグーテンベルクに取り組んでいます。 WordPressの場合と同様に、これは（1つの会社だけでなく）コミュニティの貢献で構成されています。 抜本的な発言をすることは、これに取り組んでいる人々にとって公平ではありません。 また、この問題を開始し、解決策を求めている人々にとっても公平ではありません。

この問題が軌道に戻り、この問題のポイントについて敬意を持って議論し続けることを願っています。

@ karmatosed 、 @ ntwb 、 @ tomjn 、およびこのスレッドの他の人たち、上記の私の小さな暴言が

上記のスレッドから、他のコンポーネントはCoreの一部として残しておく必要があるため、CoreでGutenbergを無効にできることは明らかだと思います。そのため、Gutenbergをオフにしているだけです。 現在プラグインとして存在し、多くのサイトで問題なく実行できるため、これは理にかなっています。 したがって、これまで提示されていなかった技術的理由を除けば、この決定は技術的なものではなく、哲学的なものであることを意味します。

そして、それがその真の核心です。 私は、コミュニティ全体がこれについて一つの心を持っているとは思いません。 程遠い。 これが、マットがその背後にある原動力であるように見えるため、決定が行われている理由です（私が「非難」ではなく「配置」と言ったことに注意してください）。 そして、明らかに、グーテンベルクをコアと5.0リリースの一部にするという揺るぎない決定の背後にあります。

質問は「なぜ？」です。

グーテンベルクをコアに強制する背後にある理由は確かにわかります。 「ブロック」は、WordPress、.org、または.comの将来の存続と普及にとって非常に重要だと思います。 私がやります。 私は「ブロック」の100％遅れています。

しかし、それらの「ブロック」の配信方法として、グーテンベルク自体がよく考えられたシステムだとは思いません。 ただ、このスレッドから、3種類のユースケースは、（私、@rosswintle、および@ smp303）とグーテンベルクは私たちのいずれかを満たすためには表示されませんがあります。 確かに、それは私たちにかなりの懸念を引き起こしています-私たち、私たちのビジネス、そして私たちのユーザーにとって。

GutenbergをCoreに組み込むという決定は、Automatticにとって理にかなっています。これは、すべてのプラグイン開発者がGutenbergを採用し、プラグインを書き直して動作するようにするためです。 これはWordPress.comにとって非常に良いことであり、おそらくWordPress.orgにとっても良いことです。 しかし、繰り返しになりますが、一部のユースケースはブロックの恩恵を受けませんが、ブロックの存在がブロックを傷つけないことを願っています。

ただし、これは、非常に少数の人々が非常に多くの人々のために非常に強力な経済的およびビジネス上の意思決定を行っていることを意味します。 私だけでも、ブロックへの変更は数百時間と数千ドルになります。さらに、システムの重要なセクションをオーバーホールするために、計画した目標（サービスを提供するコミュニティが実際に望んでいる）からリソースを奪わなければならないという開発時間が失われます。それらの未知の意思決定者の要求を満たすために（繰り返しますが、マットはその意思決定グループの大部分であると思います）。

グーテンベルクが私のために問題を解決していれば、私はこれについてそれほど悪くは感じません-正直言って、それほど怖くはありません-。 しかし、そうではありません。 これまでのところ、それは私の人生をはるかに悪化させています。 状況は改善するかもしれませんが、開発の方向性に大きな変化は見られません。 使用、実装、UI / UX、および手段と方法に関する決定の95％はすべて、多くの議論や入力なしに、他の少数のグループによって決定されたようです。

WordPressは、インターネット全体の25％以上に電力を供給しています。 これは、数百万のサイト、数十億のWebページ、そしておそらく数千億ドルに相当します。 ニューヨークタイムズから私のネットワーク上の一握りの本のブロガーまで。 大規模なeコマースサイトから、私がサービスを提供する著者によって販売された個々の署名入りの本まで。 それは巨大です-大規模。 それは事実上世界的なグローバルユーティリティです。

それでも、これらすべての基盤のかなりの部分を書き直すという決定は、何百万もの人々に影響を及ぼし、議論なしに行われたようです。 インターフェースからREACTへの依存まですべて（非常に略奪的であることが証明されているFacebookによって制御されています。SnapChatに聞いてください）。 これらの決定はすべて、主に一方的に行われました。

これがすべてJetPackのモジュールに電力を供給するためだけのものである場合、誰も本当に気にしません。 それがWordPress.comのビジネスです。 しかし、そうではありません。 それはインターネット全体の基盤を変えています。

それが私を今ここに導きます。 コミュニティ、間違いなくこのスレッドのコミュニティメンバーは、オープンソースと公開されているWordPress.orgコードを使用して構築した製品とビジネスの管理を求めています。 私たちは自分自身とユーザーを保護する能力を求めています。そうすることを考える唯一の方法は、グーテンベルクをオフにする方法を求めることです。 グーテンベルクを追加することがコアの一部になるのと同じように、私たちはその能力がコアの一部になることを求めています。

グーテンベルクをオフにする機能をコアに追加できますか？ その決定を下し、リードにそうするように指示するのは誰ですか？ その質問をするためのメカニズムは何ですか？ 答えは議論の余地がありますか？ 投票されますか？ コメントプロセスはありますか？ もしそうなら、どこ？

そして、 @ karmatosed 、Githubの「Issues」セクションがこの議論をするのに最適な場所ではないという点であなたは100％正しいです。 このリポジトリは、Gutenbergプラグインに直接関連する技術的な問題を特定して解決するという本来の目的に大きく委ねられるべきであることに同意します。

悲しいことに、この議論をする場所は他にないようです。 つまり、グーテンベルクプラグインのレビューセクションがありますが、それはこの種の会話のためのかなり限られたフォーラムです。

グーテンベルクについて話し合うためのサイトはありますか？ その実装だけでなく、インターフェースについてコメントして議論するには？ リリーススケジュールは？ （たとえば、グーテンベルクとWP5.0が「完成」し、リリースの準備ができているかどうかを決定する基準は何ですか？誰がその決定を下しますか？」）グーテンベルクインターフェースのユーザーテストはありますか？ @からデータとフィードバックを収集する方法はありますか？

YouTubeに、グーテンベルクを試してみて、その直感性を評価するように求める興味深いビデオがありました（リンクはこちら：https：//youtu.be/7iWRBLCP-l0）-このようなものは他にありますか？ グーテンベルクをテストするための大規模な取り組みはありますか？ もしそうなら、そのデータはどこに保存されていますか？ そのデータはどのように共有されますか？ コミュニティはそれを見ることができますか？ デザインを推進するために使用されていますか？

私たちが現在グーテンベルクで直面している問題、そして実際、このスレッドの背後にある原動力は、コミュニティがこのプロセスから非常に孤立していると感じていることです。 私たちはそれが私たちに起こっているように感じます。 確かに、それは私たちに強制されています。 コメントや討論のプロセスを開き、インターフェース、データの共有、ユーザーの洞察などに関する新しい意見やアイデアを許可することは、これらの恐れや懸念を軽減するのに大いに役立ちます。

そして、ブロックをコア機能にしますが、グーテンベルクをプラグインとして維持することで、すべてがはるかに怖くなくなり、コミュニティ全体にとってはるかに口当たりが良くなります。 個人的にはそれが大好きです。 コミュニティにグーテンベルクへの代替アプローチ（さまざまなインターフェースとユースケース）を調査および開発する時間を与えますが、それでもブロックの開発と将来を奨励します。

それで、それはかなり長かったです、しかし、繰り返しますが、ここ以外でこの議論をする他の場所はどこですか？ そして、この議論は非常に重要です。 影響を受ける人々や企業の数を考えると、これは現在インターネット上で最も重要な議論かもしれません。

これについて少し調べてみると、 mu-pluginファイルで必要なのは、何かを見逃していない限り、コードでグーテンベルクを無効にするために次のようになっているようです。

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

コンテキストとして、Gutenbergプラグインをアクティブにし、上記のコードをmu-pluginsフォルダー内のファイルに入れます。 これで、すべての投稿編集画面でクラシックエディターが使用されます。

これについて注意すべき点がいくつかあります。

• gutenberg_can_edit_post_typeは最終的なフィルター名ではありません- gutenberg名前は、Coreにマージする前に名前が変更されます。
• このフィルターは、「ブロックエディターをロードしない」という意味であり、「クラシックエディターを使用する」という意味ではありません。 現時点では機能しますが、将来的に機能する保証はありません。 クラシック固有のコード（たとえば、 edit-form-advanced.php ）がクラシックエディタープラグインに移動されると、クラシックエディターへのフォールバックが停止し、独自のエディターをロードすることを明示的に期待します。

@rosswintle ：先週からスレッドをピックアップ：

これについて考える最も簡単な方法は、「データが<body>と</body>間に表示される場合、そのデータはコンテンツであり、最終的にはブロックに収まる」というものです。 WordPress 5.0の場合、これはもう少し制限されています。 <article>と</article>はブロックだけです。 😉

したがって、一例を挙げると、不動産物件の投稿タイプです。 価格はpostmetaに保存されていますが、内容です。 「PropertyLede」と呼ばれるブロックがあるかもしれません。そこには、価格、住所、建物の種類、寝室/浴室/ガレージの数など、いくつかの項目を入力する必要があります。 おそらく他のブロックもあるでしょう-検査時間、機能、写真、フロアプラン、エージェントなど。ブロックテンプレートを使用して、 property投稿タイプが編集されているときにブロックエディタを設定します。ブロックはすでに配置されており、移動できません。 エンドユーザーのワークフローは、既存のメタボックスベースのワークフローが現在どのように見えるかと同じですが、最終的な出力に非常によく似ています。

それは少し長蛇の列でしたが、うまくいけば、データが保存されている場所や、フロントエンドに表示される前にデータを操作またはフォーマットする方法に関係なく、コンテンツのように見えるものはすべてコンテンツになります。 一部のブロックはデータをpost_contentに格納する場合がありますが、それはそれらをコンテンツにするものの定義機能ではありません。フロントエンドに表示されることがそれらをコンテンツにするものです。

では、フロントエンドに表示されない情報についてはどうでしょうか。 オーナーの名前は？ 予定の表示との関係は？ それは「コンテンツ」ですか？ それは「ブロック」に入れられるのですか？

カテゴリ/タグ/分類法は、フロントエンドに表示される場合と表示されない場合があります。 それらは「ブロック」ですか？

投稿ステータスはフロントエンドに表示される場合がありますが、これは間違いなくブロックではありません。

あなたは以前に言った：

メタデータはブロックではありませんが、ブロックがどのように使用または表示されるかを通知する場合があります。

どちらでも構いません。 しかし、なぜ開発者は、将来、ブロックインターフェイスを使用してメタデータを編集する必要があると言われるのでしょうか。

これは私にとって本当の混乱です。 グーテンベルクブロックがbodyタグの間にあるものを編集するのに適している理由はわかりますが、ブロックがそれらのタグの間にない他のデータを編集するのに適している理由はわかりません。

開発者がグーテンベルクをオフにしたいと思うのは、この混乱のせいであるように私には思えます。 WordPressの使用法の中には、フロントエンドに表示されない情報がたくさんあるものもありますが、将来的にはフロントエンドエディターがこのデータのインターフェイスとして使用する必要があると言われています。

これが混乱を伝えてくれることを願っています。

それで、それを無効にするこれらの方法について...？

@pentoその関数のdocブロックは、このフィルターが一時的なものであることをまったく示していません。

/**
 * Filter to allow plugins to enable/disable Gutenberg for particular post types.
 *
 * <strong i="7">@since</strong> 1.5.2
 *
 * <strong i="8">@param</strong> bool   $can_edit  Whether the post type can be edited or not.
 * <strong i="9">@param</strong> string $post_type The post type being checked.
 */

説明されているようにしない場合、そのフィルターの目的は何ですか？

さらに、これに関する@pento ：

このフィルターは、「ブロックエディターをロードしない」という意味であり、「クラシックエディターを使用する」という意味ではありません。 現時点では機能しますが、将来的に機能する保証はありません。 クラシック固有のコード（たとえば、edit-form-advanced.php）がクラシックエディタープラグインに移動されると、クラシックエディターへのフォールバックが停止し、独自のエディターをロードすることを明示的に期待します。

投稿タイプがshow_in_rest => false宣言するか、投稿編集画面のメタボックスが'__block_editor_compatible_meta_box' => false,宣言すると、クラシックエディタが読み込まれると多くの場所で言われています。 上から、これはコアの一部ではないと言っているようですが、クラシックエディタープラグインをアクティブにしていない場合はどうすればよいでしょうか。

クラシックエディターにフォールバックするには、グーテンベルクをサポートしていないものが検出されたため、クラシックエディターはコアの一部のままである必要があります。したがって、この機能を呼び出すためのプラグインは必要ありませんか？

では、フロントエンドに表示されない情報についてはどうでしょうか。 オーナーの名前は？ 予定の表示との関係は？ それは「コンテンツ」ですか？ それは「ブロック」に入れられるのですか？

確かにメタ情報の余地もあります-それは＃3330で議論されています。 私が注目したい主なことは、「メタデータ」と呼ばれるものの多くは実際にはコンテンツであるということです。

カテゴリ/タグ/分類法は、フロントエンドに表示される場合と表示されない場合があります。 それらは「ブロック」ですか？

まあ、それらは投稿のメタですが、おそらくサイトのコンテンツです。 グーテンベルクのカスタマイズの焦点には、おそらくそのメタデータを使用してコンテンツを生成するブロックが含まれます。 🙂ブロックエディタのブロックがそれらをコンテンツとして使用する可能性は低いですが、分類法がブロックではなくサイドバーにあるのはなぜですか。

どちらでも構いません。 しかし、なぜ開発者は、将来、ブロックインターフェイスを使用してメタデータを編集する必要があると言われるのでしょうか。

すべてのメタデータがブロックインターフェイスに適合すると言っているわけではありません。 あるかもしれませんが、そうする必要はありません。 重要なのは、メタボックスの既存の使用法のほとんどがブロックインターフェイスに適合するということです。それらを区別する最も簡単な方法は、フロントエンドに表示されるかどうかを検討することです。 ＃3330では、メタデータを編集するための概念について詳しく説明しています。

メタデータは、ブロックエディタインターフェイスで編集する必要がないことを明確に伝えることができます。 それがコンテンツではない場合、または何らかの形でコンテンツに関連していない場合、それはそこに属していません-そのメタデータを編集するためのインターフェイスを挿入する他の場所があります。

それで、それを無効にするこれらの方法について...？

サイトを構築する場合は、ClassicEditorプラグインを使用してください。 プラグインを作成する場合は、CPTおよびメタボックス互換フラグを使用してください。 🙂

サイトを構築する場合は、ClassicEditorプラグインを使用してください。 プラグインを作成する場合は、CPTおよびメタボックス互換フラグを使用してください。 🙂

これは、私たちが今後構築するサイトや、「本に載っている」クライアントがサイトの世話をしている場合には問題ありません。 ただし、過去にサイトを構築して正常に動作しているクライアント、自動更新などについてはどうでしょうか。おそらく、WordPressv5.0への更新をクリックします。

これらのサイトにはClassicEditorプラグインがインストールされておらず、グーテンベルクがいないときにコーディングされているため、これらのメタボックス/ CPTにフラグはありません。 これらのサイトには問題があり、所有者は混乱し、率直に言ってかなりイライラします。 ここで間違っている場合は訂正してください。

@wpmarkはそれを釘付けにしました。

将来必要になった場合は、ClassicEditorプラグインを使用します。 将来必要になった場合は、CPTとメタボックスの互換フラグを使用します。 しかし、私はすでにサイトを作成したすべての形とサイズの数十の個人、企業、慈善団体/非営利団体を持っています。 それらのいくつかは私がまだ仕事上の関係を持っています。 他の人は先に進み、サイトを自分で実行しているだけか、別の開発者と協力しているか、開発者がまったくいないかのどちらかです。

コードの変更やプラグインのインストールを必要とするすべてのサイトに期待するのは非現実的です。

これは本当に＃4423の領土です。

すべての重要な会話について、このチケットにはラベルや所有者がいません。 それが起こらないのであれば、それを開いたままにしておくことに何か意味はありますか？

gutenberg_can_edit_post_type （またはCoreで呼び出されるもの）と'__block_editor_compatible_meta_box' => falseは、WordPress5.0の従来のインターフェイスにフォールバックします。 ただし、将来のWordPressリリースでは、その動作が変更される可能性があります。

gutenberg_can_edit_post_typeは、ブロックエディタをロードするかどうかにフラグを立てるだけです。 今のところ、ブロックエディタをロードしないときのデフォルトの動作はClassicをロードすることですが、そのフィルタの前提は、ブロックエディタをロードしない場合は、独自のインターフェイスを提供することです。 それはクラシックエディタプラグインかもしれません、それはカスタムインターフェースかもしれません。 ただし、将来のWordPRessリリースでは、ClassicコードがClassicEditorに移動される可能性があります。

__block_editor_compatible_meta_boxフラグにも同様の状況が存在します。 今のところクラシックインターフェイスにフォールバックしますが、WordPressの将来のリリースでは、デフォルトの動作がブロックエディターにとどまるように変更され、メタボックスが配置される場所に警告が表示される可能性があります。

もちろん、これらの変更はいずれも、調査とサイト所有者への連絡の両方がなければ発生しません。私のポイントは、これらの設定は主にグーテンベルクへの移行を目的として存在するということです。 Classic Editorプラグインは、Classicインターフェースを強制的に使用するための安定したオプションです。

これらの問題の詳細については、＃3902を参照してください。

サイト所有者への通知のトピックに関しては、WordPress5.0は真空状態でリリースされません。 今後の変更についてサイト所有者に通知し、サイトが機能するかどうかを通知するために使用できるツールはたくさんあります。 将来のWordPress4.9.xリリースには、ブロックエディターに関する情報が含まれ、プラグインの互換性に関するデータを収集する計画が進行中です（自動化されたものとクラウド

すべての重要な会話について、このチケットにはラベルや所有者がいません。 それが起こらないのであれば、それを開いたままにしておくことに何か意味はありますか？

この話し合いの間、私はそれを開いたままにしておくことに問題はありませんでしたが、現時点では、それ以上開いたままにする必要はないと思います。 元の質問に対処するために、クラシックエディタにフォールバックするコードベースのオプションはカードにありません。

@pentoなぜこれを閉じたのですか？ この問題はまだ解決されていません。

これを閉じることで、コミュニティが耳を傾けていないという点を証明しているだけです。

私はあなたがそれを再開するべきだと本当に思います、それで私たちはこれについての解決に達することができます。

解決策はありませんでした-コードでグーテンベルクを無効にする方法は有効になりません。 プラグインに依存する必要があります。

これには完全に不満と不満がありますが、少なくとも私は試しました。

解決策はありませんでした-コードでグーテンベルクを無効にする方法は有効になりません。 プラグインに依存する必要があります。

それはいつどこで起こったのですか？ ここでの決定についての言及はありません。

それとも、これは耳を傾けるふりをしてシャットダウンするという典型的なコアチームの反応ですか？

この時点でどのような解決策が必要ですか？

定数を使用してグーテンベルクを無効にしたい場合、それは起こりません。 私たちは耳を傾け、そのアイデアは却下されました。

この話し合いの間、私はそれを開いたままにしておくことに問題はありませんでしたが、現時点では、それ以上開いたままにする必要はないと思います。 元の質問に対処するために、クラシックエディタにフォールバックするコードベースのオプションはカードにありません。

@pentoから-これが閉じた理由です

そうですね、少なくともアップデートの前にプラグインをリリースして、ユーザーエクスペリエンスが中断されないように、プラグインをインストールしてアクティブ化できるようにしてください。

つまり、メタボックスのサポートは2.0でもまだ壊れており、現時点で機能するかどうかは確信が持てません。

プラグインはすでに存在します： https ：

@ smp303の元の質問に答えるため。

1. wp-config.phpに追加

define( 'ENABLE_GUTENBERG', false );

1. mu-pluginsフォルダー内のmy-hacks.phpというファイルで、コードを作成する必要がある場合があります

<?php // (C) Bobbing Wide 2015-2018
if ( defined( "ENABLE_GUTENBERG" ) && !ENABLE_GUTENBERG ) {
    add_filter( 'gutenberg_can_edit_post_type', '__return_false' ); 
}   

小道具@ tomjn @ wpmark

Gutenbergやclassic-editorをインストールしなくても、今日これを行うことができます。
ただし、コードがコアにマージされると、フィルター名が変更される可能性があることに注意してください。
...その時点で誰かがドキュメントを作成し、別の行を追加できます。

注： my-hacks.phpというファイルは、2003年に導入され、200xで非推奨になりました。
しかし、 mu-pluginsプラグインを使用する必要があるため、実装を妨げるものは何もありません。

関連するオプションフィールドを含め、非推奨のコードを削除するのがどれほど難しいかを知りたい場合
WordPress TRAC＃33741を参照してください-my-hacks.phpおよびhack_fileオプションへの参照を削除します

さらに簡単... ​​wp-config.phpで

$_GET['classic-editor'] = true;

ブロックの概念は間違っていると思います。 私の意見では、ブロックは投稿である必要があります。 したがって、投稿に複数のコンテンツが必要な場合は、子の投稿を作成できる必要があります。 Twitterのように、ページは多くの独立したツイートによって作成されます。

投稿の中には、テキストエディタが必要です。

すべてのページを更新する予算はありません。 wpが長期的な互換性を提供しない場合、新しい企業に門戸が開かれるため、将来的にはより安定したコミュニティに変更するだけです。

今、ワードプレスはコミュニティのおかげでかっこいいです。 5.0は、0から開始することを意味します。したがって、他のフレームワークと同様です。

非アクティブ化するかどうかではなく、2つの開発ラインを使用することをお勧めします。 WPノーマルとWPグーテンベルク。 少なくとも今後5年間は。 そうすれば、グーテンベルクは安定し、WPのようにコミュニティも持つ時間があります。

開発者としてのあなたの多くが問題を抱えているなら、なぜただ入って続けないのかいいでしょう
現在のグーテンベルクプロジェクトで解決策を構築するのを助けることができない理由を無限に書くのではなく、問題を解決するための実用的な方法を提案するチケットを持ったGithub。

プログラミングスキルを活用して、問題の解決に役立ててください。

私はビジュアルデザイナーであり、現在、2人のクライアントが編集プロセスをグーテンベルクに移すのを支援する計画を立てています。現在、20年以上前のサイトを維持できないクライアントのために、新しいサイトを設計および構築しています。

飛び込んで、WordPress.orgをサイト構築ツールとして前進させるのを手伝ってください。

@TomDesignディスカッションを読んだことはありますか？ GBチームはプラグインの一部としての機能を望んでいないため、「プログラミングスキルを問題の解決に役立てる」で、誰かがアカウントをハッキングして不要なコードを追加する必要がある場合を除いて、コードの記述方法がわかりません。ここでもリモートで関連しています。

@ tomdesign ＃4981で実行可能な移行計画を
大変な作業になると指摘しました。 そして、それは私が必要だと感じているものです。

スムーズな移行を確実にするために私たちのプログラミングスキルを使用できるようにしたいと思っている開発者はかなりいると思います。 しかし、手に負えないものを開発するために時間を無駄にしたくはありません。 私の意見では、移行はそれ自体でプロジェクトに値し、各要件は論理的に評価されます。 長期的に私たちをそこに導くための十分に文書化された提案を持っていることは十分に重要です。

サイモンの当初の要求は、長期的な問題に対する短期的な修正でした。
コンテンツの移行プロセスは何年も続くと思います。

こんにちは、みんな、
コメントを読むこれはグーテンベルクについての良いプラグインを共有するのに適切な場所だと思います。
グーテンベルクエディタを管理できる無料のプラグインを紹介したいと思います。
これはGutenbergManagerと呼ばれ、さまざまな投稿タイプ（ページと投稿を含む）でエディターを有効/無効にできます。 より多くの機能がありますが、私はそれらをあなたに任せます。

WP 5.0のコア内でのグーテンベルクの将来の実装について不満を言う人々の投稿をたくさん読んだので、簡単な解決策を見つけることができました。

Gutenberg Managerはこの問題を解決し、たとえばWP 5.0の後でも、Elementor、Visual Composer、Siteorigin Builder、Cornerstoneを問題なく使用し続けることができます。
WP.orgでの最初のユーザーフィードバックから、プラグインは高く評価されているようです:)

このため、グーテンベルクマネージャーを紹介したいと思います-> https://wordpress.org/plugins/manager-for-gutenberg/

プラグインは、いくつかの便利なフックのおかげで、開発者が独自のテーマやプラグインで使用できます。 プラグインオプションパネルを非表示にするフックがあり、最終ユーザーにはWPバックエンドに表示されません（プロジェクトにGutenberg Managerを含めたい開発者にとっては素晴らしい機能です）。

また、パートナーシップとコラボレーションを活性化するために、最も有名なビルダーのチームとの取り決めも行っています。 このようにして、グーテンベルクへの移行を少しトラウマ的にしないことを望んでいます！

ご清聴ありがとうございました、
よくやった。

@unCommonsTeamたとえば、設定画面でオプションが選択されている場合、プラグインでGutenbergエディターを無効にする方法を尋ねることができますか？

確かに@wpmark 、

行79を見てください->

ベスト

@unCommonsTeam私に戻ってきてくれてありがとう。 私はおそらくここで間違っていますが、プラグインがグーテンベルクプラグインによって追加されたすべてのものを削除しているように見えます。 これは私が上で使用して提案したものです：

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

ただし、 @ pentoから通知を受けhttps://github.com/WordPress/gutenberg/issues/4409#issuecomment-357912790を参照して

@wpmarkはい、その関数はGutenbergプラグインによって追加されたものをすべて削除しますが、関数はすべてのバックエンドではなく特定のバックエンドページでのみ呼び出されます。たとえば、ページでGutenbergエディターを無効にすることにしたが、投稿で使用したい場合..だから私はそれが許容できると思います。

ベスト

@unCommonsTeamは素晴らしいプラグインのように見えますが、WordPressにエディターを追加し直す必要があるという点で、私のソリューションと同じ問題が発生すると思います。

@pentoが言っていたことから、グーテンベルクの追加を削除すると、ブロックエディターは

@pentoが述べたように：

このフィルターは、「ブロックエディターをロードしない」という意味であり、「クラシックエディターを使用する」という意味ではありません。 現時点では機能しますが、将来的に機能する保証はありません。

したがって、私はあなたのプラグインが上記の私の試みよりも同じことをしていると思います（そしてもちろん、はるかに優れており、柔軟性のためのクールなオプションがたくさんあります）。

私が考えていたもう1つのことは、プロジェクトがコアにマージされるときにグーテンベルクという名前がぶらぶらすることです。たとえば、これらの関数（ gutenberg_init ）の名前が（たとえば） block_editor_init変更されることです。

@wpmarkあなたは正しいです。 WP 5で、彼らが古典的なエディターをそこに残すことを願っています。 ただし、プラグインを介してクラシックエディタを含めるオプションを追加することもできます。 WPの開発チームがクラシックエディタを削除することを決定した場合、私たちのプラグインは本当に人気があると思います:)

あなたが正しいグーテンベルクの名前については、おそらくフックの名前を置き換えるプラグインを修正する必要があります。

さらに、私たちのプラグインは、グーテンベルクエディターに基づく他の機能（特定のブロック、新しいブロックなどを有効/無効にする）を提供します。 ですから、グーテンベルクエディターを使う人にも役立つと思います。

乾杯

これは、ほとんどすべてのスタンピードと議論を解決する良いアイデアかもしれません：

グーテンベルクがコアでデフォルトで無効になり、クラシックエディターが引き続き維持されている場合、これにより、WPを大幅に節約するとともに、約10億ドルのWordPressテーマとプラグイン市場、および膨大な数のインターネットを節約できます。プラットフォームとしての名声と信頼の喪失。

グーテンベルクは、より現代的なエディターですが、WordPress.comやWordPressを使用してブログ/ホスティングサービスを提供する同様のアウトレットの必需品のために作られているようです。 これはすべてうまくいっています。 しかし、それは生態系の残りの部分に衝撃とボールのキックをもたらすべきではありません。 広大なインターネット、人々のウェブサイト、彼らの生活は現在の方向性に影響されるでしょう。

WordPress.comではグーテンベルクをデフォルトでオンにすることができますが、WPではデフォルトでオフになっているため、エコシステム全体に最高の世界を提供します。

私はコードバードに同意する必要があります。グーテンベルクはデフォルトで無効になっており、クラシックエディターは引き続き維持されます。 現在、まさにこの理由で自動更新を無効にしています。マルチサイトネットワーク上のブロガーに、この「ページビルダー」タイプのエディターが突然表示されることは望ましくありません。また、クラシックエディターが完全に置き換えられることも望んでいません。グーテンベルクと。

少なくとも、define（ 'DISABLE_GUTENBERG'、true）;などのdefineステートメントでグーテンベルクを無効にできるはずです。 gutenbergを無効にするプラグインを使用する場合の大きな問題の1つは、必要に応じてプラグインの保守と更新を開発者に依存することです。 開発者が休暇中または忙しくてプラグインを更新できないためにプラグインが機能しなくなった数日または数週間の間に何をしますか。 プラグインを使用している人が自分の側でプラグインを更新しなければならないという問題もあります。

グーテンベルクを私たちに強制し、それを無効にするための回避策を見つけることは、後から考えることは本当に後戻りの方法であるようです。 グーテンベルクをデフォルトで無効にしてください。 単純なブログが欲しいだけの私たちの多くは、ウェブサイトビルダーに進化しているように見えるため、ワードプレスを使用することがますます難しくなっています。

別の注意点として、マルチサイトネットワークの場合、ネットワーク管理者は、グーテンベルクをネットワーク全体で利用できるようにするかどうかを決定できる必要があります。

@WebTrooper Classic EditorプラグインはWordPress開発者チーム（Coreを維持しているのと同じ人々）によって維持され、 Gutenberg RampはAutomatticによって維持されているため、どちらも「休暇中の開発者」や「忙しすぎる」要因の影響を受けないはずです。

VIPは、クライアントサイトと自社サイトで使用されているGutenbergRampプラグインに取り組んでいることに注意してください。 休暇中や物事が壊れた場合に忙しすぎることは、VIPが最後に望んでいる顧客サイトの壊れを意味する可能性があります。

また、これらのプラグインはフォーク可能であり、Automatticと作成者、およびクラシックエディタープラグインには、これらのプラグインを構築するための秘密の知識がなく、技術的に大規模または複雑でもありません。 どちらのプラグインも保守できる開発者がいる代理店は世界中に何百もあります。

余談ですが、多くの人がデフォルトでグーテンベルクを無効にすることを主張していますが、それらの議論のメリットに関係なく、デフォルトで正確にGBをオンにする必要があるのはいつかを言うことができません。 論理的な結論は、永続的な古典的なエディターの状況です。

2934年、銀河帝国がシステムに飛び込み、300隻のバトルクルーザーが登場しました。 地元の惑星ニュースネットワークは、地元の住人のためにレポートを書くために古典的な編集者を解雇しました。 彼らがサイトの構築を始める前に、誰もグーテンベルクについて彼らに話しませんでした

新規インストールでは、デフォルトでオンにすることを常にお勧めします。

ただし、既存のインストールの場合は、ユーザー主導のアプローチをお勧めします。これにより、ユーザーはGutenbergにオプトインして試して、気に入った場合は保持し、気に入らない場合は従来のエディターに戻すことができます。 WordPressは、変更の開発とドキュメント化を支援するためにユーザーが戻った場合に、統計とフィードバックを収集できます。

それがオンになっているアクティブサイトのある種の臨界量に達したとき、デフォルトでそれを有効にすることができます。 いいえ、私は空中から番号を選ぶつもりはありません。 しかし、使用量を測定して適切に行動することはできます。

または、2020年4月12日でもかまいません。 😉

これは古いPHPバージョンで起こっていますよね？ WordPressは、PHP 5.2の下位互換性に飽き飽きしています。なぜなら、多くの場合、おそらく知らないうちに、または気にせずに、WordPressを使用しているからです。 WordPressは統計を注意深く分析しています。 ホストとの調整などに多大な努力を払う。 アップグレードパスで人々を優しく案内します。 そしておそらく、プロジェクトは、ある時点で、決定を下すために必要な使用状況データに基づいて行動するでしょう。

それでも、ユーザーが知っていて、アプローチを気にかけている編集用のまったく新しいユーザーインターフェイスでは、それを強制することですか？

私が実際にグーテンベルクを提唱し始めている場合もありますが、このマージの提案が、ITスキルが低いエンドユーザー向けに多くのサイトを管理している私のような人々の懸念を取り入れることを本当に望んでいます。テクノロジーに自信がなく、グーテンベルクによって混乱し、混乱するでしょう。

以下の重要な理由により、グーテンベルクは新規インストールでもオフにする必要があると思います。

• チュートリアル、リソース、ハウツーなど、想像できるものはすべて既存のエディターに基づいて、ほぼ無限に存在します。 これらはWordPressへの人々のエントリーを非常に簡単にします。

• このように簡単に始められるため、人々は「WordPressは簡単」であると理解し、プラットフォームをすぐに温かく認識し、より受け入れやすく、自信を持って学習できるようになるため、この入力のしやすさは非常に重要です。

• これらすべてが組み合わさって「WordPressはうまく機能する」という認識になり、彼らはそれを仲間に快適に勧めます。 これが私たちがインターネットの30％を網羅するように成長することができた方法です。

• 情報の一貫性は重要です。 そして、インターネット上のすべてのリソースがグーテンベルクを反映するように更新される方法はありません。 それは多くの混乱を引き起こします。 そして、最も残念なことに、通常のユーザーの反応は「インストールしましたが、機能しません」です。なぜなら、彼/彼女は物事を行う方法を見つけることができず、物事は彼または彼女が使用するチュートリアルと同じに見えないからです。 間違いなく、更新作業の量がリソースやチュートリアルなどに関するこの混乱を解消することはありません。

したがって、Gutenbergはオプションであり、テーマ、既存のページビルダーで構築されたコンテンツプラグインなどの観点からだけでなく、オンラインにあるリソースの観点からも「下位互換性」を維持するために切り替え可能である必要があります。 プラットフォームは「それほど簡単」ではなく、グーグルが多くの異なる時代遅れの最新のリソースを混ぜ合わせて持ち出すとき、「それをインストールしてグーグル...」と言う人々にそれをお勧めすることはできません。 そして、あなたがseoの経験を持っているなら、あなたはそれがそうなることを知っています...

グーテンベルクを使用すると、上昇しているとされる「サイトビルダー」市場（wix、squarespaceなど）と潜在的な「簡単なブログ」市場（中規模など）を活用できます。 しかし、インターネットの30％のほんの一部、または10億ドルのテーマ/プラグイン市場を損益分岐点に達すると、10年以内に回復できない可能性のある、大規模で大規模なキックになります。

従来のPHPプラグインをインストールすることはできないため、PHPとの比較は関係ありません。これらは、破損することが保証されている何百万ものサイトであり、それを解決するWPベースのソリューションがないため、慎重に分析します。 また、次のリリースにはクラシックプラグインをインストールするプロンプトがあり、ユーザーはGutenbergプラグインをインストールするように求められるだけではないことにも注意してください。

いずれにせよ、この問題は解決され、決定が下されました。 クローズドイシューは、他の場所で計画されているアプローチを変更しようとするのに適した場所ではありません。

ただし、グーテンベルクは切り替え可能であることに注意してください。グーテンベルクを有効または無効にするためのプラグインがあります。 GBが開始されてから何年も経ち、これまでのところテストする時間、クライアントをトレーニングする時間、クラシックエディタプラグインをインストールする時間などがあります。これは、一夜にして人々に強制される新しいものではありません。

これらの議論のメリットに関係なく、デフォルトで正確にGBをオンにする必要があるのはいつかをすべての人が言っていないことに気づきました。

そして、それらの議論をしている人々がこれがいつ起こるべきかについて何らかの提案をしたとしても、とにかくそれは却下されるだろうと思われます。 では、なぜそれを持ち出すのですか？

クローズドチケットの仕組みを知っています。 あなたはここでかなり皮肉を脇に置いた。 それで私はそれに応じて建設的な何かを提供しようとしました。

@tomjn @rosswintleをここにエコーします。「はい」と言って、デフォルトで新規インストールの場合にのみオンにすることを提案しました-https ：//github.com/WordPress/gutenberg/issues/4423。 これは別のクローズドな問題であり、ポイントについての実際の議論なしにクローズされました。

彼らは耳を傾ける気がありません、プラグインがあります、何とか何とか何とか、これは閉じられています。 ここに表示するものは何もありません。 そのすべては.comについてであり、誰も.orgを気にしません。そこには自動化のためのお金はありません。

@ smp303彼らが誰

@rosswintle皮肉は意図されていませんでした。5.2で実行されているサイトが壊れないようにする唯一の方法は、サイトをサポートしてアップグレードを試みることです。 投稿編集画面がグーテンベルクで壊れてしまうサイトは、サーバーレベルの変更を必要とせずにクラシックエディタープラグインをインストールできます。比較は公平ではありません。

彼らは耳を傾ける気がありません、プラグインがあります、何とか何とか何とか、これは閉じられています。 ここに表示するものは何もありません。 そのすべては.comについてであり、誰も.orgを気にしません。そこには自動化のためのお金はありません。

同意する必要があります。 ここでもWordPressサポートフォーラムでも、コミュニティの多くの人々がこれに反対しているにもかかわらず、彼らはまったく気にしていないようです。 WordPressはオープンソースなので、この件に関して誰でも請願書を作成することをお勧めします。 私は個人的に、GBをコアにマージするのではなく、Jetpackのようなプラグインにするべきだと信じて提案しています。

補足： @karmatosedグーテンベルクに関するWordPressフォーラムのコメントの1つで私の質問に返信して答えることができないので、なぜ私のコメントが突然消えるのか疑問に思います。 いい動きだ！

このスレッドは、Gutenbergを無効にするコードベースのオプションがない理由についての議論から、sockpuppetアカウントからの暗黙的または完全な個人攻撃へと変わりました。

このトピックに非常に情熱を持っている人がいることを感謝します。このスレッドがこのように進んだことは残念ですが、決定は変わることはありません。

クラシックエディタープラグインは、サイト全体でクラシックエディターに戻すためのオプションです。 これは、WordPress 5.0の準備として、今すぐインストールするオプションとして、次のWordPress4.9.8リリースで目立つように宣伝されています。

クライアントをブロックエディターからオプトアウトしたいサイトビルダーの場合、クラシックエディタープラグインをインストールする（そしてバグレポートや修正を提供する）ことは、クラシックエディターを引き続き利用できるようにするための最良の長期的な解決策です。

メタボックスの場合、ブロックエディターをgutenberg_can_edit_post_typeフィルターは、マージ時に名前が変更されます（おそらく、 block_editor_can_edit_post_type 、またはそのような性質のものになります）が、コードベースのオプションとしても使用できます。

このスレッドがさらに進化するのを避けるために、私はそれをロックします。

このディスカッションに参加するすべての人は、グーテンベルクがWordPress 5.0に対応できるようにすることに引き続き参加できますが、個人的な攻撃は絶対に歓迎されておらず、問題がロックされたり、アカウントが禁止されたりすることに注意してください。