Ищу полезный материал наподобие "Как делать не нужно".

Аватар пользователя drup-user

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

Например мои ошибки:

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

Ищу что-то на подобие этого:
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 раз подумайте, если это всё планируется юзать совместно с таксономией.

Тип материала:
Версия Drupal:
0 Thanks

Комментарии

Аватар пользователя itcrowd72
itcrowd72 1 неделя назад

Граблей очень много, всех не перечислить)

Аватар пользователя loup54
loup54 1 неделя назад

Не знаю мне кажется лучше видео на ютуб посмотреть, тем более есть со ссылками на статьи у Ивана Абраменко, на орге многие тексты напоминают мне баптистские лекции, типа братья да прибудет с вами Друпал и его функции)))))))

Аватар пользователя drup-user
drup-user 1 неделя назад

Видео смотрел почти всех, кто снимал. Никто не говорит про грабли.
Все видео сводится к абстракции: "таксономию добавить здесь", "связать материал и вывести views вот так", "моудль установить и настроить вот так" и т.д.
Конкретно сайт делали лишь в нескольких видео, но там естественно были простые визитки, где кроме basic page и пару views ничего особо и не нужно.

Интересуют большие проекты и как использовать все эту Масштабируемость и Гибкость не наломав дров как я.

Аватар пользователя drup-user
drup-user 1 неделя назад

Например поля. Дублировать или использовать уже существующие? например body.

Аватар пользователя bumble
bumble 1 неделя назад
2

Лучше, разграничивать поля по типам материала, например:

  • field_article_text_field
  • field_page_text_field
Аватар пользователя drup-user
drup-user 6 дней назад

А если модулем генерируется поле, например fivestar?
Тоже
field_article_fivestar_field
field_page_fivestar_field

Это я так понимаю, чтобы можно было темизировать конкретное поле в типе материала а не сразу все fivestar_field?

Аватар пользователя bumble
bumble 6 дней назад

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

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

Аватар пользователя svisch
svisch 6 дней назад

А чем это лучше, перед использованием одного поля field_text_field для разных типов материала?

Аватар пользователя bumble
bumble 6 дней назад

Лучше тем, что это делает компоненты более независимыми.
А среди прочего - это проще для понимания.

Аватар пользователя adubovskoy
adubovskoy 6 дней назад
1

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

Аватар пользователя Pety
Pety 6 дней назад
1

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

Аватар пользователя gun_dose
gun_dose 6 дней назад
1

И темы ядерные и контрибные тоже не менять

Аватар пользователя drup-user
drup-user 6 дней назад

По поводу изменения ядра/модулей - это да. Только переопределение...

Pety написал:

Не надо бездумно плодить поля, если можно их использовать повторно

Почему?

Аватар пользователя Pety
Pety 6 дней назад

Потому что каждое новое поле - это дополнительные таблицы в базе данных

Аватар пользователя DivaDii
DivaDii 6 дней назад
2

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

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

И ещё один махонький совет.
(Подозреваю, что сейчас в меня полетит куча тапков): не стремитесь быстро перейти на 8ку. Для новичков она сложная. Без писания кода / выписывания всяких там конфигураций и тому подобное ооочень сложно справиться.
В 7ке можно очень много всего накликать и найти подходящий модуль.

А в 8ке граблей намного больше, а стабильных 100%но работающих модулей меньше. Для простых проектов 8ка вполне себе нормальная. Но чуть только влево-вправо... - надо ковыряться в коде или искать патчи,... а потом расстроиться и уйти плакать в уголок...

===

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

Побольше осваивайте возможности вьюсов. Фильтры, контекстные фильтры...

Обратите особое внимание на модуль EntityReference. В связке с контекстными фильтрами во вьюсе он позволяет творить настоящие чудеса.

Но вообще-то... - всё зависит от конкретного проекта. Где-то Вам понадобятся Rules, где-то - Panels... А где-то views data export... и так далее.

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

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

"И да пребудет с Вами Сила!"

Аватар пользователя gun_dose
gun_dose 6 дней назад

А у вас свои грабли - вы не используете стстему контроля версий)))

Аватар пользователя gun_dose
gun_dose 6 дней назад

Вот, вспомнил. 10 раз подумайте,прежде, чем использовать ECK или создавать кастомные сущности. И ещё 5 раз подумайте, если хотите это юзать совместно с вьюс. И ещё 30 раз подумайте, если это всё планируется юзать совместно с таксономией.

Аватар пользователя loup54
loup54 6 дней назад

Для 8-ки, при редактировании файлов yml используйте пробелы, а не табуляцию, а кое где вовсе ничего не надо

Аватар пользователя gun_dose
gun_dose 6 дней назад

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

Аватар пользователя bumble
bumble 6 дней назад

Все же 4 правильнее было бы.
Надеюсь, друпал-стайл-гайд тоже переведут на всеобщие стандарты...

Аватар пользователя itcrowd72
itcrowd72 6 дней назад

Не люблю 4. Код слишком растянут

Аватар пользователя bumble
bumble 6 дней назад

А я поюзал - мне понравилось, в целом.
К тому же, это стандарт. Это не про предпочтения.

Аватар пользователя gun_dose
gun_dose 6 дней назад

Занятно)) помню точно, что читал пару лет назад и друпал стайл гайд, и пср-2, а потом всё смешалось в голове)) пора бы уже придумать eslint для php, а то те тулзы, что есть, на форматирование не смотрят.

Аватар пользователя gun_dose
gun_dose 6 дней назад
1

Точно, надо его поставить. Я юзаю просто вот эту штуковину: https://github.com/kalessil/phpinspectionsea
Она форматирование не смотрит, а анализирует архитектуру.

Аватар пользователя loup54
loup54 6 дней назад
1

Да просто дело в том, что для ЯП табуляция(если не верхний отступ для пхп, по крайней мере) исполнение скрипта не сломают, а вот yml Drupal 8 выведет белый экран

Аватар пользователя VasyOK
VasyOK 6 дней назад
1

В 90х годах в газете Speed Info была рубрика о половом просвещении. Среди прочего мне запомнилась фраза "Некоторые мальчики онанируют один раз в день, не которые два, некоторые три. Это нормально. "

Чуть позже встретилась подобная же фраза в книге по кодингу Немнюгина Перколаба: "Некоторые программисты отступают один пробел, некоторые два, некоторые три. Это нормально."

Книгу увы я так и не осилил.