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 обновил заголовок, чтобы было больше смысла - ищу варианты кода :) спасибо

Я думаю, что это была бы очень полезная функция для многих разработчиков. Фактически, я бы даже сказал, что считаю, что Гутенберг должен быть активен только при новых установках WordPress версии 5.0, а не на сайтах, которые обновляются до версии WordPress 5.0 - когда происходит слияние с ядром.

Если бы это было объединено со способом активации / деактивации в коде, разработчики могли бы включить его, когда будете готовы.

Не могли бы вы пояснить, почему вам нужно добиться этого с помощью кода?

Если это проблема видимости / контроля клиента, вы всегда можете установить вышеупомянутый плагин как «обязательный плагин»: https://codex.wordpress.org/Must_Use_Plugins

Поскольку изменение кода происходит быстро и легко - включение плагина - это 1) не мой код и 2) не так просто, как добавление некоторого кода, - добавление в список зависимостей не является ни практичным, ни разумным способом решения этой проблемы.

Определение константы может быть вашим кодом, но логика, которая работает с этой константой, будет в такой же степени не вашим кодом, как официально поддерживаемым плагином «Classic Editor».

Я должен пояснить, что я не пытаюсь спорить, а скорее пытаюсь лучше понять, почему эти подходы привлекательны, убедившись, что существует достаточное количество вариантов, но при этом не предлагаю так много, чтобы быть чрезмерным для поддержания.

Почему функциональность плагина не может быть частью ядра? Просто спрашиваю, как мне любопытно :)

Я хотел бы отразить необходимость включения / выключения редактора Гутенберга. Моя конкретная ситуация заключается в том, что один из моих сайтов WordPress построен на теме, у которой есть собственный редактор (например, редактор Avia в теме Enfold).

Когда Гутенберг включен, рабочий процесс для наших редакторов меняется. Им нужно перейти в «Все сообщения»> или «Страницы» и нажать «Классический редактор», а затем нажать кнопку расширенного редактора макета, который вызывает встроенный редактор темы вместо простого нажатия «Редактировать» на странице, которую они хотят редактировать. , или со страницы предварительного просмотра. Нам нужен этот редактор, потому что внешний вид нашего сайта стандартизирован на основе шаблонов, которые мы создали с помощью этого редактора.

Хотя большинству этот процесс кажется тривиальным, изменение рабочего процесса для десятков редакторов вызовет некоторые проблемы со службой поддержки.

Мои 2 цента.

Думаю, разница только «психологическая». Наличие его в Core означает, что он будет у нас на неопределенный срок, что вредит внедрению Gutenberg, где наличие его в качестве плагина означает, что мы будем поддерживать его в течение некоторого времени (я думаю, что Мэтт сказал несколько лет), и в какой-то момент мы остановимся.

Я не знаю, нужно ли это выделить в отдельную проблему или нет, но я хотел бы выразить свою поддержку идеи @wpmark о включении Gutenberg только для новых установок WordPress 5.0 и предлагать его как возможность для людей при обновлении (если не используется плагин Classic Editor или какая-либо другая функция отключения).

Если вы хотите прочитать это, мое обоснование этого дано в сообщении в

Похоже, Гутенберг отлично подойдет тем, кто плохо знаком с WordPress, установив новый блог и приступив к работе. И это будет здорово для людей, которые обновляются и думают: «Ура, новый редактор, пожалуйста». Но для других это будет большим шоком. И в некоторых случаях использование GB может быть не лучшим интерфейсом для редактирования настраиваемого типа сообщения, или «блоки» могут не быть хорошей моделью данных для редактируемой информации.

Также кажется, что по этой теме нужно услышать голоса разработчиков и владельцев малого бизнеса. Я знаю множество небольших магазинов по разработке WordPress, и это изменение будет болезненным по всем причинам, изложенным в моем сообщении в блоге. Я не слышал, чтобы один разработчик или небольшое агентство сказал, что автоматическое включение GB для обновленных сайтов - хорошая идея. Я слышал, как многие отвергают эту идею.

Такой тип пользователей WordPress (и такие компании, как моя, являются большими сторонниками и сторонниками WordPress, поэтому мы очень надеемся, что вы прислушаетесь) хорошо понимает своих пользователей, мы хорошо знаем, что мы создали на WordPress, и действительно ли это. будет хорошо вписываться в пользовательский интерфейс GB без изменений, и нам НУЖНА возможность управлять этим изменением от имени наших клиентов.

Я знаю, что мы можем установить плагин Classic Editor, и нам все еще может потребоваться это сделать, чтобы исключить возможность того, что наши клиенты сами активируют GB. И если GB окажется необязательным для обновленных сайтов, это, естественно, потребует наличия кода для его отключения в ядре. Так что это сделало бы @ smp303 (и других, кто хочет отключить его в ядре) тоже счастливыми!

Я надеюсь, что мнения разработчиков и малых предприятий WordPress, подобных моему, будут услышаны по мере разработки плана по слиянию с ядром. Это изменение может повлиять на наши средства к существованию, и некоторые люди считают, что это изменение им навязывают слишком быстро. Пожалуйста, дайте нам больше возможностей для управления переходом и учтите, что ГБ не будет подходящим для всех, когда он впервые будет добавлен в ядро.

Фильтр в ядре WP или константа для wp-config.php кажутся двумя надежными вариантами, которые можно иметь.

Повторяя @rosswintle и его отличный пост в блоге, ссылка на который приведена выше: мы одно из многих, многих агентств, которые используют настраиваемые поля, метабоксы (в частности, ACF), чтобы предоставить действительно богатый опыт редактирования. «WordPress как платформа» было обещанием, и именно этим мы все занимались последние несколько лет.

Должен быть способ включить Gutenberg для тех, кто этого хочет, но не обеспечить его соблюдение для тех, кто этого не делает. Мне достаточно легко понять, происходит ли это в коде или через плагин - на самом деле, как человек, который поддерживает более 50 сайтов WordPress с помощью консоли управления, массовая установка плагина для отключения Гутенберга имела бы более практический смысл (если бы меньше гиковского чутья), но, пока это возможно. Даже вариант настроек на панели инструментов был бы в порядке, IMO - по умолчанию "Gutenberg: off" даже лучше ...

Точка зрения Росса о обратном согласовании сайтов с Гутенбергом также верна. Практически любой, кто строит для клиентов, знает, что подавляющее большинство тратит свой бюджет на запуск, а после этого не имеет бюджета. Модернизация Гутенберга, переподготовка клиентов, другой интерфейс - думать, что за это заплатит кто угодно, кроме разработчиков и владельцев бизнеса, - это страна фантазий.

Точно так же, как эхо настроений @ smp303 , @dmje и @rosswintle.

Возможность поместить в functions.php простое действие для отключения Гутенберга кажется самым простым и очевидным делом.

Я не могу не чувствовать, что подход с плагинами был взят для того, чтобы сделать обход Гутенберга немного сложнее, чем это должно быть.

Я знаю, что основная команда приложила массу усилий к Гутенбергу, но ее успех должен определяться его достоинствами, а не ограничением возможности избежать этого. Более того, подумайте о том, что разработчикам WP нужно разрабатывать совершенно новый редактор, учиться реагировать и при этом разрабатывать и поддерживать устаревшие вещи - накладные расходы ОГРОМНЫЕ.

Я также хотел бы повторить это - я также хотел бы отключить редактор Гутенберга через код, а не через плагин.

См. Также этот запрос Trac, который был создан и теперь закрыт как wontfix : # WP43068

Per @ dd32 в https://core.trac.wordpress.org/ticket/43068#comment : 6

Я не думаю, что мы будем поддерживать константу для этого, а вместо этого просто направляем людей к плагину и, возможно, к оболочке mu-plugin для него, просто потому, что существующий плагин не просто переключатель, он будет чтобы задействовать код, который не используется в ядре.

WordPress пытается отойти от констант, так как их очень сложно изменить позже по дорожке «О, я хочу Гутенберга, почему он отключен? О, мой случайный плагин SEO (или бывший разработчик) думал, что я не буду хочу, и принудительно отключил, отлично ... теперь кто я могу исправить это для меня "(конечный пользователь)

Я понимаю, почему некоторые люди захотят отключить его, но я не вижу необходимости делать это таким образом.

Я думаю, что мы можем безопасно закрыть это как wontfix , это может измениться позже (и тогда мы еще раз посетим это), но я этого не ожидаю.

Всем спасибо за отзывы. Я понимаю, что есть некоторые разногласия по поводу решения потребовать, чтобы плагин Classic Editor полностью отключал редактор блоков, поэтому я хотел бы поговорить о различных вариантах.

В ближайшие годы концепция «блочного» управления данными сайта станет основным методом обдумывания, размещения, взаимодействия и редактирования данных. Редактор блоков, появившийся в WordPress 5.0, является первым важным шагом в этом направлении, а акцент на настройке Gutenberg в этом году является следующим шагом, наряду с темой Gutenberg.

Конечно, не все будут готовы на 100% к редактору блоков, когда появится WordPress 5.0. Это практическая реальность, о которой все знают, и мы не хотим оставлять людей без реального способа обновления до WordPress 5.0. Имея это в виду, есть несколько разных способов отключить Gutenberg, в зависимости от вашего конкретного варианта использования.

Если вы зарегистрируете мета-блоки, которые не работают с редактором блоков, вы сможете легко пометить этот мета-блок как несовместимый .

Точно так же обсуждается добавление аналогичного флага для CPT (# 2457), чтобы CPT, которым не требуется функциональность редактора блоков, могли отказаться от него.

Это два основных варианта долгосрочного использования для отключения редактора блоков - ситуации, когда он не работает или не соответствует шаблонам использования.

Имея в виду все это, давайте подумаем о том, как WordPress потенциально будет развиваться в следующие несколько лет (обратите внимание, что я очень внимательно смотрю здесь в хрустальный шар - вещи в этом списке не обязательно будут происходить в этом порядке, временных рамках или даже вообще - это всего лишь потенциальный сценарий, который будет во многом зависеть от того, как закончится выпуск WordPress 5.0).

• Настройщик использует концепцию блока для всего. Для 99% новых сайтов блоки - это единственное, что нужно для создания целых сайтов. Манипуляция блоками - вот как создаются сайты.
• Новые темы будут развиваться вокруг строительных площадок полностью из блоков. Стандартный пользовательский интерфейс WordPress построен с использованием блоков.
• В то же время wp-admin начнет адаптировать интерфейс JavaScript-приложения, который предлагает Гутенберг. Конечно, переключение на классический редактор все еще возможно, но оно не соответствует остальному интерфейсу WordPress.

Я повторяю, что в течение нескольких лет появятся плагины, такие как Classic Editor, для восстановления старых интерфейсов, но не обязательно, чтобы эти интерфейсы были поддержаны в Core. Хотя это будет разумный вариант отключить редактор блоков в WordPress 5.0, вы окажете огромную медвежью услугу своим клиентам, если дойдете до WordPress 5.5 или 6.0, и все еще будете использовать классический редактор. Возьмем один пример: во многом по мере того, как лучшие практики макета сайта эволюционировали от макетов таблиц до нескольких итераций макетов CSS, а теперь и макетов сетки, лучшие практики разработки WordPress также развиваются.

Итак, возвращаясь к исходному вопросу, единственный вариант на основе кода для отключения редактора блоков не является жизнеспособным долгосрочным решением, он не может расширяться, чтобы предоставить подходящие варианты для будущей разработки ядра WordPress, это действительно оказывает медвежью услугу всем присутствующим, если бы мы создали эту опцию. Плагин Classic Editor, однако, может продолжать развиваться, чтобы соответствовать любой парадигме, которую принесет будущее. Это дает более непринужденную среду, где его можно разрабатывать специально для удовлетворения потребностей людей, которые в нем нуждаются, вместо того, чтобы соответствовать более общим потребностям всего мира WordPress.

Проблема с редактором Гутенберга не в блоках или концепции блоков, а в том, что сам редактор плохой. В настоящее время он во много раз более запутан, чем существующий редактор, который сам по себе очень далек от совершенства. И по мере того, как мы приближаемся к окончанию срока (ожидается в апреле, я полагаю?) И люди выражают все больше и больше опасений, обратная связь никогда не будет такой: «вы правы, вот как мы планируем решить эту проблему», все так же, как вы. выше "ну, это происходит, так что лучше садитесь на борт".

Интерес к деактивации Гутенберга, по крайней мере, мой интерес, - это не будущее блоков против виджетов и долгосрочная дорожная карта настройщика - это то, что настоящий редактор действительно отстой. Я не хочу его использовать. Мои клиенты не хотят использовать. Это не очень хорошая вещь в использовании. И причина, по которой это не очень хорошо, заключается в основной концепции, согласно которой каждый абзац и кусок текста - это «блок», и мы все это ненавидим.

Вот почему мы хотим отключить это. Переход в Гутенберг для многих - очень неприятный опыт, вызывающий серьезные проблемы как для клиентов, так и для разработчиков.

Меня не волнует будущая дорожная карта. Я забочусь о том, чтобы потерять своих клиентов и свой бизнес, и до сих пор никто в команде Гутенберга, похоже, не разделяет эту озабоченность. Что мы должны делать, когда основная платформа нашего дохода движется полным ходом в том направлении, в котором мы не хотим идти? И что мы должны делать, когда наши опасения отбрасываются во имя «дорожной карты будущего»?

Я за замену виджетов, вставок и шорткодов в универсальную блочную систему. Думаю, это хорошая идея - я за этим. Мне нравится пытаться дать пользователям больше контроля над макетом своего сайта - почему бы и нет?

Я беспокоюсь, потому что реальный инструмент для создания контента в настоящее время представляет собой горячую неразбериху, которую ни один из моих клиентов (более 300) не хочет использовать. Они на самом деле смотрят на это с ужасом, и все милые маленькие демонстрации и видео на YouTube, а также записанные разговоры на WordPress только показывают им, насколько они это ненавидят.

Они не хотят писать блоками! Им не нужен блочный редактор! Все они ненавидят это - они хотят, чтобы это работало как MS Word или Google Docs, потому что это то, что они обычно используют для написания материала. Вот чего они хотят.

Как я могу дать им это, когда все, что хочет WordPress, - это засунуть им в глотку блоки?

Единственная альтернатива, которая у меня есть, - выключить Гутенберга. Итак, мне нужен надежный способ сделать это. По крайней мере, до тех пор, пока этот поезд разработки не одумается и не создаст что-то, что действительно стоит использовать - не как блочный механизм, а как настоящий чертов редактор.

Мне нужен функциональный редактор, в котором текст НЕ основан на блоках. Когда Гутенберг предоставит это? Ответьте на него, и я скажу, что нам больше не нужен способ отключить Гутенберга. А пока проявите реальное сочувствие и заботу о миллионах пользователей и предприятий WordPress и предоставьте способ отключить Gutenberg, в который мы можем верить - это означает код, а не другой плагин.

Должен быть способ деактивировать Гутенберга на уровне кода. Пожалуйста, проявите любезность. Не давайте еще одного банального ответа - просто дайте нам возможность выключить эту чертову штуку, если все пойдет не так.

@pento , В течение многих лет для каждого пользователя существовала простая возможность отключить tinymce, и, хотя большая часть разработки была специфичной для tinymce, никто не предполагал, что эта опция будет удалена.

Я еще не слышал, чтобы кто-нибудь предлагал удалить эту опцию как часть Gutenberg, и для меня не имеет большого смысла, что вы сможете перейти от Gutenberg к текстовому редактору, не имея возможности продолжать использовать текущий tinymce. Принимая во внимание, что tinymce по-прежнему будет поддерживаться как часть текстового виджета и API wp_editor, не имеет смысла при разработке или пользовательском интерфейсе заставлять людей устанавливать плагины для предоставления активно поддерживаемых основных API.

Даже если по какой-либо причине вы не хотите изменять этот параметр пользователя, чтобы включить настройку, связанную с Gutenberg, из точки обзора разработки программного обеспечения, если вы собираетесь поддерживать отключение Gutenberg, это должен быть API, который является частью Gutenberg и поддерживается как часть его развития. Как показывает плагин импортера, даже «базовые» плагины не синхронизируются и становятся непригодными для использования главным образом потому, что они не являются частью фактической разработки ядра.

Отказ от поддержки такого API как части ядра означает, что нет никаких обязательств, позволяющих людям отключать Gutenberg даже в 5.1, выпуск которой, вероятно, будет в 2018 году. Нельзя ожидать, что люди смогут строить какие-либо среднесрочные планы с такими неопределенность.

@pento Спасибо за длинный и подробный ответ. Я не думаю, что это проблема только в том, КАК отключить Гутенберга, но также и в том, будет ли он включен по умолчанию и как. Думаю, ваш ответ охватывает оба вопроса, но меня это тоже беспокоит.

Я, например, очень удивлен, что здесь и в других местах подразумевается, что классический редактор будет удален из WP, а плагин «Classic Editor» добавит его обратно. Это правильное понимание? Мне это кажется действительно плохой идеей, но сейчас я не могу объяснить, почему.

@markkap также хорошо wp_editor API - как они будут храниться в ядре, если TinyMCE будет удален?

И редактирование кода meta_box / CPT для предотвращения загрузки Гутенберга - это нормально, но на самом деле я одинокий фрилансер, который, вероятно, создаю около 60-80 сайтов для клиентов. Я не собираюсь редактировать весь этот код, и многие из этих мелких клиентов не захотят платить мне за это. Я бы НАМНОГО предпочел, чтобы это было согласием, чем отказом: Gutenberg должен быть включен, когда я заявляю о его поддержке. По умолчанию здесь опять же наоборот. Вы заставляете людей вносить изменения, чтобы что-то не изменилось / не сломалось (при необходимости я с удовольствием подниму для этого отдельный вопрос).

вы окажете огромную медвежью услугу своим клиентам, если перейдете на WordPress 5.5 или 6.0 и все еще будете использовать классический редактор.

(Также использую свой хрустальный шар) Не думаю, что я обязательно с этим согласен. Я думаю, что невозможно сказать, что Gutenberg и блоки будут лучшим способом редактирования для всех будущих сценариев использования.

Я также обнаружил, что здесь меня немного смущает природа «блоков». Вероятно, это связано с терминологией, но из этого следует, что верно одно или несколько из следующих утверждений:

• Есть смена парадигмы, которую я пытаюсь осуществить, или я что-то неправильно понял
• Новая парадигма не очень хорошо передается
• Способы, которыми WordPress используется разработчиками, такими как я, для создания инструментов управления контентом для клиентов, не совсем понятны.
• Способы, которыми WordPress используется разработчиками, такими как я, для создания инструментов управления контентом для клиентов, хорошо известны и игнорируются.

Вы сказали:

В ближайшие годы концепция «блочного» управления данными сайта станет основным методом обдумывания, размещения, взаимодействия и редактирования данных.

Это меня немного пугает, и я вернусь к этому.

Страница Гутенберга по адресу https://wordpress.org/gutenberg , похоже, не согласна с этим описанием. Он называет блоки «блоками содержимого» и объясняет, что:

[блоки] - это единый способ стилизации контента

_Примечание: я внутренний разработчик и очень много думаю о данных: какие данные существуют в системе, какие свойства имеют элементы данных, как элементы данных связаны между собой и как данные запрашиваются и обрабатываются.

Насколько я понимаю, «блоки» - это разделы контента, которые можно использовать для включения в пост, страницу и т. Д. Они в основном хранятся внутри содержимого сообщения в базе данных с использованием комментариев HTML для обратной совместимости, но вы также можете настроить блоки для сохранения данных в других местах, таких как post_meta. (Примечание: это похоже на хакерство, чтобы люди вроде меня были довольны размещением метаданных в блоки - это не похоже на хорошо продуманное дизайнерское решение о природе блоков)

То, что вы говорите, подразумевает, что блоки должны управлять всем. Это то, как будут управляться «данные сайта». Это и другие вещи, о которых вы сказали, подразумевают, что блоки - это не просто разделы контента, а какое-то устройство пользовательского интерфейса, которое можно подключить к чему угодно: параметрам сайта, настройкам, метаданным о сообщениях, виджетам, меню и т. Д. поля профиля пользователя, все.

Поэтому я думаю, что нам нужно прояснить природу «блока».

Если то, что вы намекаете, правильно, то я думаю, что это фундаментальное неправильное понимание того, как WordPress используется такими людьми, как я. И я думаю, что именно этот подход подтолкнет меня сойти с поезда WordPress и найти альтернативную CMS для некоторых проектов. WordPress будет предназначен для блогов и журналов, но многие возможности, предоставляемые настраиваемыми типами сообщений, исчезнут.

Метаданные в WordPress выглядят так: данные о данных. Это информация, которая придает дополнительные свойства элементам контента. Мета-данные НЕ являются содержанием. И ИМО не подходит для размещения в «блоках», как я их понимаю. Некоторые из создаваемых мною типов сообщений не имеют другого содержимого, кроме заголовка: у них есть только свойства / поля / метаданные.

Если то, что вы здесь описываете, правда, тогда мне интересно, почему статус публикации не является блоком? Почему не блокируются категории и теги? Почему отрывок не является блоком?

Я лично не думаю, что это «блоки» в моем понимании, потому что они не являются содержанием, это информация о содержании. Их расположение в пользовательском интерфейсе важно. Важно, как пользователь взаимодействует с этими битами информации.

Некоторые из создаваемых мною post_meta такие же.

Мне (думаю, понравится) Гутенберг и блоки для создания постов и страниц. Но либо я неправильно понимаю «блоки», либо проект неправильно понял, как люди используют данные, которые не подходят для «блоков».

Я рад, что это прояснили, и готов меня убедить. Но наличие блоков в качестве «основного метода обдумывания, размещения, взаимодействия и редактирования данных», похоже, не соответствует тому, что я создаю в WordPress.

И, возвращаясь к основной проблеме здесь, вот почему я не считаю, что классический редактор должен быть удален из ядра, и именно поэтому я не хочу, чтобы мои пользователи автоматически включали Gutenberg, когда я обновляю их до v5. .0.

@rosswintle, вы подытожили это абсолютно во всех

Добавлен мой +1, чтобы сделать Gutenberg стандартным редактором только для новых установок.

Как сказал @rosswintle , есть сотни тысяч разработчиков WP с клиентами, которые не будут заинтересованы в том, чтобы платить за время, чтобы вернуться к классическому редактору. Позвольте существующим сайтам оставаться как есть (конечно, сделать доступным новый редактор, но также переключиться обратно, если он не такой, как они ожидали) и выпустите Gutenberg с новыми установками.

Подумайте обо всех владельцах малого бизнеса с сайтами WP. Сайты, которые были разработаны много лет назад, просто хорошо работают без новых разработок. Внезапно этим пользователям навязывают Гутенберга, и им не только нужно изучить новый интерфейс (эти пользователи могут быть изначально не очень технически подкованными, и Гутенберг может быть или не может быть более интуитивным для них), но это может помешать им от редактирования содержания своего сайта.

Также следует учитывать репутацию WordPress, поскольку мы все еще пытаемся избавиться от мнения о том, что WP полон уязвимостей. @wpmark и у меня даже был случайный разговор с кем-то ранее на этой неделе, где одна из первых вещей, которые они упомянули, когда узнали, что мы разрабатываем с помощью WordPress, было «как вы защищаете свои сайты».
Существует ли риск того, что пользователи могут обнаружить, что их сайты сломаны или с которыми будет трудно работать? Как это повлияет на репутацию WP в ближайшие годы?

Я определенно считаю, что новые сайты должны иметь поддержку Гутенберга, и это может быть важной функцией, которая кричит с крыш во время 5-минутной установки, но, пожалуйста, оставьте устаревшие сайты как есть.

Я не хотел, чтобы вопрос о включении Гутенберга только для новых установок терялся в этой также актуальной проблеме простоты отключения. Вот конкретная проблема для него https://github.com/WordPress/gutenberg/issues/4423

Пожалуйста, добавьте свои мысли, голоса и отзывы к этому. @joffff @wpmark @rosswintle @markkap @dmje

Ролик на @rosswintle.

Гутенберг должен быть включен, когда я заявляю о его поддержке. По умолчанию здесь опять же наоборот. Вы заставляете людей вносить изменения, чтобы что-то не изменилось / не сломалось (при необходимости я с удовольствием подниму для этого отдельный вопрос).

Не смог бы с этим больше согласиться, если бы попробовал. Не думаю, что парни и девушки, подталкивающие Гутенберга, это понимают.

Просто добавлю к тому, что Росс сказал с точки зрения предприятия (он хорошо освещал аспекты мелких фрилансеров): сайты, которыми я управляю для многонационального PLC, подобны нефтяным танкерам. Подобные фундаментальные изменения требуют очень много времени. Необходимо провести сквозное тестирование, и даже в этом случае они должны быть включены в еженедельный график выпуска, который является частью подробного процесса проверки и утверждения кода.

Это вызовет огромную головную боль у меня и моей команды. На самом деле, скорее всего, мы, вероятно, останемся на 4.9.x до тех пор, пока не сможем тщательно проверить влияние Гутенберга после того, как будет выпущен последний RC для 5.0.0. Это может занять недели или даже месяцы. Это не быстрое решение.

Я также обнаружил, что здесь меня немного смущает природа «блоков». Вероятно, это связано с терминологией, но из этого следует, что верно одно или несколько из следующих утверждений:

• Есть сдвиг парадигмы, который я пытаюсь осуществить или что-то неправильно понял.
• Новая парадигма не очень хорошо передается.
• Способы использования WordPress такими разработчиками, как я, для создания инструментов управления контентом для клиентов, не совсем понятны.
• Способы, которыми WordPress используется разработчиками, такими как я, для создания инструментов управления контентом для клиентов, хорошо изучены и игнорируются.

Я абсолютно уверен, что это последнее. Я не сомневаюсь, что члены команды Гутенберга знают и понимают, как большинство профессиональных разработчиков создают сайты с помощью WordPress.

Однако этот подход совершенно несовместим с продвижением WordPress к подходу конструктора сайтов, в котором Automattic нуждается в том, чтобы WordPress.com продолжал конкурировать с такими, как Squarespace, Wix et al.

WordPress не может быть конструктором сайтов и профессиональной CMS одновременно. Это просто невозможно. Он прошел тонкую грань между ними, позволяя пользователям перемещать его в любом направлении с помощью плагинов. (На пути к созданию сайта с использованием Beaver Builder, Divi и др. И к профессиональной CMS с такими плагинами, как ACF и CMB). Однако теперь ясно, что CMS уверенно движется в сторону конструкторов сайтов. Будь прокляты сайты, использующие настраиваемые поля.

Наконец, ваша точка зрения о блоках и базе данных верна.

Я думаю, это свидетельствует о многих проблемах, которые команда WordPress должна решить в первую очередь, прежде чем смотреть на такие вещи, как Гутенберг:

• Обновление min-версии PHP
• Внедрение собственных семантических данных (через настраиваемые поля) и изменение структуры БД для их учета.

В заключение, ребята из Statamic продемонстрировали, как это должно было быть решено с их новым полевым типом Барда. Дополнительный интерфейс редактора, который решает те же проблемы, что и Gutenberg, но гораздо более интеллектуальным и менее разрушительным способом.

Нет смысла повторять свои мнения, они уже были озвучены выше. Я согласен с общим мнением - это должен быть рассмотренный вариант, чтобы включить Gutenberg не обязательно при переходе с 4.x на 5.0.

Поскольку большинство разработчиков здесь, я обслуживаю ряд клиентов, некоторые из которых очень хорошо разбираются в технологиях, некоторые - нет, но подталкивание их в этом направлении, как я предполагаю, приведет только к путанице для большинства.

Что касается всего, что может сломаться; с точки зрения клиента, они уже создали и потратили бюджет на предоставленное решение, они не оценят, что им может потребоваться другой бюджет для поддержки или исправления проблем, вызванных чем-то, не созданным ими или мной.

Между разработчиком / проектировщиком или поставщиком предоставленного им тщательно продуманного решения, клиент и поставщик должны выбрать, когда разрешить такое серьезное изменение, а не что-то обязательное.

Просто выбросить его туда. Хотя WordPress не следует строго семантическому подходу к управлению версиями, версия 5.0.0 является критическим изменением.

Если Automattic не желает менять свою стратегию в отношении Гутенберга - и будем честными, это было бы правильным решением - тогда единственный другой вариант - сделать 4.9 версией LTS.

Таким образом, исправления безопасности могут быть применены к 4.9 в течение следующих, скажем, 5 лет. У разработчиков веб-сайтов достаточно времени, чтобы перенести свои сайты на Gutenberg или полностью отказаться от WordPress (что, как я подозреваю, будет самым популярным вариантом).

Ну, конечно, всем нравится писать здесь длинные комментарии. 😉 Для меня вечер, поэтому я не буду все затрагивать, но хочу затронуть несколько вопросов.

Я, со своей стороны, очень удивлен, что здесь и в других местах подразумевается, что классический редактор будет удален из WP, а плагин «Classic Editor» добавит его обратно. Это правильное понимание?

Это не так. В своем предыдущем комментарии я упоминал, что мета-блоки и CPT могут автоматически возвращаться к классическому редактору - они не смогли бы этого сделать, если бы код классического редактора был удален. 🙂

TinyMCE используется Гутенбергом для питания редактируемых текстовых блоков - это никуда не денется. Такие функции, как wp_editor() относительно легко поддерживаются в Core без необходимости переносить их в плагин - я бы ожидал, что они будут продолжать работать бесконечно.

То, что вы говорите, подразумевает, что блоки должны управлять всем. Это то, как будут управляться «данные сайта». Это и другие вещи, о которых вы сказали, подразумевают, что блоки - это не просто разделы контента, а какое-то устройство пользовательского интерфейса, которое можно подключить к чему угодно: параметрам сайта, настройкам, метаданным о сообщениях, виджетам, меню и т. Д. поля профиля пользователя, все.

Я именно это и говорю. Что ж, метаданные - это не блок, хотя они могут сообщать, как блок используется или отображается.

Поэтому я думаю, что нам нужно прояснить природу «блока».

Конечно. Блок - это кусок HTML, который совмещается с другими блоками. Существует множество API, которые упрощают и упрощают работу с блоками, но все сводится к этому.

Блок _не_:

• Кусок HTML, хранящийся в post_content (хотя некоторые блоки используют этот метод хранения).
• Статический (хотя некоторые блоки есть).
• Генерируется динамически (хотя есть и другие блоки).

@rosswintle , вы несколько раз упоминали метаданные, и я хотел бы уточнить, о чем вы здесь говорите. Не могли бы вы привести несколько примеров того, что вы считаете метаданными?

Если то, что вы здесь описываете, правда, тогда мне интересно, почему статус публикации не является блоком? Почему не блокируются категории и теги? Почему отрывок не является блоком?

Просто предложение, и я не уверен, является ли он или должен быть вариантом темы, но почему не в add_theme_support (), поскольку большинство новых разработанных функций были в прошлом?

Таким образом, исправления безопасности могут быть применены к 4.9 в течение следующих, скажем, 5 лет.

Учитывая, что WordPress 3.7 был выпущен немногим более 3 лет назад, а его последний выпуск безопасности был 6 недель назад, я думаю, разумно предположить, что WordPress 4.9 будет получать исправления безопасности в течение долгого времени.

@eirichmond : add_theme_support() может потребоваться для фокуса настройки Гутенберга, но большинство тем будут поддерживать контент на основе редактора блоков без каких-либо изменений.

add_theme_support () может потребоваться для фокуса настройки Гутенберга, но большинство тем будут поддерживать контент на основе редактора блоков без каких-либо изменений.

@pento В чем конкретно заключается фокус настройки Гутенберга, пожалуйста? Что это значит? Вы упомянули, что _most_ темы будут поддерживать блочный контент. Можете ли вы указать, почему тема не поддерживает его?

Я вижу темы с боковыми панелями, не поддерживающими определенные блоки, потому что блок указывает на полную ширину, например изображение обложки.

В чем именно заключается фокус настройки Гутенберга, пожалуйста? Что это значит?

Мэтт рассказал об этом в «Состоянии слова» - три основных направления в этом году:

• Редактор Гутенберга
• Настройка Гутенберга
• Тема Гутенберга

Редактор Гутенберга - это то, что появится в WordPress 5.0. Кастомизация Гутенберга только начинается, и он рассматривает настройку сайта и то, как это работает в блочной парадигме. Тема Гутенберга будет темой по умолчанию в этом году и, вероятно, будет запущена позже в этом году.

Можете ли вы указать, почему тема не поддерживает его?

Надеюсь, все темы будут работать. 🙂 Некоторые блоки имеют связанный с ними CSS (изображения обложек являются хорошим примером), поэтому есть вероятность, что что-то выглядит не совсем правильно. Однако нет ничего, что могло бы заставить тему перестать работать.

Могу ли я напомнить людям, что Gutenberg - это не автоматизированный проект, позволяющий не обесценивать усилия и работу неавтоматических специалистов, которые вносят свой вклад

Я также до сих пор не понимаю, почему плагин недостаточен, все аргументы, которые я видел, утверждают, что людям не нравится Гутенберг, или что у них уже настроен рабочий процесс, все проблемы, упомянутые ранее, и все исправлены установив и включив плагин классического редактора.

Имейте в виду, что в плагине ссылок тоже есть прецедент.

Но в любом случае давайте будем конструктивными:

Я обновился до WP 5.0, и Гутенберг заменил мой пользовательский редактор / мне он не нравится / мне нужно больше времени с клиентами

Что мне делать?

Установите плагин классического редактора и включите его, проблема решена. Теперь Гутенберг заменен классическим редактором, который есть в версии 4.9.

Минусы?

Вы не получите никаких новых функций Gutenberg, а новые функции в будущем могут не иметь смысла в классическом редакторе. Например, если в 5.1 появились блоки строк и столбцов, я не понимаю, как это имеет смысл в классическом редакторе.

У меня много сайтов клиентов, я не устанавливаю и активирую на каждом сайте, что, если клиент деактивируется?

Используйте его как плагин MU:

• Поместите папку плагина в wp-content/mu-plugins
• Поместите в папку mu-plugins файл, содержащий следующее:

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

Теперь плагин всегда загружается и не может быть деактивирован. Никаких дополнительных действий, кроме размещения файлов, не требуется. Затем вы можете загрузить файл и папку на каждый сайт один раз, и вам больше не придется об этом беспокоиться.

Уроки плагина Classic Editor

В этом плагине есть много полезных функций для таких вещей, как определение того, активирован ли Гутенберг, и большая часть этого фактически удаляет крючки и заменяет их.

Он даже добавляет область настроек с возможностью выбора `` классических ссылок редактора '', чтобы вместо замены Гутенберга вы получали то, что видите с плагином Gutenberg, активированным по ссылке `` классический редактор '' на экране сообщений, так что дает вам 3, а не 2 варианта.

Я настоятельно рекомендую людям взглянуть на плагин, протестировать его и посмотреть, как он построен.

Помните, что мы - сообщество, а не субъекты продуктовой команды Automattic. Если он сломается, у нас есть полный цикл выпуска WP, в течение которого мы его протестируем и исправим. Я вижу много заинтересованных лиц в этой теме, у которых есть технические навыки, чтобы исправить плагин, а также некоторых. Если это действительно так важно, я уверен, что кто-нибудь подойдет, как и люди, работающие над ядром.

@rosswintle , вы несколько раз упоминали метаданные, и я хотел бы уточнить, о чем вы здесь говорите. Не могли бы вы привести несколько примеров того, что вы считаете метаданными?

@pento Конечно:

Пример страны:

Тип сообщения "Страна", который имеет название (заголовок), описание (содержание), а затем:

• численность населения
• URL изображения флага
• ранжирование (и другие факторы, возможно, так или иначе закодированные)
• связанные «сообщества» (отношения к постам другого типа)

См .: http://peoplesunderthreat.org

Пример недвижимости:

Тип «собственности», имеющий:

• цена
• тип
• количество комнат
• дата постройки
  и т.п.

Пример события:

Тип «событие», имеющий:

• свидание
• время
• детали повторения
• расположение
  и т.д

Много.

Включив его и немного поиграв, у меня есть несколько серьезных проблем ... А пока я сосредоточусь на главном:

WooCommerce полностью ломается ... как будто его даже нет при редактировании продукта. И я полагаю, что многие другие плагины также полностью сломаются. Итак, каков план, чтобы помочь сообществу быть совместимым? И сколько времени у нас будет?

@tomjn

все аргументы, которые я видел, утверждают, что людям не нравится Гутенберг или что у них уже настроен рабочий процесс

«не нравится» - возможно, неправильный термин. Я думаю, что люди приводят веские аргументы в пользу того, что Гутенберг не подходит для многих случаев использования WordPress. Это не вопрос предпочтений или вкусов, это вопрос соответствия.

А разработчикам просто нужны варианты для этого. Я могу переключать другие основные функции, такие как отладка, редакторы кода, мультисайт, автоматические обновления и публиковать изменения в wp-config.php. Некоторые функции включаются только темами, которые их поддерживают, используя add_theme_support . Почему у нас нет параметров в коде для переключения Гутенберга таким же образом, чтобы разработчики могли использовать рабочий процесс, который им подходит для такого серьезного изменения?

Одна из проблем здесь в том, что разработчики (не обязательно я, но другие) не чувствуют, что к ним прислушиваются, когда они выражают озабоченность по поводу Гутенберга. Добавление этого в качестве символического жеста, чтобы помочь им, поможет вам немного привлечь их на свою сторону. Даже если по какой-то собственной философской причине вы не согласны с тем, что это правильно, рассматривайте это как оливковую ветвь, которую можно предложить разработчикам, которые не довольны.

Имейте в виду, что в плагине ссылок тоже есть прецедент.

Плагин ссылок - плохой пример. Он сохранил существующую функциональность в ядре, если вы ее использовали, и удалил ее только для новых установок (или если вы ее не использовали).

НРАВИТСЯ этот прецедент.

Это то, что утверждается в № 4423

Что меня действительно зацепило, так это то, что основные разработчики и Мэтт предполагают, что весь мир без вопросов полностью примет концепцию «блоков» и редактор Гутенберга. Думаю, все в порядке, но подход «по-нашему или по-своему», который они используют с Гутенбергом, не только неудобен для пользователя, но и может серьезно повлиять на состояние WordPress в целом.

На протяжении веков было много действительно отличных идей, которые просто не прижились, потому что они просто не были приняты массами. Betamax был намного превосходящим форматом, но он просто прижился, и VHS победил. Что, если Гутенберг и блоки просто не прилипнут? Что тогда будет с WordPress?

Тогда есть фактор доверия. Подавляющее большинство пользователей WordPress даже не понимают, что такое WordPress. Они используют его просто потому, что бренд WordPress популярен, и как бы вы ни смотрели на него, WordPress для большинства людей - это просто бренд. Бренды живут и умирают благодаря доверию потребителей.

Когда, наконец, выйдет обновление 5.0 и миллион сайтов WordPress внезапно это резко изменит, как отреагируют те конечные пользователи, которые ничего не следят за миром WordPress?

Большинство моих клиентов, как один выразился, «едва могут включить компьютер» или просто хотят, чтобы то, за что они заплатили, работало, как обещано. Это люди, которые доверили WordPress делать то, что обещал. Если однажды это обещание нарушится из-за совершенно нового формата управления контентом их сайта, внезапно изменится. Тогда их доверие к WordPress будет сломано, и люди БУДУТ просто бросить что-то, если они больше не будут доверять этому.

Я считаю, что именно от этого и исходит большая часть опасений разработчиков. Мы создаем отличные пользовательские сайты WordPress, которые работают именно там, где хотят наши клиенты, и теперь все это «сломается» из-за Гутенберга, и у нас нет возможности предотвратить то, что может стать огромной катастрофой.

Единственная цель Гутенберга - увеличить долю WordPress на рынке, но он очень легко может сделать прямо противоположное. Это действительно может оттолкнуть людей от WordPress. Гутенберг может стать новой кока-колой для WordPress, а WordPress не такой большой, как кока-кола, чтобы его можно было просто восстановить, как это сделала кока-кола. Люди перейдут к чему-то другому и не оглянутся назад.

Вы продолжаете говорить: «Это повлияет на будущее усыновления Гутенберга, бла, бла, бла», но это действительно так просто. Либо всем это понравится, и необходимость удалить его с помощью кода или плагина, либо что-то еще станет неактуальным, либо Gutenberg просто станет какой-то странной функцией, которую никто не использует, как Press This.

В настоящее время предполагается, что либо Gutenberg добьется успеха, либо WordPress в целом может потерпеть неудачу. Мы, разработчики, озабоченные проблемами, только пытаемся полностью не испортить отличный инструмент для управления контентом. Мы лучше всех знаем, как наши клиенты используют WordPress. Основные разработчики и Мэтт смотрят только на статистику и доли рынка, и знаете, что это нам принесло? Охотники за привидениями перезагружаются.

Мы действительно хотим работать с вами, чтобы это произошло, но было бы лучше, если бы мы могли контролировать, как это представляется миру, а не навязывать это ничего не подозревающим пользователям. Все, что мы просим, ​​- это способ облегчить нашим клиентам переход в новый редактор. Это действительно не так уж много.

Если Гутенберг действительно будет нововведением, которым обещал стать, тогда отлично! Все садятся на поезд Гутенберга. Если нет, то мы просто просим предоставить возможность не довести это до огромной катастрофы.

Как будто вы знаете, что это не будет хорошо принято, и вы хотите, чтобы это произошло так сильно, что вы чувствуете, что единственный способ даже возможно добиться успеха - это просто навязать всем. Это похоже на то, как политики говорят вам наглую ложь о том, что законопроект о налогах, который принесет пользу каждому, будет принят, когда на самом деле только супербогачи действительно выиграют от него.

Это похоже на то, что однажды сказал великий доктор Кокс.

Помоги мне помочь тебе.Помоги мне помочь тебе.Помоги мне помочь тебе.Помоги мне помочь тебе.

WooCommerce полностью ломается ... как будто его даже нет при редактировании продукта. И я полагаю, что многие другие плагины также полностью сломаются. Итак, каков план, чтобы помочь сообществу быть совместимым?

@ smp303 Не место для обсуждения этого вопроса, но мы сейчас работаем над совместимостью WooCommerce + Gutenberg. Следите за блогом разработчиков WooCommerce .

Возможно, лучшая аналогия, чем «New Coke», - это Windows 8.

Это было смелое новое видение мышления в отношении более мобильных вычислений, которое привело к ужасным неприятным последствиям, поскольку изменило слишком много базовых предположений об использовании. Да, глубоко в настройках пользователь мог восстановить большую часть своего предыдущего опыта работы с Windows, но, если он не был в технических журналах, пользователи понятия не имели, как это сделать. Результатом стала катастрофа для Windows.

Гутенберг очень быстро движется по тому же пути. Он вносит чудовищное изменение, полностью управляемое компанией, а не сообществом, и оставляет (я полагаю, некоторые подробности об этом я вижу) довольно непонятный путь через внешний плагин к возвращению к традиционному редактору для тех, кто кому не нравится эта новая методология.

Я думаю, что если Automattic / WordPress не предоставит в настройках средства для отключения Гутенберга для миллионов случайных пользователей WordPress, они будут глубоко сожалеть об этом. Гутенберг - огромная перемена. Со стороны пользователей будет МНОГО отталкивания.

В этой теме мы пытаемся предостеречь вас от этого и сообщаем, что внешнего плагина НЕ будет достаточно. Вы должны предоставить пользователям «выход» к Гутенбергу, даже если только дать им период адаптации. Если мы сможем активировать его в наших существующих темах с помощью кода, мы, возможно, сможем предотвратить катастрофу.

Мы отчаянно пытаемся помочь здесь. Внешнего плагина НЕ хватит. Возможность возврата к классическому редактору должна быть встроена. Либо сделайте это как часть выпуска, либо предоставьте нам способ сделать это с помощью кода, который мы можем встроить в наши темы.

С логической точки зрения, я пытаюсь понять философию, позволяющую разработчикам объявлять метабокс в add_meta_box (), чтобы НЕ поддерживать Гутенберг, который затем заставляет экран редактора везде, где используется метабокс, показывать «классическую версию» экрана редактора. Почему же тогда некоторые разработчики выступают против константы, определенной в файле wp-config.php? Если я могу объявить, что материал Гутенберга НЕ будет использоваться в одной области кода, почему мы не можем объявить его для использования в других областях, как мы в настоящее время устанавливаем операторы определения?

Имейте в виду, что для константы плагин классического редактора должен быть связан с WordPress с настраиваемым загрузчиком и оставаться там навсегда. Он все еще может быть там через 10-15 лет, когда появится то, что заменит Гутенберг.

Даже в этом случае для тех, кому нужны или нужны оба редактора, плагин все равно потребуется.

Не забывайте, что вы все еще можете установить и настроить плагин в версии 4.9 в ожидании прибытия Гутенберга.

Я думаю, что если Automattic / WordPress не предоставляет

@robmcclel Automattic - это не WordPress, WordPress.org! = WordPress.com, одно - сообщество с открытым исходным кодом, другое - платная сторонняя служба. Automattic не выпускает версии WordPress, WordPress не является внутренним продуктом Automattic, как и Gutenberg. Есть много участников, не относящихся к Automattic, ведущих разработчиков и т. Д., Которые делают что-то за пределами Automattic.

«Даже в этом случае для тех, кому нужны или нужны оба редактора, плагин все равно потребуется».

Фактически, из того, что обсуждалось здесь и в других местах, если пользовательский тип сообщения или метабокс заявляет, что он не поддерживает Gutenberg, экран редактора автоматически отключается ... без необходимости в подключаемом модуле «Classic Editor». Это одна из многих проблем, связанных с текущим состоянием проекта Gutenberg, существует множество мнений / утверждений о том, что происходит в определенных ситуациях, и часто эти утверждения / мнения отличаются от других.

Имейте в виду, что для константы плагин классического редактора должен быть связан с WordPress с настраиваемым загрузчиком и оставаться там навсегда.

@tomjn Подожди! Так вы говорите, что вся система мета-боксов удаляется из ядра?

Нет, я вообще не упоминал о метабоксах. Но имейте в виду, что метабоксы существуют в Гутенберге, и предполагать, что они удаляются, означает, что вы не тестировали Гутенберга, и игнорирует тот факт, что огромная часть экосистемы зависит от них. Это было бы огромной проблемой для wordcamp.org, wordpress.org и т. Д.

Для справки, я не являюсь членом команды Gutenberg, я просто наблюдаю и применяю здравый смысл. Тот факт, что я работаю в Automattic, не означает, что у меня есть особые способности к Гутенбергу. У меня такое же право голоса, как и у всех здесь, и если бы я хотел изменить это, я бы сделал это, добавив код и исправив проблемы, как и любой другой.

@tomjn Значит, то, что вы сказали, для меня не имеет никакого смысла. «Классический редактор» - это, по сути, просто страница администратора с мета-блоками на ней, функциями для сохранения и тому подобным. Это означает, что для того, чтобы иметь возможность переключаться между Gutenberg и Classic, в ядро ​​должен быть встроен код, позволяющий использовать два варианта, и весь код для классической функциональности останется на месте.

Так что это будет означать, что плагин Classic будет не чем иным, как способом активировать переключатель. Похоже, было бы проще просто создать в ядре постоянную или поддерживаемую тему, чем создавать и поддерживать плагин.

Если все для Classic все еще в ядре, зачем делать плагин только для его активации?

И что, если он должен остаться на месте. В ядре WordPress уже есть масса старого и устаревшего кода. Встроенный триггер Classic не будет иметь большого значения в общем плане.

Не будем лукавить, Том. Automattic во многом является движущей силой Gutenberg. Никакие слова «но это не», исходящие от сотрудников Automattic, не изменят тот факт, что это так же очевидно, как солнце в небе в ясный день.

Гутенберг - ребенок Мэтта; как Automattic. Он руководил проектом. Он был ее самым большим болельщиком.

Gutenberg имеет серьезные операционные преимущества для Automattic, а именно дает ему продукт, который уравновешивает игровые ощущения от его крупнейших конкурентов. Этого нельзя сказать об остальном сообществе.

Да, многие пользователи WordPress используют конструкторы страниц через плагины. Однако другая большая часть интенсивно использует настраиваемые поля через плагины, такие как ACF и CMB (и его многочисленные вилки). Эта часть сообщества годами требовала, чтобы проект WordPress реализовал настраиваемые поля в качестве встроенной функции.

Однако это не удалось реализовать, потому что для этого не было финансирования, и каждый раз, когда он поднимался, он страдает от столь распространенной проблемы с открытым исходным кодом - споров между комитетами.

Та же участь постигла и многих других, гораздо более острых проблем, например, версию min-PHP, которая не утихала более 7 лет .

Это всего лишь несколько примеров того, что нужно было сделать много лет назад, но все еще не было достигнуто, потому что основной спонсор проекта не поддержал его.

Automattic оказала поддержку Гутенбергу - во многом благодаря тому, что Мэтт оказался за рулем. Огромное количество рабочих часов было посвящено тому, чтобы это стало реальностью. Это означает прямое финансирование от основного спонсора проекта WordPress - Automattic.

Я не понимаю, какое отношение это имеет к билету?

@rosswintle Это очень актуально. Есть много разработчиков, которым нужен простой способ отключить Gutenberg. Совершенно очевидно, что власти не хотят нам этого давать и делать максимально неудобным отключение Гутенберга.

Движущей силой этого решения является намерение Matt и Automattic увеличить свою долю на рынке веб-сайтов DIY. Ясно, что проблемы сообщества не решаются из-за влияния Мэтта и Automattic на проект. Отсюда 100% недовольства сообщества Гутенбергом.

Поскольку на направление проекта Гутенберга во многом повлияли Мэтт и Автоматтик, это актуально в этом обсуждении, как и во всех обсуждениях проекта.

@tomjn

Что касается Gutenberg и этого предстоящего выпуска, WordPress является продуктом Automattic. Верить во что-либо еще - глупость. .Com или .Org не имеет значения - программа WordPress теперь является продуктом Automattic. Разработчики и им подобные, работающие над этим сейчас, являются не более чем бесплатными стажёрами для Automattic.

Сообщество хочет, чтобы Gutenberg был плагином. Мэтт этого не делает. Мэтт - глава Automattic. Мэтт сам себя назначил ведущим для этого релиза. Люди, ведущие разработку Gutenberg, - это сотрудники Automattic. Мэтт заставляет это делать. Другого решения или дебатов нет - у него 51% голосов, и он их реализует.

Не обманывайте себя, думая, что WordPress каким-либо образом формирует демократический продукт или продукт сообщества. Сейчас это продукт компании Automattic, однако в прошлом он создавался или продавался на рынке, и теперь они определяют направление разработки, темпы и решения.

@rosswintle , это относится к считает очень важным. большое целое просит.

Мэтт и Automattic усиливают свои полномочия по этому поводу. Вы могли бы с таким же успехом закрыть этот билет и все остальные, которые ему понравились, потому что наш голос больше не актуален, кроме как выразить сочувствие и дать нам возможность выразить свое мнение. С таким же успехом этот билет может даже не существовать.

За это отвечает Automattic, а не сообщество. Нам нужно столкнуться с этим и приготовиться к ударам, потому что это происходит, и единственный выход - плагин Classic Editor, и даже это небольшая благотворительность. Больше ничего не будет.

Я лично не понимаю, как обсуждение того, кто принимает здесь решения, помогает продвинуть проблему вперед. Он разрабатывается как проект с открытым исходным кодом, а это означает, что вы можете иметь право голоса, и я бы призвал людей использовать свой голос конструктивно, помогая разработать варианты и обоснование для реализации этих вариантов.

Последнее сообщение по теме сделанного запроса было написано @tomjn , за ним последовали некоторые соответствующие вопросы от @wpstudio и @jawittdesigns.

Имейте в виду, что для константы плагин классического редактора должен быть связан с WordPress с настраиваемым загрузчиком и оставаться там навсегда. Он все еще может быть там через 10-15 лет, когда появится то, что заменит Гутенберг.

Разве константа никогда не объявлялась устаревшей? (Подлинный вопрос) Похоже, WPLANG мог быть в v4.0? Это философский вопрос о природе констант? Был бы фильтр лучше? Подойдет ли фильтр для

Даже в этом случае для тех, кому нужны или нужны оба редактора, плагин все равно потребуется.

Это почему?

@jawittdesigns справедливо спрашивает:

Если все для Classic все еще в ядре, зачем делать плагин только для его активации? И что, если он должен остаться на месте. В ядре WordPress уже есть масса старого и устаревшего кода. Встроенный триггер Classic не будет иметь большого значения в общем плане.

и @pento практически исключил удаление большей части :

TinyMCE используется Гутенбергом для питания редактируемых текстовых блоков - это никуда не денется. Такие функции, как wp_editor (), можно относительно легко поддерживать в Core без необходимости переносить в плагин - я бы ожидал, что они будут продолжать работать бесконечно.

В заключение:

Не забывайте, что вы все еще можете установить и настроить плагин в версии 4.9 в ожидании прибытия Гутенберга.

Мы все об этом знаем. Мы пытаемся отстаивать разные методы, которые дают разработчикам варианты с разными рабочими процессами.

@rosswintle - это важно обсудить, потому что в конечном итоге знание того, кто принимает решения, проливает свет на то, насколько вероятно, что наши запросы будут приняты, и как сформулировать их так, чтобы они оказали максимальное влияние.

Однако да, вы правы в том, что этот конкретный вопрос - неподходящее место для его обсуждения. Однако отказ уступить по нашим просьбам свидетельствует о том, что мы находимся в более слабом положении по сравнению с теми, кто принимает решение.

Так или иначе. Вы сделали несколько хороших замечаний в последнем посте. Фактически, позвольте мне уловить вашу цитату:

Имейте в виду, что для константы плагин классического редактора должен быть связан с WordPress с настраиваемым загрузчиком и оставаться там навсегда. Он все еще может быть там через 10-15 лет, когда появится то, что заменит Гутенберг.

Должны ли мы предполагать, что как только придет то, что заменит Гутенберга, у нас больше не будет той же дискуссии? Большим УТП WordPress всегда было стремление к обратной совместимости по сравнению с конкурентами. Это хорошо работало до сих пор. Как мы все отмечали, Гутенберг нарушает это. У нас очень мало выбора, чтобы оставаться с тем, что у нас есть сейчас, за исключением того, что фактически является санкционированным официальным взломом.

Дело в том, что код все еще в ядре. Это гораздо более умный и точный подход, позволяющий использовать константу - одну строку кода - над подключаемым модулем, который нужно будет поддерживать отдельно, что в итоге превратится в сотни строк кода.

Дело в том, что код все еще в ядре. Это гораздо более умный и точный подход, позволяющий использовать константу - одну строку кода - над подключаемым модулем, который нужно будет поддерживать отдельно, что в итоге превратится в сотни строк кода.

Это моя точка зрения ... Это не просто нишевое количество людей, которым это понадобится. В связи с тем, что Гутенберг в настоящее время не работает, ломает огромное количество плагинов, тем и т.д. Неправильный способ решить проблему, которая может в конечном итоге оттолкнуть ядро ​​людей, которые создают лучшие сайты WordPress.

Другой вариант, который меня больше всего пугает, - это то, что люди просто придерживаются версии 4.9 и не обновляют сайты. Затем они становятся нестабильными и открытыми для взлома, что снижает название WordPress.

Мне просто не кажется, что об этом было уделено достаточно внимания, и поэтому плагин является конечным решением.

Если TinyMCE будет продолжать находиться «под» Гутенбергом для определенных блоков, почему бы не подойти к ситуации следующим образом:
В версиях до 5.0 (также называемых текущими сайтами, работающими на WordPress) Гутенберг был отключен по умолчанию с помощью фильтра / константы, упрощающего включение Гутенберга.
5.0+ (также известные как сайты WordPress, установленные после 5.0) по умолчанию будет включать Gutenberg с фильтром / константой, что упрощает отключение.

Таким образом, любой, кто хочет использовать Гутенберг, легко может сделать этот выбор, и любой, кто не готов или не желает использовать Гутенберг (по какой-либо причине), также может легко сделать этот выбор. Просто временами кажется, что некоторые хотят умереть на холме Гутенберга, когда появляются более практичные (в краткосрочной перспективе) решения.

@wpstudio Это почти то, о чем просит # 4423.

Как и @rosswintle , я думаю, что важно вернуть эту проблему в нужное русло для тех, кто сделал это и доволен, что последние несколько комментариев кажутся таковыми. Спасибо за то, что обсуждаете с уважением.

Однако следует сказать, что, что бы вы ни думали о компании и их мотивации, многие люди работают над Гутенбергом в самых разных компаниях. Как и в случае с WordPress, это сделано благодаря вкладу сообщества (а не одной компании). Нечестно делать резкие заявления тех, кто этим занимается. Это также несправедливо по отношению к тем, кто начал эту проблему и хочет ее решения.

Я надеюсь, что этот вопрос вернется в нужное русло и продолжу уважительное обсуждение сути этого вопроса.

@karmatposed , @ntwb , @tomjn и другие в этой ветке, если моя небольшая тирада выше оскорбила, я извиняюсь за это. Это чрезвычайно важная тема, и она заслуживает обсуждения, если мы действительно собираемся ее обсуждать.

Из приведенных выше потоков, я думаю, довольно очевидно, что Gutenberg можно отключить в Core, так как другие компоненты должны будут оставаться как часть Core, поэтому он просто отключает Gutenberg. Это имеет смысл, поскольку в настоящее время он существует как плагин, и многие сайты могут его нормально запускать. Таким образом, за исключением ранее не представленной технической причины, это означает, что это решение не техническое, а философское.

И это его настоящая суть. Я не думаю, что сообщество в целом придерживается единого мнения по этому поводу. Даже не близко. Вот почему решение переносится (обратите внимание, я сказал «помещен», а не «обвинен») на Мэтте, потому что он, кажется, является движущей силой этого. И, видимо, за непоколебимым решением сделать Gutenberg частью Core и версии 5.0.

Вопрос: «Почему?»

Я определенно вижу причины, по которым Гутенберг был вынужден работать в Core. Я думаю, что «блоки» очень важны для будущего выживания и широкого использования WordPress, .org или .com. Я делаю. Я отстаю от "блоков" на 100%.

Однако я не думаю, что сам Гутенберг, как способ доставки этих «блоков», является хорошо продуманной системой. Из этой ветки можно выделить 3 разных варианта использования (я, @ smp303 ), и Гутенберг, похоже, не удовлетворяет никого из нас. Действительно, это вызывает у нас немало беспокойства - для нас, нашего бизнеса и наших пользователей.

Решение поместить Gutenberg в Core имеет смысл для Automattic, потому что оно заставляет каждого разработчика плагинов адаптироваться к нему и переписывать свои плагины для работы с ним. Это очень хорошо для WordPress.com и, возможно, хорошо для WordPress.org. Но, опять же, для некоторых вариантов использования блоки не принесут пользы, но, надеюсь, наличие блоков им тоже не повредит.

Однако это означает, что очень небольшая группа людей принимает довольно важные экономические и деловые решения для очень большого количества людей. Только для меня переход на блоки будет стоить сотни часов и тысячи долларов, плюс потерянное время разработки, связанное с необходимостью отвлекать ресурсы от моих запланированных целей (которые на самом деле хочет сообщество, которое я обслуживаю) для капитального ремонта значительных разделов моей системы. чтобы удовлетворить требования тех неизвестных лиц, принимающих решения (опять же, я предполагаю, что Мэтт является значительной частью этой группы, принимающей решения).

Я бы не чувствовал себя так плохо из-за этого - или так боялся, если честно, - если бы Гутенберг решал проблемы за меня. Но это не так. Пока что это делает мою жизнь намного хуже. Все может улучшиться, но я не вижу большого сдвига в направлении развития. Кажется, что 95% решений об использовании, реализации, UI / UX, а также средствах и методах были приняты небольшой группой других без особых дискуссий или комментариев.

WordPress поддерживает более 25% всего Интернета. Это означает миллионы сайтов, миллиарды веб-страниц и, возможно, сотни миллиардов долларов. От New York Times до нескольких книжных блоггеров в моей сети. От крупных сайтов электронной коммерции до отдельных подписанных книг, продаваемых авторами, которые я обслуживаю. Это огромно - МАССИВНО. Это практически всемирная глобальная утилита.

Тем не менее, решение переписать значительную часть основ всего этого - затрагивающего многие миллионы людей - было очевидно принято без обсуждения. Все, от интерфейса до использования REACT (контролируемого Facebook, который зарекомендовал себя как хищник, просто спросите SnapChat). Все эти решения были приняты в основном в одностороннем порядке.

Если бы все это было только для питания модуля в JetPack, никого бы это не волновало. Это бизнес WordPress.com. Но это не так. Он преобразует основы всего Интернета.

Что приводит меня прямо здесь и сейчас. Сообщество, определенно члены сообщества в этой ветке, просят контроля над продуктом и бизнесом, которые они создали с использованием открытого исходного кода и общедоступного кода WordPress.org. Мы просим о возможности защитить себя и наших пользователей, и единственный способ, который мы можем придумать для этого, - это попросить способ отключить Гутенберга. Мы просим, ​​чтобы эта способность была частью Core, точно так же, как добавление Гутенберга должно стать частью Core.

Можно ли добавить в Core возможность отключения Гутенберга? Кто именно принимает это решение и направляет к этому потенциальных клиентов? Каков механизм, чтобы задать этот вопрос? Можно ли обсудить ответ? Будет ли он поставлен на голосование? Есть ли процесс комментирования? Если да, то где?

И, @karmatposed , вы на 100% правы в том, что раздел «Проблемы» на Github - не лучшее место для обсуждения. Я согласен с тем, что это репо следует в значительной степени оставить для использования по назначению, а именно для выявления и решения технических проблем, непосредственно связанных с подключаемым модулем Gutenberg.

К сожалению, похоже, нет другого места для этого обсуждения. Я имею в виду, что есть раздел обзоров плагина Gutenberg, но это довольно ограниченный форум для такого рода разговоров.

Будет ли создан сайт для обсуждения Гутенберга? Не только его реализацию, но и комментировать и обсуждать интерфейс? Расписание релизов? (Например, какие критерии определяют, если Gutenberg и WP5.0 "закончены" и готовы к выпуску? Кто принимает это решение? ") Будет ли проводиться пользовательское тестирование интерфейса Gutenberg? Есть ли способ собрать данные и отзывы от @ tomjn «s очень полезно„Frontenberg“? Если да, то будет опубликовано , что данные?

На YouTube было интересное видео, в котором людям предлагалось попробовать использовать Gutenberg и оценить его интуитивность (ссылка здесь: https://youtu.be/7iWRBLCP-l0) - есть ли другие подобные? Есть ли масштабные усилия по тестированию Гутенберга? Если да, то где хранятся эти данные? Как эти данные передаются? Может ли это увидеть сообщество? Используется ли он для дизайна?

Проблема, с которой мы сейчас сталкиваемся с Гутенбергом - и она действительно является движущей силой этой самой темы - заключается в том, что сообщество чувствует себя очень изолированным от этого процесса. Нам кажется, что это происходит с нами. В самом деле, это нам навязывают. Открытие процесса для комментариев и дебатов, предоставление новых голосов и идей о таких вещах, как интерфейс, обмен данными и понимание пользователей, будет иметь большое значение для облегчения этих страхов и опасений.

И создание блоков в качестве основной возможности, но сохранение Gutenberg в качестве плагина может сделать все намного менее пугающим и более приемлемым для сообщества в целом. Мне бы это лично понравилось. Дайте сообществу время изучить и разработать альтернативные подходы к Гутенбергу - различные интерфейсы и варианты использования - но при этом поощряйте развитие и будущее блоков.

Итак, это было довольно долго, но опять же, где еще мы можем провести эти дебаты, кроме как здесь? И эта дискуссия ОЧЕНЬ важна. Это может быть самая важная дискуссия в Интернете прямо сейчас, учитывая количество затронутых людей и предприятий.

Проведя небольшое исследование по этому поводу, оказалось, что все, что вам нужно в файле mu-plugin это следующее, чтобы отключить Гутенберга с помощью кода, если я что-то не пропустил - что вполне вероятно!

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

Для контекста у меня активен плагин Gutenberg и приведенный выше код находится в файле в папке mu-plugins . Теперь на всех экранах редактирования постов используется классический редактор.

Несколько замечаний по этому поводу:

• gutenberg_can_edit_post_type не является окончательным именем фильтра - имена gutenberg будут переименованы перед объединением в Core.
• Этот фильтр просто означает «не загружать редактор блоков», но не означает «использовать классический редактор». На данный момент это работает, но не гарантирует, что будет работать в будущем. Поскольку код, специфичный для Classic (например, edit-form-advanced.php ) перемещается в плагин Classic Editor, он перестанет возвращаться к классическому редактору и явно ожидает, что вы загрузите собственный редактор.

@rosswintle : с прошлой недели :

Самый простой способ подумать об этом - «если данные появляются между <body> и </body> , они являются содержимым и в конечном итоге помещаются в блок». В WordPress 5.0 это немного более ограничено - только блоки между <article> и </article> . 😉

Итак, возьмем один пример, тип сообщения о недвижимости. Цена хранится в postmeta, но это контент. У вас может быть блок под названием «Property Lede», в котором нужно заполнить несколько пунктов - цена, адрес, тип здания, количество спален / ванных комнат / гаражей и тому подобное. У вас, вероятно, будут и другие блоки - время проверок, функции, фотографии, планы этажей, агент и т. Д. Используя шаблоны блоков , вы настраиваете редактор блоков так, чтобы при редактировании типа сообщения property блоки уже расположены и не могут быть перемещены. Рабочий процесс для конечного пользователя не отличается от того, как сейчас выглядит существующий рабочий процесс на основе метабокса, но он гораздо больше напоминает окончательный результат.

Это было немного многословно, но, надеюсь, оно задает сцену - все, что выглядит как контент _is_ контент, независимо от того, где хранятся данные, или как ими можно манипулировать или форматировать, прежде чем они будут отображаться во внешнем интерфейсе. Некоторые блоки могут хранить свои данные в post_content , но это не является определяющей особенностью того, что делает их содержимым - отображение на интерфейсе - это то, что делает их содержимым.

Так что насчет информации, которая не отображается в интерфейсе? Имя владельца? Отношение к просмотру встреч? Это «содержание»? Это нужно ввести в «блок»?

Категории / теги / таксономии могут отображаться или не отображаться в интерфейсе. Это «блоки»?

Статус публикации может отображаться в интерфейсе, но это определенно не блок.

Вы ранее сказали:

метаданные не являются блоком, хотя они могут сообщать, как блок используется или отображается.

Что нормально. Но почему же тогда разработчикам говорят, что в будущем метаданные следует редактировать с помощью блочного интерфейса?

Это для меня настоящая путаница. Я понимаю, почему блоки Гутенберга хороши для редактирования того, что находится между тегами body , но я не понимаю, почему блоки хороши для редактирования других данных, которые не находятся между этими тегами.

Мне кажется, именно эта путаница заставляет разработчиков отключать Гутенберга. Некоторые из наших применений WordPress содержат МНОГО информации, которая не отображается во внешнем интерфейсе, и все же нам говорят, что в будущем интерфейсный редактор - это то, что мы должны использовать в качестве интерфейса для этих данных.

Я надеюсь, что это объясняет путаницу.

Так что насчет способов отключить его ...?

@pento блок документации для этой функции вовсе не означает, что этот фильтр временный:

/**
 * 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), перемещается в плагин Classic Editor, он перестанет возвращаться к классическому редактору и явно ожидает, что вы загрузите свой собственный редактор.

В ряде случаев нам говорили, что если типы сообщений объявляют show_in_rest => false или мета-поле на экране редактирования сообщений объявляет '__block_editor_compatible_meta_box' => false, , тогда будет загружен классический редактор. Сверху кажется, что вы говорите, что это не будет частью ядра, и, следовательно, как это может быть в случае, если вы не активировали плагин классического редактора?

Чтобы вернуться к классическому редактору, обнаружено что-то, что не поддерживает Gutenberg, тогда, конечно, классический редактор должен оставаться частью ядра - поэтому, конечно, нам не нужен плагин для вызова этой функции?

Так что насчет информации, которая не отображается в интерфейсе? Имя владельца? Отношение к просмотру встреч? Это «содержание»? Это нужно ввести в «блок»?

Конечно, есть место и для метаинформации - это обсуждается в # 3330. В первую очередь я хотел отметить, что многое из того, что называется «метаданными», на самом деле является контентом.

Категории / теги / таксономии могут отображаться или не отображаться в интерфейсе. Это «блоки»?

Ну, это мета для публикации, но, возможно, контент для сайта. Фокус настройки Гутенберга, вероятно, будет включать блок, который использует эти метаданные для создания контента. 🙂 Однако маловероятно, что блок в редакторе блоков будет использовать их в качестве содержимого, поэтому таксономии находятся на боковой панели, а не в блоке.

Что нормально. Но почему же тогда разработчикам говорят, что в будущем метаданные следует редактировать с помощью блочного интерфейса?

Мы не говорим, что все метаданные вписываются в интерфейс блока. Некоторые могут, но им не обязательно. Суть в том, что _большинство_ существующих применений метабоксов вписывается в интерфейс блока, и самый простой способ отличить их друг от друга - подумать о том, отображается ли он в интерфейсе или нет. В # 3330 более подробно обсуждаются концепции редактирования метаданных.

Я могу вам категорически сказать, что метаданные _не_ нужно редактировать в интерфейсе редактора блоков. Если он не является контентом или каким-то образом не связан с контентом, он ему не принадлежит - есть другие места для вставки интерфейса для редактирования этих метаданных.

Так что насчет способов отключить его ...?

Если вы создаете сайты, используйте плагин Classic Editor. Если вы создаете плагины, используйте флаги совместимости CPT и meta box. 🙂

Если вы создаете сайты, используйте плагин Classic Editor. Если вы создаете плагины, используйте флаги совместимости CPT и meta box. 🙂

Это нормально для сайтов, которые мы создаем в будущем, или для клиентов, которые у нас есть «в книгах» и следят за их сайтами. Однако как насчет клиентов, чьи сайты мы создавали в прошлом и работают нормально, автоматически обновляются и т. Д. Они, вероятно, нажмут обновление до WordPress v5.0.

На этих сайтах не будет установлен плагин Classic Editor, и у них не будет никаких флагов для этих мета-боксов / CPT, потому что они были закодированы, когда Гутенберга не было. У этих сайтов будут проблемы, и их владельцы будут сбиты с толку и, откровенно говоря, довольно раздражены. Пожалуйста, поправьте меня, если я ошибаюсь.

@wpmark сделал это.

Я буду использовать плагин Classic Editor, если мне понадобится в будущем. Я буду использовать флаги совместимости CPT и meta box, если мне это понадобится в будущем. Но у меня есть десятки частных лиц, предприятий и благотворительных / некоммерческих организаций всех форм и размеров, для которых я уже создал сайты. С некоторыми из них у меня до сих пор рабочие отношения. Другие ушли и либо сами управляют сайтом, либо работают с другим разработчиком, либо вообще без разработчика.

Нереально ожидать изменений кода или установки плагина на каждом сайте, который в этом нуждается.

На самом деле это территория №4423.

Для всех важных разговоров у этого билета нет ни этикеток, ни владельца. Если этого не произойдет, есть ли смысл держать его открытым?

gutenberg_can_edit_post_type (или как там это называется в Core) и '__block_editor_compatible_meta_box' => false вернутся к классическому интерфейсу в WordPress 5.0. Однако в будущих выпусках WordPress это поведение может измениться.

gutenberg_can_edit_post_type только указывает, загружать ли редактор блоков или нет. На данный момент поведение по умолчанию, когда редактор блоков не загружается, - это загрузка Classic, но этот фильтр предполагает, что, если вы не загружаете редактор блоков, вы предоставляете свой собственный интерфейс. Это может быть плагин Classic Editor или пользовательский интерфейс. Но вполне вероятно, что в будущем выпуске WordPRess код Classic будет перемещен в классический редактор.

Аналогичная ситуация существует для флага __block_editor_compatible_meta_box . На данный момент он возвращается к классическому интерфейсу, но в будущей версии WordPress может измениться поведение по умолчанию, чтобы остаться в редакторе блоков, и отобразить предупреждение, где будет мета-поле.

Конечно, ни одно из этих изменений не произойдет без исследования и обращения к владельцам сайтов - я считаю, что эти настройки в основном существуют для перехода на Gutenberg. Плагин Classic Editor - это стабильный вариант для принудительного использования классического интерфейса.

См. # 3902 для более подробного обсуждения этих вопросов.

Что касается информирования владельцев сайтов, WordPress 5.0 не будет выпускаться в вакууме. Есть много инструментов, которые мы можем использовать, чтобы проинформировать владельцев сайтов о предстоящих изменениях и сообщить им, будет ли их сайт работать или нет. Будущие выпуски WordPress 4.9.x будут включать информацию о редакторе блоков , есть планы по сбору данных о совместимости плагинов (как автоматических, так и краудсорсинговых - # 4072), и мы открыты для других вариантов, чтобы владельцы сайтов знали о что будет.

Для всех важных разговоров у этого билета нет ни этикеток, ни владельца. Если этого не произойдет, есть ли смысл держать его открытым?

У меня не было проблем с тем, чтобы оставить его открытым, пока мы обсуждали это, но на данный момент я не вижу необходимости держать его открытым. Чтобы ответить на исходный вопрос, возможность возврата к классическому редактору на основе кода отсутствует.

@pento Почему ты закрыл это? Вопрос пока не решен.

Вы просто доказываете, что к сообществу не прислушиваются, закрывая это.

Я действительно думаю, что вам следует снова открыть его, чтобы мы могли прийти к решению по этому поводу.

Разрешения не было - они не позволят отключить Гутенберга в коде. Вы должны полагаться на плагин.

Совершенно недоволен и недоволен этим, но, по крайней мере, я попытался.

Разрешения не было - они не позволят отключить Гутенберга в коде. Вы должны полагаться на плагин.

Где и когда это произошло? Здесь нет упоминания о решении.

Или это просто типичная реакция основной команды: притворяется, что слушает, а затем просто закрывает ее?

Какого рода разрешение вам нужно на данном этапе?

Если вы хотите отключить Гутенберга с помощью константы, этого не произойдет. Нас выслушали, но идея отклонена.

У меня не было проблем с тем, чтобы оставить его открытым, пока мы обсуждали это, но на данный момент я не вижу необходимости держать его открытым. Чтобы ответить на исходный вопрос, возможность возврата к классическому редактору на основе кода отсутствует.

От @pento - поэтому он закрыт

Что ж, я надеюсь, что они, по крайней мере, выпустят плагин перед обновлением, чтобы мы могли установить и активировать его, чтобы пользовательский интерфейс не нарушался.

Я имею в виду, что поддержка мета-бокса все еще не работает в версии 2.0, и я не совсем уверен, что она когда-либо будет работать на данном этапе.

Плагин уже существует: https://wordpress.org/plugins/classic-editor/

Чтобы ответить на исходный вопрос

1. В wp-config.php добавьте

define( 'ENABLE_GUTENBERG', false );

1. В файле с именем my-hacks.php в папке mu-plugins , в которой вам, возможно, придется создать код

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

реквизит @tomjn @wpmark

Вы можете сделать это сегодня без установки Gutenberg или классического редактора.
Но учтите, что имя фильтра может измениться при объединении кода с ядром.
... в этот момент кто-то будет писать документы, а затем вы можете добавить еще одну строку.

Примечания: файл с именем my-hacks.php был представлен в 2003 году и устарел в 200x.
Но ничто не мешает вам реализовать его как обязательный плагин в mu-plugins .

Если вы хотите увидеть, насколько сложно удалить устаревший код, включая связанное с ним поле параметров
см. WordPress TRAC # 33741 - Удалите ссылки на my-hacks.php и параметр hack_file

Еще проще ... в wp-config.php

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

Я считаю, что концепция блока неверна. На мой взгляд, блок должен быть постом. Итак, если нам нужно несколько материалов в сообщении, мы должны иметь возможность иметь дочерние сообщения. Как твиттер, где страницу создают множество независимых твитов.

Внутри поста нам нужен только текстовый редактор.

У нас нет бюджета на обновление всех наших страниц. Если wp не будет предлагать долгосрочную совместимость, многие из них мы просто изменим в будущем на более стабильное сообщество, поскольку двери будут открыты для новых компаний.

Теперь wordpress - это круто благодаря сообществу. 5.0 означает начать с 0. Итак, как и любой другой фреймворк.

Две линии развития могут быть хорошей идеей вместо того, чтобы отключать или нет. WP нормальный и WP Gutenberg. По крайней мере, на ближайшие 5 лет. Тогда у Гутенберга будет время, чтобы быть стабильным и иметь сообщество, как и WP.

Было бы неплохо, если бы у многих из вас, как разработчиков, возникла проблема, почему бы просто не войти и не продолжить
Github с билетом, который предлагает рабочий метод решения вашей проблемы, а не просто бесконечное написание того, почему вы не можете помочь создать решение с помощью текущего проекта Gutenberg.

Используйте свои навыки программирования, чтобы помочь решить проблему.

Я визуальный дизайнер и в настоящее время планирую помочь двум своим клиентам перенести процессы редактирования в Гутенберг, а в настоящее время я занимаюсь проектированием и созданием нового сайта для клиента с сайтом двадцатилетней давности, который они не могут поддерживать.

Присоединяйтесь и помогите продвинуть WordPress.org как инструмент для создания сайтов.

@TomDesign вы хоть пробовали читать обсуждение? Команда GB не хочет, чтобы функциональность была частью плагина, поэтому, если в разделе «Используйте свои навыки программирования, чтобы помочь решить проблему» вы имеете в виду, что кто-то должен взломать свои учетные записи, чтобы добавить код, который им не нужен, я не уверен, как писать код здесь даже отдаленно актуален.

@tomdesign Я поднял требование наличия жизнеспособного плана миграции в # 4981
Я указал, что это будет много работы. И я считаю, что это необходимо.

Я уверен, что немало разработчиков хотели бы использовать наши навыки программирования для обеспечения плавной миграции. Но мы не хотим тратить время на разработку чего-то, что будет сразу отвергнуто. На мой взгляд, миграция заслуживает отдельного проекта с логической оценкой каждого требования. Достаточно важно иметь хорошо задокументированное предложение, которое приведет нас к цели в долгосрочной перспективе.

Первоначальный запрос Саймона был краткосрочным решением долгосрочной проблемы.
Я считаю, что процесс миграции контента продлится годы.

Привет, ребята,
Читая комментарии, я думаю, что это подходящее место, чтобы поделиться хорошим плагином о Гутенберге.
Хочу представить вам бесплатный плагин, позволяющий управлять редактором Гутенберга.
Он называется Gutenberg Manager и позволяет вам включать / отключать редактор для различных типов сообщений (включая страницы и сообщения). В нем больше функций, но я оставляю их вам.

Мы прочитали множество сообщений, в которых люди жалуются на будущую реализацию Gutenberg в ядре WP 5.0, и это привело нас к поиску простого решения.

Gutenberg Manager решает эту проблему и позволяет, например, продолжать использовать Elementor, Visual Composer, Siteorigin Builder или Cornerstone без каких-либо проблем даже после WP 5.0.
Судя по первым отзывам пользователей на WP.org, плагин оценили :)

По этой причине я хотел бы познакомить вас с Gutenberg Manager -> https://wordpress.org/plugins/manager-for-gutenberg/

Плагин может использоваться разработчиками в своих собственных темах и плагинах благодаря некоторым полезным хукам. Существует способ СКРЫТЬ панель параметров плагина, чтобы конечный пользователь не увидел ее в бэкэнде WP (отличная функция для разработчиков, которые хотят включить Gutenberg Manager в свои проекты).

Мы также договариваемся с командами самых известных строителей о партнерстве и сотрудничестве. Таким образом, мы надеемся сделать переход к Гутенбергу менее травматичным!

Всем спасибо за внимание,
Молодец.

@unCommonsTeam, могу я спросить, как вы отключаете редактор Гутенберга в плагине, когда, например, эти параметры выбраны на экране настроек?

Конечно @wpmark ,

взгляните на строку 79 -> https://github.com/unCommonsTeam/gutenberg-manager/blob/master/inc/core.php

Лучший

@unCommonsTeam спасибо, что вернулись ко мне. Я, вероятно, ошибаюсь здесь, но, похоже, плагин просто удаляет все, что добавлено плагином Gutenberg. Это то, что я предложил выше, используя:

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

Однако @pento сообщил, что это не надежное решение, поскольку оно возвращает редактор в WordPress. См. Https://github.com/WordPress/gutenberg/issues/4409#issuecomment -357912790

@wpmark да, эта функция удаляет все вещи, добавленные плагином Gutenberg, но функция вызывается только на определенных внутренних страницах, а не на всех backend .. Например, если вы решили отключить редактор Gutenberg на страницах, но хотите использовать его в сообщениях .. Так что я считаю это приемлемым.

Лучший

@unCommonsTeam выглядит как отличный плагин, но я думаю, что он будет страдать от тех же проблем, что и мое решение, поскольку ему действительно нужно добавить редактор обратно в WordPress.

Из того, что говорил @pento, было то, что при удалении дополнений Гутенберга он только заявляет, что редактор блоков не нужен, но вы должны заменить его чем-то - это то, что делает классический плагин редактора.

Как заявил @pento :

Этот фильтр просто означает «не загружать редактор блоков», но не означает «использовать классический редактор». На данный момент это работает, но не гарантирует, что будет работать в будущем.

Поэтому я думаю (и я, конечно, должен быть исправлен), что ваш плагин делает то же самое (но, конечно, намного лучше и с множеством интересных вариантов для гибкости и т.д.), чем моя попытка выше.

Еще я подумал о том, что имя Гутенберг будет висеть вокруг, когда проект будет объединен с ядром, или, например, эти функции (например, gutenberg_init ) будут переименованы в (например) block_editor_init .

@wpmark ты прав. Надеемся, что в WP 5 классический редактор оставят там. Однако мы могли бы попробовать добавить возможность включения классического редактора через плагин. Если команда разработчиков WP решит удалить классический редактор, мы думаем, что наш плагин станет действительно популярным :)

Насчет наименования gutenberg вы правы, возможно, нам придется исправить наш плагин, заменив имена хуков.

Кроме того, наш плагин будет предлагать другие функции, основанные на редакторе Gutenberg (включение / отключение определенных блоков, новых блоков и т. Д.). Поэтому мы думаем, что это будет полезно и для людей, которые используют редактор Гутенберга.

Ура

Это может быть хорошей идеей, которая урегулирует почти все споры и споры:

Если Гутенберг по умолчанию отключен в ядре, а классический редактор все еще поддерживается, это может сэкономить ~ 1 миллиард долларов на рынке тем и плагинов WordPress и огромной части Интернета от множества проблем, денежных потерь, инцидентов поддержки, а также значительно сэкономит WP. потери престижа и доверия в качестве платформы.

Гутенберг, хотя и является более современным редактором, похоже, создан для нужд WordPress.com и аналогичных торговых точек, которые предоставляют услуги ведения блогов / хостинга с использованием WordPress. Это все хорошо. Однако это не должно приводить к шоку и удару по яйцам для остальной экосистемы. Текущее направление повлияет на обширную сеть Интернета, веб-сайты людей и их средства к существованию.

WordPress.com может иметь Gutenberg по умолчанию, тогда как WP поставляется с отключенным по умолчанию, что обеспечивает лучшее из миров для всей экосистемы.

Я должен согласиться с codebard, что gutenberg по умолчанию отключен, а классический редактор будет продолжать работать. В настоящее время у меня отключены автоматические обновления именно по этой причине - я не хочу, чтобы блоггерам в моей многосайтовой сети внезапно предоставлялся редактор типа «конструктор страниц», и я, конечно, не хочу, чтобы классический редактор был полностью заменен с Гутенбергом.

По крайней мере, мы должны иметь возможность отключить Gutenberg с помощью оператора определения, такого как define ('DISABLE_GUTENBERG', true); Одна большая проблема с наличием плагина для отключения Gutenberg заключается в том, что в этом случае мы будем зависеть от разработчика, который будет поддерживать и обновлять плагин, когда это необходимо. Что мы будем делать в те дни или недели, когда плагин перестанет работать, потому что разработчик находится в отпуске или по другой причине слишком занят, чтобы обновить плагин. Существует также проблема, что людям, использующим этот плагин, придется обновлять плагин на своей стороне.

Кажется, что навязать нам Гутенберга, а затем найти обходные пути, чтобы отключить его, как запоздалую мысль, - это действительно обратный способ сделать что-то. Пожалуйста, отключите Gutenberg по умолчанию. Многим из нас, кому нужен простой блог, становится все труднее и труднее использовать wordpress, поскольку он, похоже, превращается в конструктор веб-сайтов.

Еще одно замечание: в случае многосайтовых сетей администратор сети должен иметь возможность решить, следует ли сделать Gutenberg доступным по сети.

@WebTrooper, плагин Classic Editor поддерживается командой разработчиков WordPress (те же люди, которые поддерживают Core), а Gutenberg Ramp поддерживается Automattic, поэтому оба должны быть защищены от факторов «разработчик в отпуске» или «слишком занят».

Обратите внимание, что VIP поддерживает плагин Gutenberg Ramp, который используется на сайтах наших клиентов и на наших собственных сайтах. Находиться в отпуске или быть слишком занятым, если что-то сломалось, может означать сломанные сайты клиентов, а это последнее, чего хочет VIP.

Я также хотел бы отметить, что эти плагины могут быть разветвлены, Automattic, авторы и классический плагин редактора не обладают какими-либо секретными знаниями, которые позволили бы им создавать эти плагины, и при этом они не являются технически большими или сложными. По всему миру существуют сотни агентств, в которых есть разработчики, способные поддерживать любой плагин.

Кстати, многие люди выступают за отключение Gutenberg по умолчанию, но я заметил, что, несмотря на достоинства этих аргументов, все они не могут сказать, когда именно GB должен быть включен по умолчанию. Логический вывод - вечная классическая редакционная ситуация.

Это 2934 год, галактическая империя прыгнула в систему, 300 линейных крейсеров. Местная планетарная новостная сеть запустила классического редактора для написания репортажа для местных жителей. Никто не сказал им о Гутенберге, прежде чем они начали строить сайт.

Я всегда предлагал включить его по умолчанию для НОВЫХ установок.

Но для существующих установок я бы предложил подход, ориентированный на пользователя, позволяющий людям выбрать Gutenberg, попробовать его, сохранить, если он им нравится, и вернуться к классическому редактору, если они этого не делают. Затем WordPress может собирать статистику и отзывы, если / когда люди вернутся, чтобы помочь с разработкой и документацией для изменения.

Когда достигается некоторая критическая масса активных сайтов с включенным, вы можете включить его по умолчанию. И нет, я не собираюсь подбирать цифру с воздуха. Но мы могли измерить использование и действовать соответствующим образом.

В качестве альтернативы подойдет 12 апреля 2020 года. 😉

Это происходит со старыми версиями PHP, верно? WordPress был неутомим в обеспечении обратной совместимости с PHP 5.2, потому что люди все еще используют его, во многих случаях, вероятно, не зная и не заботясь. WordPress внимательно анализирует статистику; приложить много усилий для координации с хозяевами и так далее; и осторожно направляя людей по пути обновления. И, предположительно, в какой-то момент проект будет действовать на основе данных об использовании, чтобы принять решение.

Тем не менее, с совершенно новым пользовательским интерфейсом для редактирования, который пользователи знают и заботятся о подходе, заключается в том, чтобы навязать им его?

Хотя в некоторых случаях я фактически начинаю защищать Гутенберга, я действительно надеюсь, что предложение о слиянии принимает во внимание опасения таких людей, как я, которые управляют множеством сайтов для конечных пользователей, многие из которых имеют плохие ИТ-навыки. не уверен в технологиях и будет сбит с толку и дезориентирован Гутенбергом.

Я думаю, что Гутенберг также должен быть отключен для НОВЫХ установок по следующим важным причинам:

• Существует почти бесконечное количество руководств, ресурсов, практических рекомендаций и всего, что вы можете себе представить, и все они основаны на существующем редакторе. Это делает ОЧЕНЬ легким ввод людей в WordPress.

• Эта простота входа очень важна, поскольку, поскольку они так легко начинаются, люди понимают, что «WordPress - это просто», и с готовностью имеют теплое восприятие платформы, более терпимое и уверенное отношение к ее изучению.

• Все это объединяется в представление о том, что «WordPress просто работает», и они с комфортом рекомендуют его своим коллегам. Таким образом мы смогли охватить 30% Интернета.

• Согласованность информации важна. И нет никакого способа, чтобы каждый из ресурсов в Интернете был обновлен, чтобы отразить Gutenberg, даже в будущем. Это создаст много путаницы. И, к большому сожалению, реакция обычного пользователя будет: «Я установил его, но он НЕ РАБОТАЕТ» только потому, что он / она не может найти, как что-то делать, и вещи выглядят не так, как учебник, который он использует. Не заблуждайтесь, никакие усилия по обновлению не устранят эту путаницу в отношении ресурсов, руководств и так далее.

Следовательно, Gutenberg должен быть необязательным и иметь возможность переключения, чтобы поддерживать «обратную совместимость» не только с точки зрения тем, существующих плагинов контента, созданных конструктором страниц, и т. Д., Но и с точки зрения ресурсов, которые у нас есть в сети. Платформа не «так проста», и вы не можете рекомендовать ее людям, которые говорят, что «просто установите ее и погуглите ...», когда Google выводит много разных устаревших и современных ресурсов, смешанных. И если у вас есть опыт работы с SEO, вы знаете, что это будет ...

С помощью Gutenberg мы можем задействовать якобы растущий рынок «конструкторов сайтов» (wix, squarespace и т. Д.) И потенциальный рынок «легкого ведения блога» (а-ля medium и т. Д.). Но если мы при этом выйдем даже на долю 30% интернета или рынка тем / плагинов на сумму ~ 1 миллиард долларов, это будет огромным ударом по яйцам, от которого мы, возможно, не оправимся за десять лет.

Вы не можете установить классический плагин PHP, поэтому сравнение с PHP не актуально, это миллионы сайтов, которые гарантированно сломаются, без решения на основе WP, которое могло бы решить эту проблему, поэтому тщательный анализ. Также имейте в виду, что в следующем выпуске есть приглашение установить классический плагин, пользователям не просто предлагается установить плагин Gutenberg.

Так или иначе, этот вопрос был закрыт, решения приняты. Закрытый вопрос - плохое место, чтобы пытаться изменить подход, который планируется где-то еще.

Но имейте в виду, что Гутенберг может переключаться, есть плагины как для его включения, так и для отключения. С момента запуска GB прошли годы, у нас еще много времени для тестирования, время для обучения клиентов, время для установки плагина классического редактора и т. Д. Это не какая-то новомодная вещь, которую навязывают людям в одночасье.

Я заметил, что независимо от достоинств этих аргументов, все они не могут сказать, когда именно ГБ должен быть включен по умолчанию.

И, похоже, даже если бы люди, приводящие эти аргументы, высказали какое-то предположение о том, когда это должно произойти, это все равно было бы отклонено. Так зачем поднимать эту тему?

Я знаю, как работают закрытые билеты. Вы сделали здесь довольно саркастический ответ. Поэтому я попытался предложить что-то конструктивное в ответ.

@tomjn я буду эхо @rosswintle здесь, говоря , да , мы предположили , что должно быть только для новых установок по умолчанию - https://github.com/WordPress/gutenberg/issues/4423. Это еще один закрытый вопрос, закрытый без реального обсуждения предмета.

Не хотят слушать, есть плагин, бла-бла-бла, это закрыто. Двигайтесь здесь не на что смотреть. Все дело в зоне .com никого не волнует .org там нет денег на Automatic.

@ smp303, не могли бы вы определить, кто они ?

@rosswintle Никакого сарказма не предполагалось, Gutenberg 0.1.0 был выпущен 14 месяцев назад, и единственный способ избежать взлома сайтов, работающих на 5.2, - это поддержать их и попытаться заставить их обновить. Сайты, у которых экран редактирования сообщений не работает с Гутенбергом, могут установить плагин классического редактора, не требуя изменения уровня сервера, сравнение нечестно

Не хотят слушать, есть плагин, бла-бла-бла, это закрыто. Двигайтесь здесь не на что смотреть. Все дело в зоне .com никого не волнует .org там нет денег на Automatic.

Я должен согласиться. Будь то здесь или на форуме поддержки WordPress, кажется, им все равно, хотя многие люди в сообществе против этого. Поскольку WordPress является открытым исходным кодом, я хотел бы предложить любому создать петицию по этому поводу. Я лично считаю и предлагаю, чтобы GB был плагином наподобие Jetpack, а не объединял его в ядро.

Кстати, @karmatposed. Поскольку вы не можете ответить и ответить на мой вопрос в одном из комментариев на форуме WordPress относительно Гутенберга, мне интересно, почему мой комментарий внезапно исчез. Хороший ход!

Эта ветка перешла от обсуждения того, почему нет опции на основе кода для отключения Гутенберга, в подразумеваемые или прямые личные атаки со стороны учетных записей sockpuppet.

Я понимаю, что некоторые люди очень увлечены этой темой, и жаль, что эта ветка пошла по этому пути, но решение не изменится.

Плагин Classic Editor - это возможность вернуться к классическому редактору для всего сайта. Он широко рекламируется в предстоящем выпуске WordPress 4.9.8 как вариант для установки сейчас в рамках подготовки к WordPress 5.0.

Если вы являетесь создателем сайтов и хотите отключить своих клиентов от использования редактора блоков, установка плагина Classic Editor (и участие в отчетах об ошибках или исправлениях ) является лучшим долгосрочным решением, обеспечивающим доступность классического редактора.

Для метабоксов уже можно отказаться от редактора блоков , этот API будет объединен с Core. Для CPT фильтр gutenberg_can_edit_post_type будет переименован при объединении (возможно, в block_editor_can_edit_post_type или что-то в этом роде), но также будет доступен как вариант на основе кода.

Чтобы избежать дальнейшего развития этой темы, я собираюсь заблокировать ее.

Приглашаем всех, кто участвует в этом обсуждении, продолжить участие в подготовке Гутенберга к WordPress 5.0, но помните, что личные атаки абсолютно не приветствуются и приведут к блокировке проблем или блокировке учетных записей.