14 апреля 2018 в 18:27
Первый раз делаю сайт. Естественно в будущем я пойму, что нужно было что-либо делать по-другому.
Читал книгу «Профессиональная разработка сайтов на Drupal 7, но там на столько абстрактно написано, без практических и конкретных примеров.
Например мои ошибки:
- делал все страницы в одном типе материала. Из-за этого с views было сложнее работать, пришлось переделать, благо было мало страниц.
- отключил все встроенные стили, чтобы добиться чистой темы для себя. В результате отвалились некоторые встроенные функции (типа сворачивание фильтров, выпадение списков)
Ищу что-то на подобие этого:
https://drupal.ru/node/9661
или
https://www.drupal.org/node/188989
Или может быть в коментах кто-нибудь поделится своим "катехизисом" работы с Drupal.
Ведь наверняка за годы работы с движком видно, что новички, такие как я, наступают на одни и те же грабли.
Спасибо за внимание!
Собрал небольшой faq из комментариев ниже.
1. Лучше, разграничивать поля по типам материала, например: field_article_text_field, field_page_text_field. Название (так принято), должно передавать смысл данных поля. Это для того чтоб самому было понятно что там.
2. Не надо менять код ядра и контрибных модулей.
3. Не надо использовать модули, если не исчерпали возможности "коробочного" функционала
4. Не надо бездумно плодить поля, если можно их использовать повторно
5. И темы ядерные и контрибные тоже не менять
6. Делайте почаще резервные копии. И файлы, и базу данных. И рядышком кладите "листочек" с комментариями: чем эта копия отличается от другой.
7. Когда меняете какой-то файл / файл темы / css ... - сохраните лишний раз копию этого файла. Чтобы в случае чего - сразу откатиться.
8. Очень хороший способ изучения Друпала и его возможностей - открыть раздел с модулями на Д.орге, отфильтровать для 7ки, отсортировать их по популярности и изучать топ-30 или топ-50.
9. Побольше осваивайте возможности вьюсов. Фильтры, контекстные фильтры..
10. Обратите особое внимание на модуль EntityReference. В связке с контекстными фильтрами во вьюсе он позволяет творить настоящие чудеса.
11. - всё зависит от конкретного проекта. Где-то Вам понадобятся Rules, где-то - Panels... А где-то views data export... и так далее.
12. И да - будьте готовы к тому, что где-то через год Вы поймёте, что первый проект надо было делать не так. Но вообще-то, чтобы справиться с этим... - изменить структуру сайта... даже изменить тип ноды... - почаще вспоминайте волшебную фразу."И да пребудет с Вами Сила!"
13. 10 раз подумайте,прежде, чем использовать ECK или создавать кастомные сущности. И ещё 5 раз подумайте, если хотите это юзать совместно с вьюс. И ещё 30 раз подумайте, если это всё планируется юзать совместно с таксономией.
Комментарии
Граблей очень много, всех не перечислить)
Не знаю мне кажется лучше видео на ютуб посмотреть, тем более есть со ссылками на статьи у Ивана Абраменко, на орге многие тексты напоминают мне баптистские лекции, типа братья да прибудет с вами Друпал и его функции)))))))
Видео смотрел почти всех, кто снимал. Никто не говорит про грабли.
Все видео сводится к абстракции: "таксономию добавить здесь", "связать материал и вывести views вот так", "моудль установить и настроить вот так" и т.д.
Конкретно сайт делали лишь в нескольких видео, но там естественно были простые визитки, где кроме basic page и пару views ничего особо и не нужно.
Интересуют большие проекты и как использовать все эту Масштабируемость и Гибкость не наломав дров как я.
Например поля. Дублировать или использовать уже существующие? например body.
Лучше, разграничивать поля по типам материала, например:
А если модулем генерируется поле, например fivestar?
Тоже
field_article_fivestar_field
field_page_fivestar_field
Это я так понимаю, чтобы можно было темизировать конкретное поле в типе материала а не сразу все fivestar_field?
Название (так принято), должно передавать смысл данных поля.
Это для того чтоб самому было понятно что там.
В целом, нет особых правил именования.
Да, и темизация, и потом работать с ними удобнее. Ту же вьюху собирать будете - не будет вопросов "к чему это поле", не говоря уже о программных подходах.
А чем это лучше, перед использованием одного поля field_text_field для разных типов материала?
Лучше тем, что это делает компоненты более независимыми.
А среди прочего - это проще для понимания.
Потому что, например, если вы захотите этот фунционал упаковать через features, он будет автоматом подтягивать все типы материалов где оно используется. решаемо (просто не включать ненужные конфиги в модуль) но будут некоторые неудобства.
Не надо менять код ядра и контрибных модулей.
Не надо использовать модули, если не исчерпали возможности "коробочного" функционала
Не надо бездумно плодить поля, если можно их использовать повторно
И темы ядерные и контрибные тоже не менять
По поводу изменения ядра/модулей - это да. Только переопределение...
Почему?
Потому что каждое новое поле - это дополнительные таблицы в базе данных
На главные грабли Вы уже наступили.
Самое главное - делайте почаще резервные копии.
И файлы, и базу данных.
И рядышком кладите "листочек" с комментариями: чем эта копия отличается от другой.
Когда меняете какой-то файл / файл темы / css ... - сохраните лишний раз копию этого файла. Чтобы в случае чего - сразу откатиться.
И ещё один махонький совет.
(Подозреваю, что сейчас в меня полетит куча тапков): не стремитесь быстро перейти на 8ку. Для новичков она сложная. Без писания кода / выписывания всяких там конфигураций и тому подобное ооочень сложно справиться.
В 7ке можно очень много всего накликать и найти подходящий модуль.
А в 8ке граблей намного больше, а стабильных 100%но работающих модулей меньше. Для простых проектов 8ка вполне себе нормальная. Но чуть только влево-вправо... - надо ковыряться в коде или искать патчи,... а потом расстроиться и уйти плакать в уголок...
===
Не знаю, освоили ли Вы этот метод - на всякий случай напишу.
Очень хороший способ изучения Друпала и его возможностей - открыть раздел с модулями на Д.орге, отфильтровать для 7ки, отсортировать их по популярности и изучать топ-30 или топ-50.
Побольше осваивайте возможности вьюсов. Фильтры, контекстные фильтры...
Обратите особое внимание на модуль EntityReference. В связке с контекстными фильтрами во вьюсе он позволяет творить настоящие чудеса.
Но вообще-то... - всё зависит от конкретного проекта. Где-то Вам понадобятся Rules, где-то - Panels... А где-то views data export... и так далее.
Вот в той книжке, которую Вы изучали, - там есть грандиозная волшебная фраза, которая характеризует весь Друпал7: "Для этого есть модуль".
И да - будьте готовы к тому, что где-то через год Вы поймёте, что первый проект надо было делать не так. Но вообще-то, чтобы справиться с этим... - изменить структуру сайта... даже изменить тип ноды... - почаще вспоминайте волшебную фразу.
"И да пребудет с Вами Сила!"
А у вас свои грабли - вы не используете стстему контроля версий)))
Вот, вспомнил. 10 раз подумайте,прежде, чем использовать ECK или создавать кастомные сущности. И ещё 5 раз подумайте, если хотите это юзать совместно с вьюс. И ещё 30 раз подумайте, если это всё планируется юзать совместно с таксономией.
Для 8-ки, при редактировании файлов yml используйте пробелы, а не табуляцию, а кое где вовсе ничего не надо
Табуляцию уже по стандатам кода вообще лучше не использовать. Только два пробела. И никогда не 4, будь то пхп, жс или цсс
Все же 4 правильнее было бы.
Надеюсь, друпал-стайл-гайд тоже переведут на всеобщие стандарты...
https://www.drupal.org/project/coding_standards/issues/2645010 не раньше 9й.
Не люблю 4. Код слишком растянут
А я поюзал - мне понравилось, в целом.
К тому же, это стандарт. Это не про предпочтения.
Занятно)) помню точно, что читал пару лет назад и друпал стайл гайд, и пср-2, а потом всё смешалось в голове)) пора бы уже придумать eslint для php, а то те тулзы, что есть, на форматирование не смотрят.
https://www.drupal.org/node/1419988 (https://github.com/squizlabs/PHP_CodeSniffer).
Мне шторм здоровски помогает форматтить. И свитчить на разный манер довольно быстро, можно своих прессетов натыкать.
Точно, надо его поставить. Я юзаю просто вот эту штуковину: https://github.com/kalessil/phpinspectionsea
Она форматирование не смотрит, а анализирует архитектуру.
Да просто дело в том, что для ЯП табуляция(если не верхний отступ для пхп, по крайней мере) исполнение скрипта не сломают, а вот yml Drupal 8 выведет белый экран
В 90х годах в газете Speed Info была рубрика о половом просвещении. Среди прочего мне запомнилась фраза "Некоторые мальчики онанируют один раз в день, не которые два, некоторые три. Это нормально. "
Чуть позже встретилась подобная же фраза в книге по кодингу Немнюгина Перколаба: "Некоторые программисты отступают один пробел, некоторые два, некоторые три. Это нормально."
Книгу увы я так и не осилил.
Спасибо всем за советы. И так по поводу полей: существующее поле или новое.
Споры идут до сих пор)
https://www.ostraining.com/blog/drupal/re-using-drupal-fields/
https://drupal.stackexchange.com/questions/16718/whats-a-good-balance-be...