Аналіз підходів для створення лендингов і лонгридов в Drupal

image
У статті порівнюються актуальні рішення для створення неоднорідних публікацій і лэндингов, а також лонгридов в адміністративному інтерфейсі CMS Drupal. Під неоднорідністю розуміється можливість для впровадження в текст в довільному місці довільних інтерактивних елементів, таких як медіа-врізок, списків релевантних матеріалів, опитувальників та інших нетекстових елементів. Наведено авторський топ на основі аналізу 16 критичних параметрів.
Будь-хто, хто досить часто розробляє сайти на Друпалі, рано чи пізно стикається з необхідністю надати редакторам зручний інтерфейс для створення і редагування так званих «багатих» сторінок-історій або лендингов: сторінок зі складною внутрішньою структурою, макетом, інтерактивними елементами, внутрішньої навігацією і персоналізованими блоками.
При цьому один лендінгем або історія можуть зовсім відрізнятися від інших як за змістом, так і за структурою, використовуваним фоновим зображенням і набору вже згаданих елементів.
Серед прикладів інструментів для створення повноцінних міні-сайтів не з світу Drupal можна відзначити комерційні сервіси, такі як Weebly, Wix, які пропонують в деякому роді порівнянні з вимогами можливості, а також платні плагіни для Wordpress типу Visual Сомроѕег Qards або Beaver Builder.
В самому Drupal за останні роки сформувалося неабияку кількість підходів для реалізації необхідної функціональності, які в тій чи іншій мірі задовольняють інтуїтивно ставлять вимогам: «щоб був вау-ефект», «ось зробіть, як у цих». І так як варіантів, як це все зробити, то виникає великий головний біль — нарешті визначитися: що ж вибрати? Якщо всі вони, в принципі, дозволяють досягти результату...
Інтуїція інтуїцією, але потрібен якийсь нормальний зважений підхід. Адже, може за сукупністю критеріїв, якщо їх розглянути окремо, з'явиться явний лідер? Можна спробувати, тільки потрібен визначитися, які критерії взагалі існують у природі для подібних інструментів.
Якщо поміркувати, то можна здогадатися, що-далеко і ходити не треба. Виходячи із сучасних вимог до CMS цілком можна виділити підгрупу вимог до інструментів для створення глибоко кастомізованих сторінок або лендингов, так як, по суті, вони є міні-сайтами, або сайтами сайті з-за великої відмінності від решти сторінок.
Дотримуючись цього спостереження, використовуємо для аналізу і порівняння підходів наступні критерії (відсортовані за важливістю в порядку зростання, виходячи з власного досвіду, тобто суб'єктивно):
  1. Якість реалізації (відповідність стандартам Drupal, наявність документації, потенційна розширюваність сторонніми модулями, в загальному випадку DX);
  2. UX (зручність використання адміністративного інтерфейсу);
  3. Темизируемость і адаптивність (можливість гнучко та уніфіковано створювати і редагувати шаблони, необхідні зусилля з темізаціі з нуля до прийнятного виду);
  4. Інтернаціоналізація та локалізація (підтримка декількох мов);
  5. Підтримка ревізій і модерації (можливість «відкочуватися» до попередніх версій матеріалів; підтримка чорнових версій);
  6. Підтримка Drupal 8;
  7. Функціонал з-коробки (кількість стандартних елементів, блоків, списків тощо);
  8. Конфігурованість і розширюваність (кількість налаштувань, поточна розширюваність сторонніми модулями);
  9. Продуктивність (зі сторони адміністративного інтерфейсу і з боку звичайних відвідувачів сайту);
  10. Абстрагируемость виводу (можливість фонового у відмінних від HTML форматах);
  11. Семантичний висновок (мікроформати, підтримка RDF, доступність для людей з обмеженими можливостями);
  12. Контроль доступу (підтримка ролей і прав доступу);
  13. Довідкова інформація та документація (а також рівень наданої або потенційної підтримки в разі появи проблем);
  14. Повторне використання (можливість клонувати сторінки, групувати і переиспользовать макети);
  15. Тестованість (наявність готових автоматичних тестів, а також можливість для написання нових);
  16. Експортованого (можливість для експорту та імпорту сторінок).
Підходи
При розгляді альтернатив нижче основою упор робиться не на перерахування їх основних можливостей, а на виділення ключових факторів, що впливають на ту чи іншу оцінку, і мають безпосереднє значення при їх зіставленні з підходами, що займають сусідні місця в рейтингу.
Панелі
image
Напевно, самий «древній» інструмент для створення сторінок-лендингов в Drupal, основний компонент якого — модуль Panels — веде свою історію аж від Drupal 4.7.
З вбудованою системою контекстів, варіантів, генератором макетів, своїми кеш-плагінами, модуль давно є комбайном, без якого досить складно було уявити створення неоднорідних сторінок. Сама кількість налаштувань і можливостей настільки величезна, що якщо включити їх опис в дану статтю, за розміром воно більше буде самої статті.
Функціонал модуля значно розширюється за допомогою Panelizer, що дозволяє обробляти через панелі довільні ноди, розділяючи монолітне утримання на частини, розміщуючи його в різні колонки, і багато іншого.
Для створення довільних текстових секції на сторінках знайшли своє застосування модулі Bean або Fieldable Panels Panes, які додали можливість упорядкувати їх наповнення і використовувати звичайні поля замість єдиного спочатку можливого textarea.
Існує кілька варіацій даного підходу. Спільним є використання модулів Panels і Panelizer.
  1. Fieldable Panels Panes
  2. Beans
В Drupal 8 потрібне використання додаткових модулів: Page Manager, Layout Plugin.
Саме вражаюче демо даного підходу можна виявити в модулі Panopoly.
Серед додаткових модулів, що розширюють функціонал і застосовуються досить часто, можна виділити:
  1. FPP Bundles
  2. Drupal Panels Preview
  3. Panels Everywhere
Переваги:
  1. Гігантська екосистема модулів
  2. Величезну кількість налаштувань для керування видимістю елементів
  3. Велике число активних користувачів
Недоліки:
  1. Перевантажений інтерфейс
  2. Дещо ускладнена локалізація
  3. Слабка підтримка ревизионности
Вкладені поля і сутності
Field Collection, Multi-field
image
З'явився в 2010 році модуль став справжнім проривом, адже він дозволив повністю переосмислити структурування вмісту в Друпалі, без потреби використовувати чудофищные милиці у вигляді серіалізовать даних. До його виходу, як правило, всі дані, що відносяться до полів, зберігалися безпосередньо в таблиці значень (або ревізій) поля. Тобто одне поле в бандл — один віджет — один форматтер — і нескінченність однотипних значень.
(З сериализованными даними все було трохи простіше — так модулі Flexifield і Composed Field дозволяли, принципово, з одного поля отримувати кілька інших, але за це доводилося розплачуватися неможливістю нормальної вибірки або фільтрації за вкладеним полів за допомогою тих же Views. Хоча хто знає, може, ці модулі отримають друге життя у вигляді появи в MySQL 5.7 JSON datatype).
Але що робити, якщо за змістом значення поля насправді компонентно? Наприклад, вартість, де крім значення вартості фігурує валюта, або вагу, де крім значення ваги фігурує одиниця виміру.
Все це дозволив робити модуль Field Collection, який, по суті, дав можливість використовувати поля всередині інших полів.
У наш час, модуль раніше активно використовується не тільки для створення згаданих комбо-полів, але й для створення нескінченно вкладених структур вмісту. Що, однак, можна сміливо порекомендувати не робити, зважаючи на наявність більш гнучкою наступній альтерантивы в огляді.

Переваги:

  1. Зрілість рішення
  2. Велика кількість безкоштовних модулів, що розширюють функціонал
  3. Бурхливий розвиток 8.x гілки з використанням Inline Entity Form

Недоліки:

  1. Неможливість створення варіантів вмісту без «милиць» (наприклад, для підтримки омниканальности)
  2. Неможливість вибирати альтернативний пакет для кожного нового значення поля
  3. Відсутність можливості для повторного використання
Paragraphs
image
Модуль Paragraphs з'явився в 2013 році пізніше Field Collection, і, по всій видимості, був створений, щоб виправити одну фундаментально відсутню можливість колекцій — здатність довільно вказувати різний бандл для кожного доданого значення поля. Функціонал, спочатку є лише крайнім випадком використання колекцій, приводив до жахливих милиць, якщо розробники намагалися почати використовувати колекції не для зберігання однорідних вкладених даних, а скоріше для створення складно структурованих сторінок.
Незважаючи на вражаючі можливості, даний підхід тільки останнім часом почав отримувати підвищену увагу.
Чудовою примочкою до параграфів є модуль Paragraph Panes, який дозволяє створювати параграфи прямо в панелях. Серед найголовнішою особливості — це те, що створені таким чином елементи не є сутності, а лише конфігурацією даної конкретної панелі. Це означає, що якщо ви панелизируйте деяку ноду і додасте у довільні місця Paragraph Panes, то ви з коробки отримаєте підтримаю ревизионности не тільки для ноди, але і для абзаців у панелях.

Переваги:

  1. Величезна гнучкість у створенні вкладених матеріалів
  2. Можливість використання в панелях у вигляді конфігурації
  3. Відмінна підтримка від спільноти

Недоліки:

  1. Неможливість створення варіантів вмісту без «милиць» (наприклад, для підтримки омниканальности)
  2. Відсутність візуальності (наприклад, нормально показаної вкладеності) при редагуванні
  3. Неможливість переміщати вкладені параграфи до іншим батькам
Inline Entity Form
image
Як відомо в Друпалі легко можна зробити полі-посилання на довільні сутності за допомогою модуля Entity Reference. Але, що робити, якщо суті, на яку ми плануємо посилатися, поки не існує в природі? Правильно! Її потрібно створити (кеп). І для цього необхідно перейти на іншу форму. Ввести всі значення там, зберегти результат. Повернутися на форму матеріалу, де планується зробити посилання. Знайти необхідну сутність і натиснути кнопку "Зберегти". Начебто Все чудово, тільки дій реально 100500.
Дана проблема непогано вирішується за допомогою модуля Inline Entity Form.
IEF є досить старим модулем, що з'явилися аж у 2011 році, для одночасного редагування поточного матеріалу, а також матеріалів, на які поточний матеріал посилається чи буде посилатися.
Тим не менш, вбудовані в Drupal сутності (ноди, терміни таксономії тощо) не зовсім підходять для завдань зберігає структурованих даних, так як вони мають "придане" у вигляді спеціального контролю доступу, купи сторонніх хуков, які реагують на будь-які дії і багато чого ще.
Благо в друпалі існує Entity API — інтерфейс, що дозволяє створювати власні довільні сутності, реалізувавши кілька спеціальних хуків. Модуль Entity Construction Kit ж є інструментом, який дозволяє легко створювати свої типи сутності з довільним набором полів, віджетів і форматтеров, не вдаючись до програмування взагалі.
Тепер для зберігання невизначено вкладених структурованих даних не вистачає тільки одного — можливості вибирати довільний бандл суті, на яку дається посилання. Нещодавно ж з'явився модуль під назвою посилань сутності Dynamic Bundle як раз і дозволяє це робити. Це означає, що в одному полі можуть зберігається посилання не тільки на різні сутності, але і на довільні бандли цих сутностей.
Об'єднавши ж всі ці три модуля разом можна отримати цікаву суміш, що нагадує по функціоналу модуль Paragraphs, тільки більш абстрактну, яка дозволяє отримати надзвичайно потужний функціонал для компонування довільної структури даних з попередньо створених атомів (сутностей, створених за допомогою ECK).
При цьому, на відміну від параграфів, є можливість для повторного використання створених одного разу секцій. Якщо ж до всього цього добра прикрутити додатково модуль Inline Entity Form Preview, то отримаємо ще додатково функціонал превью.

Переваги:

  1. Високий рівень абстракцій, який дозволяє розширювати функціонал, запозичуючи модулі з найбагатших екосистем навколо кожного з трьох ключових модулів (так як ці модулі незалежні).
  2. Можливість повторного використання сутностей.
  3. Проблеми з продуктивністю при редагуванні великої кількості сутностей одночасно.

Недоліки:

  1. Велика кількість модулів для реалізації необхідного функціоналу. Якщо на один з ключових компонентів спільнота «заб'є», то буде проблема з підтримкою.
  2. Кілька перевантажений інтерфейс.
  3. Далеко не всі портировано на Drupal 8.
Примітка. Існує також модуль Bricks, що складається всього з 200 рядків коду, і заснований на вже згаданих модулях ECK і IEF. Даний модуль дозволяє розподіляти згадані сутності по колонкам, а також надає інтерфейс з коробки для установки CSS-класів. Bricks могли б цілком претендувати на те, щоб бути повноцінною альтернативою, якщо ми не полумертвое стан і надзвичайно мала кількість установок.
Макет і вміст у текстовому полі
Віджети CKEditor
image
Звичайно, ніхто не забороняє взяти і написати довільний HTML в текстовому полі Body, щоб зробити лонгрид або лэндинг, але чи зможе це зробити людина, яка його не знає? І чи є взагалі сенс витрачати на це години, а то і дні?
З іншого боку, існують візуальні редактори, такі як TinyMCE або CKEditor. Які прагнуть зробити все «як у word'і». Досить просто впихнути таблицю… На жаль, все знову ж виходить зовсім не так просто.
кожен, хто активно працював з даними редакторами, знає про одну типову для них «хвороба»: невдало нажатый backspace, не так зроблене копіювання, і все — існує багато що перевищує нуль ймовірність просто поламати верстку. Іноді безнадійно (щоб виправити, доведеться лізти в HTML).
Вирішити цю проблему покликаний Widget інтерфейс API, пару років тому з'явився в редакторі CKEditor (редактор нині вбудований в Drupal 8). Використання Widget API дозволяє створювати коректно переміщувані і скопійовані комплексні секції, які інтерпретуються редактором як єдине ціле.
З іншого боку останні роки в веб-розробці так чи інакше пов'язані з бурхливим становленням CSS-фреймворку Bootstrap, який дозволяє елементарно верстати складні макети, багато в чому використовуючи лише спеціальне іменування класів.
І поява спеціальних Bootstrap-сумісних віджетів в CKEditor було лише питанням часу. Так і сталося.
На даний момент, цілком придатним, хоча і сируватим, підходом є використання модулів CKEditor Bootstrap Bundle, CKEditor Bootstrap Library, CKEditor Widgets, для додавання ряду кнопок і функціональних можливостей, покликаних максимально полегшити користувачеві створення складних макетів в текстовому полі за допомогою візуального редактора.

Переваги:

  1. Велика наближеність до кінцевого результату в плані попереднього перегляду
  2. Довільне перетягування елементів
  3. Прекрасна підтримка ревізій, переказів та модерування (за інкапсуляції вкладеної структури в текстовому полі)

Недоліки:

  1. Все одно залишилася ймовірність «поламати» верстку
  2. Мала бібліотека з Drupal-елементів з коробки
  3. Неможливість гнучко оперувати з окремими інкапсульованими елементами на рівні DrupalAPI
Шорткоди
image
Як відомо, в Друпалі досить довгий час є така концепція, як токени (інакше шорткоди в деяких інших системах), яка по своїй суті дозволяє динамічно замінювати спеціальні послідовності символів у тексті в квадратних дужках на довільні дані. Наприклад, [current-user:name] за замовчуванням замінюється на ім'я поточного користувача.
З іншого боку — одинарні токени або шорткоди — це далеко не всі варіанти використання спеціальних квадратних дужок. За допомогою пари подібних токенів (відкриваючих і закриваючих) цілком можна виконувати логічну розмітку вашого тексту, щоб не вдаватися до безпосередньої верстці складно-структурованого тексту за допомогою HTML.
В якості прикладу можна розглянути використання шорткодов для позначення колонок, наприклад, окресливши необхідний текст [col] [/col]. Достатньо лише реалізувати конверсію токенів у відповідні їм теги з певними класами і стилями, наприклад, фреймворку Bootstrap. Начебто все чудово. Якби не одне «але».
Реальність така, в Друпалі використання шорткодов одержало набагато менший розвиток, ніж в тому ж Wordpress'e, і тому практично всі існуючі готові рішення не можна назвати дійсно потужними в плані інтегрованості з самим Друпалом.
Хоча використання шорткодов дозволяє, в принципі, взагалі не використовувати візуальні редактори, типу CKEditor, або звести їх використання до мінімуму, що для ряду користувачів (наприклад, тих, хто не любить gui) може бути досить серйозною підмогою.
Для іншого табору користувачів, які все-таки хочуть мати зручний візуальний інтерфейс для компонування складних макетів (наприклад, многоколоночных без використання таблиць) у візуальному редакторі, існують готові рішення, такі як модуль VCL (нехай і сируватий, і тільки для Drupal 8), а також Drupal Visual Shortcodes, які надаючи зручний інтерфейс і щодо багату бібліотеку елементу, під капотом все одно використовують ті ж шорткоди.

Переваги:

  1. Непогана розширюваність
  2. Альтернативний інтерфейс верстки складних макетів
  3. Прекрасна підтримка ревізій, переказів та модерування

Недоліки:

  1. Текстовий інтерфейс далеко не всім подобається (в принципі, нівелюється використанням утиліт для візуального редагування)
  2. Практично всі наявні рішення поки «сирі».
  3. Неможливість оперувати з окремими інкапсульованими елементами на рівні DrupalAPI
Власні рішення
MD AweContent
image
MD AweContent є комерційним рішенням для компонування складних сторінок. Поширюється через Codecanyonи стоїть на момент написання статті 32 долара США. У вартість включається підтримка протягом 6 місяців, яка, проте, не включає в себе будь-які доопрацювання напилком, хоча і обіцяється допомога з виправленням помилок.
Серед примітних особливостей можна відзначити досить оригінальний drag & drop інтерфейс, а також збереження макетів і даних в серіалізовать вигляді спеціальної таблиці.

Переваги:

  1. Оригінальний і досить зручний інтерфейс для редагування
  2. Багаті візуальні можливості по управлінню зовнішнім виглядом
  3. Можливість повторного використання елементів

Недоліки:

  1. Погана підтримка інтернаціоналізації, ревізій та модерації
  2. Неможливість гнучко контролювати доступ до елементів
  3. Відсутність підтримки Drupal 8
Drag & Drop Builder
image
Drag & Drop Builder також є комерційним рішенням, поширюваним через Codecanyon. Ціна продукту на момент написання статті становить 28 доларів. У вартість включається підтримка протягом 6 місяців, яка, проте, не включає в себе будь-які доопрацювання напилком, хоча і обіцяється допомога з виправленням помилок.
Серед примітних можливостей можна відзначити оригінальну реалізацію на основі полів Drupal, які зберігають серіалізовані дані.

Переваги:

  1. Зручний drag & drop інтерфейс з підтримкою довільної вкладеності
  2. Підтримка Drupal 8
  3. Реалізований експорт та імпорт

Недоліки:

  1. Малу кількість елементів з коробки
  2. Рідкісне оновлення для комерційних продуктів
  3. Недостатньо хороша якість коду
Azexo Composer
image
З'явився в 2014 оригінальний платний компонувальник сторінок тепер доступний абсолютно безкоштовно для завантаження на GitHub'e.
Серед особливості можна виділити реалізацію за допомогою фільтра, підтримку шорткодов, а також те, що весь макет і дані зберігаються в редагованому текстовому полі.

Переваги:

  1. Безкоштовне drag & drop рішення
  2. Хороші презентаційні можливості
  3. Непогана підтримка Bootstrap

Недоліки:

  1. Погану якість коду
  2. Відсутність підтримки Drupal 8
  3. Відсутність оновлень
Carbide Builder
image
Підхід, заснований на використанні візуального редактора Carbide Builder, є, на даний момент, одним з найбільш помітних гравців на ринку комерційних модулів і тем для Drupal.
Частково успадкувавши від Azexo Composer функціонал і інтерфейс, в Carbide Builder привноситься ряд значних поліпшень в плані наявних можливостей і елементів з коробки. Як і в Azexo Composer, весь макет зберігається безпосередньо в текстовому полі.
Модуль поширюється разом з темою з комерційною версією теми Glazed і на момент написання статті становить 48 доларів США в рік на один домен.

Переваги:

  1. Велику кількість компонентів і готових шаблонів
  2. Інлайн редагування в Drupal 7
  3. Підтримка Bootstrap 3

Недоліки:

  1. Відсутність підтримки Drupal 8
  2. Перевантажена верстка
  3. Незручність редагування на мобільних пристроях
Результати
У ході суб'єктивної оцінки розглянутих альтернатив виставлені бали (за шкалою від 0 до 5) по кожному з критеріїв, і розрахований сумарний зважений результат, який враховує відносну важливість кожного з критеріїв окремо:
  1. Paragraphs (3.68 бали)
  2. Glazed, Carbide Builder (3.65 бали)
  3. ECK, Inline Entity Form (3.63 балів)
виставлені оцінки по кожному з критеріїв, а також повний список результатів, наводяться спеціально, щоб не спровокувати спорів з концептуальних питань)
Таким чином, за сукупністю 16 критеріїв, переможцем став модуль Paragraphs, а також основані на ньому підходи, що непогано корелює зі зростаючим до нього глобальним інтересом.
На даний момент, параграфи в сукупності з модулями Panelizer і Mini Panels дозволяють робити справжні чудеса в плані гнучкості компоновки даних з практично нульовим рівнем необхідного програмування і витрат часу. Якщо кінцевим користувачем розроблюваного сайту будете ви або інші користувачі, знайомі з Друпалом, то кращого підходу зараз складно підшукати. найщасливіша людина від використання даного підходу — сайт-білдер і розробник дистрибутивів.
Щодо інших підходів дуже важливо відзначити, що розрив між альтернативами — практично мінімальний, і те, чи інше місце може визначаться на основі 1-3 критеріїв. Що, втім, і пояснюється велика варіативність у використовуваному інструментарії в даний час.
Якщо ж ваш сайт орієнтований на малий бізнес, блог або щось подібне, або якщо ж вам критичний «вау-ефект» для продажу і кінцевий користувач вашої системи жодного разу не сайт-білдер, або у вас просто немає якесь бажання щільно займатися підтримкою ресурсу, то тим краще, в першу чергу звертати увагу на платні модулі і теми, засновані на повноцінному прикручуванні Bootstrap 3 до текстових полів і мають модним інтерфейсом. найщасливіша людина від використання даного підходу — нетехнічний фахівець, який працює з сайтом, дизайнер або маркетолог.
І, нарешті, у випадку, якщо розробляється рішення є зовсім складним і великим у плані залучених ресурсів, контролю доступу, мікроформатів, персоналізації, локалізації і т. п., то цілком доцільним може виявитися використання підходу, що зайняв друге місце, на основі вкладених сутностей і ECK. Хоч і доведеться якось вирішувати проблеми, пов'язані з продуктивністю і кілька недружнім UX для авторів. найщасливіша людина від використання даного підходу — керівник або архітектор складного продукту з великими ресурсами.
Як можна, з деяким подивом, зауважити, панелі, як самостійний і основний інструмент для створення лендингов і лонгридов, повністю випали з топа. Хоча і продовжують активно застосовуватися в якості допоміжного "напилка", в основному із-за наявності панелайзера. Багато в чому це відбулося із-за деякої монстроподобности версії для сімки, відсутності версійності, нормальної роботи з мовами, а також неповороткості в плані UX. Але в плані перспективи, і особливо якщо враховувати останній зрушення в плані UX у версії для вісімки, при належних зусиллях спільноти цілком можуть у нього тріумфально повернутися. Під найбільшою загрозою при цьому виявляться, як не дивно, переможець — параграфи — так як попит на максимальну абстрагируемую архітектуру і легкий візуальний вау-інтерфейс буде, напевно, завжди.
А зробити абстрактний вау-інтерфейс до текстових полів набагато простіше і вигідніше (вважайте WYSIWYG 2.0), ніж зробити такий же інтерфейс прив'язавшись до структурованих даних. Незважаючи на те, що текстові блобы з боку інформаційної архітектури — це жахливо. Так як в першому випадку практично відсутнє обмеження на використання в межах якоїсь конкретної CMS, а — прив'язка є скоріше на конкретний фронтендовый грід-фреймворк.
Автор висловлює величезну подяку Віталію Кузьменко за незамінну допомогу при роботі над даною статтею.

А що ви використовуєте у своїй роботі в якості основного інструменту для створення лендингов?

/>
/>


<input type=«checkbox» id=«vv72512»
class=«checkbox js-field-data»
name=«variant[]»
value=«72512» />
Панелі
<input type=«checkbox» id=«vv72514»
class=«checkbox js-field-data»
name=«variant[]»
value=«72514» />
Параграфи
<input type=«checkbox» id=«vv72516»
class=«checkbox js-field-data»
name=«variant[]»
value=«72516» />
Шаблони і віджети у візуальних редакторах
<input type=«checkbox» id=«vv72518»
class=«checkbox js-field-data»
name=«variant[]»
value=«72518» />
Колекції полів
<input type=«checkbox» id=«vv72520»
class=«checkbox js-field-data»
name=«variant[]»
value=«72520» />
Шорткоди
<input type=«checkbox» id=«vv72522»
class=«checkbox js-field-data»
name=«variant[]»
value=«72522» />
Редагую шаблони
<input type=«checkbox» id=«vv72524»
class=«checkbox js-field-data»
name=«variant[]»
value=«72524» />
Комерційні рішення
<input type=«checkbox» id=«vv72526»
class=«checkbox js-field-data»
name=«variant[]»
value=«72526» />
Панелайзер (в доповнення до панелей)
<input type=«checkbox» id=«vv72528»
class=«checkbox js-field-data»
name=«variant[]»
value=«72528» />
Вкладені сутності
<input type=«checkbox» id=«vv72530»
class=«checkbox js-field-data»
name=«variant[]»
value=«72530» />
Власні рішення

Проголосувало 13 осіб. Утрималося 11 осіб.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.