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

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

Приношу свои извинения, эта фраза была плохой. Метабоксы никуда не денутся. Вот почему боковая панель Metabox получает обновление в виде новой боковой панели «Настройки публикации».

Я хотел сказать, что новые метабоксы должны быть написаны на JS и появятся на боковой панели «Настройки публикации» вместе со стандартными. Метабоксы, написанные на PHP, в идеале должны быть обновлены до JS, но должны продолжать работать и в их форме PHP. Для этого предназначена панель «Расширенные настройки», и она находится внизу не потому, что мы не хотим, чтобы они были частью боковой панели, а потому, что очень сложно смешивать метабоксы PHP и JS на боковой панели.

Есть несколько серьезных проблем с отправкой управляемых PHP метабоксов через JS и Ajax, особенно в том, как обрабатывать обновление рендера метабокса для отражения недавно сохраненного состояния: https://core.trac.wordpress.org/ticket/7756

Мне интересно, может ли встраивание устаревшего метабокса через iframe быть здесь решением, где iframe src представляет собой что-то вроде /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings и выводит только этот один метабокс в документ.

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

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

• Yoast SEO: предоставляет большое количество полей, которые, вероятно, не поместятся на боковой панели - может быть, может быть метабокс боковой панели, который открывает модальное окно для большего количества параметров, но это похоже на работу с ненужным ограничением

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

• WooCommerce - добавляет метабоксы для данных заказа и позиции, при этом удаляя основной редактор (Ву планирую в конечном итоге создать свой собственный пользовательский интерфейс, но я подозреваю, что до этого еще далеко, и другие плагины будут в аналогичной ситуации)

(Я предполагаю, что Гуттенбург планирует в конечном итоге заменить текущие представления post-new / post-edit.php, а не просто быть альтернативой?)

Ха, спасибо @braders - Yoast UX-er

Наш метабокс сейчас действительно довольно большой и широкий, поскольку он выполняет множество функций. Мы были бы не против добавить эти функции в различные метабоксы на боковой панели, чтобы обеспечить более тесную интеграцию, но мне было интересно, возможно ли это? Например, можем ли мы добавить оценки SEO в поле «Опубликовать», как сейчас? А если нет, можем ли мы подключиться к расширенному блоку настроек, даже если наш метабокс написан на JS?

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

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

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

Было бы неплохо создать отдельный билет! Со скриншотами существующего типа поста, если он у вас есть! ✨

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

+1 к обращению к WordPress VIP. Это также проблема в потоке Calypso: https://github.com/Automattic/wp-calypso/issues/587

Действительно важная функция для лидера рынка!

Мне интересно, может ли встраивание устаревшего метабокса через iframe быть здесь решением, где iframe src представляет собой что-то вроде /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings и выводит только этот один метабокс в документ.

У меня тоже была такая же идея. Это также хорошая идея для создания песочницы и управления сеансами. Затем мы можем определить распространенные варианты использования этой функции и реализовать API для их обработки.

Я хотел стать разработчиком плагинов и тем, кто использует WordPress в основном как инструмент электронной коммерции. Также, потому что

Я устал от Гутенберга сегодня, и я буквально не могу воспринимать это как WordPress, не видя, как метабоксы и кнопки редактора (добавленные с помощью хука media_buttons) являются частью этого.

Я также не большой поклонник текущего состояния редактора WordPress и metabox-palooza. Я просто подсчитал, и в просмотре отдельной публикации загрузки (тип публикации продукта Easy Digital Download) у меня есть 14 настраиваемых мета-блоков, добавленных Yoast, Easy Digital Downloads и мой собственный код с использованием CMB2. Это много, но они мне нужны. WordPress бессмысленен без этого интерфейса и того, что он предоставляет.

Я обеспокоен тем, что это не рассматривалось с самого начала, поскольку я работал на очень многих сайтах, где интерфейс настраиваемых полей, добавленный с помощью ACF, Pods, CMB2 и т. Д., Был всем процессом редактирования.

Вот мои технические проблемы:
1) Кнопки добавлены через media_buttons. В моем плагине Caldera Forms (80K + активных установок) мы используем это действие, чтобы добавить кнопку вставки формы, которая вызывает модальное окно для вставки шорткода в редактор сообщений. Может быть, мы переедем в кастомный блок в Гутенберге.
2) Как действие save_post остается обратно совместимым? Так много плагинов, тем и пользовательских перехватчиков кода в save_action и обращается к $ _POST super global. Это плохой дизайн, но это технический долг, влияющий на миллионы сайтов.
3) Было предложено отрендерить устаревшие метабоксы в iFrame. Меня это беспокоит, поскольку доступ к содержимому iFrame через JavaScript невозможен.

@ Shelob9 привет!

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

Доступ к содержимому iframe через JavaScript _ возможен, если он находится в том же домене, что и в этом случае.

Как действие save_post остается обратно совместимым? Так много плагинов, тем и пользовательских перехватчиков кода в save_action и обращается к $ _POST super global. Это плохой дизайн, но это технический долг, влияющий на миллионы сайтов.

Мы можем сделать лишь так много, чтобы упростить перенос устаревших метабоксов на Гутенберг. Существует фундаментальная разница в том, как данные моделируются в Gutenberg по сравнению с текущим экраном редактирования сообщения. То есть данные фактически моделируются впервые. Благодаря моделированию данных мы, наконец, можем использовать интерфейсы JavaScript для управления состоянием сообщений и постмета способами, которые невозможны при использовании $_POST и действия save_post , не говоря уже о возможности _preview_ изменений в postmeta. Маршрутизация постмета-изменений через модель позволит предварительно просмотреть постмета-данные. Таким образом, даже несмотря на то, что Гутенберг может включать устаревшие метабоксы, когда это возможно, они всегда будут изначально ограничены в том, насколько они могут использовать преимущества нового интерфейса. Я думаю, что это такая же реальность, как и реальность того, что у нас технический долг.

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

@westonruter, спасибо, что делает назначение области расширенных настроек более понятным.

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

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

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

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

Интересно, может ли встраивание устаревшего метабокса через iframe быть здесь решением?

Доступ к окнам iframe - не самое интересное занятие для пользователей программ чтения с экрана. Есть другие варианты?

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

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

В ответ @westonruter спасибо за разъяснения по поводу обратной совместимости. Я думаю, что нужно ОЧЕНЬ ясно дать понять, что WordPress 5.0 или где-либо еще не поддерживает обратную совместимость, поскольку это ожидалось пользователем.

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

Например, в заказах WooCommerce нет редактора контента - он просто не нужен. Важны подробности о порядке, а не редактирование контента, и по праву они должны быть в центре внимания этой страницы.

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

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

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

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

ВОПРОС, как мы определяем CPT, чтобы не использовать Gutenberg (эквивалент отсутствия редактора), и показывать ТОЛЬКО метабоксы полной ширины, на которые полагаются наши предприятия.
Я полагаюсь на метабоксы. Чаще всего мои CPT выглядят так
'supports' => array( 'title' )
И расширяются оттуда. Пожалуйста, считайте тех из нас, кто создал бизнес-инструменты для клиентов, использующих CPT с метабоксами, как ограниченный и управляемый ввод данных в форме, а не для написания статей.
Моя работа - это в основном специальные расширения для CMB2, которые взаимодействуют с клиентскими системами. Объявления EG о недвижимости с обращением к сторонним системам.

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

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

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

Тем не менее, мне интересно, нужно ли еще сделать, чтобы Guttenburg отказывался от участия / отказа. Несколько идей:

• Я предполагаю, что большинство современных CPT интенсивно используют метабоксы вместо основного редактора. Так что, возможно, авторам плагинов следует выбрать Gutturnberg с 'supports' => array( 'gutenburg' ) или аналогичным

• Для сообщений и страниц Guttenburg может быть необязательным в качестве настройки сайта. Можно даже спросить пользователей, хотят ли они использовать Guttenburg после обновления 5.0, и сохранить этот выбор в БД.

• Или, в качестве альтернативы, темы могут объявлять поддержку через post_type_supports (), но это может серьезно повредить восприятию - или темы могут быть отключены, что не поможет пользователям устаревших, неподдерживаемых тем, которые больше не обновляются. (Может быть, для пользователей устаревших тем будет достаточно плагина remove-guttenburn?)

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

Мне нравится теоретическая идея о том, что CPT явно запрашивают 'supports' => array( 'gutenberg' ) для поддержания существующей функциональности в случае, если флаг поддержки gutenberg не определен. Это сэкономило бы мне много работы по исправлению старых сайтов для рассерженных клиентов, которые обновились до WP5.

Я отмечаю, что существующие функции 'supports' => (название, редактор, автор, ...) имеют очень информативные имена, здесь Gutenberg выделяется как имя проекта. Интересно, будет ли рассматриваться более описательное имя функции для этого использования; возможно «блок-редактор»? 'supports' => array( 'block-editor' )

Конечно, должна быть стратегия, позволяющая отлавливать такие ошибки, как 'supports' => array( 'title','editor',thumbnail', 'block-editor' ) . Я бы предположил, что флаг «редактор блоков» просто заменит старый режим «редактора».

Другой разработчик плагинов здесь с проблемами.

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

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

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

Редактор выглядит отлично, но не забывайте об остальной части страницы.

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

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

А как насчет того, чтобы этот редактор работал как полноэкранный редактор без отвлекающих факторов? Таким образом, мы могли бы получить лучшее из обоих миров без ущерба для функциональности и «устаревшего» кода. (Кстати, мне кажется смешным, что способ, которым мы в настоящее время создаем мета-боксы, теперь упоминается в этом проекте как "наследие ...").

Спасибо за ваше время, ребята, это очень ценно.

А как насчет того, чтобы этот редактор работал как полноэкранный редактор без отвлекающих факторов?

+1

Я собираюсь повторить мою основную озабоченность: CPT часто не требуют «редактора», потому что пост создается из больших и динамически сгруппированных метабоксов в управляемом рабочем процессе пользователя (например, данные о продукте WooCommerce).

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

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

Сюда уже добавлено много хороших мыслей, поэтому я просто подброшу эти простые мысли:

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

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

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

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

Я хотел бы добавить к обсуждению еще два важных крючка: edit_form_after_title и edit_form_after_editor которые в настоящее время обеспечивают полный контроль над пользовательским интерфейсом после редактирования. Очевидно, что Gutenberg - это не просто замена wp_editor, это совершенно другой подход к пользовательскому интерфейсу (и, как он выглядит в настоящее время, к его будущей модульной расширяемости).

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

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

С точки зрения разработчиков / бизнеса / планирования было бы полезно понять (будущее) намерение «Гутенберга», или может кто-нибудь указать мне на такое заявление о миссии или что-то подобное?

Еще несколько мнений от меня ...

Я отмечаю, что существующие функции 'supports' => (название, редактор, автор, ...) имеют очень информативные имена, Gutenberg здесь выделяется как название проекта. Интересно, будет ли рассматриваться более описательное имя функции для этого использования; возможно «блок-редактор»? 'поддерживает' => массив ('редактор блоков')

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

Конечно, должна быть стратегия для выявления ошибок, таких как «поддерживает» => массив («заголовок», «редактор», миниатюра »,« редактор блоков »). Я бы предположил, что флаг «редактор блоков» просто заменит старый режим «редактора».

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

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

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

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

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

Если новый экран, основанный на реакции, так же подключаем, как и старые экраны редактирования, тогда нет причин, по которым эти настраиваемые рабочие процессы нельзя добавить в верхнюю часть страницы / боковую панель / под редактором или где-либо еще на странице. (Отказ от ответственности: у меня нет глубокого понимания React, поэтому еще неизвестно, насколько более сложные хуки будут вне PHP). Также # 1352

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

Когда вы определяете настраиваемый тип сообщения, он, скорее всего, будет включать в себя блоки, которые требуются, а какие блоки просто разрешены. Для пользовательского типа сообщения, не имеющего поддержки editor прежнему будет иметь «редактор», отображаемый в Gutenberg, но он может по существу отключить _inserter_. Блоки, которые появляются в редакторе, будут заблокированы на месте в соответствии с требованиями типа публикации. Если бы блоки не были заполнены, они бы отобразились как _placeholder_. Обратите внимание, что эти блоки могут затем сохранять свои свойства в postmeta, как это делают в настоящее время метабоксы, но они будут делать это нормализованным способом, а не специальным образом через действие save_post и $_POST global.

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

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

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

Спасибо @westonruter за разъяснения, но это вызывает у меня несколько новых вопросов.

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

Есть ли что-то, что мешает автору добавить в сообщение больше допустимого количества блоков? (Добавление нескольких полей post_meta, когда только одно имеет смысл)

Я был бы склонен согласиться с @westonruter относительно изучения блоков как шлюза к метаданным. Тем не менее, я бы предложил отделить идею блока от post_content. Блок в настраиваемом типе сообщения не обязательно должен быть частью того, что исходит от post_content во внешнем интерфейсе. Вот пример использования плагина Календарь событий (моя интерпретация) от современного племени.

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

WooCommerce - еще один пример, в котором один или несколько блоков информации о продукте должны иметь приоритет над описательным текстом в типе сообщения о продукте, но они не должны быть дополнительными блоками, которые пользователь должен вставить сам.

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

... нам следует отказаться от мысли о добавлении метабоксов и вместо этого подумать о добавлении блоков.

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

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

@westonruter Не могли бы вы пояснить, что вы говорите, что если бы мой пользовательский тип сообщения требовал определенных дополнительных полей, я бы ввел эти данные в блок?

Если да, у меня есть несколько дополнительных вопросов:

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

2) Как данные будут сохранены из этого блока? Насколько я понимаю, сейчас данные из блоков хранятся в виде HTML-комментариев в post_content. Как мы получим данные из этих блоков для публикации мета? Например, для моего гипотетического плагина событий, как мне получить дату начала и окончания в метаданных сообщения, чтобы я мог запрашивать их?

3) Каково обоснование того, что все идет в направлении основного редактора контента и применяется к пользовательским типам сообщений? Есть ли какое-либо пользовательское тестирование, подтверждающее это направление дизайна, особенно в отношении пользовательских типов сообщений, которые не представляют собой сообщение / статью в блоге?

@kevinwhoffman Я до сих пор не вижу фундаментального конфликта для блоков. Абстрактные настройки по-прежнему можно рассматривать как контент, но другого типа: это все данные. Каждый блок не обязательно должен иметь визуальное представление в «содержании». Я думаю, что тоже могут быть «метаблоки», хранящие данные в postmeta вместо post_content . Редактируемые блоки могут иметь заголовки / метки, похожие на то, как сегодня представлены метабоксы.

@ Shelob9 да, если для вашего произвольного типа поста требуются дополнительные поля, я думаю, они будут представлены в блоке. Если у вас есть настраиваемый тип сообщения «продукт», то может быть отдельный блок product-details котором есть поля для цены, вариантов и т. Д.

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

Да, точно. Пользовательские типы сообщений, форматы сообщений и шаблоны страниц могут просто включать концепцию требуемых блоков, которые «заблокированы», не могут быть удалены или переупорядочены. Одним из примеров этого может быть блок для выдержки из сообщения: https://github.com/WordPress/gutenberg/issues/1288#issuecomment -310544967

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

Большинство блоков сегодня хранят свои данные в HTML внутри post_content но это не обязательно. Например, в https://github.com/WordPress/gutenberg/issues/1288 вы можете увидеть обсуждение блока Excerpt, хранящего свое содержимое в post_excerpt и блока Featured Image, хранящего его содержимое в postmeta. Таким образом, у вас определенно должна быть возможность иметь блок event-details , у которого есть дата начала и дата окончания, которые сохраняются в postmeta.

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

Как указано выше, данные могут быть получены и сохранены в post_content , postmeta, terms или в любом другом месте. Идея «сначала блок» состоит в том, чтобы иметь общее здание _block_, которое все использует, и при этом компоненты блока могут быть максимально повторно использованы в WordPress. Это мое понимание.

@westonruter - Спасибо за разъяснения. Это очень полезно, так как не так много информации о том, как этот редактор относится к типам сообщений, которые не являются сообщениями / статьями в блогах и т. Д.

Надеюсь, скоро мы увидим документацию о том, как написать «метаблок».

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

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

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

Я работал над обширным плагином, который добавляет мета-блоки, такие как WooCommerce и EDD. В большинстве случаев я удалял редактор контента с экрана, так как он не нужен. Я немного обеспокоен тем, что это не должно быть чем-то, что мы должны объединить с Гутенбергом.
Иначе куда бы все это денется.

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

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

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

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

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

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

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

Вернемся сюда на минутку. Две вещи. Один из них - это поддержка старых метабоксов, написанных на PHP, для которых в этом посте есть макет панели «расширенных настроек».

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

Именно здесь мы предлагаем _blocks_ как новый интерфейс, который может объединить множество разрозненных. Мы уже предполагаем, что блоки могут быть лучше шорткодов, пользовательского HTML, виджетов и возможности встраивания. В зависимости от того, что делает метабокс, нет причин, по которым он не мог бы также включить этот интерфейс.

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

Итак, у нас есть два _легасовых_ функциональных случая:
MetaBoxes, которые обрабатывали метаданные (например, Yoast), и у нас есть MetaBoxes, которые использовались для предоставления структурированного интерфейса для ввода контента (например, WooCommerce).

Развитие для будущего
Если мы начали с чистого листа («списание нашего долга перед прошлым»), то это правда, что размещение метаданных в предложенном «расширенном» ящике вполне может сработать. Кроме того, структурированная запись контента может вписаться в заблокированный интерфейс порядка блоков внутри Gutenberg. Оба они полностью гипотетичны, но потенциально они будут работать как реализации для будущих разработок WP CMS.

Проблемы с устаревшей CMS для бизнеса
99% моей работы заключается в предоставлении индивидуальных бизнес-решений непосредственно компаниям-клиентам. Так что меня беспокоят не великие вещи, которые я мог бы построить в будущем, а холодные неопровержимые факты о функциональности моего клиентского сайта и деловых отношениях. Какие есть предложения по переносу существующих предприятий, основанных на решениях CMS, в Гутенберг? В моей ситуации у каждого клиента есть свое индивидуальное решение CMS, построенное на установленной платформе WP. Для меня фраза «списание долга прошлому» = «Выкинуть ребенка с водой из ванны».

Проблемы
Если Gutenberg будет поставляться в качестве ядра в WP5.0, я ожидаю, что у моих клиентов будут нефункциональные сайты. Затем нужно будет переделать каждый сайт и успокоить каждого клиента. Около 40 клиентов могут захотеть, чтобы я починил их CMS за эту неделю.

• Устаревшие сайты, зависящие от метабокса CMS, и их база пользователей кажутся несущественными для основной команды
• «продвинутое» предложение розыгрыша № 952 было лишено приоритета, что указывает на отсутствие интереса ко всей области.
• нет предлагаемого метода решения "задолженности прошлому" / CMS

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

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

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

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

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

Раздел @steveangstrom « Обеспокоенность» - это отличное обобщение вопросов, на которые еще нет ответа.

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

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

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

Еще одна функция ACF, которая не подходит для процесса редактирования публикации, - это страницы параметров. Я действительно не понимаю, как это будет работать на странице параметров.

Для тех, кто хочет обратной совместимости - кто-то, вероятно, создаст плагин для восстановления текущего опыта редактирования, если нет времени / ресурсов для обновления до Gutenberg (это то, что я планирую использовать). Кроме того, 5.0 будет серьезной проблемой для основной версии, что означает, что semver ).

WordPress не следует за semver.

@westonruter Думаю, в этом есть смысл:

Поля, которые вы раньше помещали в метабоксы, теперь вы будете перемещать вперед, а не помещать в блоки.

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

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

Это хорошие вопросы. Мы будем искать ответы по мере реализации этих функций.

Если бы мне пришлось угадывать, где мы здесь окажемся: текущие метабоксы будут перемещены в «унаследованную» область, и мы предоставим API, документацию и примеры для регистрации метабоксов «нового стиля».

@nylen как насчет рендеринга текущих метабоксов?

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

Сегодня существует бесчисленное количество сайтов, которые в основном построены с использованием мета-блоков с помощью плагинов, таких как Advanced Custom Fields. Здесь мы говорим о полноэкранных интерфейсах, а не об одном или двух прямоугольниках внизу сообщения. Я уверен, что ACF обновится для работы с Гутенбергом, но эти сайты не будут перестраиваться.

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

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

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

А как насчет того, чтобы этот редактор работал как полноэкранный редактор без отвлекающих факторов?

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

Также было бы лучше, если бы мы зарегистрировали поддержку редактора Гутенберга с параметром supports when register_post_type .

Наконец, как разработчик метабоксов, я хотел бы увидеть новый API, чтобы мета-боксы работали в новом редакторе. Как вы видите здесь, многие разработчики используют мета-блоки как способ предоставить дополнительный контент для сообщений. Этот контент можно разделить на категории и искать позже. Это не просто блоки контента, такие как контент для публикации. Итак, если есть новая замена функции add_meta_box() , я буду рад провести рефакторинг моего плагина Meta Box для работы с этим.

Согласен со всем, что было сказано относительно того, что стандартные метабоксы все еще работают / имеют место. Как ведущий разработчик CMB2, я могу гарантировать, что, если CMB2 каким-то образом сломается, когда выйдет WordPress 5.0, я могу гарантировать, что будет довольно много протестов. Я, конечно, не имею в виду угрозу, а просто реальность.

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

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

I can guarantee there will be a pretty significant outcry if CMB2 is somehow broken when WordPress 5.0 is released

И даже если он обновится, старые установки будут сломаны.

Также обратите внимание, что группы полей в ACF не обязательно должны быть в метабоксах, но есть также стиль «Бесшовные (без метабокса)» с параметрами «Сторона», «Нормальный - после содержимого» и «Высокий - между заголовком и редактором. (!!!) '. Последнее важно для создания осмысленного потока редактирования.

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

@ wsydney76 Также обратите внимание, что группы полей в ACF не обязательно должны быть в метабоксах, но есть также стиль «Бесшовные (без метабокса)» с параметрами «Сторона», «Нормальный - после содержимого» и «высокий - между заголовками». и редактор (!!!) '. Последнее важно для создания осмысленного потока редактирования.

Стоит отметить, что это не то, что «просто работает» в WordPress, но требует настраиваемого кода плагина для удаления обычного пользовательского интерфейса метабокса - поэтому разумно предположить, что это потребует дополнительной работы от ACF для работы с Gutenburg.

Упрости. Когда пользовательский тип сообщения не поддерживает объявленный редактор (Gutenberg), используйте свое воображение, навыки CSS и своих самых талантливых основных дизайнеров, чтобы преобразовать весь редактор во что-то еще. Сделать так, чтобы он не выглядел так, как клиент / пользователь видит на (собственном) экране редактирования сообщения. Это просто внешний вид. Клиентов не волнует, работает Гутенберг в фоновом режиме или нет, им все равно, даже если им об этом говорят веб-разработчики. Это люди визуального типа.

Что касается обратной совместимости, я предложил версию WordPress с долгосрочной поддержкой еще в феврале, задолго до объявления Gutenberg о выходе версии 5.0.

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

Сообщение можно найти здесь:
https://khromov.se/wordpress-needs-another-long-term-support-version/

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

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

Этот тип использования далеко не редкость, и сам WordPress поощрял творческое использование типов сообщений, позволяя разработчикам объявлять типы сообщений как закрытые. Такие флаги, как 'public', 'publicly_queryable' и 'show_ui', предназначены для того, чтобы разработчики могли использовать типы сообщений для целей, отличных от простого зеркального отношения 1: 1 с общедоступной страницей на веб-сайте.

Как Гутенберг вписывается в это видение?

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

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

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

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

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

Мы планируем использовать Pods 2.7 для создания приложения на основе React с использованием WordPress REST API и GatsbyJS .
Будет ли Гутенберг совместим со стручками?

Я вижу, что эта жизненно важная проблема была снята с любого этапа. Он снова был упразднен по приоритетам, а функции редактирования блога требуют много работы и добавляются в бета-версии. Это очень беспокоит будущее Wordpress как CMS.

Я сделал свои собственные генераторы кода, вдохновленные GenerateWP. Для моего личного и частного использования на localhost, а не публично.
В любом случае, мне интересно, как это будет выглядеть в Гутенберге, когда переключение будет выполнено. Поля ACF, много настраиваемого кода PHP для предварительного просмотра.

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

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

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

Вот отправная точка для просмотра списка плагинов:

Plugin                                      Active installs
======                                      ===============
advanced-custom-fields                           1,000,000+
custom-post-type-ui                                400,000+
meta-box                                           200,000+
types                                              200,000+
cmb2                                               100,000+
pods                                                50,000+
custom-field-suite                                  40,000+
wck-custom-fields-and-custom-post-types-creator     20,000+
piklist                                             10,000+
carbon-fields                                        2,000+

Плагины, которые не отображаются выше, скорее всего, потому, что они не находятся в каталоге плагинов WP.org:

• Полевой менеджер

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

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

Advanced Custom Fields добавляет свои метабоксы, регистрируя перехватчик для admin_enqueue_scripts . Этот хук проверяет, что текущая загрузка страницы равна post.php или post-new.php , и если да, добавляет действие admin_head которое вызывает add_meta_box . Ядро WP выполняет свои вызовы do_meta_boxes вскоре после этого действия, в edit-form-advanced.php .

Наконец, если вы разработчик, знакомый с тем, как WordPress в настоящее время обрабатывает и сохраняет метабоксы, ваш вклад здесь и / или на # 2251 приветствуется .

Привет, ребята,
Эллиот здесь - разработчик ACF.

ACF использует действие admin_enqueue_scripts для выполнения «логики сопоставления групп полей», а затем действие admin_head для добавления метабоксов (через add_meta_box() ). Он не использует действие add_meta_boxes .

Могу я задать здесь очевидный вопрос? Почему мы обсуждаем «трудности» метабоксов? Они являются неотъемлемой частью каждого веб-сайта WP. Конечно, логика метабокса может остаться такой, какая она есть, и жить рядом с новой областью редактора Гутенберга.

Не забудьте также отметить тег в

благодаря
E

Привет, ребята-

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

Почему мы говорим только о добавлении полей в мета-блоки? Текущая система позволяет нам добавлять что угодно. Данные, javascript для обращения к сторонним API для использования их инструментов, быстрое отображение заметок или справочной информации и даже фотографии милых котят, которые дают людям пять (хорошо, может быть, не этот, но кто знает ?!).

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

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

Благодаря,

Кевин - ведущий разработчик Piklist

На этот вопрос упоминалось во многих комментариях выше, но, насколько мне известно, ответа на него нет:

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

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

• Если поддержка editor зарегистрирована, то Гутенберг присутствует на экране редактирования с существующими мета-блоками, продолжающими функционировать, как и сегодня, в текущем редакторе.
• Если поддержка editor не зарегистрирована, тогда Гутенберг не загружается и пустой холст доступен для мета-боксов, как и сегодня.

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

Могу я задать здесь очевидный вопрос? Почему мы обсуждаем «трудности» метабоксов?

@elliotcondon - если проблему разработчика сложно решить, единственный способ найти решение - это преодолеть трудности. Я начал делать это в # 2251, но, как там объяснялось, это не будет быстрой задачей или легким решением.

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

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

Почему мы говорим только о добавлении полей в мета-блоки?

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

Для достижения этой цели,

• Какие действия отвечают за вызов add_meta_box для регистрации метабоксов
• Любые условия, которые определяют, зарегистрированы они или нет (например, текущий экран: post.php или post-new.php )

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

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

Да, нам нужно разработать набор API для создания метабоксов «нового стиля». Вот что у нас есть сегодня для блоков - я ожидаю, что это будет очень похоже, с метабоксами, зарегистрированными как «блоки», которые можно сохранять где-нибудь, кроме post_content : http://gutenberg-devdoc.surge.sh/

Обсуждение метабоксов нового стиля должно происходить на # 1684 или отдельном выпуске, чтобы предложить технический API.

Если поддержка editor не зарегистрирована, то Гутенберг не загружается и пустой холст доступен для мета-боксов, как и сегодня.

@kevinwhoffman - Гутенберг в том виде, в post_content . Поэтому понятно, что если поддержка editor не включена, то, по крайней мере, на данный момент, мы отключим ее. Это также довольно простая задача с точки зрения кода. Можете ли вы создать для этого новую задачу, и я помечу ее меткой Good First Task ?

Гутенберг в том виде, в каком он написан сегодня, предназначен для редактора post_content .

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

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

Вы обрисовали в общих чертах огромную проблему написания такого API в # 2251. Перевод метабоксов PHP в React для популярного решения с настраиваемыми полями, такого как ACF, является достаточно сложной задачей, не говоря уже о попытках сделать это для каждой реализации метабокса, существующей сегодня, популярной или нет. Не масштабируется.

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

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

Почему мы обсуждаем «трудности» метабоксов

Я счастлив прочитать это:

Если поддержка редактора не зарегистрирована, то Gutenberg не загружается, и пустой холст доступен для мета-боксов, как и сегодня.

Если вышесказанное верно, вся логика wp-admin (действия, функции и т. Д.) Должна оставаться такой же (иш) для экрана редактирования поста. Следовательно, не должно быть причин, по которым метабокс HTML не может быть отрисован, как это было в течение многих лет.

@nylen
ACF помещает в очередь несколько файлов JS и CSS для стилизации и взаимодействия с элементом HTML метабокса ACF.
ACF использует действия admin_enqueue_scripts для добавления этих ресурсов.
Многие другие плагины и темы ставят стили / скрипты в очередь - почему это может быть проблемой?
ACF не использует JS для сохранения метаданных. Он использует действие save_post для сохранения любых $_POST данных - довольно нормальный материал.

Более того, необходимость в API для преобразования мета-блоков PHP в мета-блоки React является искусственной проблемой.

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

Если поддержка редактора не зарегистрирована, то Gutenberg не загружается, и пустой холст доступен для мета-боксов, как и сегодня.

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

@kevinwhoffman @elliotcondon @nylen Или еще лучше, как насчет:

• Если зарегистрирована поддержка block-editor , то используйте Gutenberg.
• Если зарегистрирована поддержка editor , используйте TinyMCE.
• Если ни одна поддержка не прописана, значит ни Gutenberg, ни TinyMCE не загружаются.

Я не сторонник того, чтобы разделять опыт WP Admin на основе присутствия или отсутствия Гутенберга.

Если Gutenberg = New React Meta Boxes и No Gutenberg = Old PHP Meta Boxes, то сломанный админ - это то направление, в котором мы движемся.

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

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

@kevinwhoffman

Я не сторонник того, чтобы разделять опыт WP Admin на основе присутствия или отсутствия Гутенберга.

Это было в ответ на мое предложение относительно block-editor или чего-то еще?

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

@mikeschinkel Возможность включать или отключать Гутенберг необходима, но идея определения Гутенбергом поведения

@kevinwhoffman Я с вами согласен, кстати.

В модулях Pods мы делаем обычные, задокументированные, стандартные действия, используя те же действия, что и ACF и CMB2. Мы все делаем это так, как рекомендуется делать прямо сейчас.

+1 к способности продолжать использовать мета-блоки вместе с Гутенбергом, в конечном итоге люди смогут использовать Гутенберг для вещей, которые принадлежат непосредственно к контенту, а для всего остального по-прежнему есть мета-блоки, которые им нравятся для атрибутов и дополнительной информации о "сообщении" "(любого типа).

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

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

Намерен ли WordPress официально отказаться от Metabox API?

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

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

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

Экран Post Edit - это _ наиболее настраиваемый экран для каждого проекта, выходящего за рамки простого блога.

Эти настройки не ограничиваются регистрацией метабоксов. Любой крючок, который предлагают экраны редактирования администратора, используется в том же проекте. А в тех случаях, когда крючок отсутствует, разработчики используют jQuery для вставки элементов пользовательского интерфейса на страницу.

Так что для этих настроек должен быть путь вперед.

Для метабоксов предпочтительным инструментом является Fieldmanager, поскольку он одобрен VIP. Fieldmanager мощный, но ориентированный на ограниченный набор полей. Базы устаревшего кода часто не могут быть модифицированы для использования Fieldmanager или другой служебной библиотеки.

Таким образом, многие метабоксы все еще создаются с использованием специального кода. Пользовательский код означает комбинацию PHP и JavaScript, часто с взаимодействиями на основе Ajax.

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

Любое отклонение от параметров настройки на экране редактирования публикации, доступного прямо сейчас, будет недопустимо.

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

Я не понимаю, почему Metaboxes вообще что-то делают с Гутенбергом? Это всего лишь одна внутренняя страница, экран. Может быть организовано сотнями способов.
Вы сказали, что нынешняя реализация нарушает работу React.

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

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

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

@ fklein-lu Я категорически не согласен, что Fieldmanager должен быть «инструментом выбора». Я даже не вижу его в списке плагинов топ-10 полей.
https://github.com/WordPress/gutenberg/issues/952#issuecomment -320523428

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

Как добавить метабоксы на бэкэнд-экран Dashboard?
Это не имеет ничего общего с Гутенбергом.

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

@ fklein-lu Не уверен, почему вы думаете, что я неправильно цитирую вас, вот полный контекст: «Для метабоксов Fieldmanager - лучший инструмент, поскольку он одобрен VIP-персоной». Я не знаю никого, кто использует Fieldmanager, поэтому мне трудно понять эту цитату.

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

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

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

Полная обратная совместимость с текущей реализацией метабокса ОБЯЗАТЕЛЬНА. Нарушение этого подорвет доверие клиентов и пользователей на долгие годы. Моим любимым решением было бы что-то вроде «поддержки темы» и удобства использования без отвлекающих факторов.

TL; DR: не ожидайте, что корпоративные клиенты обновят свой код в течение следующих 12 месяцев для других целей, кроме обслуживания. Добавьте политику / предупреждение об устаревании с соответствующей временной шкалой. Ожидайте огромного падения доверия к WordPress, когда вы форсируете изменения (даже в лучшую сторону) с точки зрения бэкэнда и удобства использования кода.

Это стало как-то политикой или голосованием / выборами, а не кодированием. Некоторые люди решили, что старые Метабоксы «старые», «отсталые», «ограничивающие», и для них больше нет места. Без каких-либо реальных аргументов и причин против них. Я их не видел, за исключением того, что React и другие скрипты турбо-современные.

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

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

Просто чтобы заявить, насколько я объективен в этом вопросе, не пытайтесь:

• Я все еще думаю, что TinyMce и старый экран сообщений (с Metaboxes) - это что-то самое красивое, что я видел в мире CMS. Функции, фильтры, расширения и красивый дизайн. Да чистая красота и удовольствие.
• Несмотря на это, я принял Гутенберга с первого дня. Да бросьте все это "старое", переключитесь и никогда не оглядывайтесь назад.

Они знали то, чего я не знаю. У них есть собственный код. Но я больше не уверен.

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

Многие другие разработчики и компании взимают плату за обновления. Так что тогда эта дилемма будет не такой уж легкой.

@khromov Я работаю в компании Alley, которая обслуживает Fieldmanager. Мы активно отслеживаем поток, пока определяется направление продукта. Было бы справедливо сказать, что база пользователей WordPress.org обычно не использует Fieldmanager, но плагин широко используется в качестве библиотеки и пользовательской / корпоративной инфраструктуры.

Я также хочу +1 @Rarst и @kevinwhoffman. Полная поддержка существующих метабоксов может позволить нам в будущем заменить «устаревшие» метабоксы на эквиваленты Гутенберга, которые подлежат уточнению. Но нынешнюю неопределенность, связанную с обратной совместимостью, необходимо уменьшить как можно скорее.

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

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

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

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

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

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

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

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

И у меня есть один веб-сайт, который использует Jetpack и имеет только 2 уникальных посетителя в день.
Перестань меня так легко обидеть. Это WordPress, а не обсуждение новой версии Joomla. :)

@ fklein-lu Абсолютно с тобой согласен. Но если что-то и должно было стать «инструментом выбора» для полей метабокса, я бы подумал, что это будет предлагаемый Fields API .

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

Спасибо всем за то, что присоединились к нам и выразили озабоченность и идеи. Это становится длинным потоком, но я постараюсь прояснить несколько моментов.

Намерен ли WordPress официально отказаться от Metabox API?

Нет.

Вопрос, на который еще нет полного ответа, - это _ как работают мета-блоки в контексте редактора Gutenberg_. Должны ли они оставаться такими же или развиваться? Как мы можем двигаться к целям дизайна с наименьшими возможными нарушениями?

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

Тем не менее, есть несколько способов обработки метабоксов и расширяемости:

• Если мы обнаружим, что мета-блок зарегистрирован, мы можем вернуться к старому интерфейсу, ничего не изменится.
• Мы могли разделить редактирование контента и изменение метаинформации на два экрана или этапа.
• Мы можем попытаться увидеть, насколько возможно отобразить их такими, какие они есть (PHP) под содержимым: # 2251.
• Тема / плагин / CPT может отменить регистрацию нового интерфейса по мере необходимости.
• Различные элементы, которые полагались на мета-блоки, можно было преобразовать в блоки для пользовательского интерфейса (при этом данные сохраняются отдельно).
• Мы могли бы реализовать расширяемость метабоксов на основе API, например Fields API.

Или любое их сочетание.

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

Нет.

Спасибо , я думаю, многие просто выдохнули.

Вопрос, на который еще нет полного ответа, заключается в том, как работают мета-блоки в контексте редактора Gutenberg.

Почему _are_ мета-блоки в контексте редактора Гутенберга?

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

Но я все же думаю, что это был очень важный вопрос - если область видимости Gutenberg должна быть компонентом редактора, то замена области _screen_ кажется чрезмерно амбициозной. _Если_ область применения Gutenberg - (по крайней мере, частичная) замена _admin_ WordPress в целом, она _ невероятно_ более широкая и требовательная. Не то, чтобы заменить «просто» редактор так просто.

Тем не менее, есть несколько способов обработки метабоксов и расширяемости.

Гутенберг должен заменить основной компонент _editor_, а существующий пользовательский интерфейс администратора продолжает работать? Рассматривается ли _это_, если не почему?

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

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

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

Теперь, в контексте Гутенберга, если я буду поддерживать этого нового редактора, все, что мне лично нужно будет сделать, это добавить новое местоположение под названием Гутенберг, и это местоположение будет иметь:

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

• Собственное представление / шаблон: мне нужно будет создать компонент реакции для каждого типа поля. Это не имеет большого значения, слой представления довольно просто создать, когда все остальные части настроены правильно. Затем эти компоненты будут вложены в компонент реакции метабокса. Все это очень похоже на то, что я уже делал для метабоксов html на основе php, то есть поля html> field group html> location (страница настроек html, метабокс и т. Д.)

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

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

Если я не упускаю ничего серьезного (признаю, что у меня еще не было времени проверить Гутенберга), это более или менее суть того, что, как я думаю, мне нужно сделать, чтобы изначально поддерживать это новое «местоположение». У меня также есть встроенные проверки для каждого местоположения и его фильтров, чтобы убедиться, что то, что задает разработчик, возможно, например, если я попытаюсь добавить группу полей в тип сообщения "проекты", где формат, если тип сообщения - "видео ", но этот CPT не поддерживает форматы сообщений, библиотека выдаст исключение. Я надеюсь, что смогу предоставить такую ​​же обратную связь с этим новым местоположением, например, если я добавлю группу полей в местоположение Гутенберга, где тип сообщения - "обзоры", я надеюсь, что смогу узнать, является ли этот тип сообщения был зарегистрирован для поддержки Гутенберга.

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

Благодарю.

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

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

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

Мы еще не закончили, и это непросто, но мы работаем над этим каждый день.

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

Новый редактор Гутенберга и будущее ButterBean

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

Репо: https://github.com/justintadlock/butterbean/tree/dev

В целях тестирования в этот плагин включен фреймворк: https://github.com/justintadlock/custom-content-portfolio

ButterBean - это встроенный фреймворк, построенный на Backbone.js и Underscore.js. Он в значительной степени смоделирован на основе настройщика в ядре WP.

Это молодой фреймворк, но в этом году я планировал включить его в несколько плагинов. Прямо сейчас я и другие не решаются делать это из-за направления Гутенберга. И я даже не уверен, не стоит ли мне начинать с нуля в React или любой другой JS-структуре, которую в конечном итоге решили добавить в ядро ​​WP.

Крючки б / у

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

load-post.php
load-post-new.php 
add_meta_boxes
save_post 
admin_enqueue_scripts
admin_footer 
admin_print_footer_scripts

Создан # 2265, чтобы задокументировать соответствующие хуки для CMB2.

Добавлен ярлык «Дизайн», чтобы побудить людей добавлять дополнительные макеты.

В целом, я считаю, что данные, которые не являются частью отображаемого контента, не должны быть частью основной области редактора. Не все - блок.

1) Большинство моих пользовательских мета-боксов созданы с использованием Fieldmanager . На мой взгляд, они должны «просто работать», и с моей стороны не требуется никакой дополнительной работы, кроме обновления. cc / @mboynes и @bcampeau, поскольку они могут внести

2) Некоторые из наших настраиваемых мета-блоков представляют собой смесь jQuery и PHP. Например, у нас есть мета-поле «Один или нет», которое представляет собой радио с кнопкой «очистить». Предполагая, что это сломается, я ожидал бы, что будут примеры того, как я создаю это в Гутенберге, и что у меня будет значительное количество времени, чтобы перейти на версию WordPress, которая требует Гутенберга, прежде чем мой код сломается.

3) У меня есть еще один метабокс, который объединяет некоторый код jQuery и PHP, который отключает кнопку публикации, пока не будет сделан выбор. Подобно моему второму примеру, предполагая, что это сломается, я ожидал бы, что будут примеры того, как я создаю это в Гутенберге, и что у меня будет значительное количество времени, чтобы перейти на версию WordPress, которая требует Гутенберга раньше. мой код ломается.

4) Я удалил мета-поле категории в прошлом и заменил его: 1) радио-выбором 2) версией без возможности добавлять новые категории (это было глупо).

5) Я использовал post_submitbox_misc_actions чтобы добавить в метабокс публикации параметры, которые не обязательно должны быть в отдельном метабоксе.

Что касается того, что я имею в виду под значительным количеством времени, я бы сказал ~ 2 года с момента, когда API Гутенберга заморожен.

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

• 'edit_form_top'
• 'edit_form_after_title'
• 'edit_form_before_permalink'
• 'edit_form_after_editor'
• 'edit_form_advanced'

Я просто хочу повторить то, что крючках edit_form_[POSITION] . Piklist активно использует мета-блоки, рабочие процессы и другие вещи.

Еще раз спасибо за ваше время, ребята.

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

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

Во-первых, приятно видеть реальный прогресс в этом вопросе.

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

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

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

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

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

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

Макет @brentjett от 4 июля кажется чем-то, что может работать как для «обновленных метабоксов», которые не помещаются в контент («область настроек»), так и для мета-боксов, которые можно легко преобразовать в блок Гутенберга (информация о событии).

@rilwis Я думаю, вам следует зайти и упомянуть об обширном использовании Metabox в вашем плагине. Поскольку я использую его в большинстве своих продуктов, я считаю, что это обширный фреймворк. Как это вписывается во все это дело с Гутенбергом? - Здесь могут быть полезны идеи от кого-то, чей бизнес заключается в продаже плагина для создания метабокса (который пострадает больше всего).

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

Dashboard, но представьте себе Гутенберга:

Возможно, предлагаемый Fields API решит некоторые проблемы, связанные с поддержкой метабоксов в новом редакторе.

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

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

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

Ясно, что:

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

Следовательно:

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

@dmccan Нет, эти утверждения не "ясны", как и все предлагаемые до сих пор решения:

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

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

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

Решение всех проблем, которые необходимо решить для того, чтобы иметь возможность работать с одним редактором, потребует много календарного времени. Просто посмотрите на исходный ASP.NET от Microsoft и на то, насколько плохо он решил общую веб-проблему. В конце концов появился AJAX, а остальное уже история.

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

PS Требование «единого редактора» кажется нереальным. Если бы у пользователей была возможность использовать старое или новое, тогда можно было бы позволить новому развиваться с течением времени до тех пор, пока не исчезнет польза от использования старого. Но пока существуют установки с использованием существующих ловушек _ (я считаю) _ безответственно использовать решение с одним редактором. #jmtcw

@kevinwhoffman - Думаю, мы согласны, но, возможно, я недостаточно многословен.

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

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

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

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

Может, им (основным кодировщикам) стоит поговорить с Мэттом. Он все это начал, а теперь у них нет ответов.

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

В качестве побочного примечания, хотя я никогда не использовал React или Vue _ (я разработчик PHP) _, обсуждение React, требующего системы сборки, и то, что многие люди находят Vue намного проще в использовании, чем React, заставило меня сильно переживать будет ли у Гутенбурга простая в изучении и использовании модель расширяемости или нет, и будет ли это означать, что мы можем продолжать использовать WordPress для клиентских проектов.

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

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

Речь идет о полноценном интерфейсном визуальном редакторе тем.

Извините за то, что отправил всем вам электронные письма. Мой последний комментарий по этому поводу.

@Rarst @kevinwhoffman : Я полностью с вами по поводу того, является ли Гутенберг заменой редактора или экрана . Это хорошо продуманный момент. И я надеюсь, что команда разработчиков сможет вернуться к исходной точке и природе Гутенберга - редактору, и сохранить все остальное, как есть сейчас. Это 2 разные части, которые можно использовать друг с другом или без них. Так что лучше хранить их как отдельные вещи.

Кроме того, я создал # 2308, чтобы перечислить соответствующие хуки из плагина Meta Box.

@ahmadawais Спасибо за упоминание.

@nylen Стоит добавить сообщения 2 сообщения в список плагинов для рассмотрения. Хотя он больше не поддерживается, я думаю, что он все еще довольно широко используется.

@nylen Я поддерживаю свои пользовательские поля разработчика плагина

Я согласен с комментариями о том, что редактор Gutenberg - это всего лишь часть редактирования контента. Не знаю, почему и как он превратился в полную замену экрана. Все популярные конструкторы страниц делают это правильно, просто замените TinyMCE чем-нибудь другим, что упростит создание контента.

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

Возьмем, к примеру, каталог сотрудников. Зачем мне нужно, чтобы поля для информации о людях были блокированы? Не то чтобы вы хотели, чтобы они добавляли другие блоки, когда они просто должны вводить имя, фамилию и т. Д.

tldr; Гутенбергу следует заменить редактор TinyMCE только для типов сообщений, для которых требуется составление контента.

Просто добавляю сюда свои два цента.

Почему бы просто не оставить все как есть сейчас? Я имею в виду вот что.

• Сохраните два варианта редактирования при наведении курсора на заголовок сообщения, как сейчас, но измените его, чтобы по умолчанию щелчок по заголовку приводил вас к Гутенбергу. Затем Edit ссылку Classic Edit .
• Добавьте какой-либо флаг поддержки для типа публикации и страницы, чтобы Гутенберг мог быть отключен, если разработчик захочет это сделать. Если Гутенберг не включен, укажите ссылку в заголовке на «классическую» страницу редактирования, удалите ссылку Edit на Гутенберга, и текст ссылки Classic Edit изменится на Edit
• Затем с настраиваемыми типами сообщений есть поддержка Гутенберга, например для редактора, избранного изображения и т. Д. Таким образом, CPT не должен поддерживать Гутенберга.
• Затем обновите стиль классических страниц редактирования. Обновлены мета-поля и стили боковой панели, чтобы соответствовать стилю Гутенберга. Даже переместите мета-блоки выдержек и комментариев на боковые панели, как в Gutenberg.

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

И это даст разработчикам время начать продавать идею использования Gutenberg конечным пользователям. Людям не нравятся перемены. Дать им привыкнуть к новому редактору было бы намного лучше, чем просто резкое изменение.

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

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

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

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

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

Другой способ приблизиться к этому - использовать тот же рабочий процесс, что и Beaver Builder . Т.е. сохраните обычную страницу редактирования сообщения (с обычными разделами Meta Box и т. Д.), Тогда Gutenberg можно будет запустить с помощью кнопки. Затем вы перейдете на новый экран. Очень похоже на комментарии о режиме письма без отвлекающих факторов.

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

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

Чтение всей этой ветки проясняет для меня две вещи:

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

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

Если обсуждение, ориентированное на API, уже происходит, может ли кто-нибудь указать мне и всем, кто не знает, где это происходит, в правильном направлении? Благодаря!

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

Я считаю, что Гутенберг,

• Попытка привести в порядок экран редактора
• Попытка добавить функциональность компоновщика / макета страницы в ядро
• Попытка минимизировать потребность в метабоксах, упростив разработчикам создание новых блоков контента.

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

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

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

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

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

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

Вот мои предложения:

• Добавьте экраны редактирования Tabify в редактор страниц.
• Переместите метабоксы на их собственные вкладки страницы на экране редактора.
• Используйте для метабоксов страницу, не основанную на React (страница скрыта за вкладкой редактора)
• Используйте холст на основе TinyMCE по умолчанию (или аналогичный многофункциональный редактор), который хорошо работает для длинных форм и не требует, чтобы авторы использовали блоки.
• Представьте блоки Гуттенберга как дополнение к TinyMCE или аналогу TinyMCE.
• Представьте Shortcake в редакторе на основе TinyMCE, чтобы авторы могли визуально видеть содержимое блоков и чтобы авторы могли редактировать содержимое непосредственно в потоке страниц без необходимости нажимать кнопку редактирования для каждого блока.
• Упростите разработчикам добавление новых блоков в Guttenberg, связав add_shortcode () с созданием блока, например add_shortcode ('tag', 'function', 'guttenberg true / false'). Адаптируйте add_shortcode так, чтобы он автоматически делал шорткод совместимым с Guttenberg; это позволит разработчикам легко конвертировать некоторые / многие из своих метабоксов в шорткоды, которые работают в Guttenberg.

Я действительно говорю, что Гуттенберга нужно разбить на 3 задачи:

• Очистка экрана редактора
• Улучшенный интерфейс редактора
• Улучшенная структура расширения редактора.

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

У меня есть покупательница, которой за 80. Она просто хочет создавать контент. Она не хочет, чтобы ее заставляли заново учиться пользоваться экраном редактора. На то, чтобы привыкнуть к Visual Composer, у нее ушло больше года, и это простой в использовании конструктор страниц.

Я отклонился от темы исходной темы, но нужно сказать следующее: Гуттенберг убьет WordPress.

Если Guttenberg будет представлен в его нынешнем виде, WordPress будет разветвлен, а версия Guttenberg умрет.

Возможно, новый редактор имеет больше смысла, если вы используете WordPress для ведения блога и создаете для него тему PHP, но в настоящее время многие люди используют WordPress в качестве CMS для создания веб-приложений с использованием React, PODS / ACF и WordPress REST API. Отсюда необходимость поддержки метабоксов и полей отношений для расширенного связывания между CPT.

Во-первых, я думаю, что Гутенберг будет потрясающим.

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

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

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

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

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

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

Конечно, устаревшее мета-поле будет оформлено так же, как новое окно «Настройки публикации», все будет хорошо интегрировано.

Возможно, потребуется скрипт legacy-meta-box.php, который будет загружаться при необходимости, например, при вызове add_meta_box.

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

Причина, по которой мы используем поля ACF почти во всех наших проектах, заключается в том, чтобы контролировать данные, чтобы они постоянно отображались на веб-сайте. Вот два примера, над которыми мы сейчас работаем; Большой сайт мероприятий и фестиваль с работами / инсталляциями, которые нужно связать с художниками, но отображать отдельно. В обоих случаях «контент», часть, которую заменяет Гутенберг, составляет только около 10% контента на экране редактирования и на самом деле является наименее важной частью. Для сайта событий важными данными являются тип события, категория события, дата, время, место, организатор и т. Д. Вы можете опубликовать значимую запись о событии, вообще не вводя какой-либо контент в редактор. Для сайта фестиваля у нас должна быть возможность выбрать художника и связать его с работой, выбрать место работы на сайте фестиваля и загрузить избранное изображение, опять же, контент является дополнительным, а не необходимостью. Для всего «обычного» содержимого страниц на этих сайтах Гутенберг недостаточно гибок (и я не верю, что он должен быть по умолчанию), и мы продолжим использовать более полнофункциональный конструктор страниц (Beaver Builder) для лучшего варианты дизайна.

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

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

Проект должен быть НАМНОГО умнее в этом. Процесс с вкладками мог бы отлично работать, если бы вы могли выбрать (в каком-то шаблоне страницы), какие биты на какой вкладке. Вам также понадобится механизм для пошагового перехода пользователя по каждой вкладке. Тем не менее, я также считаю, что для более коротких элементов CPT вы ДОЛЖНЫ иметь возможность хранить все это на одной странице с определенными ключевыми элементами над содержимым редактора (обязательные блоки, если хотите).

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

Вот почему меня пугает временная шкала 5.0 для этого, мне кажется, что она может быть отличной по времени, но если она будет запущена, фрагментация уничтожит всякую добрую волю как разработчиков, так и клиентов. WordPress торгуется своей гибкостью, обратной совместимостью и общим удобством для пользователя. Мы не можем жертвовать этим ради новой блестящей игрушки. Посмотрите на требования PHP для WordPress, мы говорим буквально за годы до того, как PHP 5.6 или 7 станет требованием. Сообщество признало, что, какими бы неприятными ни были эти длительные сроки, необходимо не ломать веб-сайты. Разве это не ТОЧНО такая же проблема?

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

@avocadesign - Несколько хороших моментов. В будущем мы сможем регистрировать мета-блоки JavaScript, хотя, похоже, в настоящее время думают, что нужно иметь два местоположения ... что не так гибко, как вы упомянули.

@avocadesign - хорошо объяснено. Post_content не всегда в центре внимания сообщения, и ваши «события и исполнители» - хороший пример. Было бы здорово увидеть несколько снимков экрана, показывающих внутреннюю и внешнюю стороны этих типов сообщений, чтобы мы могли помочь разработчикам визуализировать, как WP используется в качестве CMS и как типичный клиент работает через экран редактирования сообщений.

@avocadesign

Если мы когда-либо будем думать о текущих решениях для мета-боксов как о «устаревших» и потребовать от них использовать старый редактор

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

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

Если Гутенберг станет частью ядра, вы сможете создать еще лучший пользовательский интерфейс для упомянутых вами примеров. Частично он будет состоять из настраиваемого блока Festival (своего рода WYSIWYG-формы) и связанных настроек в одном или нескольких (на основе JS) разделах настроек публикации. Пользователь выиграет от более быстрого интерфейса с прямой обратной связью.

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

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

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

• Тип настраиваемого сообщения "Свойство" использует 18 настраиваемых полей на 10 вкладках.
• Вкладки хранят всю необходимую информацию на одном экране и доступны редактору одним нажатием кнопки.
• Типы полей включают простые текстовые и числовые поля в дополнение к галереям ACF и полям отношений.
• Поддержка editor не была объявлена ​​при регистрации пользовательского типа сообщения, что означает, что весь пользовательский интерфейс полагается на настраиваемые мета-поля.

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

Сообществу необходимо знать, что происходит с этим типом интерфейса после введения Гутенберга, и я не думаю, что просить @elliotcondon перенести все это на React вовремя для запуска - реалистичное ожидание.

@kevinwhoffman

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

Вы правы, но цель этого вопроса № 952 - найти этот ответ путем обсуждения и предложения альтернатив. Что будет работать, что нет. В какой-то момент в будущем, когда все будут думать, что мы все пришли к чему-то, что будет работать во всех случаях, как унаследованных, так и в будущем, только тогда это можно будет реализовать, и сообществу (пользователей) можно будет объяснить, как это будет работать. ИМХО, пока рано ждать ответа от команды на этот вопрос.

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

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

@kevinwhoffman

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

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

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

От Гутенберга исходит хорошее, а не головная боль!

Вот экран редактирования событий для сайта, упомянутого выше, с полями ACF над post_content и стандартным мета-окном календаря событий под post_content.

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

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

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

«Контент» не так важен для успешного входа в событие, как различные мета-поля. Событие не будет отображаться на сайте, если дата не указана правильно или не выбрана категория. Что меня беспокоит во всей этой дискуссии, так это макеты, как в выпуске №1352, где мета-блоки помещены в нижнюю часть экрана в сворачиваемой секции. Я могу гарантировать вам, исходя из нашего опыта, что неподготовленные пользователи никогда не увидят мета-боксы, а просто введут дату и местоположение прямо в область содержимого в виде простого текста, а затем будут жаловаться, что их событие не отображается в системе. Просто неподготовленные пользователи не могут обнаружить ее в типах сообщений, требующих структурированной информации.

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

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

Гутенберг, скорее всего, выберет CPT, так же как ваш CPT не заявляет о поддержке текущего редактора.

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

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

Гутенберг не обгоняет административный интерфейс WordPress, он заменяет функциональность редактора ...

Это неточно. В том виде, в каком он существует сегодня, Gutenberg _ является полноэкранной заменой экрана редактирования сообщений.

@ BE-Webdesign и @kevinwhoffman

Кроме того, почему CPT должны упускать те аспекты Гутенберга, которые явно лучше, чем текущий экран редактирования?

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

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

ИМХО, это просто отстой.

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

Что меня беспокоит, так это то, что команда разработчиков, похоже, не понимает проблем, с которыми сталкиваются многие разработчики, применяя здесь первый подход "post_content". Мы используем Beaver builder на ВСЕХ наших сайтах, кроме CPT, где нам нужен структурированный вывод данных. Инструмент для создания страниц, которым и является Gutenberg, отлично подходит для публикаций и страниц с индивидуальными потребностями в контенте. Это ужасно для структурированных данных. Для структурированных данных согласованность интерфейса, обязательные поля и другие приоритеты компоновки всегда важнее содержимого свободной формы.

@kevinwhoffman

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

Да, но это не замена всего интерфейса администратора, о чем я имел в виду. Вы сравниваете незавершенный проект с текущим опытом. # 2251, когда он будет завершен, снова представит всемогущие мета-боксы, так что все будет не так сильно и будет намного лучше. Возможно, некоторым авторам плагинов придется кое-что изменить, но по большей части я уверен, что все пойдет гладко.

@avocadesign

Кроме того, почему CPT должны упускать те аспекты Гутенберга, которые явно лучше, чем текущий экран редактирования?

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

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

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

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

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

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

Редактировать:
Под «краткосрочным» я подразумеваю запуск версии 5.0 для широкой публики, начало 2018 года, похоже, здесь. В долгосрочной перспективе, через 2 или 3 года, я вижу, что эта проблема решается гораздо успешнее.

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

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

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

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

Это цель и то, чего хочет большинство людей.

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

Привет, ребята,

Я ведущий разработчик Carbon Fields и хотел добавить список действий / фильтров, которые мы используем, которые могут быть затронуты:

Фильтры:

• postbox_classes_{$page}_{$id}

Действия:

• init
• admin_menu
• admin_init
• wp
• admin_enqueue_scripts
• in_admin_header
• admin_notices
• admin_print_footer_scripts
• save_post
• edit_comment
• media_buttons
• edit_form_after_title (позиционирование сахара - не критично)

Мои вопросы:

• Если мы собираемся сохранить устаревшие мета-блоки, как они будут взаимодействовать с изменениями данных?
• Какие типы событий (jQuery? Некоторая открытая реализация эмиттера?) И каких именно событий мы можем ожидать от нового редактора (например, при успешной отправке, неудаче и т. Д.)?
• Будут ли эти события доступны для устаревших мета-блоков или только для реализаций React?

PS:
Я просто хочу поблагодарить команду Gutenberg за всю тяжелую работу и усилия, и меня радует, что WordPress движется к современным инструментам и решениям (даже если путешествие кажется пугающим)!

Поддержка мета-боксов очень важна ...

... для тысяч разработчиков и пользователей WordPress.

WordPress не может игнорировать большой плагин-плеер ...

... например, Advacend Custom Fields Pro (https://github.com/elliotcondon/acf/issues/622), WooCommerce или Yoast SEO.

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

Мы хотим сделать наши плагины совместимыми с Gutenberg.

Вот что я понимаю:

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

Это верно? Если да, не могли бы вы сослаться на документацию по API для отображения настраиваемых ящиков на Гутенберге?

Я думаю, что документы все еще развиваются. Некоторые документы есть на https://github.com/WordPress/gutenberg/tree/master/docs - http://gutenberg-devdoc.surge.sh/

Я слышу, что @ BE-Webdesign и другие говорят о намерении свести к минимуму неудобства - спасибо, это обнадеживает - но просто хотел добавить свои 5 пенсов (хорошо, хорошо, мои обычные 105 пенсов).

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

WordPress плюс расширенные настраиваемые поля (Pro) - отличный инструмент для эффективного создания специализированных веб-сайтов на базе баз данных (и даже инструментов управления данными интрасети) с привлекательными интерфейсами, тщательной проверкой ввода данных, интуитивно понятными и последовательными пользовательскими интерфейсами и т. Д. Эти системы могут не работать. быть масштабируемым для огромных объемов реляционных данных, но в очень многих случаях в этом нет необходимости; это простые системы, которые могут быть созданы для клиентов экономически эффективным способом. Это то, что делает WordPress действительно полезной CMS (и, по сути, облегченной СУБД), а не просто платформой для ведения блогов.

Я (и я уверен, что многие другие) малые предприятия используют WP + ACF (или аналогичные плагины для настраиваемых данных) для создания специализированных сайтов и систем для клиентских организаций и отдельных лиц, у которых нет больших ИТ-бюджетов. Если внедрение Gutenberg осуществляется без должного учета поддержки существующих потоков редактирования / ввода данных, метабоксов и т. Д., У меня будут две «нетехнические», но, тем не менее, существенные проблемы:

1 / Моим конечным пользователям потребуется переобучение (нам, как техническим специалистам, легко забыть, насколько сильно запутанные нетехнические пользователи могут получить изменения интерфейса - я написал плагин для сброса пароля Clarify, потому что я терял так много времени, разбираясь пользователи, которые были полностью заблокированы новым процессом сброса пароля, представленным в 4.3).

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

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

Мне очень нравится использовать WordPress, и я потратил много времени на изучение канатов, разработку собственных удобных рамок для проектов и т. Д. - до такой степени, что теперь я зарабатываю большую часть своей жизни (и кормлю свою семью и т. Д.) Через проекты разработки на основе WordPress. Я также попытался что-то вернуть, потратив время на формальный выпуск полезных небольших плагинов, которые я разработал, на WordPress.com, потому что я ценю OSS, разработку на основе сообщества и т. Д. Я думаю, это в основном призыв к решению проблем. упомянул в этой теме, насколько это возможно; в противном случае я согласен с тем, что существует реальная опасность разветвления кодовой базы. Как поклонник WordPress и участник плагинов, я думаю, что это ДЕЙСТВИТЕЛЬНО плохой результат; однако, как индивидуальный разработчик, полагающийся на WP, чтобы зарабатывать себе на жизнь, мне, возможно, придется перейти на разветвленную (т.е. должным образом обратно совместимую) версию по экономической необходимости. Пожалуйста, не позволяйте этому случиться!

@konamac делает несколько замечательных писал в другой ветке.

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

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

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

3. Все, что я должен уметь делать в наследии, - это все, что я должен уметь делать в Гутенберге.

4. Параметры экрана
5. Мета-боксы (ACF, Yoast и т. Д.)
6. Постоянные ссылки ?! Я даже не могу понять, почему это еще не редактируется в 1.0
7. Классический блок содержимого НЕ загружается должным образом в средах localhost
8. Документация ДОЛЖНА быть ключевой для создания различных стилевых блоков. Приведите несколько примеров, несколько вариантов использования. Не каждый разработчик тем является бэкендом, так что не думайте. Будьте кристально чистыми
9. Настройки блока требуют доработки. Очень сложно сказать, какие настройки доступны для каждого блока. Кажется случайным. Когда мне нужно редактировать настройки блока, а когда нет?
10. Все теги комментариев вокруг текстового редактора Gutenberg ... грустно видеть.

Некоторые из нас очень разочаровываются в этом процессе. Это должен быть предельно простой ответ.

Будет ли Гутенберг защищать текущее использование метабоксов / ACF и есть ли планы по обеспечению такой поддержки на неопределенный срок?

Нам не нужно знать, какое решение есть прямо сейчас - мы знаем, что вы его выясняете. Но у нас до сих пор нет ЧЕТКОГО ответа на этот вопрос. ACF, в частности, должен работать точно так же, как и всегда, для поддержки старых клиентов, которые НЕ согласятся взимать плату за обновление - особенно при обсуждении удаления устаревшего редактора в какой-то момент (как вы можете вообще начать этот разговор прямо сейчас ?! )

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

@ BE-Webdesign

когда он будет завершен, снова представит всемогущие мета-боксы

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

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

Как указано в # 2308, я скопировал хуки, которые плагин Meta Box использует при создании / сохранении настраиваемых полей:

• Скрипты и стили ставятся в очередь с использованием admin_enqueue_scripts . Мы проверяем текущий экран (через get_current_screen ), чтобы убедиться, что сценарии и стили помещены в очередь только для этих страниц. Для основного плагина он проверяет типы сообщений. Для расширений (мета термина, мета пользователя, страница настроек) он больше проверяет таксономию, страницу профиля пользователя или страницы настроек.
• Мы также используем print_media_templates для печати шаблонов Underscore.
• Скрипты, которые мы используем в плагине, включают в себя: выбор цвета, подчеркивание, магистраль, медиа-скрипты, tinymce (для поля редактора)
• Мы используем init для инициализации всех хуков для плагина.
• Мета-боксы регистрируются с помощью хуков add_meta_boxes .
• Скрытые мета-блоки используют default_hidden_meta_boxes .
• Мы также подключаемся к post_edit_form_tag чтобы разрешить загрузку файлов.
• Мы используем save_post_{$post_type} и edit_attachment , add_attachment для сохранения мета-значений для сообщений и вложений.

Что плохого в создании хуков для отображения метабоксов выше / ниже / боковой панели Гутенберга?

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

Маттиас говорит нам, что метабоксы можно переосмыслить как блоки, хранящиеся в post_meta. Если это цель слияния, то есть некоторые проблемы, которые нужно решить:

Многие метабоксы регистрируют the_editor($custom_id); чтобы это поддерживалось в контексте Гутенберга, либо интерфейс и api для создания вложенных блоков необходимы с первого дня, либо мы говорим, что метабоксы могут иметь только интерфейс редактора второго класса. , без каких-либо преимуществ блоков. Это будет особенно проблематично для большого количества агентств, которые в настоящее время проектируют с использованием гибких макетов ACF, поскольку им потребуется способ создания отдельных блоков Гутенберга для различных контекстов и областей. Даже «мышление блоками» я не вижу хорошего способа решить проблему «область содержимого, за которой следует часть шаблона, за которой следует область содержимого» без поддержки вложенности в «метаблоки» с первого дня.

В основе этого лежит техническая проблема вложенности блоков, которые не хранятся в post_content. Маттиас говорит, что блоки смогут сохранять в postmeta, но если блок может определять, где он хранится, как будет работать вложение, когда родительский блок хранится в postmeta, а пользователь добавляет дочерний элемент, который хранится в другом post_meta ... (Или в патологическом случае вложенный блок, который Tha сохраняет в postmeta, содержит блок, который хранится в том же поле postmeta.

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

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

Однозначного ответа на вопрос о будущей поддержке существующих метабоксов нет.

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

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

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

Рад слышать!

Постоянные ссылки ?! Я даже не могу понять, почему это еще не редактируется в 1.0

Потому что REST API еще не поддерживает это. Любая помощь приветствуется: https://github.com/WordPress/gutenberg/issues/1285

Я неоднократно говорил, что мы будем учитывать мета-боксы.

@mtias Я думаю, что путаница в отношении поддержки мета-боксов возникает из-за того, что

Я неоднократно говорил, что мы будем учитывать мета-боксы.

@mtias мои извинения, я, должно быть, пропустил ваше разъяснение в другом месте. Рад слышать! Сделайте текущую итерацию визуально более привлекательной и целеустремленной, и она будет иметь огромный успех.

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

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

@kevinwhoffman: Правильно, я думаю, что суть проблемы в том, что «существующие функциональные возможности» также включают презентацию, а поскольку Гутенберг значительно изменяет пользовательский интерфейс, для возврата к предыдущему потребуется отключить плагин. Как метабоксы вписываются в новый пользовательский интерфейс и как старые мета-блоки могут поддерживаться без вмешательства разработчика - вот над чем мы работаем. Я не знаю точно, как это сработает, поэтому я не смог пообещать конкретный результат. Я также думаю, что это может привести к более четкому представлению функций мета-боксов.

@brograhamer извинений не нужно, это большая ветка! Мы не хотим ничего торопить, а это довольно большой проект с множеством движущихся частей. Иногда некоторые вещи могут казаться забытыми, но это не значит, что мы не планируем их решать.

В настоящее время я создаю веб-приложение с использованием ACF с 10 настраиваемыми типами сообщений, которые не используют редактор tinymce. Я использую функцию заголовка и в среднем около 15 полей ACF для каждого CPT.
В настоящее время вы можете объявить, какие функции (например, редактор, эскиз, отрывок и т. Д.) Поддерживает CPT.
Можно ли будет скрыть / удалить блок абзаца «Напишите свою историю», а также значок «Вставить блок» с экрана редактирования?

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

С другой стороны, с v1 метабоксов, панели метабоксов могут быть расширены снизу, если мы сохраним это, мы должны гарантировать, что он всегда «открыт» для CPT без поддержки «редактора». Возможно, в этом нет необходимости, если метабоксы всегда отображаются под редактором (как некоторые из предложений по дизайну выше)

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

Есть ли какой-нибудь план по интеграции основных настраиваемых мета-полей в Gutenberg?

Привет, @jawittdesigns!

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

Не все используют WordPress для ведения блогов. Многие из нас используют WordPress в качестве CMS. В настоящее время мы создаем веб-приложение с использованием WordPress REST API и ACF. У нас есть 10 настраиваемых типов сообщений, и каждый CPT имеет 20 настраиваемых полей, и все CPT связаны друг с другом посредством двунаправленных отношений с использованием полей ACF Relationship и Post Object и плагина ACF Post-2-Post.

Гутенберг в его нынешнем виде нам бесполезен, поскольку мы даже не используем текущий редактор. Мы используем только текстовое поле Title для наших CPT, а остальное - это настраиваемые поля, которые хранятся в таблице post_meta.

Я твердо верю, что редактор Гутенберга не должен становиться частью ядра в его нынешнем состоянии. Я понимаю, что WordPress как проект должен немного подыгрывать тем разработчикам сайтов, которые не работают со своими собственными темами ... однако редактор Гутенберга, похоже, является прямой атакой на тех из нас, кто использует расширенные настраиваемые поля для создания сложного ввода контента. достаточно «идиотское доказательство» для владельцев сайтов, предоставляя им очень специфический способ ввода своего контента. Редактор Гутенберга в его нынешнем виде кажется прямой атакой на тех из нас, кто использует ACF.
С плагином Gutenberg ссылка редактирования в заголовке отправляет пользователя непосредственно в интерфейс Gutenberg, который не показывает НИКАКИХ мета-блоков ACF и не имеет вкладки параметров экрана в верхней части экрана для их активации. Да, пользователь может вернуться к массиву страниц / публикаций и выбрать вариант «классический редактор», а затем увидеть мета-блоки, но это означает, что редактор сайта должен предпринять дополнительный шаг, чтобы перейти к полям ACF. Не совсем оптимально, учитывая, что цель использования ACF во многих случаях состояла в том, чтобы сделать редактирование сложных макетов более плавным и простым для нетехнического редактора.

Какая это была давняя проблема!

После слияния # 3345 и # 3554 поддержка метабокса находится в состоянии, которое мы с радостью называем _feature complete_. Обратите внимание, что это отличается от _complete_, поскольку, очевидно, еще предстоит проделать работу по полировке опыта метабокса, особенно в отношении стиля, более сложной обработки JavaScript и определения правил для возврата к классическому редактору.

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

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

При всем уважении, эта функция должна быть далека от завершения.

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