Comments 28
Планирую в понедельник, на прошлых выходных не успел закончить.
Спасибо! ждём. Пока отдал сотрудникам на изучение. К понедельнику будут готовы ко второй части :) Следующие части будут?
По темизации наверное нет, что тут еще расскажешь. А какие темы еще интересуют?
Даже не знаю. Такие моменты как с темой омега — даже для меня открытие :) Я не знаю что у вас в загашнике есть :) Предложите.
А сотрудникам будет полезно многое. Например про панелс, вьшки, рулс. Коммерц и уберкарт опять же. Drush — не помешал бы. Это то что пришло на ум с ходу.
Еще раз подчеркиваю, что статья шикарная. А вторая часть на тему «лень-двигатель прогресса». Для быстрого, я бы сказал конвейерного создания тем для заказчиков отличный инструмент.
Не сказал бы, что облениться :) Но сосредоточиться на всяких дополнительных фишках и функционале, вместо пиления очередного велосипеда из page.tpl.php
Все настройки созданной подтемы хранятся в БД или экспортируются в info-файл?
В БД. Теоретически их можно экспортировать в Features и потом собирать платформу Drupal при помощи drush make, но хотел бы я посмотреть на человека, который в действительности построил на этом свой development workflow.
Большое спасибо за замечательную, прекрасно иллюстрированную статью.

Пробовал Omega, но идея группировать CSS-код по media queries, а не по структуре, мне не понравилась. Поэтому я отказался от Omega в пользу минималистичной базовой темы Boron и собственного starter kit'а.

Bootstrap и подобные «CSS-фреймворки» не использую принципиально из-за того, что они идут вопреки семантике. Вместо того, чтобы присваивать определенным блокам нужные свойства, CSS-фреймворк декларирует все возможные сочетания свойств под несемантическими классами. Эти классы нужно вставить в HTML блоков, чтобы свойства применились к ним… Ужасно!

Нет, это, конечно, позволяет по-быстренькому склепать тему оформления, но для серьезной работы не годится (мое личное мнение).

Гораздо более грамотный подход предлагает, например, SASS-фреймворк Susy.

Чтобы блок занял, скажем, четыре колонки, пишем:

----
// Файл: partials/blocks/.block-foo.sass
#block-foo
  +span-columns(2)
----

Чисто, семантично, аккуратно.

Susy позволяет задавать разное количество колонок в зависимости от ширины окна браузера. Я использую следующие диапазоны:
1) 0—400px — мобильники в портретном режиме;
2) 400—600 — мобильники в ландшафтном режиме;
3) 600—800 — планшеты в портретном режиме;
4) 800—1000 — планшеты в ландшафтном режиме;
5) 1000—1200 — нетбуки;
6) 1200—1400 — десктопы.

Напоминаю, что мобильные устройства имеют виртуальное разрешение, отличающееся от физического. Так, на типовом мобильнике с экраном 800×480 пикселов браузер считает, что размер экрана составляет 533×320 пикселов.

По дефолту количество колонок для каждого диапазона соответствует номеру диапазона (например, пять колонок на экране нетбука), но можно использовать и любое другое количество (причем, индивидуального для каждого контейнера и каждого диапазона!). Например:

----
// Файл: partials/blocks/.main-menu.sass
#main-menu

  // Изначально блок занимает всю ширину контейнера,
  // так что задавать значение для первого диапазона не нужно.
  // +at-bp(1)

  // Во втором диапазоне пускай тоже будет во всю ширину.
  +ap-bp(2)
    +span-columns(2)

  // Начиная с третьего диапазона и дальше список должен выстраиваться в строку.
  +from-bp(3)
    ul
     +horizontal-list

  // В четвертом диапазоне у контейнера данного блока должно быть три колонки,
  // из них одну занимает лого, а две других — главное меню.
  +at-bp(4,3)
    +span-columns(2 omega)

  // И так далее
  // ...
----

HTML-код при этом трогать вообще не нужно.

У метода есть несущественный недостаток: в итоговом CSS будут встречаться повторяющиеся участки кода. Из положения можно было бы выйти при помощи @extend, но большого смысла в этом нет, поскольку:
1) повторные куски прекрасно жмутся gzip'ом;
2) на читаемость кода это не влияет, ведь верстальщик работает с SASS, а там повторяются только вызовы mixin'ов, что не нарушает принцип DRY.
Пробовал Omega, но идея группировать CSS-код по media queries, а не по структуре, мне не понравилась. Поэтому я отказался от Omega в пользу минималистичной базовой темы Boron и собственного starter kit'а.

Можно не использовать отдельные файлы, предложенные омегой, а все писать в global.css, добавить туда media-queries самостоятельно.

Bootstrap и подобные «CSS-фреймворки» не использую принципиально из-за того, что они идут вопреки семантике. Вместо того, чтобы присваивать определенным блокам нужные свойства, CSS-фреймворк декларирует все возможные сочетания свойств под несемантическими классами. Эти классы нужно вставить в HTML блоков, чтобы свойства применились к ним… Ужасно!

Мне тоже поначалу претил такой подход. Но скорость разработки и простота дальнейшего обслуживания все перевесила. Drupal сам добавляет кучу классов ко всем компонентам, так что парочка дополнительных не помешает. Тем более, классы можно добавлять через админку Drupal, например, в выводе модуля Views задавать нужное количество колонок, которое занимает тот или иной компонент, не засоряя CSS. Сам CSS получается очень компактным, описывающим абстрактные классы. А верстальщик/редактор/админ сайта просто добавляет нужные классы нужным компонентам через админку, в любой момент может их менять, не прибегая к правке CSS.
Это не темизация а скоростное быстро-кепание типовых шаблонов сайтов (которых ~80% от всех) :)
Ну что уж там, уже само использование какой-либо CMS это «скоростное быстро-клепание типовых сайтов».

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

Хотя статья да, про скоростное быстро-клепание :)
В этой части статьи я рассказал о преимуществах и возможностях, которые дает Omega. Во второй части собираюсь рассказать о том, как прикрутить к ней Bootstrap. Таким же способом можно будет прикрутить и любой другой фреймворк. В принципе, ничего нового я не изобретаю, просто рассказываю, как можно воспользоваться уже имеющимся в Drupal и Omega функционалом. Bootstrap мне кажется самым зрелым, качественным и функциональным фреймворком, который оттачивается наиболее массивной аудиторией.
Прототипы собрать везде ± одинаково по скорости. Хотя поддержка в SCSS радует.
Мне больше www.profoundgrid.com нравится. Но тут на вкус и цвет… :)
foundation вроде как в лицензионнном не разрешается логотип убирать (или я путаю с кем то).
а также можно вставлять любой код без каких-либо ограничений
Удобно очень как, особено потом код искать везде где только можно. В допустимых значениях какого нить филда пхп код найти весело.
Суть — запросы в шаблоне — ХАРАМ!
Сам использую Adaptivetheme для своих проектов, в ней больше гибких настроек, чем в Омеге, есть поддержка panels и Gpanels, и тоже можно гибко настраивать ширину блоков в различных регионов в зависимости от грида. + очень удобная настройка поведения блоков для различных разрешений.
Плюсую за Adaptivetheme.

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

Adaptivetheme прекрасно документирована в коде, имеет намного больше настроек в админке, предоставляет большую адаптацию к HTML5 (чего стоит только поддержка figcaption для поля с изображением) + не нарадуюсь css в сабтеме — оставлены все возможные виды классов и айди, генерируемые Друпалом!
Когда я использовал AdaptiveTheme, в ней особых настроек не было. Надо будет попробовать, спасибо.
Only those users with full accounts are able to leave comments. Log in, please.