Andyceo's Words

Приветствую, дорогие читатели! Меня впечатлила одна недавняя статья на drupal.org о разработке сайта по продаже кое-каких примочек к фотошопу. (На самом деле, меня впечатлило несколько статей, но об остальных я напишу позже, если вообще смогу выделить для этого время.) Вроде бы, ничего необычного в ней нет. Просто один человек, John Forsythe, решил, что "пришло время приложить свои навыки, как Drupal-разработчика, в запуске нового бизнеса в Интернете". Разумеется, своего бизнеса. И это правильно, я считаю! Пусть каждый Drupal-разработчик, будет иметь свой приносящий доход бизнес. А может, даже не один. Кого заинтересовал - читаем мой перевод этой статьи. Также хочу добавить, что перевел и некоторые показавшиеся мне толковыми комментарии к статье, что добавило статье живости и полезных сведений.

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

Спустя несколько месяцев разработки, родился StyleWorks. Сайт работает на Drupal 6, а также интегрируется с FastSpring для реализации электронной коммерции.

Проектирование сайта: Zen или не Дзен?

После сотен итераций дизайна в Photoshop, я, наконец, получил представление о том, чего хотел, и пришло время, чтобы оно ожило в Drupal. Но сперва нужно было сделать ключевое решение: начать с нуля, или использовать Zen?

Традиционно, я всегда делал свои дизайны "с нуля". Я что-то вроде наркомана по оптимизации, и люблю писать действительно легкий код (Раньше я был более категоричен в этом, чем сейчас. Правда, когда я писал DrupalModules.com, я избегал использования вещей вроде CCK, предпочитая вместо этого писать собственные модули). Поэтому, когда я впервые посмотрел на тему Zen несколько лет назад, мое первое впечатление было "блин, ты только посмотри на весь этот лишний код! Почему здесь так много стилей"? *Удалил*

С тех пор, Zen стала дико популярной, став темой № 1 на Drupal.org. Я всегда объяснял эту популярность растущей аудиторией не-разработчиков Drupal, но, услышав несколько положительных отзывов на недавней встрече Drupal-разработчиков, я решил дать Zen еще одну попытку.

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

Что я имею в виду под гибкостью? Вот пример:

Когда в середине проекта я решил перейти от одноколоночного макета к макету из двух колонок, мне не нужно было переписывать код, Zen позаботился об этом. А потом, когда я решил отказаться от первого дизайна и дать сайту совершенно другой вид, я смог осуществить это всего лишь несколькими правками, внесенных в исходный код.

Ясно, что я недооценил Zen.

Однако, гибкость Zen приходит благодаря нескольким компромиссам.

Если вы привыкли все стили класть в один длинный CSS файл, дзенский шквал в 30+ стилей может поначалу вас немного расстроить. Там отдельные CSS-файлы для практически всего (фоны, страницы, вкладки, формы, поля и т.д.). К счастью, для большинства из этих файлов редко возникает необходимость редактирования, так что фактическое количество стилей, которые вы будете править одновременно, ближе к 6, чем к 30.

Строгое разделение правил CSS в Zen является немного неэффективным для меня. Я не уверен, что есть реальная польза в разделении стилей фона и границ для одного DIV`а в два различных файла. С таким количеством файлов, может быть сложно отслеживать, какие правила в каком файле (я нашел, что Firebug будет очень полезным в этом отношении).

Гибкая конструкция колонок также имеет некоторые недостатки. Если вы думаете об изменении размера макета, будьте готовы к небольшому экскурсу в школьную математику. Вам придется складывать и вычитать значения в нескольких местах, чтобы отрицательные отступы работали как прежде. Это объясняется достаточно хорошо в комментариях к коду, но раздражает необходимость проделывать это каждый раз, пока вы экспериментируете с размерами колонок.

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

Выбор разметки

Так как стили слоев для Photoshop − это в первую очередь визуальный продукт, мне нужен макет, который может вместить большое количество изображений, в то же время оставляя место для описания продукта. Итак, я решил работать с простым двухколоночным макетом: изображения продуктов слева, описательный текст справа.

Вопрос только в том, как получить текст и изображения в отдельных столбцах. Я посмотрел на целый ряд различных решений для работы с разметкой, в том числе Panels и Composite Layout, но ни один из них не счел достаточно подходящим.

В идеале, я просто хотел бы использовать столбцы (регионы) темы Zen. Один из способов сделать это заключается в использовании блоков, но я не хочу создавать новый блок для каждой страницы на сайте!

Вот тогда я и обнаружил модуль Nodes in Block.

Nodes in Block позволяет создавать специальные блоки, которые динамически отображают контент на основе текущего пути. Например, можно настроить один и тот же блок, чтобы он показывал опрос или рекламу, в зависимости от того, где пользователь находится на сайте. Контроль того, что проявляется в блоке, осуществляется с помощью настроек видимости для ноды (это очень похоже на стандартную настройку видимости блока).

Так что я создал тип контента для изображений продуктов, а другой тип контента для описания продуктов, и использовал Nodes in Block, чтобы получить их оба на одной странице (изображения в основной области контента, описания в боковой панели через блок). Это работало, но разделение продукта на две различных ноды далеко от идеала.

Тогда у меня появилась умная идея отображения одной и той же ноды в обеих областях. Все, что мне необходимо было сделать, это проверить переменную $node->nodesinblock в шаблоне ноды, и я мог контролировать, какие поля и на какой части страницы будут выводиться.

Заставить ноду отображаться два раза было достигнуто путем установки в ноде настройки видимости модуля "Nodes in Block" на свой собственный путь.

Структура нод

Благодаря решению использовать модуль Nodes in Block, я был в состоянии объединить изображения и описания продукта в общий тип содержания, названного "демо-версия продукта". Сам по себе этот тип контента является достаточно простым, опирается только на текст и файлы.

Текстовые поля:

• Полное наименование
• Краткое наименование
• Подзаголовок
• Короткое описание
• Полное описание
• Характеристики продукта
• Цена
• Ссылка на корзину

Файловые поля:

• Изображение для краткого описания (файл)
• Демо-изображения (файл)
• Изображения текстур (файл)

Сайт также использует традиционный тип контента "страница" (слегка видоизмененный, содержащий поле файла для изображений). Ноды типа "страница" используются в основном для не-продуктов, например, страниц "О сайте" и "Лицензия", но в конечном итоге я также использовал его для страницы группы продуктов, так как она не очень вписывается в тип контента "демо-версия продукта". В конце концов, я могу создать другой тип содержимого для этих специальных страниц продаж.

Переопределение строк

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

Как правило, эти кусочки текста в конце разработки можно жестко запрограммировать в шаблонах, но я действительно хотел, чтобы они оставались редактируемыми в Drupal. Моим решением было использовать функцию Drupal t(), а также приятный маленький модуль, который называется String Overrides.

Теперь я просто включаю этот небольшой фрагмент кода, в мой шаблон ноды...

<?php t('after_purchase'); ?>

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

Я подозреваю, что могут быть и другие (лучшие?) способы сделать это, но метод String Overrides был элегантен и его было быстро реализовать.

Установка системы электронной коммерции

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

Просматривая несколько малых бизнес-форумов, я все видел рекомендации по FastSpring, платформе электронной коммерции, которая обрабатывает все от приема кредитных карт к предоставлению загрузки файлов. Они даже позаботяться о сборе соответствующих налогов.

По-видимому, FastSpring был именно тем, что я искал, поэтому я решил дать ему выстрелить. Я смог зарегистрироваться в течение нескольких минут, а пару дней спустя, у меня была онлайн полная линейка продуктов, готовых к покупке.

Интеграция корзины FastSpring с моим сайтом было легким. Я добавил ссылку "просмотреть корзину" в меню Primary Links и создал новое текстовое поле CCK для моих продуктов "ссылка на корзину". Поле "Ссылка на корзину" есть просто URL, которое контролирует, куда передается форма "добавить в корзину" (каждый продукт имеет различный целевой URL). Когда пользователь нажимает кнопку "Добавить в корзину", он направляется непосредственно на защищенный сервер FastSpring, где он может осуществить заказ, или продолжить покупки (в этом случае, они возвращаются на мой сайт).

Я все же еще новичок в FastSpring, но первый опыт прошел на удивление гладко.

Производительность: Жизнь с 512 МБ памяти

Поскольку это был сайт электронной торговли, я чувствовал, что важно, чтобы он работал на своей собственной (виртуальной) машине. В настоящее время сайт размещается на 512MB VPS, работает под Ubuntu 9.10.

512MB является довольно небольшим объемом памяти на сервере, так что правильно настроить систему было очень важно. Если серверу не хватает памяти, она начинает обращаться к файлу подкачки, эффективно убивая всю производительность.

Первым шагом было остановить Apache от создания слишком многих процессов. Вот ключевые настройки (я использую режим Prefork):

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 13
MaxRequestsPerChild 0
KeepAlive Off 

С максимумом в 13 одновременных подключений, важно отключить поддержку подключения (KeepAlive), иначе посетители надолго застрянут в ожидании свободного слота во время пикового трафика.

Далее, я оптимизировал файл настроек MySQL, используя рекомендации от отличного скрипта-тюнера MySQL (отредактировано: Далин предлагает эту переделанную версию). Вот самое важное:

key_buffer = 32M
sort_buffer_size = 4M
read_buffer_size = 4M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 4M
query_cache_limit = 1M
query_cache_size = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
max_connections = 20
table_cache = 1024
skip-innodb

И наконец, я установил XCache, кешер байткода PHP, и настроил его так:

xcache.size = 16M
xcache.count = 1
xcache.slots = 8K

Кроме того, я включил агрессивное кэширование страниц в Drupal, кэширование блоков, сжатие страниц, CSS-оптимизацию, и JS-минификацию через модуль JavaScript Aggregator.

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

Список модулей

Из-за ограничений памяти 512MB, я старался держать количество установленных модулей как можно ниже. В конце концов, мне удалось получить список до 17 именно этих (некоторые из которых в настоящее время отключены, такие, как Devel).

Связанные с содержанием:

• Content (CCK)
• FileField
• ImageField
• Text (Part of CCK)
• Nodes in Block
• String Overrides
• Insert
• Token

SEO и производительность:

• Global Redirect
• Page Title
• JavaScript Aggregator
• Google Analytics

Средства разработчика:

• Administration menu
• Devel
• Backup and Migrate
• Database Logging
• Update status

КОММЕНТАРИИ К СТАТЬЕ

adrianmak - 14 августа 2010 - 6:52: Можете ли вы рассказать больше о том, как использовать Nodes in Block, для разделения вывода различных полей ноды, в разные части страницы (это связано с регионами?)

JohnForsythe - 14 августа 2010 - 7:06: Главное, установить оператор if в вашем шаблоне ноды node-type.tpl.php. Мой код выглядит примерно так:

<?php // ### normal output ### ?>
<?php if (!$teaser && !isset($node->nodesinblock)): ?>
    <div class="content">
      <?php
        foreach($node->field_demoimages as $images) {
          print $images['view'];
        }
      ?>
      <div class="links">
        <?php print $node->field_demonode[0]['nid']; ?>
      </div>
    </div>
<?php // ### node-in-block output ### ?>
<?php elseif (!$teaser && isset($node->nodesinblock)): ?>
    <div class="content">
      <h1 class="title"><?php print l($node->field_shorttitle[0]['safe'], 'node/'.$nid);?></h1>
      <h2 class="subtitle"><?php print $node->field_subtitle[0]['safe']; ?></h2>
 
      <?php print $node->field_longtext[0]['view']; ?>
      <?php // (etc...) ?>
    </div>
<?php endif; ?>

Таким образом, в зависимости от того, установлена ли переменная $node->nodesinblock, мы печатаем различные поля CCK.

patcon - 15 августа 2010 - 1:04: Отличное учебное пособие, Джон! Не представлял, что модуль Nodes in Block может быть настолько универсален!

Есть одна мысль, однако: не рассматривал ли ты возможность использования модуля Display Suite, для избежания необходимости пользовательской переделки шаблонов? Nodes in Block интегрируется с Display Suite так, что он обеспечивает новый "режим построения" ("build mode") в разделе "Показать поля" ("Display fields") конкретного типа контента (в дополнение к стандартным RSS, Basic, Search и Token). Таким образом, вместо создания шаблона с условным отображением полей, проверяя $node->nodesinblock, вы можете просто скрыть некоторые поля в Content type > Display fields > Basic > Full node, и скрыть альтернативный набор полей в режиме построения Nodes in Block.

Я хочу сказать, что преимущество будет в том случае, что если кто-то захочет добавить поле или переместить его между колонками, тогда он мог бы сделать все это с помощью интерфейса "Показать поля" ("Display fields"), без необходимости переопределения шаблонов.

Эй, вы же упомянули, что любите простоту, так что я пойму, если вы намеренно избегали добавления нового модуля к проекту! Все же я думаю, это может помочь кому-то с другими потребностями :)

Diegen - 29 августа 2010 - 13:20: Привет.

Представления (Views) и несколько tpl смогли бы сделать это для вас? Я вовсе не говорю что мое решение лучше, я только любопытствую.

JohnForsythe - August 29, 2010 - 13:53: Есть много способов сделать это.

Конечно. Представления (Views), Панели (Panels), Composite Layout, Contemplates... Они все работают, с некоторыми небольшими доработками. Я смотрел на множество решений, но Nodes in Block поразил меня своей простотой. На самом деле, все это может быть сделано вообще только через CSS, не требуя каких-либо модулей. Каждое решение имеет свои преимущества и недостатки, компромиссы между мощностью, сложностью и гибкостью.

chx - August 14, 2010 - 07:05: Почему модуль Nodes in Block?

Свой модуль (с очень малым) количеством строк кода, мог бы это сделать, не так ли? Также, если уж вы хотите хорошо сэкономить память, отключите Devel и включайте только когда вы действительно нуждаетесь в нем, что на продакшене должно случаться редко.

JohnForsythe - August 14, 2010 - 07:17:

Свой модуль (с очень малым) количеством строк кода, мог бы это сделать, не так ли?

Nodes in Block небольшой модуль по сравнению с большинством других. Он требует всего несколько строк кода в шаблона с моей стороны, чтобы получить результат, который я хочу, и это экономит мне время написания и отладки своего собственного решения. В старое время, я бы, наверное, написал новый модуль просто чтобы увидеть, что я могу сделать в 70 строк то, что Nodes in Block делает в 700, но сейчас я доволен, оставляя работающее решение нетронутым.

Также, если уж вы хотите хорошо экономить памяти, отключите Devel и включайте только когда вы действительно нуждаетесь в нем, что на продакшене должно случаться редко.

Devel отключен, как я уже говорил:

(некоторые из которых в настоящее время отключены, такие, как Devel)

jurgenhaas - 15 августа 2010 - 6:49:

Спасибо John Forsythe за статью, действительно есть пара вещей, чему поучиться. Превосходно.

Все же есть один вопрос: рассматривали ли вы возможность использования модуля Boost? Я сам так сделал несколько месяцев назад и получил выдающееся повышение производительности. Это выглядит как очень надежное решение и делает потрясающую работу.

JohnForsythe - 16 августа 2010 - 21:57: Вот мой опыт работы с Boost:

Измеряя производительность сайта локально, Boost дал более чем вдвое высокую производительность, с 1100 запросов в секунду до 2700 запросов в секунду.

Однако, когда тестирование проходило с удаленного компьютера, производительность оставалась неизменной на уровне около 260 запросов в секунду.

Причина? При включенном агрессивном кэшировании в Drupal, время генерации страницы отлично держится около 10 мс. Даже если Boost будет в 10 раз быстрее, он сможет срезать лишь 9 мс от общего времени запроса.

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

themegarden.org - 16 августа 2010 - 9:13: Привет Джон, большая работа, поздравляем!

Каким провайдером VPS вы пользуетесь? Linode?

JohnForsythe - 16 августа 2010 - 20:27: Да, я начал с Linode 512, это хороший выбором для проектов, которые не очень подходят для виртуального хостинга. VPS.net также выглядит неплохо, но у меня еще не было времени для их изучения.

Stevo_0 - 24 августа 2010 - 4:05: Мне интересно узнать, почему вы не используете Ubercart, довольно простой в использовании, особенно для чего-то вроде продажи загружаемых файлов, и вы могли бы принимать заказы, используя только Paypal, чтобы не напрягать себя нахождением платежных шлюзов и т.д. Интересно посмотреть в сторону этой альтернативы. Каковы издержки выбора FastSpring?

JohnForsythe - 24 августа 2010 - 4:40: Я не люблю полагаться на PayPal, особенно для цифровых товаров. Я слышал слишком много ужасных историй. Они огромная компания, и у меня нет никаких рычагов влияния, если они решат вдруг заморозить мой аккаунт.

Основным бизнесом FastSpring является продажа цифровых товаров. Они работают с корзиной, биллингом, налогами, выполнением и т.д. Есть даже интеграция с Google Analytics E-commerce! Мне не нужно беспокоиться обо всем этом. Я просто загружаю свою продукцию, и все сделано. Чувствуется, что там гораздо меньше того, что может пойти не так. Но это всего лишь несколько недель, поэтому мы посмотрим.

Об экономии, они берут 5,9% плюс $1, или 8,9% (на выбор). Там нет платы за регистрацию, за наличие магазина и т.д.

altrugon - 24 августа 2010 - 19:35: О Zen

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

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

Если никто не делает так при работе с PHP или HTML, почему мы должны позволять такое в CSS?

Во всяком случае, поздравляю вас с проектом, и вы можете быть уверены, что будете чувствовать себя все более комфортно с Zen, больше используя ее.

Оригинал: Case Study: StyleWorks Premium Photoshop Styles

Автор перевода: andyceo

PS: В FastSpring можно загрузить пользовательские CSS/XHTML шаблоны, чтобы сделать корзину более похожей на ваш сайт.