Gutenberg: Добавить блок: раздел

Мне очень нравится эта идея! Мне также нравится, что у него есть фоновая настройка.

Ницца! Что делать, если блокировка допускает три следующие «расширенные» настройки:

• Определите имя класса, которое будет сериализовано в дочерние элементы .child_class, .child_class_1
• Добавить необязательный первый дочерний класс .child_class, .child_class_1, .child_class_first
• Добавить необязательный последний дочерний класс .child_class, .child_class_n, .child_class_last

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

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

Отличная идея. Это буквально повысит ценность редактора Гутенберга.

Намного лучше, чем просто блок Columns, в котором много проблем. Круто!

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

У вас есть код для этого?

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

Пока вы не можете помещать блоки столбцов внутри блоков столбцов 😉

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

Блок раздела, который действует как голая оболочка, я думаю, был бы наиболее гибким. (как и возможность вкладывать блоки столбцов!)

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

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

Было бы здорово, если бы в этом блоке был внутренний контейнер (div), который затем содержал бы все дочерние блоки. Затем этот контейнер можно было бы стилизовать с max-width и margin-left / right: auto, чтобы центрировать дочерние блоки и иметь фон во всю ширину.

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

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

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

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

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

Кроме того, если вам нужен полноразмерный раздел со стандартной шириной содержимого, это может быть достигнуто путем вложения другого блока Section / Columns в другой, для которого задана полная ширина. Это можно сделать с помощью настройки в инспекторе, чтобы изменить ширину содержимого блока независимо от ширины всего блока .; это также может быть добавлено в виде видимых маркеров изменения размера, подобно тому, как работают строки / столбцы Beaver Builder или как блок изображения работает в Gutenberg.

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

Я передумал объединять блоки Section и Columns. Чтобы получить максимальную гибкость при работе со столбцами, было бы наиболее целесообразно, чтобы каждый столбец был отдельным блоком: блоком столбца. Это позволит легко управлять настройками отдельного столбца, а также перетаскивать столбец из одной строки в другую. Конечно, поскольку столбцы идут слева направо (и переносятся в большинстве систем макета), вам потребуется, чтобы их родительский блок вставлял контент в этом горизонтальном направлении и имел перенос (а не стандартное вертикальное направление), и это родительский блок, вероятно, позволит вставлять в него только блоки Column. Этот блок будет строкой. Эти 2 блока заменят блок Columns. Но они не охватывают ситуацию, когда вы хотите, чтобы несколько строк (часто с разным количеством столбцов внутри них) находились в одном и том же фоне / контейнере, что и делал бы блок Section. Конечно, блок Section будет не чем иным, как контейнером с параметрами фона, отступов и ширины, и в него можно вставить любой блок. А для более сложных макетов блоки секций можно вставлять в блоки столбцов.

См. №6461.

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

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

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

После некоторого обсуждения в # 6461 я решил, что моя идея блока строк + столбцов - неправильный путь. Блок Layout, подобный блоку в # 5351 (комментарий) , вероятно, был бы гораздо менее запутанным и гораздо более гибким. В любом случае, обязательно должен быть блок Section, и я думаю, что его обязательно нужно добавить до выпуска WordPress 5.0.

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

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

Я думаю, что очень важно, чтобы блок Section имел возможность настраивать количество используемых отступов или, по крайней мере, удалять отступы по умолчанию. Конечно, возникает вопрос о том, как выбрать блок Section, если в него вложен другой блок. Я думаю, что эта проблема будет решена такими улучшениями, как # 6471 и тем, над чем работают ветки try/alternate-hover-approach .

: +1:

Нам действительно нужен общий блок строки / контейнера, особенно с настройками ширины.

В идеале я думаю, что другие настройки, такие как «Цвет фона» и «Цвет текста», должны находиться на некоторых «дополнительных» вкладках настроек в каждом блоке (в дополнение к нескольким другим обычно применимым настройкам CSS).

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

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

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

@tmdesigned Он заканчивается

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

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

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

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

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

Если хотите, можете прочитать предложенный мной метод решения ваших проблем.

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

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

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

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

@tmdesigned Я ценю ваш отзыв. Я думаю, что понимаю путаницу, поэтому постараюсь прояснить.

Цель не в том, чтобы исключить или даже уменьшить количество классов CSS.

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

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

У них будут точно те же классы, что и сейчас, и у них будет точно такой же макет, как и сейчас.

НО

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

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

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

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

Редактировать примечание:

Я забыл коснуться вопроса об абстракции.

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

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

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

FWIW, мне нравится ваша идея о том, чтобы сгенерированные классы были выходными, чтобы их можно было переопределить без использования! Important.

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

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

Самый простой способ поделиться своими идеями - использовать прототип: https://wp.invisionapp.com/share/PQJPPAX4JZW

Некоторые примечания:

• Основываясь на быстром опросе: https://wordpress.slack.com/archives/C02QB2JS7/p1527283199000343 Я изменил имя с _Section_ на _Container_.
• Я удалил настройки столбца, поскольку вполне естественно, что люди захотят смешивать макеты столбцов в определенном разделе, как показано на @jvisick.
• В дополнение к цвету фона я добавил поддержку фоновых изображений. Настройки основаны на существующей функции фонового изображения ядра.
• Должны ли мы позволить людям вкладывать контейнерный блок в контейнерный блок?

@melchoyce Отлично выглядит!

Одна приятная функция, которую я хотел бы увидеть, - это выбор в инспекторе для переключения HTML-элемента блока между <aside> , <div> и <section> .

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

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

@melchoyce +1 за возможность

@SuperGeniusZeb о возможности изменить HTML-элемент тоже не

@jvisick Да, я об этом и думал. Beaver Builder и Elementor имеют такие же настройки для своих строк / секций.

@melchoyce Я считаю, что контейнеры должны быть бесконечно вложенными. Это позволит пользователям обернуть настраиваемый класс (или настраиваемый CSS) вокруг любого блока, включая другие контейнеры.

Нет причин добавлять ограничения вложенности в общий блок-контейнер.

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

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

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

Семантическое значение должно обеспечиваться (будущими) функциями шаблона блока, чтобы содержимое <aside> могло быть одной частью шаблона, а <section> другой.

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

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

Семантическое значение должно обеспечиваться (будущими) функциональными возможностями шаблона блока, чтобы содержимое <aside> могло быть одной частью шаблона, а <section> другой.

Это определенно было бы хорошо изучить.

Я не возражаю с пунктами, сделанными для сохранения простого базового UX, но затем я хотел бы спросить, куда бы вы добавили <section> , <nav> , <header> и т. Д. Элементы упаковки? Стандартный контейнерный блок, который по сути является элементом оболочки, кажется естественным выбором. Это может быть предпочтительнее дублирования блока для каждого из этих случаев. По умолчанию может быть <div> и пользователю никогда не нужно прикасаться к настройке, если в этом нет необходимости.

Что, если бы параметры для HTML-элементов работали аналогично настройкам alignwide / full, где массив поддерживаемых элементов можно было бы установить из темы или плагина?

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

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

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

Тем не менее, я согласен с @melchoyce в том, что установка HTML-элементов не требуется для первоначального запуска блока контейнера, но я думаю, что это стоит изучить на следующей фазе «построителя страниц».

Разделы по сути состоят из одной колонки ... ну, колонки.

Я заметил, что блок 3.0.0 Columns (beta) не позволяет использовать 1 столбец на своем слайдере.

Не уверен, что лучше использовать только блок Column и комбинировать эти реализации. В чем обратная сторона?

Одна вещь, которую было бы хорошо добавить, - это переключатель, должен ли контейнер (секция) быть полной ширины или содержать. Если он содержится, он должен соответствовать content_width установленному в теме (# 5650), в противном случае он должен быть полной ширины. Я думаю, что у большинства конструкторов страниц есть эта функция.

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

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

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

@melchoyce Предполагая, что я правильно вас понял, это означает, что элементы управления шириной в блоке контейнера будут влиять только на фон контейнера, а не на его содержимое? В этом есть смысл. Спасибо за разъяснения. : +1:

Ага, вот о чем я думаю!

Не уверен, что это обсуждалось, но раздел может быть элементом HTML «section», а также быть «статьей», «div» или чем-то еще, верно? Было бы неплохо иметь возможность выбора
Это также может сделать ненужным блок "row", я думаю

Реализовано в плагине

var el = wp.element.createElement,
    registerBlockType = wp.blocks.registerBlockType,
    InnerBlocks = wp.editor.InnerBlocks;

registerBlockType( 'nbrummerstedt/section', {
    title: 'Section',
    icon: 'universal-access-alt',
    category: 'layout',
    attributes: {},
    edit: function( props ) {   
        return el( 'section', {className: props.className},
            el( InnerBlocks )
        );
    },
    save: function( props ) {
        return el( 'section', {className: props.className }, 
            el( InnerBlocks.Content )
        );
    }
} );

@eddr Это обсуждалось: https://github.com/WordPress/gutenberg/issues/4900#issuecomment -392925877

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

@nbrummerstedt Хорошая начальная базовая реализация, но теперь блок <div> в качестве элемента, хотя в идеале (как упоминалось выше и в предыдущих комментариях) вы могли бы изменить HTML элемент используется от <div> до <section> , <aside> и, возможно, даже <article> .

Вот исправленная версия вашей реализации:

( ( blocks, editor, element ) => {
    const el = element.createElement,
        { registerBlockType } = blocks,
        { InnerBlocks } = editor;

    registerBlockType( 'nbrummerstedt/container', {
        title: 'Container',
        icon: 'universal-access-alt',
        category: 'layout',
        attributes: {},
        edit: ( props ) => {    
            return el( 'div', {className: props.className},
                el( InnerBlocks )
            );
        },
        save: ( props ) => {
            return el( 'div', {className: props.className }, 
                el( InnerBlocks.Content )
            );
        }
    } );
} )( window.wp.blocks, window.wp.editor, window.wp.element );

Почему это было удалено из вехи WordPress 5.0, @mtias? Это похоже на то, что, вероятно, должно войти в первоначальную версию просто из-за того, насколько это полезно и просто. У многих блоков нет настроек фона, потому что предполагалось, что для этого вы будете использовать блок Container. Этот блок не так уж и сложно реализовать, правда? Я не понимаю, почему это должно быть отодвинуто до выпуска после WordPress 5.0.

С другой стороны, я недавно проверял Oxygen и был впечатлен его системой компоновки на основе flexbox. Что, если бы блок контейнера реализовал некоторые из этих функций? Бьюсь об заклад, это могло бы быть действительно мощным и предоставить альтернативный способ иметь макеты, отличные от блока Columns ... может быть, это могло бы даже сделать блок Columns ненужным?

https://oxygenbuilder.com/documentation/visual-editing/layout-spacing/
https://oxygenbuilder.com/documentation/visual-editing/responsive-controls/

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

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

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

@ dingo-d и @ericvalois Да, я воздерживался от использования Gutenberg для чего-либо, кроме сообщений в блогах, именно из-за отсутствия трех вещей: отзывчивых столбцов, столбцов с неравной шириной и блока контейнера.

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

Конечно, есть заметная проблема, заключающаяся в том, что блок контейнера, использующий выравнивание / компоновку на основе Flexbox, не позволяет вставлять блоки с выравниванием по плавающей схеме непосредственно в него. Но я думаю, что для этого есть простое решение: добавить возможность использования контейнера в стандартном макете CSS display: block или макете Flexbox. Стандартный режим display: block будет по умолчанию, поскольку это то, что будет использовать корневой документ. При включении режима отображения flexbox все удобные параметры выравнивания появятся в инспекторе. Кроме того, вы, очевидно, захотите дать двум режимам макета другое имя в инспекторе, чтобы сделать его более удобным для пользователя. Однако я не уверен, как бы вы их назвали. Может быть «Стандарт» и «Гибкий»?

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

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

• стандартный блок контейнера, который поддерживает поплавки, но не имеет всех расширенных параметров выравнивания / макета
• блок Advanced Container (или Advanced Layout, или Flexible Layout, или как вы его называете), который использует макет Flexbox и предоставляет все удобные параметры

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

https://www.youtube.com/watch?v=NnSfR-YFcQI

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

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

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

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

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

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

На каком источнике данных вы основываете это предположение?

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

В отличие от того, что видел @ dingo-d, я использую Гутенберг только для сообщений. На самом деле я считаю, что пост-обработка в Гутенберге намного приятнее, чем в классическом редакторе. Частично из-за более модульной природы и контекстных элементов управления, а частично из-за того, что повсюду больше нет раздражающих невидимых тегов <p> . Меня это всегда раздражало.

Мне нужен блок контейнера (даже один без каких-либо опций) и достойный блок Columns (или какой-либо другой блок макета), чтобы использовать Gutenberg для создания ровных страниц. Похоже, что блок Columns получит некоторую базовую отзывчивость (см. # 6048), так что это означает, что просто отсутствие блока Container не позволяет мне использовать Gutenberg в большем количестве контекстов.

Я знаю, что блок контейнера, очевидно, будет добавлен в какой-то момент (вероятно, не позже WordPress 5.1), но я твердо уверен, что его следует добавить до выхода WordPress 5.0. Даже в контексте написания сообщений Контейнер может быть полезен для чего-то вроде <aside> (если у него есть выпадающая функция выбора HTML-элемента) для дополнительной семантики. Прямо сейчас, если вы хотите обернуть что-либо в другой элемент HTML для дополнительной семантики, вы должны использовать блок Custom HTML, что означает, что вы не можете воспользоваться преимуществами блока Paragraph ни для каких абзацев в этом блоке Custom HTML, или любые функции блока Image для любых изображений в этом блоке Custom HTML и т. д.

@karmatposed

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

На мой взгляд, блок-контейнер - это абсолютно то, что относится к первой фазе.

Что мне кажется странным, так это то, что блок Columns выглядит так, как будто он войдет в WordPress 5.0 (возможно, все еще с меткой «(Beta)», но блок Container может и не быть? Если сейчас основное внимание должно быть уделено написанию сообщений, то почему был добавлен блок Columns, но не блок Container? Блок Container, на мой взгляд, гораздо более полезен в контексте сообщений, чем блок Columns. И, конечно же, он также имеет много преимуществ в контекст построения страницы.

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

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

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

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

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

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

@SuperGeniusZeb Oxygen - это круто! Определенно стоит посмотреть на некоторые из этих исследований.

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

@tomusborne В такой ситуации есть проблема: # 7811.

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

https://github.com/marcusig/gutenberg-section-block

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

Следуя этой проблеме .. Я создал блок «Контейнер», который позволяет выбирать структуру столбцов и другие параметры.
Если это поможет улучшить блок «Столбцы» или создать новый в ядре, то он находится здесь: https://github.com/MarieComet/WP-container-block/

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

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

Я пришел к выводу, что будущее создания макетов с помощью HTML и CSS - это не всегда использовать столбцы, как большинство конструкторов страниц, но также использовать CSS Flex и Grid для отображения содержимого, используя меньше <div> s в разметки и имеют более гибкий и чистый стиль. Меня в основном вдохновляет то, что делает Oxygen. Я говорил о Oxygen в этом комментарии .

Эта проблема не связана с заменой блока столбцов прямо сейчас. Важно сосредоточиться на том, о чем идет речь, - на блоке раздела.

@karmatposed @melchoyce Кстати, нельзя ли переименовать этот выпуск? Мы перестали называть его «Раздел» и перешли на «Контейнер», чтобы не путать с элементами <section> .

Название еще не определено, так что мы все в порядке, оставим как есть ненадолго.

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

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

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

Очень надеюсь, что этой теме будет уделено большее внимание.

Я использую сторонние блоки-контейнеры повсюду (например, атомные блоки) в сочетании с блоком Columns. Они были очень полезны и стали моим самым популярным блоком. Мне кажется странным, что это будет рассматриваться позже в будущем или как дополнение; должно быть в ядре.

В противном случае я бы просто вручную создавал контейнеры в представлении HTML, однако это раздражает / неэффективно, потому что представление HTML - это дополнительный щелчок по меню. Есть сочетание клавиш для просмотра HTML ... shift + option + cmd + M ... да. И он даже не переключается вперед и назад. Повторное нажатие на ярлык ничего не дает. Чтобы вернуться к представлению WYSIWYG, вам нужно пройти через меню. Большой толстый тумблер на главной панели инструментов был бы великолепен.

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

https://editorblockswp.com/library/ есть в каталоге, но для решения этой проблемы, похоже, должно произойти что-то специфическое для разделов / контейнеров.

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

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

Кроме того, я бы также хотел иметь следующее:

• Параметры гибкого макета CSS: возможность устанавливать направление потока контента сверху вниз, влево-вправо, вправо-влево и снизу-вверх; и возможность установить вертикальное и горизонтальное выравнивание контента
• конечно, использование гибких опций несовместимо с выравниванием поплавков, поэтому у блока должно быть как минимум 2 режима компоновки: стандартный и гибкий, иначе должен быть отдельный блок Flex Container
• размер шрифта и параметры цвета, чтобы установить значения по умолчанию для содержимого в контейнере и избежать необходимости устанавливать их для каждого содержащегося блока отдельно

Феликс Арнц только что опубликовал сообщение в блоге о реализации блока раздела.
мне нравится отзывчивое фоновое изображение.
https://felix-arntz.me/blog/building-a-reusable-gutenberg-section-block/

В последние недели я экспериментировал с реализацией Marc Lacroix, которая работает нормально, но, похоже, не работает в Gutenberg 3.9.0 https://github.com/marcusig/gutenberg-section-block

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

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

У нас не так много времени на это, если мы хотим этого в 5.0.

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

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

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

Возможно, «Настройки контейнера» могут быть вкладкой рядом с «Настройки блока». Это будет (расширяемое) место, где разработчики могут добавлять (или отфильтровывать) такие вещи, как настройки фонового изображения, настройки ширины и т. Д.

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

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

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

@mikemcalister Хороший замечание, конечному пользователю все равно понадобится способ визуальной группировки / организации дерева блоков.

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

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

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

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

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

Основное колебание команды Гутенберга (в данном случае и многих других) заключается в том, чтобы снизить уровень сложности основного интерфейса до уровня Squarespace с точки зрения UI / UX.

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

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

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

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

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

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

@rchipka Очень простой способ приблизиться к этому - возможность выбрать один или несколько блоков и щелкнуть опцию «Переместить выбранные блоки в контейнерный блок» в меню «Дополнительно». Таким образом, блокам не нужна _ дополнительная_ панель настроек.

Да, блок раздела должен быть в ядре. Достаточно отрисовки простого div в HTML. Но поскольку есть буквально сотни атрибутов, которые могут быть предложены, я настоятельно рекомендую вместо этого предлагать два атрибута: CLASS и ID (причем ID является наименее важным). Таким образом элементы могут быть стилизованы в CSS там, где они должны быть.

-
Уэс Модес
Тайная история американских речных людей
http://peoplesriverhistory.us

Отправлено с моего Apple] [e

12 октября 2018 г. в 8:09 Матиас Вентура [email protected] написал:

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

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

У нас не так много времени на это, если мы хотим этого в 5.0.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

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

-
Уэс Модес
Тайная история американских речных людей
http://peoplesriverhistory.us

Отправлено с моего Apple] [e

12 октября 2018 г. в 8:40 Робби Чипка [email protected] написал:

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

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

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

Возможно, «Настройки контейнера» могут быть вкладкой рядом с «Настройки блока». Это будет (расширяемое) место, где разработчики могут добавлять (или отфильтровывать) такие вещи, как настройки фонового изображения, настройки ширины и т. Д.

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

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Я не возражаю против метода группировки (до тех пор, пока я могу назначать атрибуты класса), хотя было бы замечательно, если бы ТАКЖЕ был блок контейнера, если бы вы хотели построить таким образом.

-
Уэс Модес
Тайная история американских речных людей
http://peoplesriverhistory.us

Отправлено с моего Apple] [e

12 октября 2018 г. в 10:50 Крис Ван Паттен [email protected] написал:

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

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

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

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

Обсуждение «как мы помещаем блоки в контейнер» необходимо. Однако я не считаю, что это слишком сложно для пользователя. Многие пользователи не будут использовать его или, по крайней мере, не будут использовать его за пределами своей домашней страницы. Многие из наших клиентов и заказчиков тем выражают желания / потребности своих веб-сайтов в визуальных терминах, подходящих для блока раздела. Они говорят что-то вроде: «Мне нужна большая {bar / area / section / block / panel / span} полная ширина с красивым изображением», за которым следует «и {вставьте сюда запросы контента} в этом разделе». Они визуально понимают, что сам раздел (контейнер) отделен от содержимого внутри него.

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

@chrisvanpatten Мое предыдущее утверждение основано исключительно на семантике типов блоков.

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

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

@rchipka это не то, как я интерпретировал его комментарий - я

Тем не менее, я более чем счастлив ошибаться :)

@JiveDig Я полностью согласен ....

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

Это моя единственная основа для выдвижения этих аргументов и представления этих идей.

Опять же, если бы это был я, у нас был бы просто чертов контейнерный блок.

Я не думаю, что блок-контейнер действительно имеет смысл, поскольку он загромождает пользовательский интерфейс. Я бы предпочел увидеть что-то вроде маркера «Разрыв раздела», который вы видите встроенным в Microsoft Word. Добавление разрыва раздела предложит некоторые параметры стиля в инспекторе, такие как имя класса для раздела, цвет фона, цвет текста, тень, все, что стилистически определяет ваш раздел. Его можно было вставить как любой блок и перемещать как любой блок.

@rwrobe Эта идея не работает для вложенных контейнеров.

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

• «Раздел» - лучшее название для блока. Его смысл понятен разработчикам и конечным пользователям, и он позволяет избежать усложнения разметки / параметров за счет логического использования блока <section>.

• Единственные необходимые параметры контекстного меню - это alignnormal / wide / full (на самом деле я использую только alignfull). Выравнивание не влияет на внутренние блоки, которые остаются в пределах нормального выравнивания, если у них нет собственных параметров выравнивания. Основным вариантом использования было создание выровненного цвета фона, содержащего текстовый блок с нормальным выравниванием - очень распространенный шаблон проектирования, который в настоящее время невозможен.

• Единственные необходимые настройки блока боковой панели - это цвет фона и фоновое изображение (с соответствующими параметрами фиксированной / непрозрачности). Любую дополнительную настройку можно выполнить с помощью специального класса CSS. (Включение параметра фонового изображения также имеет побочный эффект превращения его в гораздо более полезную версию блока обложки.) (Но: если @mtias прав, избегая этого разговора, только включив параметр цвета фона, это поможет дверь быстрее, тогда я полностью за.)

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

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

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

@mikedance Я думаю, это именно то, что нужно. Хотя ИМО был бы важен вариант фонового изображения. Возможно, этот блок мог бы заменить тогда блок-обложку, хотя такое название может не подходить для людей, которым _только__ нужно фоновое изображение с основным текстом поверх него. Хотя есть некоторые совпадения в функциональности, но это уберет большой процент вариантов использования для блока Section без добавления поддержки изображений bg.

@rwrobe Следует отметить, что вы можете располагать блоки горизонтально. Блоки Column (обратите внимание на отсутствие "s") - это просто блоки. Блок Columns размещает их по горизонтали. Пользовательский интерфейс, вероятно, можно было бы улучшить в некоторых областях, но блоки не ограничиваются полной шириной или вертикальной компоновкой.

@mikedance

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

блок.

Поскольку элемент <section> имеет присоединенную к нему семантику, было бы лучше, если бы вы могли использовать <div> а не <section> , поскольку во многих случаях вы хотите обернуть несколько блоков, но они семантически не являются частью раздела. На самом деле, было бы даже лучше, если бы вы также могли использовать такие элементы, как <aside> или <header> , последний особенно полезен для добавления семантики к заголовкам с фоном при построении страницы.

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

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

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

@ZebulanStanphill @wmodes Я сомневаюсь, что включение опции выбора содержащего элемента когда-либо пройдет мимо основных разработчиков. Это слишком сложное дело. С определенной точки зрения элемент <section> является настолько семантическим, насколько это возможно, потому что пользователь уже определяет его как «Раздел» на основании создания блока. Они должны использовать его ответственно, как заголовки. Но если бы это позволило избежать аргумента семантики, у меня не возникнет проблем с использованием <div>.

@mikedance Согласен, мы, вероятно, должны просто использовать <div> . Если семантический макет вызывает беспокойство, его лучше всего рассматривать как расширение блока контейнера.

@strarsis Themes могут использовать существующий API стилей блоков для добавления стилей в блоки. (Базовый блок Button и Quote по умолчанию включает несколько вариантов стилей.) К сожалению, я не могу найти никакой документации по этой функциональности. (Существует несколько проблем с отслеживанием текущего отсутствия документации: https://github.com/WordPress/gutenberg/milestone/500)

@mikedance

С определенной точки зрения

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

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

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

Основная причина, по которой я хочу иметь возможность выбирать тег HTML, заключается в том, что он позволяет вам более легко создавать семантические страницы и сообщения, не прибегая к использованию блока Custom HTML или плагинов, которые добавляют пользовательские блоки. Если вы хотите использовать тег <section> в Gutenberg прямо сейчас, вам придется поместить все в этом разделе в пользовательский блок HTML, что приведет к потере возможностей визуального редактирования таких вещей, как абзацы, списки и т. Д., Которые вы было бы иначе. Возможно, переключатель тегов можно было бы отобразить в группе «Дополнительно» в инспекторе?

@strarsis @ZebulanStanphill

Вы можете найти документы для добавления Block Styles в справочнике в разделе расширяемости https://wordpress.org/gutenberg/handbook/extensibility/exnding-blocks/#block -style-changes

@ajitbohra Спасибо! Я проверял эту страницу несколько раз, но почему-то пропустил этот раздел. :смеющийся:

@ajitbohra : Спасибо! Есть ли, кстати, демонстрация вариантов блочного стиля Гутенберга?

@strarsis

Да, проверьте основные button и quote block

https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/button
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/quote

@strarsis Блоки pullquote , table и separator также имеют различные стили:
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/pullquote
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/separator
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/table

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

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

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

@JiveDig

что, если бы блок Cover был скорее «конфигурацией» в том смысле, что когда вы добавляете этот блок, он действительно добавляет предварительно сконфигурированный блок раздела с вложенным в него блоком заголовка или текста / абзаца?

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

Будет ли форк для тестирования нового блока раздела / контейнера? Мне интересно поиграть с ним и помочь его протестировать.

Блок контейнера / раздела очень полезен, мне пришлось использовать
Контейнерный блок Advanced Gutenberg Blocks пока что.
И важно, чтобы блок раздела / контейнера был легко видимым и доступным для выбора.

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

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

Это было решено в PR № 12406 (выше).

Рассматривается ли блокировка разделов для версии 5.1 (намечено на 21 февраля 2019 г.) или более поздней версии?

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

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

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

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

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

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

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

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

Вложенные блоки должны иметь возможность легко ссылаться на родительские атрибуты по умолчанию. Если ваша цель состоит в том, чтобы блоки не отображались на стороне сервера, за исключением редких случаев, такая передача контекстной информации _ должна происходить_, иначе render() станет пустошью return null как нового и полезного но появляются сложные блоки.

(Я думаю, что блок columns был бы более полезным, если бы он реализовал [все еще экспериментальное] свойство CSS columns . По сути, это был бы специальный тип section , включающий все элементы внутри него и передача их через свойства столбца, определенные в инспекторе: column-width , column-count , column-rule и т. д.)

есть ли дата выпуска для этого типа блока (Добавить блок: раздел)?

@JQOz Нет. Эта проблема входит в план действий для следующих версий мэра, но люди не работают над открытыми запросами на

Привет,

Я думаю об этом не один раз. Раздел должен быть контейнером во всю ширину. Можем ли мы просто добавить желоб к контейнеру внутри секции и заставить их работать как add_theme_support('alignwide') или нет.

На случай:

https://tech.cornell.edu/

У нас много разных разделов. Некоторые из них живы в контейнере. Некоторые нет. Но всем им нужен единый контейнер.

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

Когда я занимаюсь разработкой https://www.luminasolar.com/ , я должен заключить их в ключ template чтобы сохранить структуру.

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

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

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

По сути, это единственная отсутствующая функция, которая заставляет меня держать elementor на моих сайтах ...

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

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

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

Блок раздела ДОЛЖЕН находиться в ядре Gutenberg (и быть настраиваемым и расширяемым по темам), чтобы, наконец, решить проблемы, связанные с возможностью выкладывать более сложные страницы и при этом иметь возможность переключать темы.

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

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

Панели инспектора

• _Background._ Мой плагин позволяет при желании установить цвет фона и / или изображения, с элементами управления для размещения изображения, смешивания, уменьшения насыщенности и даже наложения цвета.
• _Размеры, отступы, поля._ По умолчанию, разделы автоматически увеличивают высоту до содержимого и подчиняются полному, широкому и центральному выравниванию с левым и правым уголками 45%. Тем не менее, я добавлю элементы управления, чтобы разрешить указанную ширину и / или высоту, заполнить внутренние блоки и поля вокруг блока. _Но проблемы с Гутенбергом см. Ниже.
• _Columns ... и Rows._ После множества экспериментов с использованием flex, CSS _grid_ для непосредственных дочерних элементов - лучший метод для использования, если вам нужен макет на основе столбцов. Использование сетки - это переключатель; в противном случае дочерние элементы - это просто обычные блоки. (Честно говоря, хотя строки выполнимы, они добавляют большую сложность к интерфейсу редактирования, что лучше всего можно сделать, добавив новый раздел ниже того, над которым вы работаете, когда вам нужно начать новую строку.) Сетка превосходит flex - даже если вы просто делаете столбцы - потому что flex _requires_ определенную непроцентную высоту, которая должна быть установлена ​​либо для контейнера, либо для дочерних элементов, что снижает гибкость.

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

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

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

Columns:        3,2,1,1
Column 1 width: 70%,50% 

И т.д. (Очевидно, что отдельные столбцы составляют 100%, и их не нужно указывать).

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

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

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

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

Проблемы Гутенберга
Итак, Гутенберг плохо справляется со следующим:

• Блоки, которые необходимо стыковать вертикально, что иногда может быть необходимо.
• Любой вызов для отображения чего-либо в виде гибкости или сетки. Из-за супа div редактора вам нужно отключить вызов CSS на grid или flex в оболочке внутренних блоков и сбросить его в одном из блоков редактора.
• Выровнять по левому краю и по правому краю. Я сообщил об этом ошибку, но поскольку Гутенберг не ограничивает плавающее положение левого или правого блока только непосредственным потомком блока, имеющего атрибут данных left или right (или center), все последующие вложенные блоки перемещаются влево или вправо. правильно.
• Добавление новых блоков часто является полной загадкой, куда они будут вставлены ... вы думаете, что находитесь в нижней части своего раздела, и вам нужен новый внутренний блок, а вместо этого редактор вставит его в конец вашего документа.
• Модель перетаскивания Гутенберга для движущихся блоков не работает надежно с блоками, которые могут иметь горизонтальное положение.

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

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

@rogerlos Вам стоит взглянуть на блоки Kadence . Кажется, они довольно хорошо обрабатывают столбцы на основе flexbox.

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

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

Вот демонстрация того, как блок Row Layout от Kadence повторно использует «Режимы выравнивания» на панели инструментов блока, чтобы обеспечить три разных ширины внутреннего содержимого, регулируемую ширину столбцов, регулируемые поля верхней / нижней строки, а также настройки цвета фона и текста.

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

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

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

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

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

Элементы контейнера также должны позволять наложение элементов слоя (z-index).
Это позволяет, например, использовать видеоэлемент или слайдер в качестве фона или эффект параллакса.

@strarsis Хорошая идея.

В идеале блок раздела должен использовать z-index для обеспечения переключаемого режима редактирования переднего плана / фона.

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

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

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

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

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

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

Что касается контроля разработчика: есть плагин Mesh, который предоставляет "жесткие" контейнеры,
что должно быть вызвано темой.
Иногда тема должна ограничивать доступные области, например только верхний левый угол всей страницы.
Gutenberg должен предоставить темам механизм для установки этих «жестких» контейнеров внутри редактора страниц.

@strarsis На мой взгляд, все, что происходит за пределами области the_content() не имеет отношения к редактору Гутенберга.

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

Контент страницы и шаблон страницы (/ макет)

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

Элемент является частью шаблона страницы ( а не содержимым страницы ), если:

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

Некоторый опыт, основанный на опыте

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

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

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

Итак, наконец

Определение (и возможная реализация) раздела должно распространяться только на то, чтобы удовлетворить потребности шаблонов проектирования темы, поскольку они относятся к the_content() .

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

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

Пару дней назад я хотел создать базовый макет, и мне это было нужно. Итак, я начал с установки плагина A, попробовал, обнаружил ошибки. Деинсталлировал, нашел плагин B, установил, попробовал его блокировать, получилось baaad. Следующий плагин C глючил, плагин D назвал его контейнером, и это было meh. Следующий плагин E, F .........
Я могу заверить вас, что нынешняя «экосистема» Гутенберга очень, очень разочаровывает, если вы хотите создать страницу и написать контент.
Тот факт, что здесь люди продолжают говорить «посмотрите на плагин X», «если вы хотите, чтобы эта функция установила плагин Y» и т. Д., Является явным признаком того, что людям это нужно. Они этого не хотят, им это нужно . Прямо сейчас есть дюжина плагинов, каждый из которых имеет собственную реализацию контейнера / раздела / как угодно называть это.
Я не говорю, что Гутенберг должен добавлять все функции под солнцем, но это базовая. Это должно быть там. Необязательно иметь все мыслимые возможности, но основы должны быть в наличии, и разработчики могут при необходимости расширить.
Мы приближаемся к точке, когда будет 20 различных реализаций для базового контейнера, и ни одна из них не будет работать должным образом (личное мнение, конечно).

В качестве простой альтернативы я просто использовал блок столбцов и установил количество столбцов на 1 (ползунок ограничен от 2 до 6, но вы можете ввести 1 в поле ввода). После этого нужно исправить CSS в админке:

//Allow single columns
add_action('admin_head', 'gutenberg_allow_single_columns');
function gutenberg_allow_single_columns() {
    ?>
    <style type="text/css">
    <strong i="6">@media</strong> (min-width: 600px) {
        .wp-block-columns.has-1-columns > .editor-inner-blocks > .editor-block-list__layout > [data-type="core/column"] {
            flex-basis: 100% !important;
            flex-grow: 0; } }
    </style>
    <?php
}

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

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

@strarsis Это определенно нужно было сделать с самого начала.

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

Например, без упаковки каждой строки сложно и хакерски создавать разделы разной ширины (особенно разделы с полной шириной).

Я также рассматривал вариант синтаксического анализа PHP, но понял, что он не дает редактору контента никакого контроля над типом раздела, в котором находится конкретный фрагмент контента.

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

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

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

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

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

Видеть:
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

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

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

Спасибо! С уважением.

Да, совершенно верно. Я считаю, что это даже более важно, чем все остальные блоки, которые сейчас разрабатываются. @youknowriad Разве ты не можешь уделить этому больше внимания?

Он уже находится в рамках фазы 2 https://github.com/WordPress/gutenberg/issues/13113, если кто-то хочет попробовать, сделайте это.

@youknowriad Боюсь, я не разработчик. Но я помню, что разработка уже велась. Незадолго до выпуска Wordpress 5 был уже очень продвинутый PR. Осталось уточнить детали, но он был почти готов. К сожалению, я больше не могу найти PR. Кто-нибудь знает, где это?

Да не волнуйтесь, я понимаю.

Вот и пиар. https://github.com/WordPress/gutenberg/pull/10562

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

Я повторяю, что если есть разработчики, которые хотят, чтобы это происходило быстрее и хотят помочь, их ждут еженедельные собрания в канале Core Slack # core-editor (и собрания), где они обсуждают / сотрудничают / просят о помощи.

Аххх да вот оно что! Большой! У вас есть обзор !!!

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

Пожалуйста, поймите неправильно: вы делаете отличную работу. И вы, как руководитель фазы 2, делаете первоклассную работу. Все дело в фокусе. Я подниму тост в следующем чате ... ;-)

Еще раз большое спасибо!

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

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

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

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

Спасибо! С уважением.

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

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

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

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

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

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

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

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

Даже не могу поверить, что его еще нет ...

В качестве альтернативы можно было бы разрешить блоку столбцов иметь только один столбец, а также разрешить установку цвета фона для столбцов. TA-DA: секционный блок.

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

https://github.com/Impuls-Werbeagentur/impuls-section-block

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

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

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

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

Например:

<div class="wp-block-paragraph">
  <div class="wp-block-paragraph__container">
    <InnerContent />
  </div>
</div>

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

<ol>
  <li></li>
</ol>

К этому можно добавить обертку:

<div class="wp-block-listing">
  <div class="wp-block-listing__container">
    <ol>
      <li></li>
    </ol>
  </div>
</div>

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

// Example
#content > * > * {
  max-width: 1280px;
  padding: 0 20px;
}

@talldan, не
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

Блоки секций были бы замечательными, но сделайте их только семантической разметкой! Хранение вещей в семантической структуре HTML создало бы самую независимую базу кода.
<section>, <article>, <header> намного лучше <div class="wp-section"> или что-то еще.

@talldan Извините, я пропустил ваш комментарий, но я на 100% согласен с тем, что вы взяли это на себя 🙌 Я уверен, что вам это понравится!

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

Отличная вещь, которая, кстати, есть и у многих конструкторов страниц. Или хотя бы что-то вроде этого:

Договорились, что здесь было бы здорово выбрать фокус. Очень хорошо работает в блоке обложки!

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

Предварительный просмотр :

Вы можете ознакомиться с прототипом здесь .

Некоторые дополнительные примечания:

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

Я согласен, фоновое изображение можно добавить с помощью css, если это необходимо на данный момент: +1:

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

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

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

Ницца! Было бы полезно иметь классы small / medium / large для вертикального заполнения.

Ницца! Было бы полезно иметь классы small / medium / large для вертикального заполнения.

Это относится к уровню темы / фреймворка, и я не уверен, есть ли в ядре место для чего-нибудь вроде https://cdn.vaadin.com/vaadin-lumo-styles/1.4.1/demo/sizing-and-spacing. .html

Думаю, для начала надо запустить его без фонового изображения

Не могу с этим согласиться. Получите v1, а затем v2 может добавить более сложные функции.

Этот блок не будет содержать никаких адаптивных настроек

Согласен - этот блок должен быть максимально простым и бесхитростным.

Думаю, если возможно, надо объединить этот пиар .

Меня поразило что-то вроде этого ... выпущенного как плагин:

https://wordpress.org/plugins/magic-block/

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

@webdados Я

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

Особенно в мире, где есть такая проблема .

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

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

Когда мы можем ожидать эту функцию?

Уже должно быть в последней версии:
https://github.com/WordPress/gutenberg/releases/tag/v5.5.0

@ksere : Я пропустил это, вероятно, потому, что журнал изменений для v5.5.0 плагина пуст .

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

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

• Добавление внутреннего контейнера для упрощения стилизации - https://github.com/WordPress/gutenberg/pull/15210
• Добавление параметров редактора для группировки / разгруппировки выбранных блоков - https://github.com/WordPress/gutenberg/pull/14908

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

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

Я только что установил WordPress 5.2.4 и не могу найти ни одного блока «Раздел» или «Группа». Что тут происходит?

@patrikhuber : это будет включено в WordPress 5.3, который в настоящее время планируется выпустить 12 ноября.

@noisysocks Понятно , большое спасибо!