4. Не правильное размещение файлов темы и модулей будущего
сайта
а) Удобство для других разработчиков
б) Удобство в дальнейшем сопровождении сайта
в) Удобство при обновлении кода
г) Файлы как лицо исполнителя
5. Общие правила написания качественного кода
1. Стараться не использовать кирилицу в коде без явной на то необходимости.
2. Обязательное четкое разделение функций выполняющих получение данных,
обрабатывающих данные, выводящих данные конечному пользователю.
а) Функция выполняющая запрос в БД и возвращающая обработанный массив или объект с результатами
(в ней желательно предусмотреть параметры + static);
б) Функция обрабатывающая массив и готовящая данные для вывода пользователю (обычно это
preprocess функция)
в) Функция выводящая обработанные данные theme_ или шаблон tpl.php
3. Использование API системы, в Друпал можно прицепиться фактически к любому
процессу.
a) hook_nodeapi
б) hook_form_alter (и все его производные)
в) hook_menu_alter
6. Форк модулей, когда он бывает необходим?
Форк (англ. fork — вилка) — процесс расщепления программного проекта (обычно
свободного) на два отдельных проекта (ветки). При этом каждая из веток
развивается независимо от другой, разными авторами.
1. Модуль подходит нам менее чем на 50% - проще написать свой.
2. Модуль удовлетворяет наши потребности более чем на 50%, но в нем
не предусмотрены первоначальными разработчиками хуки или какое
либо АПИ. Либо модуль более не поддерживается.
В этом случае возможны 2 варианта:
а) Писать функционал в том же модуле просто расширяя его;
б) Писать свой модуль перенося из исходника функции заменяя их
названия
7. Стандарты темизации и написания собственных модулей
1. Файлы и папки должны быть структурированы CSS + JS
2. Файлы должны подключаться с использованием
стандартных функций друпала.
а) drupal_add_js(); drupal_add_css();
Зависимость от решения конкретной задачи в проекте.
Использование бихевиоров при создании JS
3. Разделение файлов админской, рабочей и
темизирущей области модуля.
8. Стандарты темизации и написания собственных модулей
1. На сайт должен быть загружен favicon для темы сайта и для админской
темы.
2. Для страниц администрирования и редактирования материалов должна
быть установлена специальная тема (удобная для администрирования),
но не тема проекта.
3. Верстка должна быть кроссбраузерная. Обязательно поддерживаются
(по убыванию важности)
4. Использовать спрайты для увеличения скорости загрузки страниц и
предотвращения нежелательных эффектов, связанных с подгрузкой
графики. Группировать изображения в зависимости от их появления на
страницах.
5. Внешний вид сайта не должен ломаться при увеличении или уменьшении
размера текста в браузере (как минимум на 2 позии).
6. Логотип сайта желательно реализовывать как блок и должен быть
ссылкой, которая ведет на главную страницу.
7. Не должно быть неприятных (побочных) эффектов во время загрузки
страницы.
9. Стандарты темизации и написания собственных модулей
Верстка сайта должна быть валидна.
Исключение могут составить непринципиальные моменты, от которых можно
отказаться в пользу SEO или если не валидность вызвана особенностью
функционала.
Cайт необходимо проверять на валидностьhttp://validator.w3.org.
Для проверки всего сайта можно использовать http://htmlhelp.com/tools/validator.
10. Удобная админка для пользователя
1. Создание качественной, удобной конечному потребителю админки.
а) Чем понятнее и интуитивнее будет админская часть для конечного пользователя, тем
проще потом сдавать проект и меньше потратится времени на обучение заказчика или
клиента.
б) Views + Bulck operation:
11. Удобная админка для пользователя
в) Роль редактора контента или почему не надо давать секретарше пароль
суперадмина.
г) Вьюс и блоки:
- Для реализации страниц вьюсов (листинг нодов) мы не используем вьюс
напрямую, вместо этого создается страница (node type Page), а вьюха делается
блоком, который потом помещается на эту страницу. Вступительный текст
реализуется как тело страницы, а не как заголовок вьюхи, также заголовок
страницы, заголовок окна, мета теги и все остальное что важно для страницы,
задается в ноде страницы.
Причины такого подхода:
1. Редактору сложно разбираться в админке вьюсов, все параметры страницы
проще делать в знакомом интерфейсе нода Страницы.
2. Не возможно разделить доступ к отдельным частям вьюсов, поэтому приходится
запрещать доступ к вьюсам.
3. Некоторые параметры страницы такие как Page Title не возмжно редактировать
для вьюсов
12. Удобная админка для пользователя
2. Почему блоки?
- Все основные данные находятся в одном месте и пользователю не надо
запоминать что настройка лого и иконок это «admin/build/themes/settings/global»,
а футер меседжа и т. д. это по admin/settings/site-information. Вполне
самодостаточно что управление всем этим находится - /admin/build/block
3. Обязательно создается роль Editor (редактор), которая будет выдана клиенту
для управления сайтом. Этой роли разрешено делать все операции с нодами,
блоками, меню ( только реально используемые меню), пользователями сайта.
Конфигурационные настройки, менющие структуру данных или поведение сайта
этой роли недоступны.
- Меньше прав - легче саппортить
13. Производительность
1. Перед запуском сайта, все неиспользуемые модули, а так же служебные
модули (которые используются для разработки) необходимо отключить.
2.В процессе разработки сайта необходимо анализировать какие
используются вьюхи и какие пишутся собственные SQL запросы и в
соответствии с этим создавать индексы по нужным полям. Создание
индексов оформлять как update к модулю проекта.
3. ПОСЛЕ запуска сайта (т.е. на живом сервере) необходимо включить все
возможные режимы кеширования:
- Кеширование блоков
- Кеширование views (в завиcимости от ситуации и возможности)
- Сжатие CSS и JavaScript
- Кеш страниц
14. Спасибо за внимание
Юрий Глушков — ARDAS GROUP
г.Днепропетровск.
Связь:
Skype: yuriglu
ICQ: 562-904-730
Тел: (066) 048-8485, (096) 186-7634
E-mail: yury.glushkov@ardas.dp.ua, glyuri@yandex.ru
