Для размещения статей предусмотрены варианты:
- картинка слева, текст справа
- картинка слева обтекаемая текстом
- текст между 2-мя картнками
и т.п.
Думаю использовать paragraphs, т.к. неудобно заставлять юзеров набивать дивы в текстовых полях.
Поэтому вопросы:
- Модуль относительно новый. Есть подводные камни?
- На сайте уже есть контент в поле типа текстовая область (Количество значений: Неограничено). Можно как-то конвертировать это поле в параграфы?
Комментарии
1. Модуль появился в 2013 году, установлен на почти 96 тысячах сайтов. Чего ещё надо то? Камней нет. По сути это тот же филд колекшн, только без глюков.
2. Конвертировать можно. Написать батч и прогнать через него все ноды.
Вопрос, нужно ли это. Большой минус такой организации контента в том, что если это статья, то текст связанный, но будет находится по кускам в разных окнах, между которыми будут вставлены поля картинок и кнопки действий. То есть форма громоздкая, банально для вычитки того, что сам только что написал, она очень неудобна.
Я бы смотрел в сторону расширений для ckeditor. Например вот: https://www.drupal.org/project/ckeditor_widgets
Там правда используется бутстраповская сетка, но ты в принципе мог бы просто добавить в свою тему стили для этих нескольких классов и всё бы работало.
Параграф - не "новый модуль", а достаточно пожилой-)
Можно чего-нибудь с VBO придумать (если совсем готового решения нет (не встречал))
т.е. скопировать одно поле материала в другое.
Надо только готовый экшн найти, или дописать или доделать..
Обычно это совсем не много, пару-тройку строчек.
1. Советую paragraphs
2. В параграфе можно использовать это поле для новых материалов, значения в старых придется "подтягивать"
Злой ты, не любишь контент-менеджеров!
"Конвертировать можно. Написать батч и прогнать через него все ноды. " - уж лучше экспорт + feeds. Тем более, что он всего год назад с параграфами подружился. https://www.drupal.org/project/feeds_para_mapper/releases Потому и не пользовался ими. А field_collection c feeds работало.
"минус такой организации контента в то..." текстовое поле со множеством значений было на сайте до меня.
Какое-то извращение)) Но если юзеры привыкли, то с параграфами смогут совладать без проблем.
Нет, не извращение.
Статья примерно так собрана:
Текст + фотка.
Таблица.
Пару фоток между ними текст.
И все это абсолютно без всякой системы. Маленькие кусочки текста (абцатцы) править легче чем один большой.
Почему бы не вставить это всё в одно поле с помощью ckeditor?
Многозначное поле - так сделали до меня. Вот и вся причина.
Это уже не статья, а лэндинг какой-то. Ну или журнал, причём как на бумаге.
А сейчас иначе никак по сути.
Обычная статья с картинками. На любом новостном портале такие.
Обычная это картинку налево, картинку направо. Использовать для этого модуль которые использует связки полей это немного не то.
То, что для этого использовать связки полей неразумно, я писал тут уже несколько раз. И приводил пример хорошей реализации. Для ленивых запощу видео с демкой:
Никакие параграфы, множественные поля и т.д. для редактирования статей не нужны.
Я не против поставить это в CKEditor. И даже поставлю, но уверен, что моим вариантом, мои пользователи будут пользоваться больше.
Вопрос такой. Для работы параграфов с feeds есть https://www.drupal.org/project/feeds_para_mapper.
Работает. Но допустим в ноде несколько параграфов с одинаковыми полями. Это можно импортировать? Не вижу как.
Блин, сделать что-ли доброе дело - написать модуль с тоннами ббкода, позволяющий нафигачить почти лэндинг в любой странице...
Уже пишут. Гуттенберг называется. Уже можно потестить.
Так а что тебя не устраивает в лендингах на каждой странице?
Не про ббкод речь, а про технологию. Она используется уже годы как для коммерческих посадочных страниц, так и для информационных. Раньше на панелях делали, теперь параграфы, скоро Гутенберг. И паралельно всякие блок_токен и подобные модули были. Или ты не в курсе?
Ещё лэйаут билдер хорош.
Гуттенберг уже завезли в вп, народ уже выматерился:)
Оно мне не нравится в философском смысле - всё это используется для ярких обёрток в ущерб смыслу. Безусловно, _иногда_ нужно представить информацию в таком виде, но случаев когда это действительно нужно не так уж и много, в большинстве же предпочтительнее стена текста с оглавлением в 1-3 уровня.
Это какое-то отношение к feeds имеет?
Немного рано я обрадовался. Если в парграфе есть fulltext поле - через feeds импортируеться только 2 позиции на каждую ноду.
Без параграфов - всё импортируется нормально.
Ну ты сам решил, что фидс лучше, чем писать свой батч для конвертации))
даже если напишу, что с этим всем делать потом? feeds постоянно используется для обновления всего. Даже с field collection таких проблем не было.
Написал, запустил, сконвертил и живи по-новому. Со сложными импортами у фидса часто проблемы. Фидс хорош там, где надо допустим таблицу экселя загрузить без всяких изысков. А как юзать фидс, если нужно поля ноды переконвертировать в параграфы, я слабо представляю.
Возможно.
Где найти как написать "админку" к этой болванке: https://www.drupal.org/node/2731611
?
В болванке описан код одной операции. Остальное см. тут: http://xandeadx.ru/blog/drupal/395
Если уж чего-то "писать", то тогда не для фидса..
Ништяцкие пацаны импортирую мигрейтом (migrate)
Он как-бы предполагался для миграции с одной версии drupal на другую,
и даже с вордпреса и прочих вражеских КМС на друпал,
но и для импорта тоже отлично подходит.
И очень часто для импорта его и используют.
Значит можно и какие-то готовые наработки, как раз для данного случая найти.
Помниться, мне отлично в голову вложил понимание ,что это за крутая штука, вот этот доклад Дмитро Данилевского : https://www.youtube.com/watch?v=Kzp1gCi8K9c
Одно из больших его преимуществ - запутанные и нудные батчи писать не надо..
Импорт выполняется драшем, а ему на лимиты пофигу.
Во-первых, мигрэйт только для восьмёрки. Во-вторых, я с ним уже набодался в своё время. Если импорт нужно делать регулярно, то в сторону мигрэйта лучше вообще не смотреть. Хотя даже для одноразового импорта перед использованием мигрэйт стоит 100 раз подумать, в этих ймл-ках чёрт ногу сломит. А если нужен сложный импорт, то всё равно придется плагины кодить. В итоге, переписав миграции на полностью кастомный код мне удалось получить прирост производительности в 7 раз. Плюс стало проще это всё редактировать.
Да.. для восмерки, похоже его "передрали" с минимальными доработками с семерки.
Пытался его приспособить для одного сложного импорта, плюнул и пишу свой мигрейт.
Для семерки я его тоже использовал, и весьма успешно.
В версии для семерки нет имл-ок и как-то все попроще и погибче.
Да, я вспомнил, юзал на семёрке мигрэйт. Он там как-то и поживее работает. Но опять же, в данном случае уже найден по кускам нужный код, можно скомпоновать без всяких миграций.
Ок, другой вопрос: c imagefield_tokens можно заставить параграфами работать?