CMS на основе XML

Web/сайты Прочее

Был(а) онлайн: 20.07.18 16:13
Umen 24 года

1.0 Был(а) онлайн: 20.07.18 16:13

Недавно
Привожу ниже ТЗ! НЕ нужно писать ставки, что цена 10000$! Цена этого плана 2000-4000 у.е 1 месяц на базовое написание. + 1 месяц на доработки. Связыватся только тем кто реально сумеет осуществить проект

ICQ 997544
Skype Sevasot
Тел 410-19-98

Партнерская система


1. Введение
- Надобно написать мини CMS систему партнерского магазина (по типу sotoshop.ru партнерский магазин http://www.sotmarket.ru)
- Конструкция стержневой базы данных есть и менять ее невозможно (на стороне основного магазина (сервер), на стороне партнерских магазинов (заказчик) база данных должна быть разработана)
- Обмен данными между заказчиком и сервером должен протекать в формате XML.

2. Системные требования к клиенту
- Язык реализации – PHP 5.x
- СУБД – MySQL 4.1.x

3. Обновление данных
Данные на заказчике обязаны обновляться раз в день в механическом режиме
Должно быть два варианта обновления (выбирается в админке заказчика):
а) механический – с поддержкой cron
б) полуавтоматический – при заходе всякого пользователя на сайт проверяется время последнего обновления, и если оно огромнее 24 часов, инициируется обновление
в) Через админку при клике на ссылку обновить
Данные для обновления будет генерироваться 1 раз в сутки на сервере.
Сервер принимает запросы на обновление и составляет из них очередь.
С определенным промежутком (предлагаю 10 мин) сервер запускает процедуру посылки обновленных данных заказчикам в порядке сформированной очереди, позже чего очередь очищается и процесс повторяется вновь.
Очередь очищается – но только позже того, как будет проведено обновление. Надобно предусмотреть приоритеты обновления, и для тех, кто вызвал его вручную – ставить их наверх очереди.
Все бинарные файлы данных (картинки, видео и т.д.) обязаны храниться на сервере, заказчику передается лишь ссылка.
Заказчик может локально модифицировать некоторые данные (Наименование, Title, Meta Keyword, Meta Desc опсиание, короткое изложение, картинки, опции для категорий и для продуктов), соответственно в админке заказчика должна быть настройка «перезаписывать модифицированные данные при обновлении – да/нет»

Сжатие данных при обновлении – система должна определять, дозволяет ли заказчик применять сжатие данных и в этом случае передавать данные в zip-архиве

Авторизация при обновлении – для всякого заказчика в базе данных сервера заводится учетная запись, при запросе на обновление заказчик должен передать данные аутентификации серверу.


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


4. Обновление кода и шаблонов

Заказчик периодично (раз в сутки) опрашивает сервер о доступности обновлений кода и/или образцов. Обновления бывают 2-х видов – устанавливаемые без одобрения заказчика, и устанавливаемые по одобрению заказчика. Для всех обновлений в админке плана должен быть список – обновление(версия), дата, изложение. Для тех, которые устанавливаются по одобрению – еще и кнопка «установить». При установке обновлений должна проверяться контрольная суммы файлов, которые будут переписаны при обновлении (т.е. не были ли файлы модифицированы локально на заказчике). Если сумма не совпадает – выводить ранг обновления – «не установлено из-за локальных модификаций».

Сжатие данных и авторизация при обновлении кода – см. предшествующий пункт

5. Учет клиентов

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

6. Модули клиента

Функциональность заказчика должна быть реализована модульно (к примеру: модуль, «новинки магазина», модуль «знаменитые товары»,
Модули обязаны отображаться в разделе «модули» в админке с вероятностью включить/отключить их, настроить параметры итога (число товаров для показа, показывать картинку либо нет).

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

Всякий образец должен иметь заблаговременно объявленные места для итога всех! модулей. По умолчанию включены те, что включены в выбранном образце. Потом компаньон выбирает какие ему необходимы, включает либо выключает их в админке. Для всякого модуля в админке должно быть предусмотрено действие «Получить яваскрипт код» (для вставки ссылки на продукт, категорию и т.д. с иного сайта). Яваскрипт код должен поставляться отдельным файлом совместно с модулем.

Модули, которые обязаны быть включены в поставку
1. Генератор ссылок на аксессуары для данной модели. Данные модуль разрешает выводить ссылки на аксессуары для данной модели. (В виде Ява скрипт кода либо PHP)
2. Генератор ссылок на категории + картинки. Данный модуль разрешает Вам выводить список категорий с картинками в Вашем магазине (В виде Ява скрипт кода либо PHP)
3. Информатор цены сотового телефона. Информатор цены сотового телефона разрешает выводить цену и ссылку для покупки телефонов в каталогах для определенной модели телефона. (В виде Ява скрипт кода либо PHP)
4. Информатор цены товара по ID. Данный модуль дозволяет выводить цену в каталогах для определенного товара по id(В виде Ява скрипт кода либо PHP)
5. Модуль итога блока новинок. Данный модуль разрешает выводить на партнерском сайте блок новинок в партнерском магазине. (В виде блока)
6. Модуль рекламы продажи сотовых телефонов. (В виде блока)
7. Модуль скидок и распродаж. Данный модуль разрешает выводить на партнерском сайте блок товаров со скидкой и распродажей. (В виде блока)
8. Модуль ТОП товаров.Данный модуль выводит на Вашем сайте блок полулярных товаров по продажам. (В виде блока)
9. Навигационное меню. Данный модуль разрешает выводить на партнерском сайте меню навигацию по категориям и изготовителям. (В виде блока)

7. Базовая функциональность клиента


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

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

По умолчанию в заказчике обязаны присутствовать страницы
- Главная
- Страница категорий
- Страница списка товаров.
В списке товаров должна быть предусмотрена фильтрация:
- По изготовителю и Модели
- По категории + Изготовителю + модели
+ Должна быть вероятность из админки добавлять фильтры (выпадающий список) в список продуктов по справочным полям.
- Страница продукта
- Аккаунт заказчика (здесь компаньон сумеет отслеживать ранг и историю заказа, даты доставки и т.д. Все данные по заказам берутся в режиме реального времени с сервера)
- Страница оформления заказа
- Поиск (текстовое поле, поиск по наименованиям продуктов, изложениям, категориям)

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

Система редактирования добавочного контента: в заказчик необходимо встроить систему, в которой компаньон сумеет создавать новые категории (страницы) и добавлять в эту категорию статьи (с подмогой VYSIWYG-редактора)


8. Шаблонная система

Система должна быть построена на шаблонном итоге (Smarty либо что-то сходственное).
В админке должен быть раздел «Образцы», где будут список доступных образцов (минимальная первая поставка 10 штук, образцы не примитивно с различным дизайном, а с различным итогом информаций, с различными настройками, с различными включенными модулями). Т.е. образец включает в себя не только файлы внешнего вида, но и файлы конфигурирования модулей.
Новые образцы скачиваются в процессе обновления кода (пункт 4).

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

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

9. Процесс заказа и покупки

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

a. Для поисковых ботов, представление сессии, представление регистрации не существует
b. Формируется 1 запрос, с указанием ID заказчика и посылается на наш сервер, в результат мы отдаем данные о том что в корзине о его истории, мы это делаем для того, дабы скажем те, кто положил в корзину товар, но не закончил заказ, мы ночью обработаем таких заказчиков и вышлем предложение закончить заказ
c. Когда товар кладется в корзину эти данные также отсылаются на наш сервер и вставляются в базу корзина
d. При регистрации заказчика все данные высылаются на наш сервер, а мы возвращаем ID этого клиента
e. Сама форма регистрации теснее сделана для сервера, она будет взята из него, пример bellmaster.ru кнопка купить

Чтобы добавить заявку к этому заказу, нужно войти или зарегистрироваться

Мой блок

20.07.18 16:13
Umen 24