Всё о форме подписки.

Об извещении о работе с персональными данными.

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

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

Несмотря на некий идиотизм ситуации, когда пользователь совершенно добровольно оставляет свой e-mail, чтобы Вы могли с ним связаться, либо переслать пользователю какие-то материалы, ему же и нужные, это тоже трактуется как работа с персональными данными пользователя. И тот в явном виде должен согласиться, чтобы Вы узнали его e-mail адрес.

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

Если Вы возымеете желание как-то тот канцелярит отредактировать, то искать его текст следует в файле пользовательских интерфейсов, который в дистрибутиве расположен по адресу ./data/content/postman/index.php

Подписка через стандартный функционал Почтовой Наны.

Оговорка:

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

Пожалуйста, внимательно изучите данный документ.
Он в полной мере раскрывает все возможности.

По пути "Управление службами" - "Выбрать службу" - "Форма подписки" Админка Почтовой Наны среди прочего покажет URL, по которому расположена так называемая стандартная форма подписки. Стандартная она потому, что построена на шаблонах движка Наны, но может быть изменена как угодно в файле пользовательского интерфейса ./data/content/postman/index.php (согласно инструкции по инсталляции Почтовой Наны, файл пользовательского интерфейса расположен в указанном месте, но Вы вправе заселить Почтовую Нану в какую-нибудь другую папку, и тогда файл следует искать там).

URL стандартной подписной формы генерируется макросом (кликабельно):
---JobForm---

Пользователь заносит в форму то, что у него спрошено, и жмёт кнопку.

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

Давайте вспомним, что у Администратора есть возможность для каждой службы сформировать так называемую "морду службы", что делается в Админке по пути "Управление службами" - "Выбрать службу" - "Шаблоны файлов" - "Морда службы".

URL морды службы генерируется макросом (кликабельно):
---JobPage---

Чтобы перенести все слова и картинки с "морды службы" на страничку стандартной формы подписки этой же службы, надо адресовать пользователя по URL, генерируемому макросом (кликабельно):
---JobFull---

Учтите, что если документ "морды службы" уже оснащён формой подписки, всё равно в каком виде и дизайне, и эта форма заключена в теги комментариев

<!-- Code Start --> ... <!-- Code End -->

то весь HTML код в этом месте будет удалён, а вместо него подставится стандартная подписная форма. Что наглядно видно на примере.

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

Любителям тайтлов:

Обратите внимание, что через стандартные макросы Почтовой Наны документу можно назначить Subject, если это письмо, или Title, если это web-документ. Документы "морды сервиса" и "морды службы" не являются исключением, и тайтлы для них тоже легко задаются.

При импорте контента "морды службы" на страничку стандартной формы подписки возможность подстановки тайтла тоже сохраняется. В демодоступе по ссылкам выше всё это прекрасно видно.

Подписка через Морду Службы, либо любой внешний сайт.

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

То есть Почтовая Нана взаимодействует с подписчиком не одинаково. Если он подписывается непосредственно на страничке стандартной подписной формы, то заполненная подписчиком форма сразу инициирует процесс подписки. Если же форма подписки заполнялась где-то в другом месте (на стороннем сайте, на "морде службы" как варианте стороннего сайта), данные пользователя предъявляются в виде заполненной формы для повторной отправки.

Тут может возникнуть закономерный вопрос, зачем эта повторная форма вообще нужна.

Есть очевидная причина.

При перекодировке имени подписчика из UTF кодировки стороннего сайта, какой-нибудь символ, коих в UTF многие сотни тысяч, запросто может породить дикую кракозябу, и она не пройдёт валидацию. А потому кракозябу придётся поправить руками, так что без формы тут не обойтись.

Есть также и не очевидная причина. Её надо понять.

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

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

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

Минимальный код подписной формы.

Напоминание: подписная форма для каждой службы индивидуальна, поэтому путь к её коду пролегает очевидным образом: "Управление службами" - "Выбрать службу" - "Форма подписки".

Естественно, Вы ни в коем случае не ограничены дизайном подписной формы, предлагаемым админкой. Используйте какое угодно оформление, какие угодно стили, Java скрипты и прочий Аякс. Всё это абсолютно не важно. Жизненно необходимый "скелет" подписной формы будет всего лишь таким:

<form
   action
="http://..." 
   
accept-charset="windows-1251"
   
method="post"
   
target="_blank"
>
   <
input type="hidden" name="do" value="Подписаться">
   <
input type="email" name="email">
   <
input type="text" name="fio">
   <
input type="submit" name="go" value="Тут любые слова">
</
form>

Имена полей менять нельзя.

Дополнительные поля подписной формы.

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

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

Чуть подробнее:

Например, партнёр с логином Assistant берёт форму подписки с морды службы, и добавляет в неё скрытое дополнительное поле, всего одну строчку:

<input type="hidden" name="user_aff" value="Assistant">

Разместив модифицированную форму где-то у себя, он поставляет подписчиков совершенно постороннему ресурсу. Казалось бы, глупость.

Однако в коде третьего письма в ссылке на магазин присутствует специальный макрос ---Field=aff--- В итоге все продажи по такой ссылке засчитываются партнёру Assistant

Правила работы с дополнительными полями:
  1. Имена дополнительных полей обязаны быть в формате user_xxx
    Где xxx - произвольные символы латинского алфавита и цифры.

  2. Соответствующее поле в письмо подставляет макрос ---Field=xxx---
    Где xxx - часть имени дополнительного поля user_xxx

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

Пожалуйста, понимайте, что разговор про партнёрскую программу тут абстрактен. Вместо логина партнёра вполне можно указать идентификатор сайта, где располагаются формы подписки. Тогда в разделе "Управление службами" - "Выбрать службу" - "Состав базы данных" в пункте "Активность партнёров" будет понятно, с какого именно сайта идёт больше подписок.

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