 Вот говорили про Advanced Custom Fields. Есть в зале те, кто не знает, что это такое. Ок, я видел одну руку. А из тех, кто сейчас не поднимал руки, есть те, кто постоянно используют возможности этого плагина. Иииии. Давайте рассмотрим, что же это за возможности такие. Вот, я буду стараться лазером там, туда-сюда светить. Что нам дает Advanced Custom Fields плагин? Он дает возможность создавать огромное количество метод данных, использовать их, создавать их очень быстро, использовать их в абсолютно любых сущностях внутри WordPress, это касается и всех постайпов, всех постов, это касается пользователей, это касается таксономии, меню, всего чего угодно. Опции можно создавать. Вот. И все это можно делать очень легко. Более того, Advanced Custom Fields сделан разработчиками для разработчиков. И у вас есть отличная API, отличные легкие PHP-функции, которые вы можете вставлять в любое место в вашем исходном коде и таким образом получать доступ к тем самым методанным, которые были легко созданы. Что касается базы знаний, которые есть у этого плагина. Это огромная база знаний с хорошим описанием всех типов полей, которые существуют. Также есть хорошая документация по функциям, хорошая документация по хукам и отличный портал для взаимодействия разработчиков плагина с комьюнити. Ещё, когда я лично говорю про Advanced Custom Fields, я всегда подразумеваю именно про версию этого плагина, потому что именно в про версии есть огромное количество классных функциональных фич. Это и repeatable-field, и всякие разные, и flexible-content, которые позволяют нам заменить пейдж-билдеры, как бы мы их с вами не любили, конечно же. И очень классная фича — это те самые блоки для Gutenberg, о которых мы с вами сегодня будем говорить. И, конечно же, клон-филды, которые позволяют уменьшить нагрузку на базу данных. Ну, и многое-многое другое. Рассмотрим мы с вами пример обычного таймлайна. Таймлайн этот есть у нас на сайте. Такой таймлайн можно сделать абсолютно любыми методами, если вы там front-end, back-end разработчик. Но мы с вами рассмотрим парочку, или можно сделать благодаря Advanced Custom Field Down. Так, тут немножко кинематографа. Извините, анимация не сделала. Значит, мы с вами перемещаемся на машине времени в прошлое. Машиной времени для нас служит плагин, который позволяет деактивировать Gutenberg, и попадаем вот в такой простецкий и интуитивно понятный интерфейс Advanced Custom Fields Plugin. Все действительно просто, понятно, очень напоминает Google таблицы. И с точки зрения того самого User Experience, о котором я тоже немножко должен рассказать в этом докладе, это не очень хорошо. Advanced Custom Fields Plugin позволяет нам добавлять CSS-селекторы, менять расположение блоков и расстояния между ними, их ширину, их размеры. Но, как правило, добавлять стили в админку не так просто, а вот эти вот штуки, которые встроены, они приводят к тому, что интерфейс не намного лучше становится. У нас получается большое количество вайт-спейсов, ну и ожидания, соответственно, не совпадают с реальностью. При этом есть код. Есть в зале те, кто любит спагетти, пасту. Окей, а спагетти код кто-то любит? Понятно, есть один человек. Понимаете, за что это за понятие? Ну, по сути, это простыня кода. Это когда у нас есть, например, какой-нибудь Single PHP или просто там PHP-HP, и в которой мы пишем огромное количество кода. Надеюсь, что в 21 веке никто это не делает, и все используют так называемые template-parts. То есть мы приходим к вот этой блочной или модульной разработке. Сами по себе template-parts — это просто PHP-шаблон, немножко HTML или немножко PHP. Есть возможность работать с ворпрессовскими глобалями, со всеми встроенными функциями самого ворпресса и плагинов. И, по сути, все, ничего сложного, правда? Я ждал, ждал, что кто-то скажет, да. Что еще можно сказать про ICF, да? Мы же с вами эволюционируем еще немножко кинематографа. Есть такая штука flexible content. Существуют ситуации, в которых клиент хочет использовать page-builder, а вы не хотите использовать page-builder, у вас есть огромное количество наработок, там template-parts, и вы говорите, ну, типа, нет, никаких биверов, ничего такого. Хочу свои template-parts. В этом случае flexible content призван вам помочь, потому что вот это вот небольшое отличие в интерфейсе, маленькое такое, оно на самом деле очень значительное, потому что вот эта вот кнопочка, она позволяет вам добавлять любые блоки, в любом порядке их выстраивать и создавать любое их количество. Таким образом, если у вас есть какой-то template-part на странице, вы можете его повторить множество раз. Сам по себе template-part почти не меняется. Это мы говорим о коде. Единственное, что field-methods заменяются на sub-field-methods, потому что вводится такое понятие, как layout или элементы layout, которые, в свою очередь, надо перебирать в цикле. Но если у вас большое количество блоков на странице или на сайте в принципе, то тот случай, который нам предлагают документации с if-else'ом или с which-case'ом, он не очень подходит. А если у вас нет проблем с naming'ом и с расположением с файлов внутри темы, то гораздо проще работать через цикл, через вот такую вот структуру. То есть вы парсяте информацию самого блока и подставляете это незамысловатыми стрингрейплейсами в... конвертите это просто в имя файла. И получается так, что вы вот в эту папочку с template-part'ами добавляете все свои template-part'ы и, собственно, все, используйте это. Идем дальше. Эволюция эта штука хорошая. Появился у нас с вами наконец-то Gutenberg. Наконец-то кто-то разделяет еще мое мнение про наконец-то. Е-е, класс. Что собой представляет Gutenberg? Ну, на самом деле очень много хайпа было развито вокруг Gutenberg, и автоматик и самообщество постарались на тем, чтобы было много информации. Но на самом деле низкий старт не оказался, давайте с вами быть откровенными, таким вот уж радужным и классным. Что мы имеем? Gutenberg, на самом деле, вот как киберспортсмены любят говорить, это новая эра там или новая мета. Он действительно реализован с использованием новых технологий там. Есть Next, Syntaxis, React.js подобные компоненты, использование REST API. Автоматик и сообщество вообще молодцы. Сначала у нас появилась REST API, потом появилась Kalypsa, а теперь вот этот вот React-Based Editor Content. Ну, классно. При этом есть явная такая вот позиция в мире, что популярность джавоскрипта растет, а популярность PHP. Давайте быть откровенными немножко спадает. На рынке все меньше вакансий, заказов и всего остального. Новшество, которое как бы нам преподносит Gutenberg, это построение всего на блоках. Надо писать как можно меньше кода или вообще его не писать. Пользуйтесь стандартными блоками, вам этого хватит. Ну, каким-то с обычным модератором сайтов возможно. Нам с вами этого не хватает. При этом есть документация. Не самое подробное на сегодняшний день, я вынужден об этом сказать. Мы с вами будем работать на тем, чтобы она улучшалась. И, в принципе, все то, о чем мы говорили с вами в ACF, построение блоков, template-part и прочее, Gutenberg нам дает новый интерфейс для взаимодействия со всем этим. Моя любимая часть доклада. Значит, эта штука называется HypeCycle. Это специальная разработка американской компании Gartner. Компания занимается консалтингом и всякими исследованиями в области рынка информационных технологий. О чем говорит нам вот этот HypeCycle? Любая новая технология, она проходит определенные этапы до становления своей зрелости, так называемой. Критерии вот эти вот всякие штуки, которые, да, написаны на этом графике, характеризуют уровень интереса к этой самой технологии. Гартнер, к сожалению или, к счастью, не проводило исследований про Gutenberg. Ну, я в всяком случае не нашел. А мы с вами здесь же не зря собрались, мы сейчас проведем с вами исследование такая большая научная коллегия Colloquium. Значит, что такое Innovation Trigger? Это тот момент, когда создатели какой-то технологии генерят большое количество информации о этой самой новой технологии и привлекают большое количество участников из сообщества для того, чтобы развить много шумихи вокруг этой самой технологии. У разработчиков получилось. Они много рекламы нам давали на этот счет. Они вводили сам плагин как отдельный модуль, до того, как перешли на версию WordPress 5. И таким образом, технология попала на так называемый пик завышенных ожиданий. Наступил 2019 год версия WordPress 5. Все получили доступ к исходному коду, начали делать свои блоки и посыпалось огромное количество всего. Багов, рекомендаций от гигантов индустрии тем и плагинов о том, что погодите, давайте пока не использовать Гуттонберг, подождите там марта, февраля всего остального, пока Гуттонберг станет лучше, пока мы научимся с ним работать, ну и вы, соответственно, тоже научитесь с ним работать. Вот. И Гуттонберг скатился вот в этот момент разрушения иллюзий, и мы с вами сейчас призваны, и Гуттонберг на самом деле сегодня находится вот как раз на вот этом вот подъеме, маленькая анимация, классно, научился делать анимации. Вот. Именно это сегодня является проблемой, и мы призваны с вами эту проблему решить. До сих пор есть люди, которые старонятся, Гуттонберга, хоть все эти гиганты нам сказали, все, чуваки, можно, давайте использовать, давайте работать в этом направлении, но все еще есть консервативные люди, типа меня, наверное, тоже, которые говорят, что создание Гуттонберг блоков это сложно. Давайте разберемся, что мы видим. Регистрация скрипта, да, там его название, зависимости какие-то новые у нас появились. Создание скрипта, ну, регистрация, я имею в виду, стилей, и непосредственно, регистрация самого блока, где мы указываем namespace, чтобы вам это тоже было, ребята, видно. Вот. Ну, и непосредственно, подключаем эти стилей скрипты. PHP-код, хуки, обычное подключение стилей, ну, все как раньше, никаких проблем, да? Ровно до того момента, как мы заходим в самый главный файл, тут в код можете даже не вникать, это очень сложно. Это JSX-файл, да, который написан по ESNext-формату, с использованием такого синтаксиса, в нем есть фрагменты HTML, в нем есть какой-то большущий джевоскриптовый объект, со своими свойствами, методами, пробсами, какими-то стейтами, все очень страшно и сложно. И надо, чтобы это все как-то прикрутилось и заработало, какой-то бабель, какая-то прагма, какие-то вот эти вот страшные слова, а я, ну, я бекент-разработчик. Для меня это все по сей день, очень страшные вещи. Есть в зале те, кто так же думает? Еее, вот вы моя целевая аудитория сегодня. Суть в том, что, чтобы я дальше не говорил, как бы мы с вами не упирались, все равно нам придется учить вот этот вот джевоскрипт, который набирает популярность, пробовать, переквалифицироваться. Для нас больше возможности на рынке откроется, и с точки зрения появления новых клиентов, и с точки зрения появления новых рабочих мест. Но это все равно сложно. Чтобы я вот дальше в слайдах вам не показывал, не рассказывал, вы все равно должны понять, что вы к этому должны прийти. Я призываю вас встаньте и идите, и это надо будет делать. Но ACF с версией 5.8 с этими тремя буквами у нас чуть комфортнее. Диалог идет, да. ACF, топчик, лучший плагин в мире, окей. ACF с версией 5.8 предоставил нам возможность создавать Gutenberg блоки с нулями, вот этими большими нулями, строчек джевоскрипт-кода. То есть с джевоскрипт-кода у вас остается только тот интерактивчик, который вы прикрепляли темплейт-партом. Темплейт-парты остаются теми же самыми, я их даже тут не показываю. А сами Gutenberg блоки создаются очень просто. У нас есть ACF.init.hook функции регистрации самого блока с теми самыми параметрами, которые мы потом в админочке видим. И, так как у нас все хорошо с неймингом и расположением файлов внутри темы, у нас есть просто маленькая функция, которая является каубеком для отрисовки вот этого самого блока. И она у нас одна для всех блоков, потому что имя блока соответствует имени файла и все такое. Понятно это, да? Окей. Как выглядит сам блок? Опять-таки, не вникайте в код. HTML, PHP, никакого джевоскрипта. Единственное, что у нас появляется новое, это доступ к вот этой вот блок переменной. То есть это массив с параметрами самого Gutenberg блока, который мы только что зарегистрировали, создали. Все. Но это все о коде. Также лучше, да, без джевоскрипта. Чуть, ну, спокойнее. Окей, я вижу лайкосики. Вот. Что в админке? В админке ну, моё мнение, беда. Если туда не влезти, ничего не сделать, беда. Почему беда? Узенький Gutenberg редактор. Кого бесит узенький Gutenberg редактор? Вот. И сайтбарчик, да? Но у нас как бы интерфейс тот же самый. Та же типа Google Sheet, но и появился возможность превьюшки смотреть, да? Как выглядят превьюшки? Привьюшки выглядят вот так. Вот наш, значит, интерфейс редактирования полей, да? Видно там, ребят. Вот. И тот же узенький Gutenberg. И вообще не похоже на то, что мы должны увидеть на фронте. Помните, да, там один из первых слайдов был таймлайн красивенький, шрифты, картинки, SVG-шки, вот это вот всё. Чего-то не хватает. Часто вы своих клиентов балуете стилями в ВП-дэш-борде. Ну, окей, за деньги не вопрос. Есть древняя профессия, которая за деньги тоже радует людей. Вот. Но всё-таки нечасто, да? Простите, ребят, но это диалог. Всё хорошо. В чём суть? С Gutenberg'ом придётся работать со стилями в админке. Причём маленький спойлер, вы на него смотрите, я дальше пошёл. Если вы вспомните, как раньше можно было добавлять стили в админку. Есть хук, админ, скрипт, да, который позволяет подключать стили, скрипты в админку, редактировать, делать там всякие свистелки, всякие интересные штуки, анимации и прочее. Что надо помнить, когда мы работаем с этим хуком? Надо помнить о том, что есть такая штука, какая идит скрин, и надо определять, на каком идит скрине мы находимся. Определять, какой сейчас глобальный стиль, который запущен, и рестриктить там всякие меню и прочее, чтобы всё нормально работало. Беда, да, капец, я понял. Вот, и там пост-стайп. В общем, всё-всё-всё очень сложно. Что появилось в новой версии World Press, вот появился хук NQ Block Assets, который в свою очередь позволяет прикреплять, привязывать, регистрировать стили только в тот момент, когда запущен Gutenberg, а перед этим вы можете зарестриктить Gutenberg для тех или иных пост-стайпов, отдельным хуком, просто в PHP-коде, да, говорили там, что только в JavaScript можно отказаться от компонентов, можно в PHP отказаться от компонентов, спасибо ACF'у. И помимо этого вот этот хук NQ Block Assets, сразу же эти же стили выгрузят на фронт, если этот блок там будет для этой страницы. Есть проблемы с кишированием, с тем, что много эсетов на одной странице. Но это всё решаем, и я об этом в рамках этого доклада не расскажу, но если вопросы будете задавать, я буду там пару идей предложить. Ну и собственно всё. Теперь наша админка выглядит почти, блин, очень плохо видно, что не рассчитал с контрастом картинок, но поверьте мне на слово, стили те же самое, это не фотошопка, говорил предыдущий спикер, админка выглядит точно так же, как и фронт офис, при этом есть интерфейс. Что мы сделали, помимо подключения стилей этого template-парта, мы расширили один берк и расширили чуть сайт-бар. Ну, нельзя было этого не сделать. И собственно всё. Клиент доволен, у него такая великолепная реакция, разработчик в принципе тоже, потому что мы отживоскрипта ушли, но можно ли что-то улучшить? О, секундочку, ребята. Нет, не лучше. Ну ладно. Но всё равно, мы можем так, да? Такая интимная обстановка на своём. Вот, улучшить всегда можно, что-то есть, вот эти вот цитаты великих людей. Все помнят, что такое иерархия шаблонов, и как создавать template-страниц. Там всё сводится к тому, что должен быть один комментарий в начале файлика, там template-name и погнали. Что если мы позаимствуем вот эту механику и попробуем автоматизировать создание Gutenberg-блоков? Мы добавим вот этот вот комментарий, в начале файлов, в котором будут все параметры Gutenberg-блока, дальше весь код мы добавим такой, какой он есть. И сделаем небольшой скриптик. Этим потом можно будет, наверно, где-то как-то поделиться, но что нам с вами надо знать? Есть вот такой PHP-Build-in, то есть встроенный класс-директор-итеретер, который позволяет читать директории, все файлы из директории. Помимо этого есть встроенная WordPress-функция GetFileData, который читает первых 8-киллабайт файла, и методанные разбитые по строкам, позволяют читать. Мы это все спарсили, смэпили, и сделали регистрацию блока через вот эти вот массивчики, которые мы спарсили и смэпили. И таким образом, каждый раз, когда мы в директорию, с нашими template-partами добавляем новый файл с правильным комментариям, у нас автоматически создается ECF-блок. И все. И больше ничего не надо делать. Никакого джевоскрипта. Джевоскрипт это вот я уже говорил, наверное, или нет. Я хотел точно сказать, что для меня в джевоскрипте есть что-то. JQuery, работа с RESTAP, и ну, там, не знаю, пару каких-то мультистеп-форм на Vue.js написанных. Ну и хватит. Это уже современные технологии. Вот. В принципе, с магией все, можно в шапочке из фольги снимать, у нас с вами должны быть ну, как вывод, да, из любого докладу, у нас с вами должны быть какие-то next steps. Как я уже сказал, учить esnext, и вообще пиджевоскрипт. И Gutenberg компоненты создавать через React, через Javascript, как положено. Это надо делать за этим будущее. От этого мы никуда не денемся. Создание компонентов влечет за собой создание огромного количества field grope. Помните, да, что-то в админочке, там, такие штуки для создания template parts. Если их будет много, их надо будет как-то группировать. Мы должны с вами помнить о том, что field grope это мы можем к нему прилепить таксономию. Таким образом, это все группировать, выравнивать. Помимо этого, мы можем облепить этот весь процесс хуками, создавать автоматический field grope, помимо Gutenberg блока, парсить оттуда esf.json, сразу получать строготипизируемый массив со всеми филдами. И все будет круто. Помимо этого, у нас можно все это, как первый спикер говорил, обернуть в класс и сделать из этого таз для ввп-кли. И у нас полноценный генератор кода внутри WordPress. Ну, и это всего лишь несколько идей, которые у меня в голове появились, когда я готовил этот доклад. Надеюсь, у вас появится еще больше идей. И мы с вами все сделаем, что вот по тому графику, Gutenberg как можно быстрее поднялся, вот эта платопродуктивность. Я вам всем говорю большое спасибо. Пока мы будем дискутировать, я оставлю слайд с информацией, который вдохновлялся автор этого курса. Ну, здесь есть два варианта. Есть вот так вот скринс с ссылочками, а есть большущий QR-код. Вам что лучше оставить? QR-код. Если не будет читаться, потом скажете, я переключу слайд. Спасибо большое за внимание. Моя задача была в вас вселить надежду о том, что Gutenberg классно и все-таки можно какой-то смуз переход делать без этой ступеньки на ESNext. И жду ваших вопросов. Спасибо. Где там микрофончик? Все дела. А там же трансляция, наверное, для этого надо. Да, Юр, привет. Отлично, супер. Вопрос там, где ты подключал вот эти кастенные стили для блоков. Получается, вы отдельно пишете стили под админку и на фронт? Нет, нет, подключаю. Это просто как сейчас показываю. Это просто пример кода, как было раньше и как стало сейчас. Файл и тот же. Ну, просто здесь разные. Получается, в админку грузится те же стили, которые на фронте. Я предвижу, наверное, вопрос следующий. Если мы используем какой-нибудь Bootstrap, Foundation, какие-нибудь Framework, с этим могут возникнуть проблемы, потому что надо как-то рестриктить то, что принимает в себя Gutenberg, то есть сделать какой-то контейнер для того, чтобы стили Framework работали нормально в админке, вот в этом месте. Но если Framework есть стили, компонент, стили-компонент, то никаких проблем нет. Просто в классическом редакторе, там в самом редакторе есть стили, которая цепляется, кажется, через Important или через Edition for Body, кажется. Все говорят о том, что есть проблемы с этим, но когда мы работаем с ICF, там почти не используются эти дефолтные input и дефолтные selector, они есть только у врапера. И когда мы забрасываем стили внутрь в рапера, ICF их принимает в себя и он подпрасывает в темплейт-парт, который мы ему скормили PHP-шный. Поэтому те стили, которые работают для этого темплейт-парта, они как бы изолированы от всех остальных selector и ничего перебивать, ну там минимум перебить надо, но это какие-то, ну типа как Reset CSS для всего Gutenberg. А получаются стили, которые идут на весь сайт, они не влияют на стили самого Gutenberg, ну самого этого редактора. Ты имеешь в виду стили типа для хедера, футера, сайбара, все стили, которые на фронте, ну естественно они будут влиять, если мы их подключим, мы хитрим, мы их не подключаем, то есть все general стили, они у нас в отдельном файле они грузятся только на фронт, через NQ скрипт, как раньше, а те, которые касаются этих компонентов, мы их добрасываем, и все, таким образом вот как бы все навели порядок, разбрасывались. Понял, спасибо. Блин, так мало вопросов. Окей. Спасибо большое за доклад информацию. Тоже начал с минус там полгода назад вот это все делать, и самое вот охиле своя пятам, мне кажется, в этом всем процессе это начупать, ну как-то найти метод, как можно, здесь у нас переключен Gutenberg в режим просмотра, и он нам не разрешает по сути редактировать контент, то есть мы должны пользоваться панелькой справа. Было бы круто, вот мой собственный вопрос, там есть ли уже какие-то наметки или идеи, или как-то может добавить функциональность КЦФ, чтобы можно было право скрыть, и прокатировать сразу здесь. И менять текст просто здесь, то есть, чтобы инпуты появились. Чтобы JS, вот этот Next, понимал, что сразу нужно запулять. Такая фишка уже есть вместе с этими ICF-блоками, и я, к сожалению, про нее подробнее не могу рассказать, но я кинул контакты этого мальчика, который автор всего детища. Я эту штуку видел, это работает, но, правда, у нас там была обычная сайтла, бэкграундом, сделана на ICF, и там вместо просто поля был инпут, и это можно было делать. Еще секундочку, еще одну штуку я не сказал, в template-парте для Gutenberg, который, вот, я говорил, не меняется никак, ну, допустим, вот этот возьмем. Помните, я говорил о том, что есть такая типа placeholder data у Gutenberg, то есть то, что они используют. Для того, чтобы это работало с использованием ICF-блоков, тут достаточно тернарненький, просто там, где мы get field, the field делаем эту штуку, тернарненький добавили, и вот это и будут данные по дефолту. Следующий вопрос. Я все тема не вникал, поэтому хочу узнать, а сам контент сборигается в кастомных полях или уже в середине всего контента? Сам Gutenberg вообще? Нет, сами блоки, а это в блоке Gutenberg. ICF-блоке Gutenberg, они представляют с собой всю ту же старую структуру, то есть в базе часть преобразовывается и получается тот шаблон, который из template part, он потом попадает к конвертации есть, то есть если мы посмотрим исходники, конвертация в JavaScript, Waste Next, она все равно есть. Из-за этого есть еще одна проблема, когда много полей на странице, которые сделаны именно через ICF и сервер слабенький, то часть компонентов будет в прилоде висеть, потому что много коннектов в базу, и пока ICF не оптимизировал этот момент, либо оптимизировал, но надо еще на более слабых серваках с этим поработать. Это проблема, то есть пока это все сделано таким небольшим велосипедом, но это все равно хороший вариант смуз-перехода для старых back-end разработчиков. А теперь как бы ты в ситуации, когда в тебе ACF и плюс WPML и там, допустим, 20 мов? Хороший вопрос. Ну легче всего увеличить производительность для базы это всегда с WPML-ом работает. Но есть хороший вариант использовать вот этот вот тип поля-клон который есть в ACF, для того, чтобы мы уменьшили количество обращений в базу и увеличили, соответственно, количество обращений в cache, который в JSON или просто в cache в глобальном WPML лежит, для того, чтобы мы уменьшить коннекты к базе. Тогда это все получится чуть оптимизировать и улучшить. Но вот этот процесс конвертации, к сожалению пока от этого уйти не получится. Окей, а яйка с штукой, который может конвектоваться, допустим в visual-композер на вот такие блоки? Я на текущий момент да, разработчики, правильный ответ. Я на текущий момент, ну, мы искали что-то подобное мы искали что-то подобное не нашли, и это как бы тоже одна из идей, которую я не написал не внес в слайд. Для Gutenberg было бы неплохо сделать то, что сделали ребята из команды предыдущего спикера, то есть существующих блоков побольше налопатить и добавить по дефолту и юзать их. И таким образом, как бы получится вот из visual-композера все сконвертить. Опять-таки, если ACF научились конвертить обычные template-парты вот в эти компоненты джевоскриптовые, то сконвертить то, что сделано шорт-кодом тоже не будет большой проблем. Надо просто выявить, ну, что парсить, во что мэпить, связать это и, скорее всего, получится опять-таки один какой-нибудь цикл автоматизированный сделать и сконвертить. Надо просто заняться этим. Есть еще вопросы? Ну ладно. Здравствуйте. Скажите, чем Gutenberg лучше, чем Builder? Чем Gutenberg лучше, чем Builder? Хороший вопрос. А какой именно Builder? Любой. Окей. Я честно субъективно скажу, я Builder не люблю. Многие в зале наверняка тоже не любят Builder, потому что есть огромное количество s, это в которой грузится на фронте, огромное количество какой-то непонятной логики, но вроде как для конечного пользователя это flexible, для разработчика это не flexible. И в этом плане Gutenberg, из-за того, что над ним все-таки большая команда работала, и ребята понимают о том, что потом с этим надо будет работать конечным они стараются сделать простой унифицированный подход. И если мы с вами опустим наше не знание джавоскрипта современного, то создание блоков, оно не сложное. Это гораздо легче делать, чем создавать блоки в visual композировать с вот этими шорткодами, бесконечными, пробрасываниями, параметров и всего остального. В элементаре я его считаю лучшим из пейч-билдеров, существующих на сегодняшний день. В элементаре это все чуть круче, реализовано, там ООП, бекенды, все интересные штуки, но все равно как уже говорили сегодня, за Гуттенбергом будущее и интерфейс, на самом деле, хоть и сырой пока, но он довольно простой. Этим, собственно, лучше пейч-билдеров. А зачем нам поддерживать Гуттенберг, если он лишает нас работы? Зачем тогда, когда-то там Wix придумали, все остальное? Но как бы это другой рынок? Я не знаю, ответ как-то вот конкретно на это. Я понял, с какой идеей, с какой глобальной мыслью был задан этот вопрос, но не знаю, можно не поддерживать искать своих клиентов на рынке. Но, если мы хотим идти в ногу со временем, не пользоваться старыми версиями, там, плаги, на фрешении всего остального, а идти вот в свет с чем-то новым, использовать композитор для того, чтобы деплодировать вот пресс, как dependency, просто и прочее, прочее, прочее, то всем новым надо пользоваться, но как бы мы это делаем, это круто, и есть на западном рынке клиенты, которые подвержены маркетингу, это у нас с вами фейсбучек, и Гутенберг не продается, как вот, ну, покупайте сайты на WordPress, и Гутенберг лучше всех. За бугром это есть, и если там человек услышал, чтобы Гутенберг это плохо отставить, Гутенберг это хорошо, и он пришел в ваше агентство и говорит, сделайте мне сайт на Гутенберге, а вы не умеете, вы потеряли клиента. То есть тут как бы, мне кажется, конверсии будет еще меньше, чем просто ничего не делать, не поддерживать Гутенберг. Бизнес такие процессы уже у нас уже пошли сайт, но окей, там в кулуарах если что подходите, задавайте вопросы, будет интересно пообщаться, всем большое спасибо.