войти зарегистрироваться

Drupal whois

индекс
128,53

Создание сайта из готовых компонентов на примере сайта заказа еды в офис

В окрестностях нашего офиса нет приличного общепита, поэтому обеды нам привозят на заказ из одного кафэ. Заказ осуществляется за день (на понедельник заказ делается с пятницы), по телефону, с перечислением всех блюд и их количества (в случае если заказ не изменился относительно вчерашнего достаточно просто сказать это). Как компания, занимающаяся разработкой ПО, преимущественно веб, мы до недавнего времени жили по принципу «Сапожник без сапог», и весь учет заказов велся ответсвенным за заказ еды человеком на листочке, в случае изменения заказа нужно было писать письмо этому ответственному человеку, а он уже пересчитывал общий заказ.

Выкроив немного свободного времени в перерыве между проектами реализовал (именно реализовал, а не написал — почему именно так, расскажу немного ниже) систему для заказа еды. За основу, как нетрудно догадаться исходя из тематики блога, была взята CMS Drupal, которая является моим основным инструментом уже около полутора лет.

Цели данного топика:
  • Показать новичкам на довольно простом примере, как создается сайт невысокой сложности на CMS Drupal
  • Кратко расказать про несколько основных модулей — как правило они применяются в 90% проектов на друпале
  • Показать как можно собрать сайт на друпале из готовых компонентов, не написав при этом ни одной строчки кода (на самом деле будет пара строк кода, но немного не в том виде, как он обычно пишется =))


Итак, что должно быть реализовано в проекте:
  • Меню — список блюд, разделенных на категории, с возможностью описания блюд
  • Индивидуальные заказы — пользователь может сделать и заказ, просмотреть его содержимое и изменить
  • Сводный заказ — список всех заказаных пользователями блюд с указанием их количества
  • Возможность делиться впечатлениями о блюдах — тут просто возможность комментирования и рейтингования



Начну я с небольшого отступления. Т.к. я в основном работаю с западными заказчиками и привык к английскому при разработке в Drupal, то все инструкции, примеры и скриншоты будут на английском (с небольшими вставками русского, когда сделать это будет проще =)). Но с локализацией вобще и с русификацией в частности у друпала все в порядке. Загрузить русификацию и почитать о локализации можно на сайте отечественной штаб-квартиры друпала. Так же прошу обратить внимание, что в статье перечислено достаточно большое количество модулей. Наличие огромного количества модулей является большим плюсом и в то же время некоторым минусом при работе с Drupal. Плюс в том что уже написано огромное количество функционала, для использования которого нам достаточно будет установить модуль и поставить пару галочек в настройках. Минусом же является то, что нужно знать какие именно модули нужно использовать для получения необходимого функционала, что делает точку вхождения в разработку на друпале досточно высоко.

Итак, приступам. Первое что нам понадобится, это собственно сам Drupal. На момент написания статьи последняя стабильная версия — 6.10. Установка друпала не должна вызвать никаких затруднений — все, ИМХО, предельно просто и понятно — инсталятор дает достаточно подсказок и пояснений. После установки у нас имеется девственно-чистая система.


Т.к. во время разработки нам очень много приется ходить по разным разделам сайта, то начнем мы с установки модуля Administration menu. Этот модуль создает меню вверху страницы для быстрой навигации по сайту для администрирования. Для установки модуля скачиваем его (на момент написания статьи последняя стабильная версия 6.x-1.3), распаковываем и помещаем в sites/all/modules (папку modules нужно будет создать самому, почему именно сюда — можете почитать в документации друпала). После этого идем в Administer -> Site building -> Modules и включаем модуль. Сразу после установки модуля должны увидеть вверху то самое администраторское меню, с выпадающими пунктами. Вобще, для того чтобы оно появилось, необходимо дать пользователям на это разрешение в разделе Administer -> User management -> Permissions, но т.к. мы сейчас работаем под пользователем с UID 1, то нам можно все и всегда (поэтому тестировать им ни в коем случае нельзя).


Теперь нам нужно создать новый тип контента, который будет представлять собой описание блюда. Для этого идем в Administer -> Content management -> Content types -> Add content type и настраиваем все необходимое нам. Я назвал тип контента Meal (врутреннее имя meal), переименовал Body в Description (ибо у нас тут будет описание), убрал галку с Promoted to front page, ибо мы не собираемся выводить информацию о блюдах на главную и покрутил немного настройки каментов.


Фундамент положен, и теперь нужно на его основе строить сайт. Одного описания и названия для блюда мало. Во первых нам необходимо разделять блюда по категориям (Салаты, Супы, Горячее и т.д.), затем нам нужна цена блюда и, добавим еще возможность прикрепления избражений блюда. Если первое мы может сделать при помощи модуля Taxonomy, который входит в базовую поставку друпала, то для остального нам нужно будет установить дополнительные модули. Для добавления полей разных типов в контент тайпы у друпала есть модуль Content Construction Kit (CCK). В его поставку включены как базовый модуль для добавления дополнительных полей, так и небольшой набор частоиспользуемых типов полей. Скачиваем, распаковываем и помещаем этот модуль в sites/all/modules (это набор действий одинаков для все всех новых модулей, поэтому больше описывать его я не буду, при установке нового стороннего модуля оно подразумевается автоматически). Для добавления цены нам понадобится поле типа Money, которое входит в состав модуля Money CCK field. Этот модуль зависит от нескольких модулей (узнать это можно зайдя в раздел управления модулями) — это Currency API, который является частью модуля Currency Exchange, Format Number API и Formatted Number CCK. Для добавления изображений к ноде (нода — это название еденицы контента в друале) вобще-то можно воспользоватся стандартным модулем прикрепления файлов, но нам хочется чтобы все было красиво, а посему воспользуемся настраиваемым полем для загрузки изображений. Для реализации этого нам понадобятся модули ImageField и ImageCache, а так же их зависимости — FileField и ImageAPI.

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

Итак, после того как все модули скачаны и помещены куда нужно идем в секцию управления модулями (Administer -> Site building -> Modules) и отмечаем галочками нужные нам модули. А нужны нам следующие — ImageField, Money CCK field, ImageCache, ImageCache UI, ImageAPI GD2 и Taxonomy (должен быть установлен по умолчанию, но если нет, то установим). Все требуемые им модули будут установлены автоматически (в установщике модуля Money CCK field верси 1.0 есть небольшая ошибка, и он выдает сообщение о то что его зависимости не установлены, хотя они устанавливаются автоматически, поэтому этот модуль придется еще раз отметить галкой и запустить установку).

Теперь создадим профиль для загружаемых изображений блюд. Для этого нам и нужен был модуль ImageCache. Идем в Administer -> Site configuration -> By module (сюда, потому что ImageCache UI почему-то не выносит ссылку на свои настройки в общий список), ищем модуль ImageCache UI и идем в единственный его возможный вариант настройки — ImageCache. Создаем новый набор настроек (Add new preset). Назовом его meal_img и добавим действие Scale (масштабирование). В поле Width укажем 120 (пикселей), а из поля Height удалим значение. Тогда изображения у нас будут масштабироваться с соблюдением пропорций и уменьшаться относительно ширины.

Теперь создадим категории, по которым у нас будут делится блюда. Для этого идем в Administer -> Content management -> Taxonomy -> Add vocabulary и заполняем поля:
— Vocabulary name — Категория
— Content types — Meal
— Required
После чего идем в раздел add terms нашего словаря и создаем несколько категорий (терминов).


Теперь можно переходить к добавлению необходимых нам полей к созданному ранее типу контента Meal. Для этог идем в Administer -> Content management -> Content types -> Edit Meal -> Manage fields и создаем нужные поля. А нужны нам следующие поля:
  1. Label: Cost, Field Name: field_cost, Type: Money, Form element: Amount and currency, после создания выбираем удобный нам вид отображения и валюту (почему-то всегда считал что Российский рубль это RUR, а тут почему-то RUB) и делаем поле обязательным для заполнения (Required)
  2. Label: Pictures, Field Name: field_pictures, Type: File, Form element: Image, обязательным это поле делать не обязательно, а максимальное количесто (Number of values) можно установить, например, в 3, ну и покрутить немного настройки, чтобы пользователям было проще добавлять новые блюда в меню.



Теперь нам нужно настроить отображение нод. Для этого идем в Administer -> Content management -> Content types -> Edit Meal -> Display fields -> Basic. Тут для поля Pictures нужно выставить:
— Teaser — <Hidden>
— Full node — meal_img image linked to image (для этого мы и создавали пресет)
Для поля Cost можно выставить поле Label в значение Inline, чтобы подпись к полю была в одну строку со значением.


Ну а теперь пришло время наконец-то создать несколько экзепляров блюд для дальнейшего тестирования. Для этого идем в Create content -> Meal и заполняем поля. Повторяем это действие несколько раз. Добавим по парочке блюд в каждую категорию.


Далее, добавим блюдам собственно возможность заказа и систему рейтингования (просто так =)). В этом нам помогут модули Flag и модуль Fivestar, для которого потребуется установить так же Voting API. Качаем эти модули, идем в панель управления модулями и включаем Flag и Fivestar. После установки, необходимо настроить модули. Для этого сначала идем в Administer -> Site configuration -> Fivestar и выбираем стиль, который вам нравится больше всего (я выбрал Basic с желтым набором цветов, наведя курсор на звездочки можно сразу увидеть как они будут выглядеть). Теперь нужно активировать систему рейтингов для контента, реализующего блюда. Для этого идем в Administer -> Content types -> Edit Meal и в разделе Fivestar ratings ставим галку Enable Fivestar rating, и выставим значение поля Teaser display в Clickable widget below teaser (пригодится нам позже). Остальные настройки можете крутить на свой вкус.


Теперь ненадолго отвлечемся от контента и сделаем несколько настроек для пользователей. Наш ресурс для заказа еды будет являться внутренним, но расположен он будет в глобальной сети, поэтому нам нужно как-то его защитить. Для этого мы во-первых отключим возможность регистрации новых пользователей (при устройстве на работу наш сисадмин заводит учетные записи в используемых нами системах — почта, форум, бейзкэмп, теперь еще и в системе заказа еды). Сделать это можно пройдя в Administer -> User management -> User settings и выставив переключатель Public registrations в положение Only site administrators can create new user accounts. Теперь идем в Administer -> User management -> Roles и добавляем новую роль (я назвал ее HabraUser). Теперь настроим права доступа. Для этого идем в Administer -> User management -> Permissions, убираем все права у групп anonymous user и authenticated user, а группе HabraUser даем следующий набор прав:
— comment module: access comments, post comments, post comments without approval
— fivestar module: rate content
— node module: access content
— user module: access user profiles


Теперь, наконец-то, добавим возможность заказывать блюда. Для этого нужно создать и настроить новый флаг. Для этого идем в Administer -> Site building -> Flags -> Add и создаем флаг с именем meal_order и типом Nodes. Задаем разные надписи (мой варинат можете посмотреть на скриншоте к этому абзацу), разрешаем только пользователям из группы HabraUser пользоваться этим типом флага, и применяем этот флаг только к нодам типа Meal. Показывать флаг будем как в тизере, так и на странице. Link type оставим в значении Javascript toggle — тогда флаг будет переключаться используя AJAX.


Ну что ж, 2/3 пути пройдено. Теперь осталось сделать отображение меню, отображение заказа пользователя и сводный заказ. Приступим к выполнению этих пунктов.

Для реализации всевозможных списков в друпале есть очень гибкий модуль Views, им мы и воспользуемся. Скачиваем, идем в панель управления модулями и включаем Views (ядро) и Views UI (админский интерфейс для управления вьюхами). Теперь создадим вьюхи для отображения блюд из разных категорий, для этого идем в Administer -> Site building -> Views -> Add и создаем меню с именем meal_menu, и типом Node. После чего попадаем на страницу управления вьюхой. Изначално у нас нет отображений, и мы можем настроить параметры общие для всех отображений. Я сделал следующие настройки:
  • Basic settings
    • Row style: Node -> Display only teaser, Display links (отображать ноды полностью, показывать только тизер и линки — в линках у нас будет флаг заказа)
    • Items to display: 0 (все блюда на одной станице)
    • Access: Role -> HabraUser

  • Sort criteria
    • Node: Post date: Ascending (тут можете выбрать что вам больше нравится)

  • Filters
    • Node: Published: Yes
    • Node: Type: Is one of -> Meal


В итоге должно получиться то же самое что у меня на скриншоте (жирным выделены как раз измененные поля). Жмем кнопку Save и сохраняем текущее состояние базовой вьюхи.


Теперь создадим конкретные страницы для каждой категории блюд, унаследовав все страницы от базовой. Для этого в левой колонке настройки вьюх выбираемв выпадающем списке тип отображения Page (обычна выбрана по умолчанию) и жмем кнопку Add display и сразу же видим как у нас добавилось новое отображение во вьюху. Т.к.это конкретное отображение — у него несколько изменился набор параметров — добавились параметры меню, и исчезли общие настройки вьюх. Теперь нам нужно переопределить некоторые параметры базовой вьюхи. Первое что нам нужно — добавить фильтр на тармин из словаря категорий таксономии. Для этого добавляем новый фильтр Taxonomy: Term и в нем:
  • Vocabulary — Категория (он у нас, собственно, только один)
  • Selection type — Dropdown
  • Operator — Is one of
  • Select terms from vocabulary Категория — Горячее (нужно выбрать только один термин)


Теперь очень важное действие — необходимо нажать кнопку Override, для того чтобы этот фильтр применился только к этому экзепляру отображения. В противном случае он применится к базовому отображению. Теперь жмем Update, что сохранит наш новый фильтр. Далее, дадим отображению имя и заголовок по названию термина. Т.е. поменяем в Basic settings параметры Name и Title (тут так же необходимо будет нажать Override для переопределения параметра, относительно базового отображения) на Горячее. Теперь, для того чтобы можно было попасть на страницу, реализующую данный тип отображения необходимо установить для нее путь. Делается это в разделе Page settings, например meal_menu/hot. Сохраняем вьюху (доэтого все действия заносились во временное хранилице, и легко могут быть отменены).


Теперь повторяем те же самые действия, но для всех остальных терминов таксономии. В итоге должно получиться 3 (у меня 3 термина в словаре, сколько категорий блюд будет в мню, столько и терминов) реализации отображения. У меня они имеют следующие названия/заголовки и пути:
  • Горячее — meal_menu/hot
  • Салаты — meal_menu/salad
  • Супы — meal_menu/soup

Посмотреть что получилось можно перейдя по ссылкам вида View «Салаты», расположенным вверху.


Теперь, когда у нас есть составные части меню, в виде списков блюд по категориям, самое время занятся самим меню. Для этого воспользуемся модулем Panels. На момент написания статьи стабильной версии модуля для шестой версии друпала нет. Есть 2 версии модуля, находящихся в версии альфа — 6.x-3.0-alpha2 и 6.x-2.0-alpha3, т.е. достаточно ранние. И хотя рекомендованной отмечена версия 2.0, мы все же воспользуемся версией 3.0, хотя бы потому что она более новая. А по опыту использования могу сказать что по моим субъективным ощущениям стабильность этих двух верий находится примерно на одном уровне, причем достаточно высоком. Версия 6.x-3.0-alpha2 так же имеет в замисимостях модуль Chaos tool suite. Качаем и идем в панель управления модулями. Там активизируем следующие модули — Chaos tools, Delegator, Panels и Views panes.

Теперь создадим саму страницу с меню. Для этого идем в Administer -> Site building -> Pages -> Add page. Задаем имя и путь для страницы (в моем случае и то и другое meal_menu). Далее добавляем правило доступа на страницу (как вы помните мы создаем сайт для внутреннего использовани, но с доступом через Интернет, поэтому дадим доступ только созданной нами группе). Т.к. меню — это основная функциональная страница сайта, то добавим ссылку на нее в главное меню. Для этого выберем в Type Normal menu entry, зададим заголовок (у меня это Meal Menu) и выберем в Menu Primary links. Далее выберем одиночный обработчик для нашей страницы (Create a single handler for this page) и установим его в Panel (если честно, никогда не пользовался множественными обработчиками). Теперь настроим обработчик. Зададим для него такой же уровень доступа как и для страницы. Из шаблонов нам больше подходит Three column 33/34/33 (по одной категории в колонку, хотя на живом сайте у меня в эти же 3 колонки помещено больше категорий). Далее зададим заголовок для страницы (например Meal Menu) и выберем стиль для панели (советую Rounded corners, ибо этот стиль по умолчанию дает достаточно большое и удобное расстояние между колонками). Ну и наконец добавим в колонки созданные нами ранее отображения вьюхи — meal_menu: Горячее, meal_menu: Салаты, meal_menu: Супы. Если хочется поменять порядок следования вьюх в колонке или поменять колонку для некоторых вьюх — достаточно просто перетащить их — Drag&Drop работает стабильно. Наконец жмем Finish и… не замечаем абсолютно никаких изменений =)


Все дело в том что модуль Panels пользуется своей системой для определения возможности доступа пользователя, поэтому пользователь с UID 1 не имеет привелегий. Как мы помним, доступ к меню был дан только пользователям из группы HabraUser, поэтому просто добавим себя в эту группу. Для этого идем в редактирование своего профиля (My account -> Edit) и в разделе Account information ставим галку HabraUser в поле Roles и сохраняем профиль. Теперь в главном меню появился пункт меню, который и приведет нас на страницу с меню. Теперь мы можем сделать заказ, и перейти к следующей части =)


После того как заказ сделан, нам интересно посмотреть свой заказ у себя в профиле. Для этого опять же воспользуемся возможностями модуля Views. Идем в Administer -> Views -> Add и создаем вьюху с именем user_meal_order c типом Node. У базового отображения (я бы сравнил его с абстрактным базовым классом в ООП) делаем следующие настройки:
  • Basic settings
    • Style: HTML List -> Unordered list
    • Items to display: (все)

  • Relationships
    • Flags: Node flag -> Include only flagged content, Flag: Заказ еды, By: Current user

  • Fields
    • Node: Title -> Label: <пустое значение>, Link this field to its node

  • Sort criteria
    • Flags: Flagged time -> Ascending

  • Filters
    • Node: Published -> Yes


Теперь добавим новое отображение типа Block и добавим следующие настройки:
  • Basic settings
    • Title: Мой заказ (не забудте нажать Override пред сохранением параметра, чтобы переопределить его, а не менять у базового отображения)


Сохраняем вьюху и идем в панель управления блоками Administer -> Blocks -> List. Там в списке находим наш блок, user_meal_order: Block, и добавляем его в регион Left sidebar. Для удобства перетаскиваем блок в самый низ списка блоков региона. Сохраняем настройки блоков. Мы видим что блок появился в левой панели. Но я считаю что не очень красиво, чтобы этот блок болтался на всех страницах. Сделаем так, чтобы блок был виден только в профиле у владельца. Для этого жмем configure рядом с нашим блоком и попадаем на страницу редактирования настроек блока. Тут нас интересует раздел Page specific visibility settings. Устанавливаем параметр Show block on specific pages в значение Show if the following PHP code returns TRUE (PHP-mode, experts only) и пишем в поле ввода следующее (да, это первый кусочек кода =)):

<?php
global $user;
return (arg(0) == 'user' && arg(1) == $user->uid);
?>


Спасибо пользователю brmn за подсказку в оптимизации этого кусочка кода.

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


Последнее что нам осталось реализовать — сводный заказ, т.е. список всех заказаных блюд с указанием их количества. Для этого опять же воспользуемся модулем Views. Для этой страницы нам понадобится дополнительный модуль, поэтому идем в панель управления модулями и включаем PHP filter (идет в стандартной поставке). Теперь идем в Administer -> Views -> Add и создаем вьюху с именем meal_order c типом Node. Изменяем у базового отображения параметры следующим образом:
  • Basic settings
    • Style: HTML List -> Unordered list
    • Row style (настройки, иконка в виде шестеренки, нужно будет сделать после того, как будет пройден пункт Fields): ометить оба поля и в качестве разделителя вписать " — "
    • Items to display:
    • Distinct: Distinct (в противном случае у нас будет столько строк с одним блюдом, сколько раз оно заказано)
    • Access: Role -> HabraUser

  • Relationships
    • Flags: Node flag: Include only flagged content, Flag: Заказ еды, By: Any user
    • Flags: Node flag counter: Include only flagged content, Flag: Заказ еды

  • Fields
    • Node: Title: Label: <пустое значение>, Link this field to its node
    • Flags: Flag counter: Label: <пустое значение>

  • Sort criteria
    • Node: Post date -> Ascending

  • Filters
    • Node: Published -> Yes


Затем добавляем новое отображение типа Page и переопределяем в нем в разделе Basic settings следующие параметры:
  • Title: Сводный заказ
  • Header: Display even if view has no result, Input format: PHP code и в поле ввода забиваем следующее (да, второй кусочек кода =))
    <h3>Дата:
<?php
echo ((date('w') > 0 && date('w') < 5) ? date('d.m.Y', strtotime('+1 day')) : date('d.m.Y', strtotime('next Monday')));
?>
</h3>

    Т.е. выводим дату следующего дня, если у нас сейчас пнд-чтв, либо понедельника, в противном случае.

Теперь в разделе Page settings зададим путь (meal_order) и создадим ссылку в главном меню (Normal menu entry). Сохраняем, и видим в главное меню добавилась ссылка на страницу с общим заказом, куда можно сходить и убедиться в работоспособности выборки. Теперь можно выкладывать систему в Интернет и создавать аккаунты своим коллегам (Administer -> User management -> Users -> Add user)


Дополнительно, сдантартная тема друпала предоставляет CSS для удобного вывода страниц на печать.


Вот вобщем-то и все, что я собирался рассказать в этой статье. Все что задумывалось в проекте — достигнуто. Достигнуты ли цели топика — решать читателям. Жду отзывов и вопросов.

PS: На создание живой версии сайта для мой компании ушло порядка 2.5 часов. В это время входило вбивание порядка сотни наименований блюд (правда без изображений).

UPD:
Заинтересовавшимся темой разработки на друпале могу порекомендовать замечательную книгу, по которой в свое время учился сам — в ней все достаточно понятно и подробно описано (правда во втором издании нашел ошибку в коде =)). Книга называется Pro Drupal Development (издатльство Apress, ISBN 9781430209898). Книг таких в природе существует 2 — первое и второе издание. Первое описывает Drupal 5, второе издание — Drupal 6. Найти их в сети достаточно просто. Книги советую читать в оригинале, т.е. на англ. Ибо о существовании второго издания на русском ничего не знаю, а первое недавно купили в офис (спустя пол года как перешли на Д6) — какое-то оно тонкое, такое чуство что там что-то сократили.
+88
15 марта 2009, 14:46
krig

комментарии (115)

  • Спасибо, помогли!
  • ожидаем наплыв рекламы в чате DC++ «продам еду через сайт». Но это шутка.

    А вообще, своим топиком Вы показали, как понимаю, что иногда (если не часто) проще воспользоваться готовыми решениями, чем городить огород.

    Огромное спасибо за топик.
    • Именно так.
      Этот проект не подразумевает высокой нагрузки (хотя я потихоньку добавляю функциональности нашему внутреннему ресурсу), поэтому никакой оптимизации не требуется. Нужно было готовое решение, собранное за короткий промежуток времени — и оно есть. Сейчас я даже не стал устанавливать и настраивать механизм кэширования для панелей, хотя он опять же идет в комплекте.
      • И все-таки… сколько запросов на страницу?
        • Страница «меню» — 108 запросов
          Страница «сводный заказ» — 37 запросов
          Страница с описанием одного блюда (с изображниями) — 51 запрос

          Все таки включил модуль Panels simple cache, включил кэширование для страницы «меню», но в итоге только получил сообщение об ошибке. Все таки alpha2 дает о себе знать.
          • пиздец, простите — мне религия не позволит такое сделать. Пишу и плачу — честно от того, что реально я ограничен. Когда меня просят: сделай мне простой сайтег, я отказываюсь. Я не могу пользоваться такими монстрами как битрикс/друпал/UMI.CMS и их аналогами по доброй воле. Мне очень жаль что спрос все таки будет стимулировать их, а не простые и заточенные решения интернет магазина, ведь согласитесь, весь этот функционал не сложно сделать в общем-то с нуля по-нормальному за 2-3 дня плюс за неделю — две заточить до обобщенного решения интернет магазина. Но нет никто не будет этим пользоваться. Что в итоге? в итоге мне для общего развития придется теперь изучить как там устроен друпал. Я плачу.
            Поздравляю с удачной диверсией в умы людей.
            • Это палка о двух концах. С одной стороны скорость разработки и удобство поддержки (согласитесь, что поддерживать сайт, созданный на CMS с детально документированным API значительно проще, чем продукт с большим количеством самописного кода), а с другой — производительность. И решение о выборе платформы необходимо принимать исходя из требований к проекту: сроки, планируемые нагрузки (сейчас и через год-два), удобство сопровождения.
            • может вы думаете что я ругаю друпал? нет! я в шоке от того что он востребован!
              я понимаю прекрасно вашу вилку между удобством /скоростью/производительностью.
              Хотя думаю что вы не верно оценили поддержку (что вы будите делать когда столкнетесь с неописанной проблемой? ждать релиза?), но боюсь холиварить посему мнение мое не призываю слушать. Сам факт того, что столь обобщенное решение есть и популяризовано, а более частного решения популяризованного нет — вот что меня удивляет
              • Сталкивались, и неоднократно.
                Иногда помогало гугление — система широко распространена и открыта, имеет много пользоватлей и программистов, велика вероятность что с преблемой уже кто-то сталкивался и решил ее. Некоторые проблемы решали сами, засылали патчи разработчикам, даже вносили патчи в ядро друпала.
              • а что здесь такого, что друпал востребован?
                1) не все являются гениальными программерами, что бы самостоятельно писать код
                2) для друпала туева хуча модулей, можно быстро нарастить функционал сайта и, как тут уже говорили, быстрее приступить к работе. а самостоятельно изобретать велосипед — это значит не ценить свое время.
                3) при постоянном росте производительности серверов, оптимизация запросов, алгоритмов уходит на второй план. вступает в действие оптимизиция бизнес процессов и т.п.
                4) друпал — это офигенный и очень гибкий ИНСТРУМЕНТ, который помогает быстро зарабатывать ДЕНЬГИ, при грамотном подходе. лично я занимаюсь разработкой сайтов с 2000 года, перепробовал все популярные движки, но не один меня не устраивал, так как Друпал.
                5) пока вы будуте писать один проект, я сделаю 3-4, более качественных в плане юзабилити.
            • А теперь смотрите.
              Мои 2.5 часа и ваши 1.5-2 недели — как думаете, какое решение выберет потенциальный заказчик? Отсюда и популярность систем быстрой разработки.
              Да, порой они монстроподобные.
              Да, они используют большое количество ресурсов системы.
              Да, чтобы сделать на них что-то нужно сначала выучить много материала.

              Но есть одна проблема — разницу между 10 и 100 sql-запросами заказчики не понимают, а вот разницу между оплатой 10 и 100 часов работы — понимают очень хорошо.

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

              Речь конечно же идет о небольших пректах. В больших и сложных проектах уже другие категории оценки и другие сроки.
              • Попросту для инвестора проект на Drupal имеет больше шансов на завершение с положительным результатом, а вот проект где всё пишется с нуля — больше подвержен провалу. При инвестировании нового проекта взвешиваются все риски и выбираетс Drupal, WordPress и т.д.
              • Пипец, сайт за один день! Я в восторге! Заказчик доволен!
                • «Один день» и «одна неделя»- это обстрактные отрезки времени, показывающие только то, что первый отрезок меньше второго.
                  А можно поинтересоваться, сколько у вас успешно завершенных серьезных (т.е. не домашняя страничка) проектов, продолжительностью больше 3 месяцев, написаных с нуля?
            • Кстати, уже есть отличное обобщенное решение для создания интернет-магазина — это Magento.
              • Магенто конечно куль, да только там тоже не все так гладко ))) — хотя опыт работы у меня с ним соовсем небольшой, но имхо многие моменты не имеют настроек. Например зачем мне в магазине shipping при заказе??? и вообще — я хочу чтоб у меня на самой странице /cart/ была форма для ввода/выбора данных покупателя и покупателю не нужно было бы вводить кучу информации и нажимать кучу кнопок для оформления заказа (ведь этот фактор может отпугнуть многих потенциальных покупателей)
                А попробуйте все вышеописанное сделать без патчей кода…
              • Оно-то отличное… но тормозит круче любого Друпала… :)
              • есть Ubercart для Drupal
            • Все можно оптимизировать, при желании и знании. За три дня, все это можно заточить к приемлимой скорости, получая при этом все обозначенные плюсы. И минимум самописа по функционалу.

              Вторая вещь, о которой я часто думаю — цена гигабайта оперативы, которая сейчас составляет 20 баксов. Вставьть эту планку в сервер, используйте memcached (модуль включается одним кликом), и окончательно забудьте о самописе. Повторяю, цена вопроса — 20 баксов. Против ваших двух недель разработки (в районе тысячи $).
              • НЕ могу себе даже представить такого диалога, с моими заказчиками
                Заказчик: твой сайт тормозит
                Программер: купите сервер помощнее )
                Заказчик: твой сайт еще кладет нашу БД
                Программер: ну купите больше памяти на серв
                Заказчик: o_O но щас на сайте только пару человек ходит, что же будет дальше
                Программер: может кластер замутим…
                • ну вы слишком утрируете, у меня на VPS крутится сайт с посещаемостью 3000 уников без проблем, к лету планирую добавить на этот же VPS еще пару таких проектов
                  • А какой у вас vps?
                    • Тариф Optimal
                      hosting.agava.ru/vps/tp_optimal.shtml
            • Приймите соболезнованя. На Joomla! этот функционал делается основным инсталлом + 3-4 модуля. Все free of charge. Основное время около 1 раб. дняя уйдёт на внесение (и фотографирование, если нет) их меню.

              Вопрос в другом: помните картинку про Linux? «Из простой буханки хлеба вожно с помощью напильника и пары-тройки запчастей и нехитрых приспособлений сделать троллейбус. НО НАХРЕНА?»

              Ведь никому кроме программиста это не нужно было — все и так жили прекрасно«с бумажкой».
              • Ждем от вас примерно такого же подробного рассказа про Joomla
            • Если этот сайт нормально работает на стандартном хостинге и выдерживает запланированную нагрузку (думаю она в районе 300-500 человек в сутки) — то абсолютно по барабану сколько он делает запросов.

              А с учетом того, что сделано это за 2,5 часа — вообще не вижу проблем. Понадобится — переделают с нуля, не велика потеря.
  • Огромное спасибо за топик. Заново понравился Друпал. :)
  • сколько времени ушло?
    • На создание живой версии сайта для мой компании ушло порядка 2.5 часов. Я написал об этом в постскриптуме.
      На написание статьи ушло значительно больше времени =)
  • Друпал — отличнася CMSка, только у нее есть проблема — жрет много ресурсов.
    На дешевых тарифных планах хостеров Drupal тормозит.
    • Кэш спасет мир.
      • Кеш — не панацея
        • Панацеи не существует.
          Просто должно быть понимание что можно и что нельзя делать при помощи того или иного инструмента.
          Если сайт статический — почему бы и не друпал? А если динамический да еще и высоконагруженный — так это отдельны разговор.
          • Страшный вы человек )
            • Почему?
          • Если сайт статический, то на что там CMS??
            • ну даже статические сайты надо наполнять информацией, добавлять-удалять статьи.
              А контент-менеджеры, или кто там этим будет заниматься, не всегда хотят учить html :(
              • Ну тогда этот сайт уже не будет называться статическим.
                • почему же не будет?
                  А если странички всё так же будут храниться на жёстком диске в статичных html файлах? Или в базе данных в виде статичных статей из простого форматированного текста? Иными словами содержимое сайта меняется только под воздействием контент-менеджера. В остальное время (и при других условиях) он статичен ;)
  • Хорошая статья ;) Приятно видеть своих людей и здесь.
  • На создание живой версии сайта для мой компании ушло порядка 2.5 часов. В это время входило вбивание порядка сотни наименований блюд (правда без изображений).
    Топик писали наверное гораздо дольше. Спасибо!
    • Чистого времени — часов 6-7. Если учитывать время на сон, еду и жизнь вне сети — около двух дней.
      Но оно того стоило =)
  • Эх, если бы я увидел такой топик, когда только разбирался, с чем едят Друпал. Спасибо за статью.
    • Тогда бы он и не не помешал =)
      Первые пол года моего знакомства с друпалом я занимался исключительно написанием подулей и, соответственно, изучением его апи. Мне давали задание, что нужно от модуля, и я его выполнял (проект был большой, специфичных модулей было написано немало). И только потом я начал разбираться с «безкодовыми» решениями на друпале — вначалае было очень тяжко. Тогда казалось что проще за пол часа написать руками несколько запросов и передать результаты в шаблон. Но потом ничего, разобрался. Хотя пошаговых мануалов по использованию модулей с примерами в сети не так уж и много. Собственно это мой вклад =)
  • Отличная статья, только скринкаст нужен. В какой-то момент понял, что уже ничего не понимаю… Видимо придется по шагам все описанное пройти. :) Но туториал отличный. :)
    • Т.е. видеоролик с пояснениями чего сейчас происходит?
      Когда в следующий раз соберусь написать статью — обязательно подумаю о таком виде подачи материала.
      Думаю что по времени может занять даже меньше, чем написание текста и создание скриншотов. Несколькими модулями научился пользоваться именно таким образом — благо английским владею неплохо, чтобы смотреть англоязычные ролики.
  • «Как бы ты не менял drupal, его всегда можно узнать по форме авторизации» :-)
    • далеко не факт, просто есть более приоритетные задачи чем форма авторизации
    • Да ну? =)
      • а возможно ли это сделать используя стандартные модули? )
        • Внешний вид, без написание кода, поменять не удастся.
  • опечатки:
    дял
    для отображения люд из разных категори

    • Спасибо, поправил.
  • спасибо за топик.
    вы могли бы еще коротко рассказать про другие полезные модули (например о Administration menu узнал только от вас)?
    • Да, пожалуй стоит рассказать о частоиспользуемых и полезных модулях Drupal.
      Как выкрою еще свободного времени — обязательно этим займусь.
      • Вот. Только что нарыл. Разбирался с drupal+javascript и Drupal.behaviors…
  • спасибо огромное за статью!

    как раз попросили сделать нечто подобное.

    особенно за модуль currency, api очень поможет :)

    есть ещё вопрос по views.
    • Задавайте. Постараюсь ответить.
      • мне нужно также сделать подобный каталог, правда для другой продукции.

        нужно сделать вывод нод на странице таксономии в таблицу (т.е. ноды подряд в таблицу).

        поковырял views для вьюшки taxonomy_term.

        настроить вывод я смог, но вот не показывается содержание полей Содержание и Teaser, т.е. собственно содержание страниц, однако nid и прочая информация показывается
  • Отличная статья!

    Вот бы ещё кто написал подробную статью про написание модулей под Drupal (только что-нибудь посложнее HelloWorld'а из мануала). А то начал изучать возможности друпала и так и бросил на основах :(
    • Давайте идею модуля — постараюсь сделать и рассказать как =)
      • даже не знаю, в принципе, всё равно
        ну или если ткнуть пальцем в небо, то давайте на примере форума

        я понимаю, что с нуля, «от и до» тяжело написать, поэтому можно просто только некоторые куски кода
        вот у меня возникли, например, возникли проблемы с:

        1. темизацией модуля

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

        2. переопределение стандартных функций
        возможно ли без правки ядра?

        вот у меня была такая проблема, сайт что-то типа магазина, пользователь ходит кладёт товары в корзину, а затем ему нужно авторизироваться (зарегистрироваться), есть ли какое красивое решение как привязать корзину к юзеру, я как-то через ж… сделал, писал корзину в сессию, а затем отлавил момент авторизации и затем писал корзину напрямую в базу

        и проблема была со стандартной функцией регистрации(авторизации), во-первых, есть ли возможность зарегистрировать пользователя не перенаправляя его на user/register, а самому из своего модуля показать форму, вызвать нужную функцию и добавить пользователя

        и проблема была в авторизации, задаю страницу куда пользователя должно перекинуть, если пользователь с первого раза нормально входит, то всё ок, юзера перенаправляют на нужную мне страницу, но если юзер введёт пароль не с первого раза или пощелкает поочердно по вкладкам «регистрации», «авторизация», то после авторизации его кинет на главную страницу.

        3. интересует взаимодействие с другими модулями
        например можно ли, чтобы все статьи с сайта дублировались в определённой ветке форума, первый пост — сама статья, ну а дальше комментарии
        как другие модули могут взаимодействовать с моим?

        4. также инересна работа модуля с элементами друпала, меню, блоками, нодами и пр.
        например, как генерировать динамическое меню
        • Для форумов есть модуль Advanced Forum — там и с темизацией все достаточно просто и настроек больше чем в стандартных друпаловских.

          Про межмодульное взаимодействие — тут можно подумать.
          • Да в том и дело, что нужно не готовое решение, а научиться самому нормально писать под друпал.

            Разбирать чужой код мягко говоря тяжело, и не всегда понятно почему сделано так, а не по другому, какие были альтернативы и почему от них отказались.
      • Востребованная идея модуля — портфолио/галерея товара с более подробным описанием.

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

        Интересует с точки зрения не столько вывода в клиентской части (что мы — не придумаем как двадцать картинок в табличку вывести?), сколько в плане управления этой радостью из админки пользователем — передвинуть картинку вверх-вниз-влево-вправо на матрице-табличке, изменить картинки так, чтобы это было удобно и все такое.

        Если я правильно оцениваю время — не должно больше часа — двух уйти.
  • никогда не любил (читай «так и не выучил») регулярки.
    <?php
  if (preg_match('#^user/(\d+)$#', $_GET['q'], $m)) {
    global $user;
    return ($m[1] == $user->uid);
  }
  return false;
?>

    не проще ли задействовать все тот же drupal?
    <?php
if (arg(0) == 'user') return (arg(1) == $user->uid);
return false;
?>
    • даже еще проще
      global $user;
return ( arg(0) == 'user' && arg(1) == $user->uid );
      • я тоже об этом подумал)
        зачем автору стока модулей, если он входную переменную вручную вытаскивает
        > if (preg_match('#^user/(\d+)$#', $_GET['q'], $m)) {
      • Согласен, значительно проще.
        Сразу не подумал об этом. Сейчас внесу поправку с статью.
  • И все-таки до чего же неюзабельная и тяжелая система. Правда и другие не лучше. :(
    • Вы, просто не умеете ее готовить ;)
      На самом деле, после не долгого изучения манов и api, пользование CMF Drupal становиться приятным и комфортным.
      Не стесняйтесь учиться!
      • Не про то я. Я имею ввиду юзабилити редакторского интерфейса.
        • Notepad++ — прекрасный редакторский интерфейс
        • ну смотря что вы имеете ввиду, если WYSIWYG — я например пользую TinyMCE + IMCE, очень удобно. все остальное настраивается через CCK
          • Нет. Весь комплекс построения и обслуживания сайта.
            Wisiwig — дело десятое.
            • ну, я например из статьи узнал про модуль Administration menu, мне очень понравился, повысит юзабилити моих проектов на порядок.
              • скорее не юзабилити проектов, а удобство управления
                • ну да, я имел ввиду «Весь комплекс построения и обслуживания сайта»
                  • постоением занимаетесь вы. И вы этим занимаетесь долго. Настолько долго что неудобство и тяжеловесность интерфейса уже не мозолит глаза.

                    А обслуживанием занимаются совсем другие люди. И они друпал до того в глаза не видели. Вот им как раз разбираться в этом тяжело.
                    Но опять же повторю это общее место в интерфейсах всех универсальных CMS. Есть совсем ужасные, есть не совсем. Друпал посередине.
                    • вы не правы, друпал я выбрал как раз из-за того, что для конечного пользователя все очень просто (если я продумаю интерфейс) — работа с текстом, закачка картинок, файлов, построение пользовательского интерфейса. поверьте, я поработал со многими системами и только на друпале я начал делать проекты, которые могут наполняться без моего моего вмешательства и лишних вопросов ко мне.
  • Система гибкая, но для серьезных проектов я лично выбирать drupal не буду.
    «Программирование» мышкой — не в моей вкусе )
    • drupal и не «программируется» мышкой для серьезных проектов.
      Это пост для начинающих. Для понимания структуры.
      Реальные перцы сами модули и темы пишут ;)
      • а если все равно писать самому придется…
        еще учитывая:
        > Страница «меню» — 108 запросов
        то для себя я выбор сделан. и не в пользу drupal

        и не надо мне говорить что кеш и оптимизация может помочь.
        если система даже для ЭЛЕМЕНТАРНЫХ задач требует мощного сервера и кеша, то проблема именно в системе.
        я понимаю что эта Плата за универсальность и гибкость. Этим страдают почти все CMF-ки. И такие системы всегда будут популярны, ни смотря ни на что.

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

          никакого мощного сервера не нужно. проблемы с «кэшем» в основном во время разработки. живой, готовый сайт носится как угорелый.

          человеку способному писать оптимизированное по запросам приложение не стоит заниматься друпалом. жаль что таких людей гораздо меньше чем тех которые так о себе говорят.
  • Спасибо, полезно!
  • Пробежал глазами, не увидел ссылки на Ubercart.
    Может автор объяснить почему не использовал готовое решение?

    Там вверху спор про самописность. Мнение новичка в программировании такое — CMS типа Drupal для достижения уровня понимания описанного в статье требует столько же времени как и изучение необходимого уровня для данной задачи, например в ASP.NET+MSSQL или PHP+MySQL. Drupal сложноизвращённый пример самописного фреймвока с псевдо ООП. По сути это отдельный язык, недвром по нему пишут целые книжки. Это очень серъёзный минус. Будь он в струе стандартного ООП от PHP это был бы огромный плюс.

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

    И самое главное — при написании самописной самой простой системы вы должны быть специалистом в нескольких областях. В Drupal вам помогает не одна тысяча человек.

    Другой вопрос — сложные специализированные вещи. Практически они требуют самостоятельного написания всего функционала. И тут уже Drupal и мышление по-друпаловски будет мешать.

    Друпал как хобби — 1 год. Доход около 500 долларов — 5 сайтов
    ASP.NET+MSSQL как хобби — 6 мес. Доход около 2000 долларов. -1 сайт.

    Выводы для себя и за того парня (заказчика) делайте сами.
    • Знаю о возможностях уберкарта, но сам им никогда не пользовался, а описывать модуль о котором я сам практически ничего не знаю — не самый лучший вариант.

      К тому же цель статьи была больше показать некоторые возможности друпала, некоторых основных модулей (Views, CCK) и компонентов (Blocks, Menu, Roles, Permissions) системы, а не сборка «магазина» самым оптимальным образом.
      • Я это и хотел сказать. Как пример — да. Но если говорить о практике — установка юберкарт сэкономит ещё 57 минут из заявленных полутора часов :)
        • сэкономит 57 минут для начинающего?
          боюсь, добавит пару-тройку часов.
          • Стоп!

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

            2,5 часа — это чисто клавишные.
            • Что значит чисто клавишные?

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

                Я про это. И вот когда вы были готовы вы смогли реализовать то что реализуется.
              • У меня это займёт 30 минут кстати :)

                Предлагаю соревнование — скоростное программирование на друпале.
                • Спасибо, я не поклонник спортивного программирования.
                  А вы в 30 минут включили создание примерно 100 едениц контента? =)
                  • при помощи nod_import буквально вчера я вбил в интернет магазин > 50 000 наименований — адрес zapchasti.yamotor.ru (проект пока тестовый, сделан вчера за 1 вечер)
                    так что 100 едениц контента вбивается за секунду, плюс время на подготовку CSV файла
                    • Я делал это при помощи FeedAPI + Parser CSV. Вот на это я потратил некоторое количество времени, ибо делал это первый раз. Пришлось немного почитать доку и посмотреть видео-туториал.
                    • будьте осторожны когда начнёте перевносить или пытаться обновить прайс. node_import пока (три месяца назад) плохо работает с категориями.

                      не реагирует на галки «заместить» тупо добавляет новые категории с одинаковыми названиями. и другие малоприятные глюки.
                  • Вы меня пугаете.
                    100 единиц контента за 150 минут может сделать или вурдалак (человек укушенный волком и получивший нечеловеческие способности) или Б.Гейтс (что недалеко от вурдалака)
                    • А зачем вы считаете мое время? Я спрашивал про вашу оценку в 30 минут =)
                      Мои 150 минут на все — это свершившийся факт. Как я уже упоминал выше — повторение того же самого функционала с контентом займет у меня скорее всего не более полутора часов.
                      • нет. это ложное время. я про 30 минут.

                        у меня расценки:
                        1 позиция товара — 10 минут.
                        1 текст а4 с форматированием — 2 часа.
                        изображения — коэфициент 1,5

                        Мне кажется, но эти мои цифры более правильные как по отношению ко мне так и по отношению к заказчику. Чтобы не получилось как в анекдоте
                        — С какой скоростью набираете текст?
                        — 1500 знаков в минуту!
                        -?!!!
                        -Правда такая ерунда получается.
  • спасибо за tutorial.
  • А зачем panels, можно ж все через блоки, точно так же вывести?
    • ТС, спасибо за идею, всё в коллекцию.
    • В данном случае — да, вполне можно было обойтись блоками.
      Но т.к. цель данного туторала не сделать самым оптимальным образом, а показать возможноти и модули, то я выбрал панели — прост чтобы люди узнали о их существовании и возможностях и не городили огород в проектах, когда это совсем не нужно (видел пару экземпляров).
  • дошел до пункта поставить модуль Ctools и тут страница списка модулей перестала грузится. Удалил. загрузилось.
    На этом эксперимент закончил ;-)
    • странно, можно поподробней?
      • ну подробнее чем в инструкции некуда, т.к. делалось ровно по шагам и по тексту.
        Единственное отличие, что не которые модули стали чуть свежее версией.

        И после:
        >>Там активизируем следующие модули — Chaos tools, Delegator, Panels и Views panes.

        — теперь зайти в раздел modules можно если удалить директорию Ctools

        Может завтра попробую снова, обнулю базы, удалю все и поставлю заново.
        • А какие симптомы? ПХП отваливается по таймауту или из-за нехватки памяти?

          Вобще во время активной разработки рекомендую совсем отрубать модуль Update Status, чтобы хождение за статусами десятка модулей занимат немало времени, а т.к. при разработке приходится постоянно чистить кэш (либо он сам чистится на некоторых операциях), то и за обновлениями система ходит постоянно.
          • Ну вот снова, удалил всю директорию сайта, полностью DROP-нул базу данных, пошел по пунктам. Дошел до:
            >>Там активизируем следующие модули — Chaos tools, Delegator, Panels и Views panes.
            После установки галочек и нажатия Save, страница модулей перестала грузится.

            Кстати, Views panes — такого нет, есть Views content panes.

            Страница модулей никакого html текста не содержит, видимо её не отдает?
            • В пхп вывод ошибок включен?
              Подозреваю что просто пхп вылетает по таймауту, а вывод ошибок отключен.
              display_errors в пхп включен?
  • Почему-то потерялись все картинки… =(
    Можно попросить автора топика их вернуть?..
    Спасибо большое.
    • Все изображения потерялись из-за того что умер ipicture.ru
      Исходные изображения я не сохранил — понадеялся на картинкохранилище. В итоге потерял иллюстрации для нескольких статей и пары раздач на торрентах.

      Более того — сама статья немного устарела — админский интерфейс Panels 3 сильно изменился с тех пор, как была написана статья.

      Но вобще — статья даже без картинок имеет ценность, ибо я стрался все моменты прописывать, а изображениям отводилась вспомогательная роль.
      • Ясно. Жаль, конечно…
        А если я очень попрошу вас снова их выложить/сделать, вы найдёте время для этого?

        Заранее спасибо, а то всё-таки очень информативная статья была с картинками…
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.