Реализация корзины

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

  1. Корзина хранится в БД
  2. Если пользователь известен (залогинен), то id корзины записывается ему в профиль
  3. Если пользователь неизвестен (гость), id корзины сохраняется в долгоживущую cookie

Надо предусмотреть действие на случай, если гость накидал товаров в корзину, а потом авторизовался и у него оказалась еще одна, непустая, сохраненная корзина.

Нужно предусмотреть механизм удаления старых корзин.

Почему бы просто не хранить все это добро в сессии? Спросите у маркетолога, какие идеи у него появляются при словах «брошенная корзина». :)

Кстати, бегло просмотрел несколько бесплатных скриптов — такого функционала не увидел. Максимум хранят корзину у известного пользователя, а корзину гостя в сессии.

SPF/DKIM годно-ли?

Пока изучал, что к чему и как настраивать различные подписи писем, чтоб получатели не вываливали мои письма в спам, нераз натыкался на топики, где люди с упоением писали, что правило, скажем, для SPF, надо жестко указывать как Fail («-all»), а не SoftFail («~all»). Ню-ню. Половина, если не больше, скриптов разных CMS, недо-CMS и прочих контактых форм на сайтах, не утруждая себя, отправляет письма с сайта от вашего имени, т.е. подставляет в адрес отправителя указанный адрес из контактной формы. Если почта у владельца сайта, скажем, на Google, есть шанс, что вообще не увидит этого сообщения. Ни во «Входящих», ни в «Спаме».

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

Google как-то вообще очень вольно с письмами обращается. Часть писем, которые он считает спамом, молча убивает. И никто об этом не узнает.

Сижу, проверяю подведомственные скрипты на тему отправки фидбеков с сайта. Так, чтобы отправителем числился сайт, а в поле Reply-To был реальный адрес посетителя сайта.

Почтовые адреса

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

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

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

  1. Почтовый индекс
  2. Страна
  3. Регион, штат или другая территориальная единица (если есть)
  4. Город
  5. улица, дом, квартира и т.д.

Для крупных городов, например, для Москвы или Санкт-Петербурга можно дополнительно спросить ближайшую станцию метро. В Webasyst Shop-Script это реализуется дополнительным полем.

Применительно к России возникает вопрос к 3-му пункту, у нас весьма пестрое административное деление. Самое простое — воспользоваться списком кодов субъектов РФ из Википедии. Но тут надо иметь в виду, что некоторые субъекты могут входить в состав других — автономные округа могут входить в состав краев и областей. Большинство реализаций скриптов этого не предусматривают, а зря. Деление на регионы должно быть не плоским списком а древовидным!. Стоп, не надо бежать срочно добавлять поле «parent_id» в существующую базу. Надо сначала погуглить на тему nested sets и проникнуться.

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

Также имеет смысл хранить список наиболее крупных населенных пунктов каждого региона, чтобы пользователь мог выбрать город из списка или написать, если в списке нет нужного населенного пункта. Минимум опечаток — максимум точности при определении стоимости доставки.

Update. Раз уж речь зашла о древовидном хранении, то список страны-регионы_(области, края и т.д.) можно хранить в единой таблице. В ней корневыми элементами или элементами первого уровня (корень тогда будет «World» :) ) будут страны. Для классификации можно воспользоваться стандартом ISO 3166 и его подразделами относительно административных единиц.