Gutenberg: Являются ли iframe жизнеспособным долгосрочным решением для мета-боксов?

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

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

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

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

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

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

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

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

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

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

Можно ли решить эти проблемы, не требуя модификации темы или плагина, который генерирует мета-поле?

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

Привет, Кевин,

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

Можно ли запустить окно содержимого из мета-окна, выходящего за пределы iframe?

Вы имеете в виду модальный лайтбокс, который должен занимать всю страницу?

Вы имеете в виду модальный лайтбокс, который должен занимать всю страницу?

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

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

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

Зная, насколько негативна реализация iFrame по отношению к ресурсам плагина / темы, я думаю, что это должно приостановить проект. Настоящий ответ здесь - WordPress поставляет Fields API https://github.com/sc0ttkclark/wordpress-fields-api - без этого эффективная реализация метабоксов с помощью Gutenberg практически невозможна, если мы вообще заботимся о производительности.

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

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

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

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

Возможно, стоит отметить, что в недавней заметке разработчика Core Customizer было обращено внимание на удаление использования iframe в качестве _улучшения_. Реализация iframe в качестве решения здесь кажется шагом назад.

Привет, Матетос,

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

Я согласен, что Fields API было бы неплохо. Однако это также повлечет за собой необходимость принятия людьми API полей. Если не многие захотят переписать свой плагин / тему для Gutenberg, я не думаю, что они захотят сделать это для Fields API. Я также думаю, что это было где-то в предыдущем выпуске, поэтому я бы порекомендовал найти это в истории GitHub и добавить свои мысли о том, как Fields API может помочь Гутенбергу.

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

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

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

Источник: https://yoast.com/gutenberg-alternative-approach/

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

Просто отметим, что эта концепция нарушает существующие метабоксы, потому что нет центрального экземпляра TinyMCE для связи. Вместо того, чтобы поддерживать 80% метабоксов, это будет поддерживать 90% (эти числа я составил).

Эта концепция не решает проблему обратной совместимости, а просто откладывает ее решение на потом с той же проблемой. Gutenberg - это первый шаг к JS-интерфейсам в WP, и он не остановится на Gutenberg.

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

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

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

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

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

Зачем тратить тысячи часов на разработку идеального редактора, если его нельзя сделать совместимым с существующими сайтами?

Просто быть чистым,

• невозможно быть на 100% совместимым с существующими веб-сайтами, независимо от того, какой вариант вы выберете для редактора, потому что плагины имеют полный доступ к DOM, любая вещь, которую вы изменяете в dom, нарушает обратную совместимость
• Есть только один способ обеспечить 100% обратную совместимость при любых изменениях: не вносить изменения. Плагин, отключающий Гутенберга, уже доступен.
• Редактор уже совместим с огромным количеством сайтов. Но, как и все остальное, когда он ломается, он всегда более заметен.

невозможно быть на 100% совместимым с существующими веб-сайтами

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

Все ли метабоксы должны работать на мобильных устройствах?

Да, а почему бы и нет?

В каких случаях (если таковые имеются) нельзя преобразовать в блоки?

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

Что касается таких вещей, как настраиваемые типы сообщений, которые могут состоять ТОЛЬКО из мета-блоков, у меня возникают проблемы с пониманием нового пользовательского интерфейса. Поскольку в WordPress отсутствует комплексный CRUD API для данных, многие разработчики используют WP_Query и его набор связанных API в качестве замены, а также используют мета-поля на экранах редактирования CPT, чтобы изолировать пользовательский интерфейс для добавления определенных данных или ассоциации. Многие (большинство) пользовательских типов сообщений в дикой природе приуменьшают значение или игнорируют традиционное использование «контента» - так что для сообщений в блогах, да, контент находится в центре внимания, но для многих случаев использования CMS WYSIWYG не делает много смысла.

В этой текущей итерации поддержка Meta Box является надстройкой, тогда как в реальности для многих людей Meta Box ЯВЛЯЕТСЯ UI, API, механизмом, который они используют для создания своей CMS. <iframe> s - это ГУЛАГ.

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

Я закончу этим примером: если один из моих "старых" мета-блоков вызывает открытие пользовательского интерфейса для мультимедиа, как это будет работать в этом "новом" сценарии изнутри iframe, без кого-то (клиент, с которым я больше не работаю ) переписывая код?

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

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

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

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

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

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

невозможно быть на 100% совместимым с существующими веб-сайтами

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

Iframe - это тупик с точки зрения удобства использования. Открыл виджет выбора даты на основе jquery в мета-поле и был удивлен, когда щелчок в другом случайном месте в окне не закрыл его. Мне потребовалась минута, чтобы понять, что событие щелчка было в родительском окне и не распространялось в iframe. Я был удивлен, но в конце концов получил это, но как вы собираетесь объяснить такую ​​вещь пользователям? Ожидаете ли вы, что каждый плагин ответит на вопрос каждого пользователя о таких тривиальных ожиданиях UX?
И как вы ожидаете, что внешние ссылки будут работать?

Есть веские причины, по которым люди используют iframe только в крайнем случае.

Мое продуктивное предложение - не объявлять мета-бокс готовым, пока yoast seo не работает в нем должным образом. Он немного сложен с точки зрения взаимодействия и установлен на дерьмовом множестве сайтов. Если Гутенберг не может с ним работать, вероятно, никто не будет им пользоваться.

Мое продуктивное предложение - не объявлять мета-бокс готовым

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

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

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

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

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

Согласовано

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

Согласовано

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

Согласен, не думаю, что здесь с тобой кто-то не согласится. Однако я думаю, что еще есть место для обсуждения того, что и когда ломается. Подобные решения также влияют на то, какую работу должны выполнять разработчики, чтобы исправить все поломки. Существует значительная разница между настройкой вещей, потому что селекторы dom были изменены, и необходимостью переписывать пользовательскую модель контента, чтобы соответствовать новой парадигме Гутенберга, где метабоксы работают только как бы :) Разногласия вокруг метабоксов показывают мне, что это то, что, вероятно, не Хорошая вещь для предотвращения взлома первоначальной версии Gutenberg в ядре.

Я _get_, что все это эксперимент, я думаю, @kevinwhoffman тоже. Я рассматриваю эту проблему как хорошо продуманную _оценку_ этого эксперимента, и ее следует воспринимать именно так. Достаточно ли этого эксперимента в качестве окончательного решения? Нет. Так какой следующий эксперимент?

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

tldr; Ожидаем ли разрыва с Гутенбергом? Да! Но мы все равно должны быть избирательны в отношении того, _ что_ мы ломаем, и насколько далеко заходит эта поломка в _ начальной_ итерации Гутенберга, объединенной с ядром.

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

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

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

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

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

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

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

@aaronjorbin ну, похоже, здесь есть проблема со связью, как было прямо сказано в https://make.wordpress.org/core/2017/10/24/whats-new-in-gutenberg-24th-october/

Этот выпуск включает долгожданную поддержку мета-боксов (требует тестирования!),

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

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

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

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

Просто чтобы разработчики знали об этом.

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

Windows XP = WordPress без Гутенберга
Windows 10 = Wordpress с Гутенбергом.

Эти 2 нельзя смешивать и обновлять с пакетами другого.

Joomla и Drupal сделали это. Почему бы и нет. Не то, что я предпочитаю, а то, что есть альтернатива.

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

Разделение админа было бы одним из худших результатов, которые может дать Гутенберг. Я изложил причины, по которым в https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341752490.

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

Кевин Хоффман:

Я полностью согласен с этой концепцией, выдвинутой Yoast, которая, как мне кажется, сохранит большую часть уже выполненной работы, уменьшив масштаб проекта, чтобы сосредоточиться на компоненте редактора. Источник: https://yoast.com/gutenberg-alternative-approach/

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

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

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

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

Какова цель Гутенберга?

Это не так и никогда не было, главная цель Гутенберга - прокладывать путь в будущее WordPress Core. Технически, используя REST API, пользовательский интерфейс на стороне клиента и объединяя основные концепции: виджеты, шорткоды, блоки, метабоксы контента под уникальной концепцией «Блок» и получая опыт, отвечая на следующие вопросы: Как можно упростить создание веб-сайтов (подумайте о настройке) и публикация контента (думаю, редактор) в WordPress.

Какова цель редактора Гутенберга?

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

Что насчет метабоксов, они важны для WordPress?

Они есть. Как и шорткоды, пользовательские кнопки TinyMCE, они активно используются и злоупотребляют для расширения страницы редактора WordPress.

В чем разница между шорткодами, кнопками TinyMCE и метабоксами?

Основное отличие состоит в том, что «Метабоксы» не имеют «цели», это просто способ расширить страницу редактора без единообразия, в то время как у шорткодов и кнопок TinyMCE она есть.

Шорткоды - это строка, преобразованная в контент на этапе рендеринга, кнопки TinyMCE - это настраиваемые кнопки, добавляемые на панель инструментов TinyMCE и использующие TinyMCE API для связи с контентом редактора. Метабоксы? Я не знаю, это может быть что угодно, вы просто добавляете кучу HTML, Javascript и PHP, чтобы расширить страницу редактора и как она себя ведет при сохранении.

Это отсутствие «цели» - проблема или преимущество?

Хорошо! Его можно рассматривать как «профи», потому что плагин может делать с редактором все, что угодно, включая такие вещи, как:

• Замена любой кнопки, текстового поля, ввода, div, чего угодно. Полный доступ к DOM
• Использование любой глобальной переменной javascript, включая глобальный экземпляр TinyMCE

Гибкое право! А как насчет обновлений WordPress. Любое обновление экрана редактора. Любое обновление TinyMCE, любое изменение класса, любое новое div , любая удаленная / перемещенная кнопка, любое изменение нарушает совместимость с плагинами, потому что как разработчик Core WordPress вы не знаете, для каких плагинов используются Metaboxes.

Можем ли мы сделать вывод, что в долгосрочной перспективе метабоксы блокируют его эволюцию (независимо от Гутенберга)?

Да. И история Интернета так много раз доказывала, что технология, которая не развивается, умирает. (пожалуйста, не реагируйте с 👎 Если вам не нравится этот ответ, это факт, а не мнение)

Хорошо, но как же тогда продвигать WordPress, если мы застряли на Metabox?

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

Для чего текущие плагины используют метабоксы?

Я бы сказал, что есть две категории плагинов «Метабоксы»:

• Метабоксы как контент (часто хранятся в мета поста, но не всегда)
• Метабоксы как расширение возможностей редактора (SEO, проверка орфографии,…)

Хорошо, зная это, как мы можем двигаться дальше?

Нам понадобятся три вещи:

• Предоставьте возможность создавать или обновлять эти плагины во время поставки Gutenberg (или любого обновления WordPress).
• Предоставьте людям, использующим эти плагины, оптимальные способы обновления. Это включает в себя: посмотреть, могут ли эти плагины по-прежнему работать с приближающимися изменениями, и как минимизировать поломки.

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

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

Лично я бы не назвал это хорошим путем апгрейда, это даже не апгрейд, что-нибудь лучше?

Этот способ обновления (отключение Гутенберга) необходим, но да, мы можем сделать лучше. Если вы посмотрите на плагины, использующие Metaboxes, 90% из них не имеют никакого взаимодействия с областью содержимого, поэтому, если мы заменим только область содержимого (подход yoast), мы нарушим только 10% плагинов.

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

Оптимальный пользовательский интерфейс Gutenberg состоит из замены подключаемых модулей метабоксов на подключаемые модули, обеспечивающие ту же функциональность, что и новые API-интерфейсы Gutenberg Extensibility.

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

Это решение iframe, о котором все говорят?

Да, именно так. Мы показываем мета-блоки в окнах iframe, у которых есть свои недостатки (ссылка, модальные окна, перезагрузка ресурсов), но в то же время он позволяет работать 80% плагинов, наслаждаясь всем опытом Gutenberg. Это решение только что появилось, и мы все еще экспериментируем с ним. Что несомненно, так это то, что невозможно заставить все метабоксы работать и вносить изменения в редактор.

Ясно, не могли бы вы рассказать о возможностях обновления?

Конечно.

1- Отключить Гутенберг: не ломать 100% плагинов
2- Гутенберг заменяет только область контента: 90% плагинов работают, UX страдает
3- Гутенберг заменяет весь экран: 80% плагинов работают, UX лучше
4- Gutenberg с совместимыми плагинами: лучший возможный UX

Итак, что нам нужно делать?

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

Как я могу выбрать один вариант вместо другого?

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

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

Мы все в одной лодке, мы хотим лучшего для WordPress.

Очень подробные объяснения, Риад. Спасибо, что нашли время написать их. Позвольте мне помочь вам избежать этого ограничения с помощью a и 🤗. Надеюсь, поможет.

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

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

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

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

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

Сами по себе мокапы не сигнализировали о том, что кодовая база всей страницы редактирования будет переписана в React. Никто не мог знать, глядя на макет, что критические хуки будут удалены или мета-боксы сломаны. Однако, когда мне стало очевидно, что переход на всю страницу создаст проблему для мета-боксов, я высказал эту озабоченность 15 июня , за день до того, как 0.1.0 был помечен для выпуска. Четыре месяца и 15 выпусков спустя мы впервые увидели, что мета-блоки появляются в интерфейсе внутри iframe.

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

Основное отличие состоит в том, что «Метабоксы» не имеют «цели», это просто способ расширить страницу редактора без единообразия, в то время как у шорткодов и кнопок TinyMCE она есть.

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

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

Любое обновление экрана редактора. Любое обновление TinyMCE, любое изменение класса, любой новый div, любая удаленная / перемещенная кнопка, любое изменение нарушает совместимость с плагинами, потому что как разработчик Core WordPress вы не знаете, для каких плагинов используются Metaboxes.

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

Мы показываем мета-блоки в окнах iframe, у которых есть свои недостатки (ссылка, модальные окна, перезагрузка ресурсов), но в то же время он позволяет работать 80% плагинов, наслаждаясь всем опытом Gutenberg.

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

Пожалуйста, остановитесь и оцените заново сейчас, не позже

После всего этого обсуждения и того, что я считал доказательством того, что фреймы не являются жизнеспособным долгосрочным решением, я наткнулся на https://github.com/WordPress/gutenberg/issues/3165#issuecomment -341476059, который, похоже, добавит третий iframe в Гутенберг.

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

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

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

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

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

Это единственный пример, но ухудшение восприятия метабоксов не является приемлемым решением, пока Гутенберг не превзойдет паритетность. Этого не произойдет с WP 5.0

Вот дорожная карта к плану «единого администратора» для Гутенберга, который действительно сработает:

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

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

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

Гутенберг похож на концепт-кар. Теперь уменьшите масштаб и отправьте итеративное улучшение в редактор (не на страницу редактора). Затем, в течение следующего года или двух, вы можете довести проект до 100% административного покрытия.

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

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

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

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

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

Только мои два цента, с нетерпением жду возможности увидеть здесь результат.

Количество плагинов, работающих с Gutenberg, может составлять 80%, 90% или 0%, как в наших тестах, чего следует избегать, так это того, что тысячи и тысячи владельцев сайтов должны сами выяснять, будет ли их конфигурация, вероятно, работать или не будет работать. с Гутенбергом. Это было бы огромной тратой времени (= денег), вызвало бы много недоразумений и убило бы доверие.

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

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

PS.
Для моих собственных проектов (платформа микросайтов интрасети для клиента> 30 000 сотрудников и множество сайтов для малого бизнеса / некоммерческих организаций) мы решили отключить Gutenberg, пока он не проработает хотя бы один год.

В любом случае проценты не раскрывают всей истории. Любое обсуждение влияния Гутенберга должно учитывать, сколько веб-сайтов затронуто его реализацией метабокса, а не сколько плагинов затронуто. Gutenberg может повлиять только на несколько плагинов и по-прежнему затронуть миллионы пользователей, поскольку некоторые из наиболее широко используемых плагинов зависят от метабоксов и настраиваемых полей - два очевидных примера - ACF и Yoast SEO.

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

Чего я не понимаю, так это желания получить от 0 до 100 за один присест. Почему здесь не выбирают итеративный выпуск? Почему есть два варианта: «ничего не сломать» или «сломать все»?

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

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

2- Гутенберг заменяет только область контента: 90% плагинов работают, UX страдает

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

4- Gutenberg с совместимыми плагинами: лучший возможный UX

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

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

Я не совсем понимаю, что это значит. Вы хотите создать Gutenberg, предполагая, что все плагины просто работают с ним, и использовать это решение, чтобы вернуться к вариантам 2 и 3? Стремление сначала к 2, а затем к 3, разве это не то, что приведет нас к 4?

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

Наряду с опасениями Кевина по поводу iframe я хотел бы указать на некоторые проблемы с доступностью. Во-первых, в то время как пользователи, которые визуально воспринимают сайт, будут воспринимать наборы фреймов и фреймы как единое целое вместе с остальной частью страницы, пользователи программ чтения с экрана этого не делают. Пользователи программ чтения с экрана воспринимают каждый кадр в наборе фреймов, и каждый iframe как отдельную часть, отдельную от остальной страницы, поскольку веб-страницы воспринимаются линейно. Некоторые программы чтения с экрана (в частности, Jaws для Windows, которая занимает наибольшую долю рынка согласно ежегодному исследованию использования программ чтения с экрана WEBAIM), имеют настройку конфигурации, позволяющую игнорировать фреймы, в том числе встроенные, потому что они могут сильно раздражать некоторые экраны читатели пользователей. При вызове параметра игнорирования фреймов содержимое внутри фреймов и фреймов исчезает. Даже если Гутенберг следует всем передовым практикам доступности, когда дело доходит до iframe, просьба пользователей отключить этот параметр, чтобы иметь возможность полностью редактировать контент, также подвергает их воздействию каждого отдельного экземпляра iframe и худшей практики фреймов в сети. Единственная альтернатива для этих пользователей - попросить их создать отдельный профиль только для использования Gutenberg, что является непростым процессом, потому что это означает, что им нужно заново настраивать каждый параметр браузера и параметр речи. Это также означает, что им необходимо поддерживать как минимум два отдельных профиля браузера. Я буду первым, кто скажет пользователям Jaws for Windows перейти на NVDA на постоянной основе по причинам. Использование Гутенбергом фреймов для поддержки метабокса не является одной из этих причин.

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

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

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

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

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

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

2- Гутенберг заменяет только область контента: 90% плагинов работают, UX страдает

@youknowriad , как вы можете сказать, что UX не страдает от Gutenberg по сравнению с TinyMCE? Я искренне задаю этот вопрос, а не корчу. Я могу вам сказать, что UX действительно сильно страдает в Gutenberg по сравнению с TinyMCE и мета-боксами. Я бы посоветовал вам выяснить это для себя:

(1) Отключение мыши.
(2) Если вы используете Mack, нажмите command + f5 и попытайтесь сделать что-нибудь продуктивное с помощью VoiceOver.
(3) Если вы работаете на ПК, загрузите NVDA, установите его, отключите мышь и выполните тот же тест. Попытайтесь сделать что-нибудь продуктивное с Гутенбергом в этих обстоятельствах.

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

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

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

1. Открытый источник. Думаю, эта аудитория согласится, насколько это мощно и выгодно.
2. Удобство использования. WordPress упростил для не разработчиков создание и обновление контента. Это было очень важно в первые годы создания веб-сайтов для частных лиц и предприятий.
3. Определение содержания. Пользовательские типы сообщений, пользовательские таксономии и пользовательские мета-поля. Когда все, что привело к этому, достигло сингулярности, я не думаю, что достигну, когда говорю, что это было тогда, когда WordPress был «продаваемым» бизнес-сообществом как нечто большее, чем просто программное обеспечение для ведения блогов. (WordCamp Phoenix 2012 - CMB. Отличное произведение Джастина Тэдлока по определению типов сообщений, таксономий и мета-блоков.)

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

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

@jchristopher очень хорошо

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

@jnicol и @aurooba делают отличные @amandarush , за обращение к

@aaronjorbin сказал это ранее, когда кто-то принимает WordPress, они не принимают WordPress (номер версии-здесь), они принимают WordPress в целом.

Есть еще одна версия этого, которую, вероятно, часто слышит любой сотрудник клиентских служб. Когда кто-то приходит к вам и говорит, что ему нужен новый сайт (мы не говорим о блогах), они обычно не говорят: «Мне нужен новый сайт на Wordpress», или «Я хочу новый сайт на Drupal» и т. Д. Им просто нужен новый сайт, который работает и работает хорошо.

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

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

Я буду откровенен, здесь:

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

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

В качестве альтернативы (и это было бы НАМНОГО лучше) ОБЯЗАТЕЛЬНО примите эти мысли. Правильно подумайте о том, что говорят люди. Поймите, что нас беспокоит, как людей, управляющих бизнесом, использующим WordPress, и понимайте, что мы заботимся не только о себе, но и о наших клиентах.

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

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

Я вижу упоминания о желании обслуживать пользователей новой установки (что? ~ 1% роста Интернета в год?), Но, похоже, это происходит за счет существующей базы пользователей (~ 28%), большинство из которых, вероятно, будет запускать плагин, у которого есть хотя бы один мета-блок. Это похоже на плохое деловое чутье в любом масштабе.

Я понимаю идеологию: создать лучший редактор, а затем использовать шаблон адаптера, чтобы старые общались с новыми. Проблема в том, что PHP и JS - это разные технологии, и переносить эту проблему в сферу HTML iframe нецелесообразно по всем причинам, указанным ранее.

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

Никто не придумал подходящего решения, когда дело доходит до мета-боксов, которое удовлетворяет все стороны.

Это означает, что одна сторона должна уступить - и будет ли это 10-50 программистов-сторонников Гутенберга или сотни / тысячи разработчиков, которые _ напуганы_, или влияние этих изменений на них, не говоря уже об их пользователях, мы увидим.

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

Вернемся к исходному вопросу - являются ли iframe долгосрочным решением для мета-боксов? Несколько разработчиков (и не будем забывать, что они тоже Пользователи) объяснили, почему ответ отрицательный.

У нас здесь в основном конструктивное обсуждение. Помните:

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

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

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

• Первая итерация включала в себя ошибку, заставляющую WP делать вид, что он находится на странице edit.php , и таким образом генерировать метабоксы. Первоначальные отчеты показали, что у него были проблемы с совместимостью, и он был супер взломанным, а не жизнеспособным решением. Это связано с тем, что многие плагины регистрируют метабоксы только при определенных обстоятельствах и не доверяют WP знать, когда их отображать.
• Вторая итерация, которая была объединена, использует фреймы, поэтому метабоксы отображаются в классическом редакторе, хотя все, кроме метабокса, удалено. Это немного неуклюже, но метабоксы работают, хотя и с проблемами
• Также существует решение, в котором мы получаем HTML-код, а затем полностью вставляем его в компонент, что было бы катастрофой для безопасности, несмотря на то, что это супер очевидное решение. Вот почему этого не сделали.

Мое предложение:

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

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

• мы избегаем ерунды iframe
• метабоксы работают как всегда, что касается регистрации
• существующий JS работает так, как ожидалось, и никаких хаков для работы на стороне PHP не требуется

Кроме того, дизайн yoast симпатичный, но где же мета-блок?

К сожалению, у меня очень мало опыта работы с js на уровне, необходимом для внесения фактического кода в Gutenberg. Я только начинаю погружаться в мир разработки WordPress, а не на его основе. Поэтому лучшее, что я могу сделать, это оставить свой отзыв, протестировать редактор (я активно использую Gutenberg в своем личном блоге) и поделиться своими предложениями / мыслями. Если бы я _ мог_ внести свой код, я бы это сделал. Если есть еще один способ помочь, я хотел бы знать. Потому что меня это очень волнует. :)

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

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

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

Мое предложение:

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

Да, это, скорее всего, следующая итерация, и я думаю, что это отличное предложение, а также конструктивная идея. Еще не уверен на 100%, как это сделать чисто, но вполне возможно не использовать фреймы и иметь такой же улучшенный UX, который уже предоставляет Гутенберг. В ближайшее время появятся обновления для улучшения работы с мета-блоками, которые, вероятно, будут связаны с удалением фреймов. Метод iframe служил способом увидеть, как может быть реализована поддержка метабокса, теперь будут внесены лучшие улучшения. Когда много месяцев назад что-то впервые исследовалось с помощью мета-боксов (это не новая тема), имело смысл двигаться дальше с подходом iframe из-за состояния Гутенберга тогда, теперь, когда он объединен и многие другие части были перемещены С технической точки зрения использование iframe больше не требуется. Потребуется дополнительная работа.

@ BE-Webdesign Спасибо за ваши усилия и вклад. Давайте закроем это и начнем новую тему, когда этот подход будет готов для обсуждения.

Пожалуйста, остановитесь и оцените заново сейчас, не позже

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

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

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

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

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

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

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

К сожалению, это полностью противоречит тому, что @youknowriad сообщает в этой ветке.

Я думаю, вы просто неправильно поняли то, что я сказал, я просто перечислял факты и разделяю мысли @mtias на 100%

@mtias

То, что некоторые называют прагматическим подходом, не соответствует тому направлению дизайна, которое этот проект имел с самого начала - к полной настройке сайта.

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

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

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

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

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

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

за счет использования REST API, пользовательского интерфейса на стороне клиента и объединения основных концепций: виджетов, шорткодов, блоков, метабоксов контента в рамках уникальной концепции «Блок»

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

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

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

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

Это гигантское заблуждение , что должно поднять брови в Automattic. (И я надеюсь, что @mtias и @m слушают). Это просто неправда, и я действительно сомневаюсь в вашем суждении после этого заявления.

Можем ли мы сделать вывод, что в долгосрочной перспективе метабоксы блокируют его эволюцию (независимо от Гутенберга)?
Да.

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

Я также спрашиваю @mtias, говоря о людях, которые

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

@mtias ,

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

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

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

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

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

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

@khromov , как ведущий дизайнер этого проекта, так же, как Матиас является техническим руководителем, я на 100% поддерживаю @youknowriad. Я понимаю, что вы увлечены, но не проявляете уважения. Пожалуйста, измените свой подход, вызвав одного человека. Давайте перестанем быть личными.

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

@khromov

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

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

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

• Планируется, что виджеты станут блоками. Это НЕ означает, что они будут существовать в редакторе и сохраняться в post_content. Это просто означает, что они будут управляться системой, построенной на платформе JavaScript, с помощью единого общего API.
• Планируется, что Настройщик будет заменен блоками. Интерфейс, вероятно, останется (примерно) таким же, но разделы Настройщика будут управляться одним и тем же API.
• Страница плагинов, редактор тем и сама панель управления в конечном итоге должны стать блоками. Если идею этих разделов в том виде, в каком они есть, невозможно представить воссозданным с помощью общего API, то у вас, вероятно, есть некоторые заблуждения, связанные с тем, что такое блок, на языке WordPress.

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

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

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

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

Или, если вы используете WooCommerce вместе с любым плагином, который ставит новую версию библиотеки Select2 в очередь, один или другой нарушит ваш интерфейс администратора с критической ошибкой JS.

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

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

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

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

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

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

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

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

Очевидно, что команда Гутенберга, связанная с Automattic, не сдвинулась ни на дюйм и отклоняет всю критику.

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

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

Automattic не «выпускает» и не «создает» WordPress, а Gutenberg не является продуктом Automattic.

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

Количество недоразумений, вызванных идеей о том, что «редактор берет на себя», огромно, и с ними должно быть очень трудно справиться. В их задачу входит создание общих строительных блоков для администратора WordPress и их проверка путем перестройки редактора. Хотя я считаю, что эта задача была бы гораздо более приемлемой и гибкой для публики, если бы они просто перестраивали интерфейс wp_editor() и расширяли его оттуда, понятно, почему все связанные компоненты «опыта редактирования» создают более полное испытание предлагаемой новой парадигмы.

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

@karmatposed

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

Тем не менее , у меня был личный чат с

@tomjn

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

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

Почему никто не может понять, почему вы не рассматриваете этот подход?

@khromov у нас уже был , и в некоторых других местах в чатах редактора и т. д. Эта проблема, в частности, касалась реализации iframe.

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

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

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

Постепенное продвижение ни в коем случае не ставит под угрозу цели проекта.

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

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

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

@gschoppe Я знаю, что в прошлом у нас была

Вы из Automattic не должны жаловаться на то, что мы не можем уважать вашу работу и что мы слишком вас подталкиваем.
Не за 7000 - 10.000 € за месячную зарплату вам платят. Глупо. Это не то, что люди жалуются на WP Trac разработчикам-добровольцам.
Если Гутенберг вызывает у вас головную боль, поговорите со своим начальником. Он дал вам невыполнимую задачу.

Во-вторых, вы намного лучше программируете, чем большинство людей, которые здесь комментировали. Почему вы пытались пропустить решение «iframe»?
Я сказал вам, вы относитесь к людям как к детям. Давайте попробуем использовать iframe и посмотрим, будут ли люди кричать слишком сильно, слишком ли эмоционально. Если много шума, мы уходим от iframe.

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

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

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

@StaggerLeee, пожалуйста,

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

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

Вы из Automattic не должны жаловаться на то, что мы не можем уважать вашу работу и что мы слишком вас подталкиваем.
Не за 7000 - 10.000 € за месячную зарплату вам платят. Глупо. Это не то, что люди жалуются на WP Trac разработчикам-добровольцам.
Если Гутенберг вызывает у вас головную боль, поговорите со своим начальником. Он дал вам невыполнимую задачу.

@StaggerLeee Я бы хотел, чтобы мне заплатили столько подсказок 😂 но Automattic - это не Google, и я могу заработать больше в другом месте в мире WP. Мое собственное присутствие здесь исключительно из моей собственной спины, мне не платят за то, чтобы я здесь, как и многие другие люди, работающие над этим. На самом деле мне платят за проверку кода и помощь в запуске корпоративных клиентов!

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

Тем, кого все еще беспокоят фреймы , я предлагаю посмотреть здесь этот запрос на извлечение (https://github.com/WordPress/gutenberg/pull/3345), который пытается отменить фреймы и реализовать мое предложение, сделанное ранее.

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