Эксперт по MODX
2,4
рейтинг
25 сентября 2013 в 06:11

Разработка → Готовая сборка интернет-магазина на MODX Revolution recovery mode

MODX*, CMS*
Часто, когда разработчик выбирает движок для очередного магазина, он обычно оценивает этот вопрос по нескольким критериям:
  • Платный/бесплатный (если платный, то сколько).
  • Какой функционал есть «из коробки».
  • Насколько легко докрутить какой-то свой функционал.
  • Как много он потянет товаров, чтобы на хостинг не разориться.
  • Насколько гибкие политики безопасности, чтобы обеспечить совместную работу различных отделов.
  • Какие платежные системы поддерживаются.

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

В конце статьи видео с кратким обзором движка и двумя способами установки

Важно!!! Забыл сказать: кто поленится посмотреть видео, но развернет у себя сборку, логин/пароль в админку по умолчанию: admin/admin.


Демо-сайт.


Прежде чем читать дальше, советую покликать демо-версию сборки.

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

Основа движка (а так же довольно большая предыстория)


За основу был взят фреймворк MODX Revolution. Только не торопитесь плеваться и закрывать страницу. Это не в точности тот MODX, с которым вам возможно приходилось встречаться. Я с MODX работаю с начала 2009-го года, и знаю его вдоль и поперек. И да, я как и многие сталкивался со многими его минусами (типа шаблонов и чанков в базе данных, тормоза и т.п.). Плюс к этому до знакомства с MODX много работал с различными самописками и другими движками, и на MODX-е я остался именно за его гибкость. Да, мне не все в нем нравится, но он позволяет с легкостью многое в нем изменить, при этом не трогая самого ядра. В процессе у меня появилось несколько компонентов, которые дополняют или меняют определенный функционал MODX-а. Вот парочка наиболее важных из них:
phpTemplates — позволяет статические MODX-шаблоны вызывать как обычные php-файлы.
modxSmarty — Подключает для фронта шаблонизатор Smarty и дополняет его некоторыми плюшками, обеспечивая тесное взаимодействие с самим MODX-ом.
shopModx — модуль для разработки интернет-магазинов.

В итоге MODX обретает не только полноценную шаблонизацию, но и гораздо бОльшую производительность. Сайты с десятками тысяч документов работают с откликом 0,02 — 0,6 секунд. Плюс к этому можно практически полностью забить на синтаксис самого MODX-а, и если вы умеете программировать на php и знаете Smarty — то здесь в разработке у вас никаких проблем не возникнет.

Но одна из самых важных вещей в MODX-е, которая точно меня держит цепями — это система пакетов (модулей для MODX-а). Она реально классная. Я даже написал модуль, который позволяет создавать свои собственные репозитории пакетов. Это особенно полезно различным веб-студиям и активным разработчикам. При этом самая вкусняшка заключается в том, что упаковывать можно не только отдельные модули, но и вообще все что угодно на сайте, хоть целиком, хоть по отдельности, хоть весь сайт вообще. Так появились снапшоты MODX-сайтов. Изначально это было реализовано только на самом modxcloud.com (официальный хостинг от разработчиков MODX-а), но совершенно без документации и каких-либо релизов ими был выложен скрипт vapor, который предназначался для того, чтобы любой мог сделать снимок своего сайта и закинуть его на modxcloud.com. При этом обратная связь как бы и не подразумевалась (то есть брать снимки с modxcloud.com и разворачивать на любом своем хостинге). Не буду вдаваться в подробности, но я взял этот vapor, модифицировал его и добавил ему еще один скрипт (import.php). Теперь с помощью этого скрипта можно как делать снимки сайтов, так и разворачивать их поверх чистого сайта. Скачать мой vapor можно из официального репозитория. И вот как раз с этим вапором я взял курс не только на отдельные модули, но и на готовые сборки сайтов.

В чем смысл таких сборок?

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

Что уже есть в этой сборке?


  • Добавлен компонент Billing. На этом модуле завязано все, что связано с заказами, оплатой и т.п.
  • Корзина перестала существовать отдельно. Теперь Корзина — это еще не оформленный Заказ (Order). Теперь даже не оформленные заказы хранятся в базе данных, что как минимум позволяет видеть кого что интересует, а так же определять реальный процент конверсии и выявлять возможные ошибки.
  • Компонент Basket (Корзина) остался, но почти все, что связано с самими заказами, перенесено в Billing. Basket и дальше останется отдельным модулем, а в Billing-е будет только необходимый минимум логики. Рассчет на то, что сам механизм заказа, оплаты и т.п. можно будет реализовывать в любых сторонних модулях, которые будут взаимодействовать с биллингом.
  • Добавлен и сверстан новый шаблон по умолчанию с использованием bootstrap. Много всяких аджаксовых плюшек и полноценное JS-API.
  • Добавлен табличный редактор документов.
  • Добавлено управление заказами.
  • Добавлен личный кабинет пользователя, регистрация, смена пароля, восстановление пароля и т.п.
  • Настроена регистрация через Login, смена/восстановление пароля и т.п.
  • Добавлен модуль modHybridAuth (авторизация через социальные сети). Пока четко проверены Twitter, Facebook и Google, но должны и другие работать.
  • Подключен сервис оплаты Robokassa.
  • Настроены политики безопасности:
    • Контент-менеджер;
    • Администратор магазина;
    • Менеджер магазина;
    • Продвинутый менеджер магазина.



Что дальше делать с этим сайтом после установки?


Делаете копию шаблона и меняете в нем все, что угодно. Шаблонизация на Smarty, входные данные массивами, все процессоры на классах. То есть не трогая ядра, можно переделать сайт как угодно.

Пример, как добавлять еще платежные системы

Вот у нас есть оплата через робокассу, и стоит задача прикрутить еще какой-нибудь способ оплаты. Посмотрим, как это делается.

Это базовый процессор для любых типов оплаты.
<?php

/*
    Абстрактный класс на проведение оплаты.
    Его нельзя вызывать напрямую, чтобы исключить случаи инжекта оплаты. 
    Этот класс должен расширяться другим классом конкретной платежной системы,
    чтобы использовать методы проверки платежа самой платежной системы
*/

abstract class modWebPaymentsCreateProcessor extends modObjectCreateProcessor{
    public $classKey = 'Payment';
    
    protected $BillingProcessorsPath;
    
    public function checkPermissions() {
        
        // Проверяем подпись платежной системы
        $ok = $this->checkSignature();
        if($ok !== true){
            $this->error($ok);
            return false;
        }
        
        return parent::checkPermissions();
    }
    
    public function initialize(){
        
        $this->BillingProcessorsPath = MODX_CORE_PATH . 'components/billing/processors/';
        
        $this->setDefaultProperties(array(
            'currency_id'  => $this->modx->getOption('shopmodx.default_currency'),
        ));
        
        if(!$this->getProperty('paysystem_id')){
            return $this->error("Не был получен ID платежной системы");
        }
        
        return parent::initialize();
    }
    
    public function beforeSet(){
        
        $this->setProperties(array(
            "createdby" => $this->modx->user->id ? $this->modx->user->id : null,
            "date"      => time(),
        ));
        
        return parent::beforeSet();
    }
    
    public function beforeSave(){
        if(
            !$currency_id = (int)$this->getProperty('currency_id')
            OR !$currency = $this->modx->getObject('modResource', $currency_id)
            OR ! $currency instanceof ShopmodxResourceCurrency
        ){
            return $this->error("Не был получен объект валюты");
        }
        
        if(
            !$paysystem_id = (int)$this->getProperty('paysystem_id')
            OR !$paysystem = $this->modx->getObject('Paysystem', $paysystem_id)
            OR ! $paysystem instanceof Paysystem
        ){
            return $this->error("Не был получен объект платежной системы");
        }
        
        // Проверяем, если указан счет платежной системы, то надо убедиться, что 
        // он еще не числится в биллинге
        if($paysys_invoice_id = $this->object->get('paysys_invoice_id')){
            if($this->modx->getCount($this->classKey, array(
                'paysys_invoice_id' => $paysys_invoice_id,
                'paysystem_id'      => $paysystem_id,
            ))){
                return $this->error("Данный счет уже создан в системе.");
            }
        }
        
        $this->object->addOne($currency);
        $this->object->addOne($paysystem);
        
        return parent::beforeSave();
    }
    
    /*
        Обязательно надо прописывать метод, в котором будет выполняться проверка 
        подписи с сервера платежной системы
    */
    abstract protected function checkSignature();
    
    protected function log($msg, $level = null){
        if($level === null){
            $level = xPDO::LOG_LEVEL_INFO;
        }
        $this->modx->log($level, "[Basket - ".__CLASS__."] {$msg}");
        $this->modx->log($level, print_r($this->getProperties(), true));
        return $msg;
    }
    
    protected function error($msg){
        return $this->log($msg, xPDO::LOG_LEVEL_ERROR);
    }
    
    /*
        Логируем все ошибки процессора, на всякий случай
    */
    public function failure($msg = '',$object = null) {
        $this->error($msg);
        if(!empty($this->object) && is_object($this->object)){
            $this->error(print_r($this->object->toArray(), true));
        }
        return parent::failure($msg,$object);
    }
    
    public function cleanup() {
        /*
            // Если оплата прошла успешно, то обновляем статус заказа
        */
        if($order_id = $this->object->get('order_id')){
            $this->modx->runProcessor('mgr/orders/status/pay', array(
                'order_id'  => $order_id,
            ), array(
                'processors_path' => $this->BillingProcessorsPath,    
            ));
            // На всякий случай сбрасываем счетчик ошибок, если вдруг в вызываемом
            // процессоре были ошибки
            $this->modx->error->reset();
        }
        
        return $this->success($this->getSuccessMessage(), $this->object);
    }
    
    protected function getSuccessMessage(){
        return '';
    }
}

return 'modWebPaymentsCreateProcessor';


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

А вот расширяющий процессор конкретно для робокассы:
<?php
/*
    Проводка платежа от робокассы
*/

require_once dirname(dirname(__FILE__)). '/create.class.php';

class modWebPaymentsRobokassaCreateProcessor extends modWebPaymentsCreateProcessor{
    
    public function initialize(){
        
        $this->setProperties(array(
            "paysystem_id"  => $this->modx->getOption('robokassa.bill_serv_id'),
        ));
        
        return parent::initialize();
    }
    
    /*
        Проверяем подпись с робокассы
    */
    protected function checkSignature(){
        
        $mrh_pass2 = $this->modx->getOption('robokassa.mrh_pass2');

        // Параметры, передаваемые в запросе от робокассы
        $crc        = mb_strtoupper($this->getProperty('SignatureValue'));
        $out_sum    = $this->getProperty('OutSum');
        $inv_id     = $this->getProperty('InvId');
        $shp_aid    = $this->getProperty('shp_aid'); 
        $shp_order  = $this->getProperty('shp_order', null);
        $shp_trff   = $this->getProperty('shp_trff');
        $shp_uid    = $this->getProperty('shp_uid');
         
        $my_crc = mb_strtoupper(md5("{$out_sum}:{$inv_id}:{$mrh_pass2}:shp_aid={$shp_aid}:shp_order={$shp_order}:shp_trff={$shp_trff}:shp_uid={$shp_uid}"));
        
        $this->modx->log(xPDO::LOG_LEVEL_INFO, "[Robokassa - robokassa.payResult]", print_r($_REQUEST, true));
        
        // проверка корректности подписи
        if ($my_crc !=$crc){
            $error = "[Robokassa - robokassa.payResult] - Неверная подпись. Получена: '{$crc}'. Должна быть: '{$my_crc}'";
            $this->modx->log(xPDO::LOG_LEVEL_ERROR, $error);
            return "bad sign";
        } 
        
        // else
        $this->setProperties(array(
            "sum"               => $out_sum,  
            "order_id"          => $shp_order,  
            "owner"             => $shp_uid,
            "paysys_invoice_id" => $inv_id,
        ));
        
        return true;
    }
    
    protected function getSuccessMessage(){
        return 'OK'.$this->getProperty('InvId');
    }    
}


Как видно, это всего 60 строчек кода. Но в результате не только будет проведена оплата с учетом кто платил, через что, сколько и т.п., но и будет автоматически изменен статус заказа на Оплачен. И вот прикрутить еще какой-нибудь способ оплаты — это всего несколько десятков строк.

Итоги


В итоге, получился на самом деле очень не плохой движок. Сразу скажу, что помимо гибкости, производительность у него тоже весьма не плохая. Как раз недавно наткнулся на топик, в котором народ рассуждал, что даже 40 000 товаров уже напрягает не хило их магазины. Я делал магазины на shopModx с десятками тысяч товаров без всяких особых ухищрений, и все нормально работает. И даже если товаров будут сотни тысяч (я уже делал один на 150 000 товаров), то с небольшими доработками магазин и столько потянет.

И самое главное: эта сборка совершенно бесплатная! Конечно мы всегда открыты для приема донейтов от благодарных разработчиков, но де факто движок полностью бесплатный.

И напоследок видео с кратким обзором движка и двумя способами установки.




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

кликабельно


Чуть более распишу статусы заказов:

Новый. Как только пользователь пытается добавить товар в корзину, если заказ для него еще не создан, создается новый заказ и товар сразу добавляется к этому заказу. То есть все заказы видно сразу, даже если пользователь не авторизован и вообще больше ничего не сделал.
Это позволяет отделу маркетинга более четко видеть жизнь магазина, просчитывать конверсию, оценивать возможные причины поведения пользователей и т.п.

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



Оплачен. Если пользователь самостоятельно оплачивает заказ на сайте, то статус заказа автоматически меняется на Оплачен.

Далее еще несколько типовых статусов, типа оплачен и т.п.


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

UPD2:
Вот в нагрузку еще сделал тест loadimpact.com.
Тест бесплатный и не известно откуда (показывает загрузку к секунд), но любой может покликать сайт и убедиться, что там далеко не 5 секунд. Зато график стабильный, что на одном, что на 50-ти клиентах. И даже на 50-ти клиентах процессор был далек от полной загрузки, выдавая чаще всего 10-25%, и только иногда 50-70%. (хостинг digitalocean.com за $10).



UPD3: Картинки к вот этому комментарию.









UPD4: Вчера мы провели вебинар по ShopModxBox, и хотя качество записи получилось не очень, выкладываю его тоже (для общего ознакомления).
Ланец Николай @Fi1osof
карма
13,0
рейтинг 2,4
Эксперт по MODX
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (27)

  • 0
    Спасибо! Как раз вовремя!
    • 0
      Пожалуйста!
  • +5
    Пишу без наездов

    Жмём кнопку «купить»
    image



    Переходим к оформлению заказа
    image



    Заполняем поля
    image



    и долго-долго ждём эту страницу (более минуты!)
    image

    Вот уже ступор. А где вариант выбора оплаты/доставки? Зачем всё так усложнять пользователю?

    А вот это очень даже неприемлемо, ведь вы предлагает пройти пользователю дальше и просмотреть заказ. И вот что дальше, если нажать

    страница управления заказами
    image

    «эта ссылка»
    image

    Скромные пункты todo

    • Регистрировать пользователя в процессе оформления заказа и в процессе заказа предлагать авторизацию или регистрацию с последующим редиректом на продолжение оформления.
    • Сделать пошаговое оформление заказа (авторизация/регистрация → выбор доставки → выбор оплаты → просмотр данных заказа → отправка заказа)


    • 0
      Извините за долгий ответ. Отдыхал.

      Спасибо, что подробно все расписали! Да, все именно так. И сейчас этот момент сразу разберем.
      На самом деле просто еще не все сделано. Мы вдвоем с напарником эту обновленную сборку сделали дней за 5 (правда в авральном режиме), и закладывали только самую основу. При этом очень многое уже заложено, и расчет на то, чтобы примерно движок можно было оценить и оценить примерный объем работ по доработке, но доработки индивидуального — это как правило на любом проекте.

      и долго-долго ждём эту страницу (более минуты!)
      С задержкой ясности нет. Сам ни разу не видел тормозов на сайте. Может в сети перебой был, а может хабраэффект (таки заказов новых в системе уже 760). И серверочек оочень простенький за $10 с одним ядром.

      Вот уже ступор. А где вариант выбора оплаты/доставки? Зачем всё так усложнять пользователю?
      Сами мы в процессе конечно на основе отзывов и советов постараемся какую-то оптимальную схему заложить, но всем мы все равно не угодим, так как на многих магазинах наблюдаются совершенно разные пользовательские сценарии. Но я могу вам гарантировать, что на этой сборке свой сценарий заложить вообще не проблема. Если вы со Smarty работали, то поймете почему.

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

      Не был получен заказ
      Скорее всего вы попытались открыть ссылку оплаты без GET-параметра с ID заказа. Если сразу открыть ссылку оплаты (с ID-шником), или перейти в управление заказами и оттуда открыть, то все будет ОК.

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

      Кстати, в админке есть онлайн-среда для программирования и основные модули добавлены в проект
      www.youtube.com/watch?feature=player_detailpage&v=g_cSfGgSO9g#t=464

      Сделать пошаговое оформление заказа (авторизация/регистрация → выбор доставки → выбор оплаты → просмотр данных заказа → отправка заказа)
      Так же будем думать над каким-то универсальным сценарием, но в большинстве случаев все равно же каждый под себя будет дорабатывать.

      P.S. у меня карма минусовая, отвечать могу раз в час. Если не сложно, плюсуйте карму.

      P.P.S. по поводу багов и обновлений: если баги находите, не стесняйтесь, шлити багрепорты. Если кто переживает, что поставит сборку, а потом вылезут баги и кто и как это будет править — не переживайте. Будут выкладываться патчи и так же через менеджер пакетов в админке вы всегда сможете накатить свежий патч. Никакой переустановки или ручного патчинга не потребуется.
    • 0
      Баги исправил. Выпустил патч (ShopModxBoxPatch (так же доступный для скачивания в менеджере пакетов) ) и новую сборку ShopModxBox-2.0.1

      Помимо исправления добавлены вход через Яндекс и госдеповская таблица транслитерации.
  • +1
    подтверждаю глючок.
    неправильно считается количество товаров в корзине
    image
    • 0
      Спасибо за багрепорт!

      Да, причина понятна. Вы скорее всего добавили два товара, а потом один удалили. Из соображений сбора статистики товар из корзины не удаляется на самом деле, а просто устанавливается кол-во 0 (потом будет статус скорее всего докручен). А при выборке товаров корзины я забыл добавить условие quantity != 0.

      Поправлю, патч выложу.
      • 0
        Да нет же.
        1. зашел на сайт
        2. ткнул на название товара (открылось как бы его описание)
        3. нажал «купить» (появилась черненькая плашка, что товар добавлен)
        4. нажал на ссылку в правом углу
        5. увидел этот результат
        — Только что повторил это в другом браузере с полностью чистыми куками и т.д.
        глюк тот же. «в корзине 2 товара»
        • 0
          ОК. Будем тестировать и поправлять.
        • 0
          Этот баг тоже пофиксили. Спасибо за багрепорт!
  • –3
    Если выбирать из модх то выбор очивиден :-)
    А если нет то тогда мадженто
    • 0
      А почему не Drupal + Commerce?

      Меня всегда поражает, когда топик про одно, а там навязывают другое. Почему бы не отписаться по делу?
      • 0
        Только по тому что маджента лидер рынка, а значит на многие грабли там уже наступили сотни раз. Но если для вас легче тратится на поддержку (ну например сайт умрёт через год) то любое решение сойдёт

        По делу мне нечего сказать. Как то с этим продуктом не довелось столкнутся. Слышал только о наличии двух веток развития, что дополнительно отталкиват от платформы

        А продукт для которого сразу нашёлся баг в основном функционала втопку
        • +2
          | А продукт для которого сразу нашёлся баг в основном функционала втопку
          Это бета. Вы где-то видели бету без багов? Бага будет поправлена.

          По поводу магенты: каждый выбирает то, что ему больше нравиться/подходит — это однозначно. Но говорю вам точно, что обращался к нам заказчик после того, как изначально они хотели делать магазин на магенте (вопрос бюджетов вообще не стоял). Но как ни странно, именно магенто-разработчик после детального изучения ТЗ сказал, что он замахается дорабатывать эти хотелки на магенте (так как магента — узкопрофильная) и посоветовал именно MODX. Вот то, что получилось: www.factum-doors.ru/ (13 000 товаров). Вообще это только один из двух сайтов (розничный). Вообще на этом же движке крутится еще один сайт (для оптовиков), который внешне полностью отличается (к сожалению, не могу его показать, заказчик просил не показывать). Так вот, это не два отдельных сайта на копиях движка, а именно два сайта на одном движке, но на разных доменах. И каталог они используют единый. Просто в товарах проставлены сразу розничная и оптовая цены.

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

          Но это еще не все. Там каталог не просто Производитель-Товар. Там товары собраны в модели товаров. Это потому что есть модель двери, к примеру Венеция, и у нее есть куча всяких исполнений (цвет, материал и т.п.). Порой таких вариантов до 160-ти штук. Так вот, основное описание делается в модели товара, а индивидуальные параметры (цена, картинка, материал и т.п.) — это уже в самом товаре. И вот можете глянуть как сделана карточка товара вот здесь: www.factum-doors.ru/dveri_mezhkomnatnye/milyana/venecija/
          Выбирая параметры двери, подставляется картинка именно соответствующая этим параметрам. А выбирая картинку, меняются параметры.

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

          Поэтому, не было бы прецедентов, и разговора не было бы.
          • 0
            Картинки к комменту смотрите в UPD3 топика.
          • 0
            Но это еще не все. Там каталог не просто Производитель-Товар. Там товары собраны в модели товаров. Это потому что есть модель двери, к примеру Венеция, и у нее есть куча всяких исполнений (цвет, материал и т.п.). Порой таких вариантов до 160-ти штук. Так вот, основное описание делается в модели товара, а индивидуальные параметры (цена, картинка, материал и т.п.) — это уже в самом товаре. И вот можете глянуть как сделана карточка товара вот здесь: www.factum-doors.ru/dveri_mezhkomnatnye/milyana/venecija/
            Выбирая параметры двери, подставляется картинка именно соответствующая этим параметрам. А выбирая картинку, меняются параметры.
            Drupal + Commerce из коробки с условием, что у разработчика прямые руки и есть знания :)
            А factum-doors.ru мне понравился

            Удачи в нелёгком деле!
            • 0
              Спасибо!
              Будем стараться.
            • 0
              И в маджента тоже из коробки
              Но согласен что друпал Ито лучше
          • 0
            Как бы запускать сайт на бета версии интересное решение…

            Но зато вы смо ли сделать то что хотели — это уже успех:-)
            Хотя велосипедом так попахивает

            • –1
              Модуль — бета. А сам движок MODX — не бета. Так что ничего особо страшного нет. И это только пакет. Реальный проект будет доработан и нет никаких проблем.
              В любом случае ни магенту, ни друпал ничто другое лично я не возьму. Просто потому что мне не хочется. И другие так же делают, выбирая то, что ему хочется, иначе все бы сидели только на одном каком-то движке, но они этого не делают. Поэтому, если вам это не нравится — здесь с моей стороны нет никаких упреков. Понравится кому-нибудь другому.

              | Но зато вы смо ли сделать то что хотели — это уже успех:-)
              спасибо.
  • 0
    Попутно, краткие мануалы:
    Как подключить сайт к социальным сетям, чтобы обеспечить вход через них: modxclub.ru/blog/vehicles/230.html#comment1994
    Как добавить Яндекс в модуль входа через социалки: modxclub.ru/blog/vehicles/230.html#comment1998
  • 0
    Спасибо за сборку! Работает интересно!
    Пожелание: сделайте проверку на наличие адреса доставки с почтовым индексом, чтобы конечному менеджеру пришлось меньше обрабатывать заказы. Или разбейте это на отдельные поля. Я думаю, что учитывать такое в заказах будет куда проще. Индекс показывает относительную адресацию до района или почтового отделения. Заодно отобьет спам-ботов
    • 0
      У меня карма минусовая, поэтому топики писать могу раз в неделю всего :-)
      На днях подготовлю топик, в котором опишу принципы кастомизации. Суть заключается в том, что это не один компонент. Здесь несколько слоев и направлений. К примеру, Smarty-шаблон можно назвать самым высоким уровнем. По сути патчи и новые сборки не предполагают внесение изменений в шаблоны, так как изменение их — это уже дело конечного разработчика. Так же для надежности рекомендуется сразу переименовывать или делать копии паблик- и смарти-шаблонов default (затем просто меняете имя шаблона в настройке компонента modxSmarty).
      На уровне шаблона можно уже очень многое поменять. К примеру, прописать собственную дополнительную проверку, вызвать другой/другие процессоры и т.п.

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

      А вот дальше идет модуль billing. Вот его уже трогать ни в коем случае не советую. Ежели решите трогать, считайте, что обратной совместимости на апдейтах уже не будет. Именно этот компонент обеспечивает самую важную логику по заказам, оплатам и т.п. При этом логика там минимальная, чтобы обеспечить гибкость на уровне модулей типа basket. То есть логических проверок там минимум, только самое необходимое (к примеру, обязательное указание order_id в процессорах, которые работают с заказами, или new_status в процессорах, отвечающих за смену статуса). Но самая логика когда статус можно менять или нет, или какие поля обязательные — это уже basket.

      Расчет на самом деле ни в коем случае не на то, что эта сборка из коробки сможет покрыть 95% задач всех магазинов. Расчет именно на быстрый старт и легкость модификации. Кому-то надо индекс, а кому-то оплата в один клик нужна. У каждого магазина свои задачи. Но по опыту могу утверждать, что многие проекты после того, как разрабатываются до какой-то логической точки со своими индивидуальными фишками, почти не обновляются в плане ядра. Свои плюшки дописываются, это да, а вот ядро порой по года два не обновляют. Особенно если низкобюджетный проект. И вот как раз на это и был расчет — чтобы программист с малыми бюджетами быстро мог реализовать проект со своими плюшками.
  • 0
    Вопрос по реализации. Как реализовано хранение товаров через ресурсы или в сторонних таблицах?
    Я сам тоже реализовывал магазин на MODX. Моя реализация на сторонних таблицах. Но в моем случае без этого было никак, т.к. магазин работает под 1С (через обмен данными) и категоризация товаров там двойная: по структуре номенклатуры из 1С и по свойствам товара. Отображение во фронтенде по свойствам. Пришлось изрядно попотеть и конструкцию со стороны БД пришлось укреплять процедурами. А для управления всем этим чудом использовал MIGX.
    • 0
      И так, и так. То есть есть документ-товар (ShopmodxResourceProduct, расширяющий класс modResource), и есть таблица с сопутствующими данными товара (ShopmodxProduct). Это дает несколько плюсов:
      1. Возможность получить разом все товары без перебора категорий и т.п., просто за счет inner join. Таким образом отсекаются все остальные документы сайта.
      2. Хранение основных полей товара не в TV или типа того, а в одной строчке своей таблицы (к примеру цена, артикул, валюта и т.п.).
      3. Генерация УРЛов и кеширование карты ресурсов средствами самого MODX-а, нет необходимости написания собственного роутера.
      4. Совместимость с большинством родных пакетов для MODX-а.
      5. Можно использовать TV-шки, различные шаблоны, уровни доступов и т.п.
      Еще куча всяких плюшек.
      А вот с хранением товаров в нескольких категориях — это и мы делали. Это просто через дополнительную таблицу Товар-Категория и собственный роутер. В принципе, не возникало кучи проблем.
      • 0
        Ничего не скажешь. Для большинства магазинов такого движка более чем хватит. Надо будет на досуге поковыряться.
        • 0
          Поковыряйте.

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