Извлечение из Правил

25.11.2012

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

Задача, которую передо мной поставили, была такова. На сайте нужно организовать доску свободных объявлений с автоматической регистрацией пользователя, который такое объявление оставил. При этом пользователю должно на e-mail прийти сообщение с логином и паролем. После регистрации он должен иметь возможность редактировать свое объявление или удалить его совсем. Сайт работает на Drupal 6.x.

Вот так вот. Резоны о премодерации и прочих вещах, способных в конечном итоге упростить администрирование успеха не возымели. Нужно было сделать так, как заказали. Коль шла речь о автоматической регистрации, сразу пришёл на ум модуль rules, позволяющий совершать довольно обширный список различных действий по определённым условиям. В данном случае таким условием было создание объявления анонимным пользователем.

Надо сказать, до этого я с rules не работал, этот заказ давал прекрасную возможность познакомиться с ним. Оставалось выбрать, каким образом организовать "объявление". Вариантов было два. Можно было воспользоваться популярным модулем webforms, позволяющим работать с разного рода интерфейсными элементами для создания анкет, опросов и т.п. Или, установив CCK (мне ведь для 6-го Drupal-а заказ пришёл), создать новый тип ноды.

Поначалу я попробовал webforms, решив обойтись без CCK. Сразу выяснилось, что он не очень-то дружит с rules, хотя и нашёлся вроде бы костыль в виде модуля webforms_rules, позволяющий связать действия с событиями webforms. Но окончательно эту идею "похоронил" views, которым я так и не смог вытащить нужные поля из submitted forms, для формирования списка опубликованных объявлений. Да, нашёл я и там какой-то костыль, по-моему webforms_views_submitted его название, но он у меня категорически ничего не выбирал, хотя поля для выбора во views появились.

Пришлось использовать классический подход, что оказалось, пожалуй, даже проще. Потому что нода - это есть нода, с ней будет работать любой модуль. Устанавливаем CCK и дополнительный модуль email, добавляющий ему соответствующий тип поля. Включаем поля "Email", "Option Widget" (У объявлений есть поле "Раздел"), и "Text".

Создаём новый тип материала "Объявление" с такими полями. Для "раздела"  используется виджет "Select list".

Так выглядит страница добавления нового объявления, создание которых мы сделаем доступным анонимам.

Теперь создадим правило, реализующее заказанный клиентом функционал. Срабатывать оно должно на событие "Node - После сохранения нового контента". Кстати, перевод фразы Triggerred Rules как "Запланированные правила" несколько некорректен, что может сбить с толку.

Срабатывать правило будет на группу условий ("Созданный материал новый" И "Тип материала - Объявление" И "Пользователь-автор - аноним")

Теперь настраиваем действия. Их тоже будет три, как видно из предыдущей картинки. Во-первых, создание нового пользователя, во-вторых изменение авторства нового объявления с "Гостя" на пользователя, созданного первым шагом. И в-третьих, отправка по указанному e-mail-у письма с регистрационными данными. Вот так создаём пользователя.

В качестве логина я применил конструкцию user+номер ноды. "Номер ноды" повторяться не будет, даже если такое объявление будет удалено. Для подстановки используем шаблоны, предоставляемые замечательным модулем token. Например, e-mail берём из созданного объявления, используя [node:field_email-raw]. Все возможные в данном случае шаблоны можно увидеть, развернув секцию "Шаблоны маркеров замещения". Помимо этого, нужно задать еще названия переменных, хранящих имя созданного пользователя и его пароль, которые понадобятся нам при отправке письма. У меня это user_added_from_advert и user_added_from_advert_pw.

Второе действие - изменение авторства.

Третье действие - отправка письма пользователю. "Send a mail to an arbitrary mail address" отличается от "Послать письмо пользователю" тем, что в первом случае можно выбрать e-mail, а во втором выбирается пользователь. Можно использовать любой вариант.

После создания всей этой конструкции, включая ещё и создание вьюхи, выводящей список объявлений, выяснились некоторые особенности. В частности, оказалось что при выполнении действия "Create user" происходит проверка по таблице users на присутствие в ней e-mail, с которым мы пытаемся этого user-а создать. И если такой адрес уже присутствует, действие не срабатывает. При этом не выводится никаких сообщений, пользователь не создаётся, авторство не меняется, письмо не уходит. У меня это выглядело так - вроде всё работало, письмо получено. После этого ЧТО-ТО произошло, и всё сломалось. Прошло определённое время, прежде чем до меня дошло, что дело в том адресе, который я раз за разом выбирал.

Update: На этом, однако, всё не закончилось. Последовало продолжение.



Комментарии

Александр
11.12.2013

Здравствуйте!
Скажите, а какой режим регистрации пользователя указывать в настройках, с подтверждением по мейлу?
Спасибо

kwoqer
13.12.2013

На сайте, для которого делалась доска объявлений, установлено так: "Посетители могут создавать учетные записи, разрешение администратора не требуется", при этом стоит галка "Требуется подтверждение по электронной почте, когда посетитель создает учетную запись". А какая разница? Ведь в данном случае используется вход без регистрации, пользователь создаётся автоматически.

Добавить комментарий