Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Друзья, нам очень стыдно, но некоторые ссылки поломал jsfiddle, в котором мы с Олегом делали этот пост. Если у вас 404, просто удалите прицепившиеся query-параметры и всё заработает. А мы починим ссылки очень скоро.
Спасибо за подборку.
Микросовет — global $user в функциях
Автор пишет правильно, но катастрофически мало. Про подмену global $user это вообще руки поотрывать.
— $uid — передавать и присвоить по умолчанию NULL.
— в начале функции проверить на пустоту $uid и загрузить в случае чего пользователя по global $user->uid.
Нужно именно грузить пользователя:
function my_module_work($param1, $uid = NULL) {
global $user;
if (!$uid) {
$account = user_load($user->uid);
}
…
В дополнительной загрузки нет лишней нагрузке, так как Друпал статически кеширует пользователя и ноды, поэтому лишних обращений к базе данных не будет. Но в некоторых местах, пользователь в глобальной переменной загружен не полностью и если вы ему измените какие-то параметры и потом сохраните, то может получится что вы удалите часть параметров у пользователя.
Автор пишет правильно, но катастрофически мало. Про подмену global $user это вообще руки поотрывать.
— $uid — передавать и присвоить по умолчанию NULL.
— в начале функции проверить на пустоту $uid и загрузить в случае чего пользователя по global $user->uid.
Нужно именно грузить пользователя:
function my_module_work($param1, $uid = NULL) {
global $user;
if (!$uid) {
$account = user_load($user->uid);
}
…
В дополнительной загрузки нет лишней нагрузке, так как Друпал статически кеширует пользователя и ноды, поэтому лишних обращений к базе данных не будет. Но в некоторых местах, пользователь в глобальной переменной загружен не полностью и если вы ему измените какие-то параметры и потом сохраните, то может получится что вы удалите часть параметров у пользователя.
Тут промелькнуло что авторы Умного Дома нещадно эксплуатируют все bad practices, которые можно найти в друпале. А есть где-нибудь сборник этих самых bad practices? Или типа вредных советов что-нибудь?
Так сходу не припомню никаких статей или докладов с вредными советами. Наткнусь — сообщу.
Про «все» я, конечно, слукавила. Ну, пишут они код прямо в ноде с помощью PHP-фильтра, подумаешь. В CMS есть эта функциональность, и значит они в праве её использовать, если им надо :)
Тут промелькнуло что авторы Умного Дома нещадно эксплуатируют все bad practices, которые можно найти в друпале.
Про «все» я, конечно, слукавила. Ну, пишут они код прямо в ноде с помощью PHP-фильтра, подумаешь. В CMS есть эта функциональность, и значит они в праве её использовать, если им надо :)
— в своих функциях (и параметрах) использовать $user (правильно только $account. даже если не используется global $user;);
— не соблюдать Друпал стандарты (код читать не возможно);
— ставить стопятсот модулей и жаловаться что Друпал медленный;
— делать SQL запросы или логику в шаблонах;
— хакать ядро или контриб модули (в 99% это не нужно, а в 1% проценте нужно патчить и патч ложить в специальную папочку);
— устанавливать модули темы в папки ядра (правильно в sites/all/modules, sites/all/theme);
— удаление модулей/тем переименовыванием папок. Это вообще жуть, друпалу все равно как папки называются он ищет *.info файлы рекурсивно;
— — иметь одинаковые модули в папках: modules, sites/all/modules, sites/site-name.com/modules, sites/default/modules. Были жуткие случае когда модули разных версий на одном сайте были по разным папкам, разные версии и код работал из одной папки, шаблоны из другой;
— не запускать update.php;
— не делать бекап перед обновлением (да и вообще бекапы всегда нужны);
— удалять файлы модулей, не удалив их из админки (сначала нужно отключить, а потом удалить в админке);
— использовать РНР фильтр (постоянно нельзя, это только для безнадежных случаем);
— для сложных модулей делать все в куче (правильно, логика отдельно, теминг отдельно, а еще можно и по разным файлам разнести);
— подключать JS в хедере как НТМЛ;
— не подключать к формам JS, а грузить в hook_init(), например;
— писать стили/скрипты в шаблоне, а не отдельном файлике модуля. Или писать этот код в основном файле, вместо выноса раздельно;
— забывать про BatchAPI и пытаться кроном перелопатить пол-базы за раз;
— не использовать кеширование;
— использовать кеширование не правильно. Например, во Views ставить маленькое время жизни кеша и получается нагрузка только возрастает, так как каждое обращение пересоздает кеш;
— не юзать аргументы во views, были случаи когда вместо одного блока с аргументом, создавали 50 блоков (на каждый термин по блоку);
Это что с ходу вспомнилось.
— не соблюдать Друпал стандарты (код читать не возможно);
— ставить стопятсот модулей и жаловаться что Друпал медленный;
— делать SQL запросы или логику в шаблонах;
— хакать ядро или контриб модули (в 99% это не нужно, а в 1% проценте нужно патчить и патч ложить в специальную папочку);
— устанавливать модули темы в папки ядра (правильно в sites/all/modules, sites/all/theme);
— удаление модулей/тем переименовыванием папок. Это вообще жуть, друпалу все равно как папки называются он ищет *.info файлы рекурсивно;
— — иметь одинаковые модули в папках: modules, sites/all/modules, sites/site-name.com/modules, sites/default/modules. Были жуткие случае когда модули разных версий на одном сайте были по разным папкам, разные версии и код работал из одной папки, шаблоны из другой;
— не запускать update.php;
— не делать бекап перед обновлением (да и вообще бекапы всегда нужны);
— удалять файлы модулей, не удалив их из админки (сначала нужно отключить, а потом удалить в админке);
— использовать РНР фильтр (постоянно нельзя, это только для безнадежных случаем);
— для сложных модулей делать все в куче (правильно, логика отдельно, теминг отдельно, а еще можно и по разным файлам разнести);
— подключать JS в хедере как НТМЛ;
— не подключать к формам JS, а грузить в hook_init(), например;
— писать стили/скрипты в шаблоне, а не отдельном файлике модуля. Или писать этот код в основном файле, вместо выноса раздельно;
— забывать про BatchAPI и пытаться кроном перелопатить пол-базы за раз;
— не использовать кеширование;
— использовать кеширование не правильно. Например, во Views ставить маленькое время жизни кеша и получается нагрузка только возрастает, так как каждое обращение пересоздает кеш;
— не юзать аргументы во views, были случаи когда вместо одного блока с аргументом, создавали 50 блоков (на каждый термин по блоку);
Это что с ходу вспомнилось.
Забыл самое любимое, которое даже на хабре было:
— не использовать t();
— использовать t() для русского языка.
— не использовать t();
— использовать t() для русского языка.
Решил подборку оформить временно тут drupal.ua/groups/drupal-kukhnya/samye-rasprastranennye-oshybky-v-drupal-razrabotke
Потом список разобью по группа и популярности.
Дополняйте своими вариантами!
Потом список разобью по группа и популярности.
Дополняйте своими вариантами!
У holyorb2 накипело, как видно.
Моё любимое: $_SESSION в шаблоне page.tpl.php, а потом, ой, что-то у меня кеширование станиц не работает :)
Моё любимое: $_SESSION в шаблоне page.tpl.php, а потом, ой, что-то у меня кеширование станиц не работает :)
Ошибся веткой. Коментарий удалён.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дайджест интересных материалов из мира Drupal #4