Сегодня очень объемное и очень важное обновление. Всем разработчикам, которые работают с ShopModxBox, советую очень внимательно все прочитать и до конца, так как это обновление во многом определяет дальнейшее развитие данного продукта и не без преувеличения скажу, что затрагивает всех участников этого рынка.
1. modxSmarty-1.0.0
В прошлой статье, посвященной слиянию сайтов modxclub.ru и shopmodx.ru, я писал, что во многом красивому объединению этих двух сайтов способствовала новая, пока еще не опубликованная версия modxSmarty с последней версией библиотеки Smarty на борту. Так вот, новая версия опубликована. Теперь есть системная настройка modxSmarty.pre_template. По умолчанию она пустая. Если указать, то будет использоваться дополнительная директория-скин, в которой можно переопределить отдельные файлы-шаблоны основного скина сайта. В приведенной выше статье все подробно расписано.
2. modxSite-1.3.0
Здесь нет крупных изменений, но все-таки важные моменты есть.
1. Добавлено MODX-логирование SQL-ошибок. При чем здесь есть момент: При выполнении метода $modx->getCount() в случае SQL-ошибки, MODX никак об этом не сообщает. Он просто возвращает ноль и все. А ведь может быть просто ноль записей, а может быть конкретно ошибка, что совсем не одно и то же. Сейчас getdata-процессор залогирует сообщение об ошибке.
2. Немного изменен порядок вызова методов в самом основном процессоре. Это никак не должно привести к ошибкам расширяющих процессоров (то есть можно обновляться, но не забывая про бэкапы), но зато устраняет важный минус прошлой версии — невозможность указать сортировку для добавляемых колонок. К примеру, раньше такое не проканало бы:
function initialize(){ $this->setProperty("sort", "title"); return parent::initialize(); } function prepareQueryAfterCount(xPDOQuery $c){ $c = parent::prepareCountAfterQuery($c); $c->select(array( "pagetitle as title", )); return $c; }
Раньше бы запрос вернул ошибку, что колонки title не существует. Сейчас все отработается ОК.
3. ShopModxBox-2.5.0
Ну и самое главное — это конечно же сама сборка магазина ShopModxBox.
Основные изменения.
Во-первых, (что само собой понятно), сборка включает в себя новые пакеты, и конечно же новые возможности, которые они дают.
Во-вторых, с этого момента меняется наш формат работы с той сборкой и ее дальнейшее развитие. Раньше было как? — ставьте сборку, делайте копию дефолтового скина сайта и далее творите что хотите. То есть дефолтовый скин сборки — это типа как для примера, а нормальный конечный продукт (конечный магазин) — это уже на совести конечного разработчика. Типа программное API на процессорах имеется, а оформление сайта уже сами фигачте с нуля. Это на самом деле конечно же не круто. Во-первых, слишком во многом надо разбираться. Во-вторых, нет у нас сейчас кучи готовых разнообразных шаблонов на выбор, как, к примеру, для Magento, Bitrix и т.п. И вот как раз это мы и решили изменить. Теперь у нас так: есть дефолтовые Smarty-шаблон и Public-шаблон. Вот теперь их трогать вообще не надо, только если вы не шлете пуллреквесты (о чем мы поговорим ниже). Теперь, если вы хотите изменить шаблоны сайта, вы просто создаете папку своих Smarty-шаблонов в корневой папке шаблонов, например site, и прописываете название этого шаблона site в настройку modxSmarty.pre_template (сейчас там прописано skins/default/, это скин для примера. В его шаблонах прописано как расширять основные шаблоны). В целом, даже если у вас там не будет ни одного файла (даже и папки самой не будет), Смарти-ошибок никаких не будет (если Смарти найдет файлы шаблонов в основном скине), но если вам что-то нужно будет изменить, вам не надо будет копировать весь скин и в дальнейшем развивать его только самостоятельно. Теперь основной скин будет как бы набор всего самого необходимого, и в дальнейшем, если чего-то не будет хватать, а спрос будет большой, мы будем добавлять это в основной скин, и обновив этот основной скин, можно будет получить эти новые плюшки автоматом, не выискивая чтобы такое изменить в своей копии всего скина. Покажу это на простом примере. Вот теперь есть папка common. В ней будут лежать различные универсальные и часто используемые вкусности, например шаблон для получения и вывода списков, или шаблон для формирования постраничности (да, мы отказались от сниппета getPage по ряду причин, главные из которых низкая производительность и отсутствие Смарти-шаблонизации).
Эти шаблоны в целом работают в паре (если нужна постраничность), но могут использоваться и по отдельности, но главное — это возможность расширения. Посмотрите как это делают шаблоны вывода товаров и новостей. Просто расширяете лист-шаблон, добавляете/меняете параметры запроса, вызываемый процессор (если надо), шаблон для вывода и все. Механизм централизованный, и в дальнейшем будет развиваться/улучшаться. В таком ключе, если вы в своем скине расширяете базовый лист-шаблон, накатив обновления на основной скин сайта, если этот шаблон получит новые плюшки, то эти плюшки сразу достанутся и вашему расширяющему скину.
Прочие изменения и приятные вкусности.
Smarty-шаблон на замену getPage. Как я и писал выше, основная причина — производительность. По моим наблюдениям, на сайте, который открывается за 0.4-0.5 сек, getPage может съесть 0.1+ сек. Да, он вполне прожорлив.
Вторая причина — его излишняя глобальность. Мне не хочется следить за тем, чтобы указывать имя get-переменной вместо page, только для того, чтобы если на странице несколько блоков с постраничностью, чтобы они не мешали друг другу, ведь getPage берет значение страницы из глобального $_GET. А еще он результат фигачит в глобальный плейсхолдер [[+page.nav]], за чем так же не хочется следить. Теперь в смарти-пагинатор передается массив-ответ $result от процессора, и постраничность формируется конкретно от его значений limit, total и т.п. Теперь все необходимые для постраничности данные возвращает сам процессор.
Login используется меньше. Login, как и getPage, тоже кушает не мало. При чем мне на самом деле всегда не нравилась путаница с авторизациями в разных контекстах. К примеру, у пользователя есть метод isAuthenticated($sessionContext= 'web'), то есть он проверяет а действительно ли пользователь авторизован в этом контексте. При этом сам MODX, получая при инициализации текущего пользователя, не найдя его в текущем контексте, проверяет, а не авторизован ли он в админке, и если авторизован, то инициализирует его. И получается, что если пользователь в админке авторизовался, но не авторизовался во фронте, то пользователь как бы есть, и как бы его нет, потому что Login проверяет его только в текущем контексте. Все это наблюдали на большинстве своих сайтов, где используется авторизация через Login. Вот теперь этот вопрос решается. Конечно, на каких-нибудь мегасложных сайтах с кучей контекстов и жестким распределением прав может и надо то, как работает Login, но это крайнее исключение, так что в нашей сборке я его заменил. Но оговорюсь, что на страницах регистрации, обновления профиля и смены пароля все еще используется Login, и при попытке зайти на них без авторизации во фронте вы получите отказ, но это уже совсем мелочи, так как тем, кто авторизован в админке, вряд ли сильно нужны эти страницы.
Большая производительность.
Благодаря этим двум вышеописанным моментами, производительность сайта еще поднялась. К примеру, я у себя на тестовом сайте сейчас не редко могу видеть такие цифры:
Memory: 9.0521 Mb TotalTime: 0.1242 s
Для сравнения, раньше обычно меньше 0.25 не снижалось.
Не забываем на боевом сайте в шаблонах переключать настройку phptemplates.non-cached в false.
Обновлен Bootstrap до последней версии 3.3.1. Перешли мы со старой версии 2. Верстка подправлена, но есть еще места, где помощь не помешает, к примеру страницы контактов, форма оформления заказа и т.п., так что кто силен в бутстрапе, шлите пуллреквесты, вам воздастся.
Поправлена форма авторизации. Теперь авторизация аджаксовая, так что не получается как раньше, что нажал Авторизоваться, страница обновилась, а ты не видишь Ок или что, только если опять нажимаешь на Логин.
Автоматическое присвоение корзины при авторизации. Есть проблемный сценарий: анонимный пользователь накидал товаров в корзину (корзина сейчас ни к кому не привязана), затем он авторизовался (и по прежнему видит корзину и может в нее добавлять товары, но эта корзина все так же никому не принадлежит), затем юзер разлогинился, сессия умерла и корзина осталась анонимной и безхозяйной. Сейчас, при авторизации, если есть корзина в сессии, и у текущего пользователя нет своей собственной неоформленной корзины, то эта корзина присваивается ему (отвечает сейчас за это процессор Site).
Приглашаем к разработке дополнительных скинов сторонних разработчиков.
А теперь самое сладенькое :) Все это не только улучшает нашу сборку как самостоятельный продукт, но и дает возможность подключиться к нему сторонним разработчикам не только как создателям конечных интернет-проектов для своих клиентов, но и как соавторам. Я имею ввиду создание дополнительных скинов сборки. Как я и говорил выше, для скинов есть свои папки раз и два. Что надо делать? 1. Создаете свои папки скинов (сейчас там пока только default для примера). Не забываем изменить название скина в настройке modxSmarty.pre_template
2. В своем layout.tpl переопределяете блок стилей, например так:
{block name=styles} <link href="{$pre_template_url}css/style.css" rel="stylesheet" type="text/css" /> {/block}
Переменная $pre_template_url будет содержать путь до вашей публичной части скина, например assets/components/modxsite/templates/skins/test/
Все, кастомные стили основного скина будут заменены вашими. Теперь вы можете менять внешнее оформление сайта как угодно. Повторюсь, что в дальнейшем основной шаблон сайта будет развиваться централизованно, а скины будут только стилевые изменения нести, не затрагивая общую логику. Если у кого-то будут предложения по дополнению логики в основном шаблоне, так же присылайте свои пуллреквесты. Вклад каждого будет освещен, что по сути является вашей рекламой :) Сам я очень скоро планирую в основной шаблон добавить аджаксовый каталог и аджаксовую миникорзину, примерно, как я сделал это здесь.
Все достойные скины будут включены в сборку, и будут содержать информацию о разработчике и прямую ссылку на его аккаунт на сайте Клуба и его сайт. На самой сборке будет добавлен переключатель скинов сайта, чтобы потенциальный заказчик мог выбрать понравившийся. Все скины будут представлены в отдельном каталоге сборки так, чтобы ссылки на разработчика индексировались, так что это будет давать дополнительную ссылочную массу на ваш сайт. Наиболее интересный скин будет использоваться в качестве основного, и даст наибольшее кол-во полезных ссылок автору, а так же обеспечит кучу плюсов в карму :)
Традиционно, готов выслушать ваше мнение и предложения.
UPD: Для тех, кто не добрался до шаблона, где прописан JivoSite и не знает как это сделать. Вот этот кусочек шаблона. Но его не надо удалять/редактировать. Есть системная настройка jivosite.widget_id. Если удалить значение, модуль выводиться не будет. Если вы регистрируете свой аккаунт в JivoSite, найдите свой id-шник в выдаваемом JS-коде и просто скопируйте и вставьте оттуда id в системную настройку, будет выводиться ваш модуль.
Я уже неудачно пробовал обновиться до прошлой версии вчера. Взял файлы с гитхаба, заменил — но обновление не прошо удачно, все переопределенные процессоры глючили. причем, если в корзине был заказ — то все ок, а если нет, то не работает все, что ниже корзины. Причем аджаксовый каталог отрабатывает, там же нету корзины. Вероятно, надо было сначала выпелить все упоминания о сборки из папок core, manager ну и где оно упоминается. И вот я теперь побаиваюсь новых обновлений. Это обновление будет происходить в будущем? И почему для него нельзя задействовать пакеты, чтобы обновил все до новых версий в управлении пакетами — и радуешься?
То, что я дальше напишу конечно стоило бы отложить до того, как я покручу новую сборку, но раз уж начал писать, то заодно. Наверно изменения с шаблонами направлены на более удобное обновление, но когда наши темплейты site были абсолютно автономны от shopmodx мы уверены, что там то, что нужно нам. Даже если этого нет в сборке. И ничего, что не нужно. То, что появится что-то не нужное на самом деле не очень страшно. Все таки не программисты-то неплохие добавляют, говно не подбросят ))) Страшно, что ты не сможешь прикрутить что-то свое т.к. шаблоны site уже не самостоятельны. Вот что тоже пугает.
По поводу обновления до последней/прошлой версии: все-таки многое зависит от того, что вы переопределяли в своих расширенных процессорах и т.п. Напомню — бекапы рулят. К примеру, если вы редактировали процессоры самой сборки, то конечно же апдейт их затер. Ежели вы дописали какие-то свои дополнительные процессоры, то ничего не должно было с ними случиться.
Это обновление будет происходить в будущем?
Обновления в будущем конечно же будут появляться, но повторюсь: во-первых, и от вас будет многое зависеть. Во-вторых, и мы будем стараться, чтобы обратная совместимость улучшалась.
И почему для него нельзя задействовать пакеты, чтобы обновил все до новых версий в управлении пакетами — и радуешься?
Для чего-то есть пакеты, а для чего-то нет. К примеру, пакет modxSite можно с большой долей вероятности накатывать через управление пакетами. Его родные процессоры в папке processors/site/ лежат, а доппроцессоры сборки лежат в processors/web/. processors/site/ не рекомендуется трогать вообще никогда, ибо затрется при обновлении. А в processors/web/ можете менять при необходимости, но если хотите накатить обновления — проверяйте внимательно.
Почему не все в пакетах и не все универсально — у всего есть две стороны медали. Универсальность/гибкость/производительность — это примерно как быстро/качественно/дешево.
По поводу шаблонов: если хотите, можете полностью делать копию основного шаблона и работать только с ней. Но лучше все-таки работать с допскинами. При чем если вы хотите максимально снизить риски, но получить преимущество обновлений, вы можете сделать копию основного шаблона и добавить свой кастомный скин поверх, расширяющий основной шаблон. А когда будут выходить обновления, вы уже сами будете решать какие изменения в основной шаблон накатывать, а какие нет. Но, как я и говорил, обновления в основной шаблон сейчас будут добавляться очень осторожно, с сохранением основных блоков и т.п.
Обновил smarty до 1.0.0, сайт перестал грузиться:
Unable to load template file 'tpl/mainpage.tpl'
разобрался- smarty при переустановке меняет templates_dir ^)
Саш, уточни где именно и что на что изменилось при переустановке смарти.
А то, что вместо того, чтобы удалять товары из таблицы billing_order_products, его количество (quantity) меняется на ноль — это так задумано?
Да, так задумано. Это для маркетологов. Им важно не только то, что покупают, но и то, что не покупают. Много вопросов здесь — «почему клиент в итоге отказался от этого товара?», «может он нашел другой и решил сменить?», «от каких товаров чаще всего отказываются?» и т.д. и т.п. Понятное дело, что на магазине с посещаемостью 50 человек в сутки такой статистики слишком мало для оценки, но для крупных магазинов это будет ценная информация.
Помимо смарти другие варианты не рассматривали?
В свое время еще на community обсуждали всякие эти шаблонизаторы, и даже Даник Twig прикручивал, но не полетело. На хабре вот хорошая статья сравнительная имеется, где чел наглядно показал, что смарти производительней, чем твиг. Остальные даже не рассматривались, так как им нечего предъявить. Но вот интерес есть к шаблонизатору Jade (для php — JadePHP). Буду изучать эту тему, ибо есть подозрение, что поучится сделать единую шаблонизацию и для серверной стороны, и для фронтовой (см. хабр).
1 установил чистую сборку ShopModxBox на локалку
2 скачал с гитхаба github.com/Fi1osof/ShopModxBox
3 обновил версию modx на локальной копии сайта (все не работало)
4 поменял файлы на файлы из гитхаба
5 скопировал пакеты из core/packages чистой сборки ShopModxBox (из пункта 1) и переустановил все. Может быть, что-то удалял и заного скачивал…
локалка заработала! Ну, что-то затерлось, но вернул и ок.
1 обновил modx на боевом сайте.
2 поменял файлы из /assets/components, core/components, manager/components/
3 закинул пакеты из чистой сборки ShopModxBox, обновил все.
Нифига не заработало. Ощущение такое, что ничего не обновилось. Нового пакета modxsmarty там старый, кстати.
Как жить дальше? В смысле, где ж косяк? И самое интересное, как сделать, чтобы заработало?
кеш чистил? у меня все обновилось нормально. и на локалке, и на боевом.
Сделай копию боевого сайта, обнови ShopModxBox на нем. Если все заработало — затри им боевой и все.
Проблема точно не в ShopModxBox. Вот на днях появится кейс, как я прикручивал сборку к очередному магазину на шопкипере.
1. Установил пакет modxSite (он сразу тянет и настраивает phpTemplates, modxSmarty и т.п.).
2. Скачал все файлы сборки с гитхаба и закинул их на сайт (можно смело заливать их поверх на сторонний MODX-сайт, так как там с большой долей вероятности не будет конфликтных файлов).
3. Залил с копии сборки на сайта дамп биллинговых таблиц (modx_billing_).
4. Настроил валюты.
5. Прописал недостающие extension_packages.
6. Перенес шаблоны в Smarty и доработал.
7. Допилил механизм учета остатков.
8. Оптимизировал базу данных (там 40 000 товаров, 500 000 записей ТВшек).
Прочие мелочи докрутил. На все про все ушло 20 часов.
1. Установил пакет modxSite (он сразу тянет и настраивает phpTemplates, modxSmarty и т.п.).
И еще shopModx установил.
Там, конечно же, еще надо некоторые неймспейсы добавить и настроить их где надо (billing, basket и т.п.), но если изначально сайт на ShopModxBox был, то этого делать не приходится.
Пытаюсь добавить репозиторий как на видео, пишет, что «Не указано имя пользователя. Это логин на сайте MODX-Клуба»
rest.modxstore.ru/extras/
Доступ к репозиторию теперь платный. Подробности здесь.