Drupal → Bad Practices

Андеад, не мг бы разъяснить по п.6, всегда задавался вопросом, что правильнее использовать и почему.

И по пункту 11, пожалуйста. Как правильно надо?

PHP фильтр в список не попал. :)

Тема для админки Adminimal в 100500 раз круче унылой стандартной Seven, с 17 пунктом я бы сильно поспорил

Андеад, не мг бы разъяснить по п.6, всегда задавался вопросом, что правильнее использовать и почему.

Я же написал - hook_form_FORM_ID_alte/hook_form_BASE_FORM_ID_alter, у них нет оверхеда.

И по пункту 11, пожалуйста. Как правильно надо?

Писать свою тему с нуля.

PHP фильтр в список не попал. :)

Я люблю PHP фильтр ;)

Насчет adminimal согласен, но она вроде как на Seven основана.

Насчет темы bootstrap: не вижу причин игнорировать готовую тему, по моему, в includes и templates учтено столько мелочей по темизации элементов друпала, что мало кто сделает такое с нуля. Думаю, все же тут выбор надо делать в зависимости от своего уровня.

Подписываюсь под каждым пунктом, кроме 10. Не совсем ясно, почему стоит избегать селекторов вида #main-menu .content ul.menu li a ? Конечно же мы не про меню сейчас, но бывает очень замороченный дизайн, где без длинных селекторов не обойтись. Другое дело, возможно правильней было бы использование явного указание дочернего элемента, например вот так #main-menu .content > ul.menu > li > a .

10 бред. Учитывая пре процессоры писать надо удобно. 11й то же бред. Использование базовых тем ускоряет разработку в команде. 17 тоже не в кассу так как всем известно что фломастеры для всех разные. Ну и 16... Много где вообще бихейвер не нужен. Хватит просто реди

"бред" и "так как всем известно" отличные аргументы, не поспоришь.

п. 2 в друпал 8 тяжело соблюдать, по умолчанию он создает машинные имена на транслите. вы предлагаете вписывать переводы?

Во-первых: спасибо, что собрал все в одном месте :)

Не могу полностью согласится с п. 10. Как писали выше - это дополнительная гибкость, и если это помогает решить задачу не прибегая к переписыванию шаблонов и альтерам - не считаю это преступлением. Другое дело именно излишек селекторов, возможно об этом и шла речь, например тот же:

#main-menu .content ul.menu li a { ...; }

если можно отделаться только:

#main-menu a { ...; }

Так же, поддержу писавших выше по поводу п. 17. Особенно в случаях, когда сооружаешь хоть некое подобие бекенда, использовать приходится ну как минимум отнаследованную тему. А в идеале, опять же - свой велосипед.

Последний пункт (п. 18) не понятен - что означает "логика в коде, написанном через админку"?

код, исполняемый через eval не должен быть сложным

17. Использование темы для админки отличной от Seven.

Остальное понятно, но вот почему нельзя использовать другие темы для админки?
https://www.drupal.org/project/adminimal_theme
https://www.drupal.org/project/shiny
Чем плохи эти темы?

тем что Seven - стандарт, остальное нет

Думаю, что тема "Seven" должна быть по-умолчанию у администратора "своего" сайта и конечно же включаться при отладке, так как она действительно стандартна и хорошо работает. В иных случаях бывает так, что "Заказчик хочет другую тему" или же вам хочется как то приукрасить админку при сдаче проекта. Всякое бывает... Кстати проект comerce kickstart 2 для админки использует тему, основанную на "Shiny".

возможно поэтому comerce kickstart 2 такое слово из пяти букв :)

Cогласен, если это слово из 5 букв начинается на Х, а заканчивается на Я. Кикстарт очень сильно перегружен модулями, вьюхами, фичями и прочим функционалом и из-за этого сильно тормозит, но благодаря ему я получил представление, как ненужно делать интернет-магазин на Drupal =)

По поводу 10 пункта, все кто думает, что это бред, глубоко ошибаются, возможно потому, что не знают как браузеры обрабатывают селекторы. Если вы напишите много подобных селекторов:
#main-menu .content ul.menu li a { ...; }
То скорость чтения браузером стилей сильно возростет, потому стоит выбирать между производительностью и удобством, или ленью, или какой-то другой причиной.

а п.3 можете прокомментировать? Лежат себе и лежат, не?

С чем можно поспорить.
п.2.
Если сайт не большой и сопровождать будет один человек, то можно и транслитом писать.
Не вижу причин, чтобы так не делать. Сам транслитом не люблю писать, но редкие случаи бывает.
п.3.
Не понятно. Почему лишние модули не надо отключать? особенно в п.4. написано что лишние надо отключать.
п.10.
Спорный пункт.
#main-menu a - стиль применится к всем "A" , а если мне надо чтобы второй уровень "А" был отличим от первого уровня "A", то мне что надо писать хук, чтобы добавлять к второму уровню "А"? Глупо.
п.17.
А вот это не обоснованно. Стандартная тема убогая. Использую adminimal и не вижу причин использовать Seven.
Надо расскрыть тему, может есть причины весомей чем "тем что Seven - стандарт, остальное нет"

Если сайт не большой и сопровождать будет один человек, то можно и транслитом писать.

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

Почему лишние модули не надо отключать?

Там такого не написано.

а если мне надо чтобы второй уровень "А" был отличим от первого уровня "A"

#main-menu a a

А вот это не обоснованно.

А "Стандартная тема убогая" конечно крайне обоснованно

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

Я так понимаю, а почему? Ты не ответишь?

Там такого не написано.

Там написано как хочешь так и понимай.

#main-menu a a

Сам пишешь, что так делать нельзя.

А "Стандартная тема убогая" конечно крайне обоснованно

Так может, это ты должен тему расскрывать, а не я. Не мой же блог.
И все таки, почему надо юзать семерку только? Или секрет?

З.Ы. Писать надо понятней. В такой трактовке как у тебя, почти все пункты оспариваются.
Распиши подробней, чтобы вопросов не было лишних.

Я так понимаю, а почему? Ты не ответишь?

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

Сам пишешь, что так делать нельзя.

Я такого не писал.

почему надо юзать семерку только?

Читайте выше.

Писал и скорее всего буду писать транслитом, хотя английский я знаю хорошо. Удобно, когда у тебя поле называется 1 к 1 в админке и в коде. Например "Мощность двигателя" и "field_moshnost_dvigatela". Особенно это становится актуально когда у тебя полей штук 60, фасетов например. И жутко неудобно, когда чувак до тебя с 3мя классами английского называет поле по-английски, но с ошибками.
Покуда я знаю что мои сайты никогда не выйдут за пределы рунета, и обслуживать их будут русскоязычные люди - этот совет бессмысленный.
Дургое дело комментарии в коде должны быть на английском. Это стандарт кодинга. А на поля станадарта нет.

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

xandeadx, ну и всё-таки хочется по п.3 - почему держать отключённые модули на сайте - плохо.

потому что это бессмысленно

и вот ещё 13. Как быть-то, если нужен кастомный вывод, если не переопределять шалоны? DS?

Переопределяйте, но не делайте это бездумно. Пользуйтесь возможностями theming api - preprocess, process, alter.

Писал и скорее всего буду писать транслитом, хотя английский я знаю хорошо. Удобно, когда у тебя поле называется 1 к 1 в админке и в коде. Например "Мощность двигателя" и "field_moshnost_dvigatela"

Человека, хорошо знающего английский стошнит от такого названия. Более того, стошнит просто аккуратного человека, не очень хорошо знающего английский. Меня уже тошнит. Даже если допущена ошибка, по мне это лучше, чем кривизна. Интересно, если сайт двуязычный, тоже транслитом переводить будуте текст? Напоминает смс начала 2000.
Выйдет сайт за пределы рунета или нет совершенно не важно. Важно, что если вы кините того, кому сделали сайт (а это ранг или поздно произойдет), то новому лицу будет противно его поддерживать. О каких стандартах вы в таком случае говорите?
Что касаемо комментаииев в коде, то считаю тут наоборот. Если сайт делается русскими для русских, лучше по-русски прокоментировать, что значит некий кусочег кода, ибо с таким подходом писать по английски бессмысленно.

жутко неудобно, когда чувак до тебя с 3мя классами английского называет поле по-английски, но с ошибками

Странно такое читать от человека, сделавшего две ошибки в "moshnost_dvigatela".

Павел, я говорю об удобстве работы с сайтом, а не об эстетических предпочтениях. Я 4 года на Друпале, пробовал и так и так, и работал сайтами сделанными и так и эдак. Мне ни разу не повезло встретить сайт, в котором все поля называются на красивом правильном английском. Это вегда или мешанина из транслита и английского, или ломанный английский, или транслит. Вот с просто транслитом удобнее всего работать, просто мне просто по опыту, особенно когда полей очень много.

О каких стандартах вы в таком случае говорите?
https://www.drupal.org/coding-standards

и они не зависят от того, кину я человека которому сделал сайт или нет, они абсолютны.

Андед, Вы придираетесь. Вы-то сами для себя определились, какой транслит правильный:
moshchnost-dvigatelya
moshhnost-dvigatelya
moshchnost-dvigatelja
moshhnost-dvigatelja
другой?

Для меня нет правильного транслита, я им не пользуюсь.

я ж 2 ошибки сделал по-вашему :)

Выберите любой из предложенных и найдете те самые 2-е ошибки.

Мне ни разу не повезло встретить сайт, в котором все поля называются на красивом правильном английском. Это вегда или мешанина из транслита и английского, или ломанный английский, или транслит.

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

 $field = array(
      'field_name' => 'field_moshnost_dvigatela', 
      'type' => 'text', 
    );
    field_create_field($field);

Более того, как потом выглядят стили?

.field_moshnost_dvigatela ?

Как потом обращаться к полям с помощью js/jquery?

$('.field_moshnost_dvigatela') ?

Конечно, компьютеру все-равно как будет называться поле, хоть xxx1-field, он его обработает правильно. Но это же в конце концов некрасиво и вызывает негатив людей, кому удосужилось поработать далее с проектом. Очень прошу, не перенимать плохую привычку и не гадить себе же в карму. Оно конечно и так работает, но лучше стремиться к идеалу.

ок, тема создания полей в 8ке осталась нераскрытой. Господа переназывают поля после автотранслита в админке?

ок, тема создания полей в 8ке осталась нераскрытой. Господа переназывают поля после автотранслита в админке?

А какая разница? Сделали для удобства, чтобы любой желающий мог сделать сайт для себя без знания html, css, js, php и не заморачиваться. Мы же говорим про лучшие практики!

Точнее обсуждаем худшее и лучшее.

Давайте просто проведём аналогию например с окраской дома. Можно красить по старой краске и современная краска позволяет это сделать, но вопрос сколько это прослужит? А можно максимально снять старый слой и покрасить новым, той же краской. Думаю будет качественнее. Тут тоже самое. Если есть автотранслит - это не значит, что не надо заморачиваться.

Я не Дриса, я господ здесь тусующих спрашиваю. Вот Вы, PazitiFF - переназываете поля которые Вам в админке 8ка предлагает? Чтобы не транслитом, а по-православному, на чистом англицком.

Восьмеркой пока особо не пользуюсь из-за нехватки времени, так как работаю на работе с проектами на d6 и d7, а дома своих дел по-горло. Но всё же d8 я ставил и пробовал писать для неё простые модули по мануалу. Я обратил внимание на эту фишку автотранслита, но когда буду вплотную использовать d8 - обязательно буду переименовывать. Кнопочка "edit" существует именно для этого.

PazitiFF спасибо. Но Вы же понимаете, что таких как Вы немного. И теперь с этой фишкой сайтов с полями транслитов будет чуть менее чем все. Хотите Вы этого или нет. Так что Вы, и Ваши коллеги по английским полям уже вполне можете уже запасаться ритуальными пистолетами и учиться из них стрелять :)

Тут уже каждый решает сам за себя, как сделать ту или иную задачу. Повторюсь, что мы обсуждаем, что хуже и как лучше. Думаю, что с выходом восьмёрки надо запасаться не ритульными пистолетами, а автоматами калашникова и гранатами, для массового уничтожения всех, кто не с нами =)

Если слушать гостя, то
украинец должен писать "field_potujnist_dviguna"
белорус "field_magutnasc_ruhavika"
казахи "field_kozfaltkish_kuati"

Ну а поддерживать всё это должен будет русский. Отличная перспектива.

Кстати очень хороший пример!

Акбар, не так. Я имел в виду, что в русскоязычном пространстве удобно использовать русский язык в виде транслита. И украинцы, и белорусы, и казахи обычно хорошо знают русский язык.

Акбар, а будет ли русскому удобно поддерживать сайт на не знакомом языке, например английском?

русскому незнакомому с английским стоит для начала закончить школу и только потом браться за поддержку сайтов

ха-ха-ха, никогда не думал, что это даже может обсуждаться. Для тех кто называет поля на транслите есть отдельное место в аду.
Вот вам пример из сообщения по вариантам транслита:
moshchnost-dvigatelya
moshhnost-dvigatelya
moshchnost-dvigatelja
moshhnost-dvigatelja
Для того кто писал, что ему потом удобно в коде обращаться к полю на транслите - ломай голову какой ты вариант использовал. Если не знаешь англ. или не уверен в написании: есть же переводчики - расширения для браузера (в один клик переводишь и времени почти не занимает + заодно пополняешь свои знания в англ. языке). Хотя я даже не представляю как можно изучать друпал хотя бы без базового знания технического англ. языка. Рунет слишком скудное место для черпания знаний по друпал.

Например razmer, dom, dlina, giperbola
и что не сможете понять что за переменные?
Для того кто писал, что ему потом удобно в коде обращаться к полю на транслите - ломай голову какой ты вариант использовал. а если называть на английском ломать голову не надо?

2 Еврей
вы привели слишком простые примеры, а если на транслите слова где есть буквы: ш, щ, ь, ц, я и т.д., то все усложняется. Вам нужно всегда помнить как именно вы написали. На англ. как раз все однозначно. Там как в, примере с мощностью двигателя, вы назвали engine_power и все других вариантов быть не может. Да вы и попробуйте в коде писать такую муру moshchnost_dvigatelya - вы просто задолбаетесь в правильном порядке ставить буквы.
Конечно если вы один работаете с сайтом и у вас есть свой стиль как писать на транслите - то для вас может это и не проблема, но нужно думать и о других.

Cуществует огромное количество ситуаций, в которых одно и то же русское слово можно перевести на английский по-разному. Например "тип двигателя". Разговор о строительной технике, варианты значений - бензиновый, дизельный, электрический. Как будем переводить? engine_type? motor_type?
У меня таких примеров было в жизни мильён, щас просто не припомню, но, думаю, все поняли о чём речь.
Объём двигателя это engine_capacity или engine_volume? Переводчик в таких делах не всегда помогает, потому что часто чтобы правильно перевести нужно знать контекст. Если полей 100 штук - убейте меня, я не буду каждое поле переводить в переводчике, проверять в оксфордском словаре варианты использования полученного перевода. Да, англоязычным специалистам будет сложно поддерживать мой сайт о спецтехнике в Перми, это печально :)

Если полей 100 штук

Если полей 100 штук, то вы уже что-то делаете не так.

хм. Подскажете другие варианты создания фасетого поиска по товарам из 53 категорий? 100 полей это я образно сказал, их раза в 3-4 больше, считать лень.

EAV

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

Про транслит больше похоже на неграмотность в языковом вопросе. Русский язык не прибит гвоздями к кириллице. Так же как и другие языки, используемые народами России. Поэтому это только личная Ваша неприязнь к латинской графике в русском языке.
И про длинные селекторы типа
#main-menu div.content ul.menu li a
это сферический конь в вакууме, CSS3 позволяет все делать кратче и аккуратнее...

Отключённый watchdog / отключённый вывод ошибок / ошибки в watchdog / ошибки на экране.

Кстати, существует модуль Notify log который выдает нотисы/ошибки прям в попапчиках на странице. Очень удобно, мы вообще с некоторых пор стараемся ставить на любом проекте.

Здравствуйте. В целом все верно, но
11. Согласен, с Bootstrap, но Omega вроде как позиционируют себя что они не бутстрап и подход у них другой. В целом конечно можно создать свой велосипед (базовую тему) и расширять по мере необходимости.
10. Тут бы сделать оговорку что принципиально не длинна селектора, а то что селектор однозначно идентифицирующий элемент должен быть максимально коротким и не включать избыточную цепочку элементов.
17. Вопрос вкуса. Т.к. это тоже самое, что не включать admin_menu (который таки отрицательно сказывается на производительности), не отключать overlay. Это модули из разряда удобства и нельзя говорить что это вот можно использовать, а это нет.
А в целом явно видно перфекциониста и педанта)) Который, впрочем, сидит в каждом хорошем разработчике.

Расскажите, пожалуйста, более подробно по поводу 6 пункта (Использование hook_form_alter(). Всегда пользуйтесь hook_form_FORM_ID_alter() и hook_form_BASE_FORM_ID_alter().). Почему именно так?

Легче код читать.

Потому что данный хук не вывзывается к каждой форме, а только к нужной. Работает быстрее и однозначнее.

xandeadx:

11. Использование тяжёлых базовых тем типа Bootstrap или Omega. Поначалу кажется, что они могут сэкономить время, но это ощущение обманчиво.

Для Drupal 8 это тоже актуально ?

Это актуально для любых cms, автоматически генерящих разметку.

А чем обусловлена тяжесть, количеством файлов и их регистрацией ?
И в чем это проявляется, в скорости загрузки или только в потреблении ресурсов ?

Большим функционалом, большую часть которого вы никогда не будете использовать.

Правильно ли я понимаю, не стоит использовать базовые темы для создания подтем ?
Лучше отсечь все лишнее от готовой ?
А идеальный вариант, это создание темы с нуля ?

Ну да

Очень Спасибо =)