Textpattern - на русском языке

И еще один документ...
----------------------------
Итак - оформление заказа.

По сути - это кнопка, со стороны посетителя она так и будет выглядеть.

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

и отдельный скрипт, который указывается в письме пользователя с кодо подтверждения, который должен
1. в базе пометить, что заказ подтвержден
2. отправить письмо администратору сервиса (т.е. где-то должен быть атрибутом емэйл, этот емэйл может не совпадать с емэйлом админа ТП) , в письме указывается содержимое заказа (видимо - опять по шаблону), данные о заказчике
3. проверить все неподтвержденные заказы в базе и если срок жизни подтверждения вышел (тоже где-то надо устанавливать), чистить поле с кодом, чтобы если через полгода кто-то случайно нажмет на ссылку с кодом подтверждения) скрипт просто выдаст, что заказ устарел

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

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

Я думаю, было бы не плохо изучить решения конкуренты. Напримерн, есть модуль для ВордПресса, сейчас появилось решение для ТхР, есть модуль для Друпала. Можно посмотреть логику работы там и потом начинать строить своё решение.

Возможно все. Писал модуль для сайта на jQuery+cookie+немного_php

Получается достаточно удобно и красиво. Но, без яваскриптов и печенек не работает, так что - некоторым приходится звонить по телефону магазина

Похоже, придётся много цитировать. Мне так удобней, надеюсь, вам тоже и это никого не будет напрягать. Всё, естественно, IMHO.

Evgeny написал:

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

Евгений, ты смотришь с позиции разработчика, но это не совсем правильно в данном случае. Да это почти никогда не правильно :) Настройки не должны быть атрибутами тэга, они должны быть внутри админки в удобном и понятном интерфейсе.

Evgeny написал:

3. Текущее количество товаров в корзине. Отображение состояния корзины.
4. Итоговая стоимость товаров, сейчас находящихся в корзине. Отображение состояния корзины.

Почему бы не совместить?

Evgeny написал:

6. Тэг для вывода итоговой суммы содержимого корзины.
7. Тэг для вывода кнопки "Очистить содержимое корзины"

Мне кажется, почти всё, что касается  корзины (кроме вывода её содержимого), стоит делать одним тегом с атрибутами. Если атрибутов нет, выводить код с максимальными фишками.

Evgeny написал:

8. Тэг для вывода кнопки "Пересчитать" итоговую сумму.

Зачем? Почему сразу правильно не считается?

Evgeny написал:

содержимое заказа нужно куда-то сохранять (желательно не в базу).

Почему не в базу? Это удобно.

Evgeny написал:

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

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

Evgeny написал:

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

Это да, массовая загрузка данных была бы очень востребована. Но это почти нереальная задача, так как нет общего стандарта. У кого-то в exel хранится всё, у кого-то, наверно, в каком-нибудь 1C и т.п.

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

Evgeny написал:

НА сегодняшний момент я бы разделил задачу на 2 части
1. Создание каталога товаров и работы с ним.
2. Создание корзины.

Я пришел к такой концепции, что каталог товаров как отдельная сущность в TxP не нужен. Один товар - одна статья. С дополнительными полями.

Отредактированно BrokenBrake (22-07-2009 02:14:59)

Xeon написал:

Ух, хорошо что тема ожила! Со всем тем, что выше согласен.

BrokenBrake написал:

Один товар - одна статья. С дополнительными полями.

А что будет на главной? Бесконечный список товара? Или его там вообще не будет и он будет доступен только через меню с подкатегориями?

А на главной будет то, что захотите - хотите, список самых популярных товаров (=статей), хотите, список выбранных вами обычных статей, хотите - ничего не будет.

При подходе товар="1 статья с полями", вся реализация происходит очень быстро.

BrokenBrake,  со всеми замечаниями согласен.
Это и есть особенности реализации.

По поводу массового экспорта-импорта данных о товарах - стандартом стало использование csv-файлов. С которым работают и 1С и Excel и, все чаще встречающийся у клиентов, Open Office Calc

Каталог товаров нужен не для ТхП, а для пользователей :-)
Каталог товаров - это отдельная задача. Которая часто востребована. Общего решения для нее нет.
Имеется в виду готовое решение со структурой сайта, с рубрикацией, упорядоченным и определенным набором полей, всей перелинковкой. Куда остается добавить дизайн и данные. Вот такое решение хотелось бы иметь в арсенале разработчика :-)

Корзина востребована значительно реже, чем каталог товаров.
Ну - это по моему раскладу... У других может быть и наоборот.

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

Но вот анонсирование в TxP 4.2 возможности создания своих тем для админки дает шанс устранить этот недостаток.
Так что у магазина на ТхП есть будущее :-)

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

Уважаемые, а в каком состоянии разработка?