Вопросы специалистов

Документация для специалистов

Объявления о работе

Blog by Fi1osof

Каталог ограничен 15 товарами.

Ajax-каталог на практике

Оригинальный интернет-каталог на MODX+node.js+react.js

парсер с интерент магазина с настройкой страницы каталога на своем домене

Добрый день.
 Там нет ограничения. Просто пагинация не выводится. Пропишите пагинацию в шаблоне категории. Смотрите как это работает на корневой странице каталога http://swisskarma.ru/catalog/ .

Добрый день.
 Там нет ограничения. Просто пагинаци

а можно по подробнее?

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

Нет. Если знаний не хватает здесь, лучше ShopModxB

Пусть пробует, смотри работу сниппетов и плейсхолдеров, забыл видимо вставить пагинацию.
 Не понимаешь, смотри по примеру, как сказал Николай.

Пусть пробует, смотри работу сниппетов и плейсхолд

сегодня праздник нубов. тоже разбираюсь с этим. нид хелп.
 очевидно править нужно category.tpl правильно? https://yadi.sk/i/_AkE-3PDbyJdF
 но что-то не помогает. 
 еще задержка в том, что много одноименных файлов в разных категориях (list.tpl, layout.tpl)

сегодня праздник нубов. тоже разбираюсь с этим. ни

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


Сниппетом выводятся товары, я не знаю какой там, могу предположить getPage
 Взято из проекта для примера:
 [[!getPage? &elementClass=`modSnippet` &element=`getResources` &showHidden=`1` &tpl=`office_tpl` &limit=`1000` &includeContent=`1` &includeTVs=`1` &processTVs=`1` &hideContainers=`1` &pageLimit=`5` &pageNavVar=`page.nav` &sortby=`{"menuindex":"ASC"}` ]]


вот, если он то забыли указать  [[!+page.nav]]

Нет не правильно, внутри чанка где вызывается сниппет, для вывода товаров. Сниппетом выводятся товары, я не знаю какой там, могу предположить getPage
 Взято из проекта для примера:
 [[!getPage? &elementClass=`modSnippet` &element=`getResources` &showHidden=`1` &tpl=`office_tpl` &limit=`1000` &includeContent=`1` &includeTVs=`1` &processTVs=`1` &hideContainers=`1` &pageLimit=`5` &pageNavVar=`page.nav` &sortby=`{"menuindex":"ASC"}` ]] [[!+page.nav]] вот, если он то забыли указать  [[!+page.nav]]

Нет не правильно, внутри чанка где вызывается снип

Плохо нельзя редактировать комментарии:
 При условии, что указали
 

Плохо нельзя редактировать комментарии:
 При условии, что указали &pageNavVar=`page.nav`

Плохо нельзя редактировать комментарии:
 При услов

В целом правильно. Только надо еще дальше плясать. Там есть вызов:
 

{block name=content}

{processor action="web/catalog/category/products/getdata" ns="modxsite" assign=result}

{* Набиваем через единый шаблон листинга *}

{include file="shop/catalog/list/fetch.tpl"}

{/block}

Вот вложенные шаблоны и надо смотреть. И здесь два момента:
 1. Во вложенном шаблоне прописан плейсхолдер [[+page.nav]], но в вызове процессора не прописан передаваемый параметр getPage => true. Без этого параметра не будет вызываться в процессоре сниппет getPage.
 2. Сейчас все шаблоны некешируемые (включена настройка в шаблонах phptemplate.non-cached=true). Если некеширование выключить, то пагинация не будет корректно работать. В шаблоне tpl/category.tpl надо бы переделать на вызов некешируемого сниппета [!smarty?tpl=`...`]. Но это так, для справки.

В целом правильно. Только надо еще дальше плясать. Там есть вызов: {block name=content}

{processor action="web/catalog/category/products/getdata" ns="modxsite" assign=result}

{* Набиваем через единый шаблон листинга *}

{include file="shop/catalog/list/fetch.tpl"}

{/block} Вот вложенные шаблоны и надо смотреть. И здесь два момента:
 1. Во вложенном шаблоне прописан плейсхолдер [[+page.nav]], но в вызове процессора не прописан передаваемый параметр getPage => true. Без этого параметра не будет вызываться в процессоре сниппет getPage.
 2. Сейчас все шаблоны некешируемые (включена настройка в шаблонах phptemplate.non-cached=true). Если некеширование выключить, то пагинация не будет корректно работать. В шаблоне tpl/category.tpl надо бы переделать на вызов некешируемого сниппета [!smarty?tpl=`...`]. Но это так, для справки.

В целом правильно. Только надо еще дальше плясать.

Поправка: у нас не используются чанки, у нас не используется getResources, у нас не используются pdoTools и т.д. и т.п. У нас Smarty и процессоры. Поэтому человек написал выше правильно. Речь здесь о сборке магазина ShopModxBox.

Поправка: у нас не используются чанки, у нас не ис

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

{snippet name="getProducts" params="includeTVs=`1` &includeTVList=`price0,image0,tags,availability` &limit=`4` &tpl=`product` &resources=`{tv name="mainNew" contentid="1" parse="true"}`" parse="true"}

или воспользоваться процессорами, и насчёт чанков, не совсем понял как от них отказаться, предполагаю что создавать смарти шаблоны и их инклюдить каким то образом? Если что то напутал подправте, пытаюсь перейти на вами предложенный способ смарти+процессоры, пытаюсь вникнуть в суть, заранее спасибо.

Николай, вы предлагаете не использовать чанки и сниппеты, а пользоваться процессорами, получается под каждую задачу писать такой код который решает только данную задачу, а что быстрее будет работать, использовать стандартный сниппет в смарти шаблонах например: {snippet name="getProducts" params="includeTVs=`1` &includeTVList=`price0,image0,tags,availability` &limit=`4` &tpl=`product` &resources=`{tv name="mainNew" contentid="1" parse="true"}`" parse="true"} или воспользоваться процессорами, и насчёт чанков, не совсем понял как от них отказаться, предполагаю что создавать смарти шаблоны и их инклюдить каким то образом? Если что то напутал подправте, пытаюсь перейти на вами предложенный способ смарти+процессоры, пытаюсь вникнуть в суть, заранее спасибо.

Николай, вы предлагаете не использовать чанки и сн

Валентин, не обязательно писать код под каждую задачу. Во-первых, есть готовые процессоры (типа того же site/web/getdata), которые можно использовать. К тому же процессоры лучше сниппетов тем, что их можно расширять. Вот сниппеты как правило используются под конкретные задачи, так как их можно использовать только в том виде, в каком они поставляются. Вы не можете их модифицировать, иначе как сделать копию и там уже вносить правки. А вот процессоры запросто расширить и можно, к примеру, переопределить нужный метод. Во-вторых, у нас используется Smarty-шаблонизация, что позволяет во многих случаях вообще отказаться от вызова сниппетов, чанков и тех же процессоров, если задача простая. Простой пример: не раз видел вызов сниппета типа [[year]], который возвращает значение текущего года ( return date('Y'); ). От чего это происходит? От того, что ни в MODX-шаблонах, ни в чанках нет возможности выполнить php-код (то есть какую-то логику). В Смарти-шаблоне я просто напишу {date('Y')} и все. Не надо никаких сниппетов или чанков.
 То есть призыв отказываться от чанков и сниппетов, это не какая-то тотальная борьба с ними, а просто такая парадигма разработки в рамках наших технологий. То есть если вы используете чистый MODX, то иначе как на чанках и сниппетах вы и не сможете работать. А если у вас phpTemplates+modxSmarty, то вы можете так же работать на чанках и сниппетах, но это уже не так эффективно. Зачем тогда вообще использовать phpTemplates+modxSmarty?
 И справедливости ради следует отметить, что совсем от чанков и сниппетов не получится отказаться. Во-первых, как минимум чанки нужны для модулей Login и Wayfinder, от которых мы пока не отказались. Во-вторых, элементарно для вызова некешируемого Смарти-шаблона по прежнему используется некешируемый вызов сниппета [[!smarty?tpl=`...`]]. Но относительно традиционных методов разработки на MODX-е, когда чанков и сниппетов порой больше двух-трех сотен штук, можно сказать что мы не используем чанки и сниппеты.

Валентин, не обязательно писать код под каждую зад

Большое спасибо за ответ, и заметил что у вас нет поиска, приходится идти в гугл и искать ответ вот так "modxclub smarty  и его приимущество", или у вас он где то есть, но спрятан?

Большое спасибо за ответ, и заметил что у вас нет 

Если бы у нас был поиск, вряд ли бы вы что-то через него нашли у нас по этому запросу :)
 Нет, здесь поиск не сделан, все руки не доходят. А если вы хотите в гугле искать именно по нашему запросу, добавляйте к запросу site:modxclub.ru и все.

Если бы у нас был поиск, вряд ли бы вы что-то чере

спасибо всем за комментарии,
 неожиданно решил проблему, отредактировав category.tpl


{extends file="layout.tpl"}

{block name=content}

    {processor action="web/catalog/category/products/getdata" ns="modxsite" params="limit=`6`&getPage=`1`" assign=result}

    {* Набиваем через единый шаблон листинга *}

    {include file="shop/catalog/list/fetch.tpl"}

{/block}

спасибо всем за комментарии,
 неожиданно решил проблему, отредактировав category.tpl {extends file="layout.tpl"}

{block name=content}

    {processor action="web/catalog/category/products/getdata" ns="modxsite" params="limit=`6`&getPage=`1`" assign=result}

    {* Набиваем через единый шаблон листинга *}

    {include file="shop/catalog/list/fetch.tpl"}

{/block}

спасибо всем за комментарии,
 неожиданно решил про

Ничего неожиданного. Выше я писал:
 

1. Во вложенном шаблоне прописан плейсхолдер [[+page.nav]], но в вызове процессора не прописан передаваемый параметр getPage => true. Без этого параметра не будет вызываться в процессоре сниппет getPage.

Вы прописали этот параметр в params в вызове процессора, и постраничность заработала.
 Но как я и писал там же, постраничность перестанет нормально работать, если отключить некеширование шаблонов. А не отключить - будет сайт медленней работать. Поэтому возьмите создайте новый Смарти-шаблончик, например inc/category/list.tpl, перекиньте в него ваш код:
 

   {processor action="web/catalog/category/products/getdata" ns="modxsite" params="limit=`6`&getPage=`1`" assign=result}

    {* Набиваем через единый шаблон листинга *}

    {include file="shop/catalog/list/fetch.tpl"}



А вместо него пропишите некешируемый вызов [[!smarty?tpl=`inc/category/list.tpl`]].
 Тогда можно будет отключить некеширование шаблонов (в параметрах MODX-шаблонов).

Ничего неожиданного. Выше я писал: 1. Во вложенном шаблоне прописан плейсхолдер [[+page.nav]], но в вызове процессора не прописан передаваемый параметр getPage => true. Без этого параметра не будет вызываться в процессоре сниппет getPage. Вы прописали этот параметр в params в вызове процессора, и постраничность заработала.
 Но как я и писал там же, постраничность перестанет нормально работать, если отключить некеширование шаблонов. А не отключить - будет сайт медленней работать. Поэтому возьмите создайте новый Смарти-шаблончик, например inc/category/list.tpl, перекиньте в него ваш код: {processor action="web/catalog/category/products/getdata" ns="modxsite" params="limit=`6`&getPage=`1`" assign=result}

    {* Набиваем через единый шаблон листинга *}

    {include file="shop/catalog/list/fetch.tpl"} А вместо него пропишите некешируемый вызов [[!smarty?tpl=`inc/category/list.tpl`]].
 Тогда можно будет отключить некеширование шаблонов (в параметрах MODX-шаблонов).

Ничего неожиданного. Выше я писал: 1. Во вложенном

Да, действительно хороший пример, причём AJAX замечательно индексируется)
 Думаю этот ход явно в сторону будущего, скоро, да уже и сейчас многие магазины переходят на AJAX, а лидеры рынков уже давно на этой технологии.
 ShopModx замечательно выглядит, подскажите только пожалуйста, где я могу изучить фильтрацию поподробнее, а так же как лучше устроить магазин, если товаров планируется более 7000. Причём изменение цен происходить будет каждую неделю.
 Есть ещё интересная задача, как решить на MODX - не знаю, но предполагаю что можно задачей на CRON.
 Суть задачи - загружать прайс-лист с тем же названием каждую пятницу в определённую папку и чтобы он автоматически обновлял цены. Или может есть ещё пути решения?

Да, действительно хороший пример, причём AJAX заме

Думаю этот ход явно в сторону будущего

На самом деле в этом мы идем не в будущее, а возвращаемся в прошлое))), так как Smarty - ветеран шаблонизации, и все это делалось уже не один год назад. А мы просто подтягиваем эти технологии и методики в MODX.
 

причём AJAX замечательно индексируется)

Нет, гораздо лучше реализация была здесь: http://home-ex_ru.portfolio.modxclub.ru/catalog/, при чем я делал это года три-4 назад, и там много фишек, включая смену адресной строки, сохранение страниц в кеш браузера и работу исторических кнопок браузера. Это одна из лучших вещей, что я делал. Но вот как раз там мне очень не хватало Smarty-шаблонизации.


где я могу изучить фильтрацию поподробнее

Очень полезна в этом будет эта статья.


а так же как лучше устроить магазин, если товаров планируется более 7000

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


Причём изменение цен происходить будет каждую неделю.
 Есть ещё интересная задача, как решить на MODX - не знаю, но предполагаю что можно задачей на CRON.

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

Думаю этот ход явно в сторону будущего На самом деле в этом мы идем не в будущее, а возвращаемся в прошлое))), так как Smarty - ветеран шаблонизации, и все это делалось уже не один год назад. А мы просто подтягиваем эти технологии и методики в MODX. причём AJAX замечательно индексируется) Нет, гораздо лучше реализация была здесь: http://home-ex_ru.portfolio.modxclub.ru/catalog/, при чем я делал это года три-4 назад, и там много фишек, включая смену адресной строки, сохранение страниц в кеш браузера и работу исторических кнопок браузера. Это одна из лучших вещей, что я делал. Но вот как раз там мне очень не хватало Smarty-шаблонизации. где я могу изучить фильтрацию поподробнее Очень полезна в этом будет эта статья. а так же как лучше устроить магазин, если товаров планируется более 7000 .
 Ничего особенного для этого не надо, разве что в настройках MODX-а отключите кеширование карты ресурсов cache_alias_map, чтобы сократить объем кеш-файла при инициализации MODX-а. Причём изменение цен происходить будет каждую неделю.
 Есть ещё интересная задача, как решить на MODX - не знаю, но предполагаю что можно задачей на CRON. Теории импорт/экспорт в двух словах не буду рассказывать. Все это решаемо. Научить в короткий срок не получится, если сами не справитесь с импортом - заказывайте индивидуальную разработку.

Думаю этот ход явно в сторону будущего На самом де

причём AJAX замечательно индексируется) В каком смысле?

причём AJAX замечательно индексируется) В каком см

Да это он скорее всего про то, что ссылки абсолютные, реальные, и даже если отключен JS, контент подается идентичный.

В каком смысле? Да это он скорее всего про то, что ссылки абсолютные, реальные, и даже если отключен JS, контент подается идентичный.

В каком смысле? Да это он скорее всего про то, что

Беда,
 Your text to link...
 сделал как у вас, в принципе отсюда, лимит устанавливается, значит работает, но вот пагинация не появляется, а если в выводе списка товаров shop/catalog/list/fetch.tpl прописать 

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

Беда,
 Your text to link...
 сделал как у вас, в принципе отсюда, лимит устанавливается, значит работает, но вот пагинация не появляется, а если в выводе списка товаров shop/catalog/list/fetch.tpl прописать [[+page.nav]] то пагинация появляется столько сколько должно быть страниц, но не переходит по ним.

Беда,
 Your text to link...
 сделал как у вас, в п

1. Надо передавать в параметры вызываемого процессора «page» => $smarty.get.page, то есть $_GET-параметр запроса.
 2. Если у вас свежая сборка, то вообще правильней не [[+page.nav]] вставлять, а инклюдить шаблон постраничности.

1. Надо передавать в параметры вызываемого процесс

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

Спасибо, теперь все выводиться. 
 Но по страницам 

В контейнере товаров вызывают вот такой шаблон
 

{extends file="layout.tpl"}


{block name=content}
    {processor action="web/catalog/category/products/getdata" ns="modxsite" params="&limit=`4`&getPage=`1`" assign=result}

    {* Набиваем через единый шаблон листинга *}
    {include file="shop/catalog/list/fetch.tpl"}

    {include "common/pagination/pagination.tpl"}

{/block}

В контейнере товаров вызывают вот такой шаблон {extends file="layout.tpl"}


{block name=content}
    {processor action="web/catalog/category/products/getdata" ns="modxsite" params="&limit=`4`&getPage=`1`" assign=result}

    {* Набиваем через единый шаблон листинга *}
    {include file="shop/catalog/list/fetch.tpl"}

    {include "common/pagination/pagination.tpl"}

{/block}

В контейнере товаров вызывают вот такой шаблон {ex

1. Надо передавать в параметры вызываемого процессора «page» => $smarty.get.page, то есть $_GET-параметр запроса.

У вас здесь где передача этого параметра? Во-вторых, это кешируемый блок, так как находится внутри самого шаблона документа. Сделайте так:
 1. В шаблоне категории пропишите вызов своего субшаблона, типа так:
 

{block name=content}
   [[!smarty?tpl=`inc/shop/category/index.tpl`]]
{/block}

А в inc/shop/category/index.tpl пропишите
 

{$params = [
    "limit" => 4,
    "page"    => $smarty.get.page
]}
{processor action="web/catalog/category/products/getdata" ns="modxsite" params=$params assign=result}
    {* Набиваем через единый шаблон листинга *}
    {include file="shop/catalog/list/fetch.tpl"}
    {include "common/pagination/pagination.tpl"}

getPage не нужен для работы шаблона постраничности. Главное — чтобы был сам этот шаблон постраничности.

1. Надо передавать в параметры вызываемого процессора «page» => $smarty.get.page, то есть $_GET-параметр запроса. У вас здесь где передача этого параметра? Во-вторых, это кешируемый блок, так как находится внутри самого шаблона документа. Сделайте так:
 1. В шаблоне категории пропишите вызов своего субшаблона, типа так: {block name=content}
   [[!smarty?tpl=`inc/shop/category/index.tpl`]]
{/block} А в inc/shop/category/index.tpl пропишите {$params = [
    "limit" => 4,
    "page"    => $smarty.get.page
]}
{processor action="web/catalog/category/products/getdata" ns="modxsite" params=$params assign=result}
    {* Набиваем через единый шаблон листинга *}
    {include file="shop/catalog/list/fetch.tpl"}
    {include "common/pagination/pagination.tpl"} getPage не нужен для работы шаблона постраничности. Главное — чтобы был сам этот шаблон постраничности.

Ура спасибо, низкий вам поклон, Николай))) доперло до меня, заработало) [А то я в этом смарти вообще ничего не смыслю, а есть какие нибудь качественные уроки по этому смарти???]
 с продажи сайта, отблагодарю.)))))

Ура спасибо, низкий вам поклон, Николай))) доперло

Про уроки я имею в виду те которые вы считаете, хорошими — правильными.

Про уроки я имею в виду те которые вы считаете, хо

Пожалуйста.
 Уроков не встречал и не искал. Читаю официальную документацию.

Пожалуйста.
 Уроков не встречал и не искал. Читаю 

Спасибо, почитаю на досуге.)

Пожалуйста.

Круто. У нас вот из-за проблемы получения на старте всего стейта приложения в итоге отказались от сервер сайд рендеринга. Или он просто не работал. Я в детали сильно не углублялся - у меня было полно других задачь. Но тимлид в итоге назвал ошибкой выбор reflux вместо redux. Redux как раз эту проблему сервер сайд рендеринга бы решил. 

Круто. У нас вот из-за проблемы получения на старт

На самом деле не думаю, что reflux, redux или flux решили бы эту проблему. Да, на них можно отправить изменения, которые повлияли бы на запрос данных и в итоге получили бы измененный стейт приложения, но повторюсь, новые компоненты могут порождать другие компоненты и т.п. Это бы добавило коллизий. Этих коллизий можно было бы избежать только в случае, когда все изменения проходят через подобные хранилища без самостоятельной логики в самих компонентах. То есть компоненты только для отрисовки. Но на своем опыте я осознал, что подобные решения слишком неповоротливые получаются. Да, предсказуемость растет, но гибкость падает и объем кода растет. Я для себя решил это так: при заходе на страницу (первый запрос на сервер), система через react-router получает запрашиваемый компонент (тот, который на основе настроек роутера отрабатывался бы на стороне браузера, на основании адресной строки). У этого компонента запрашивается метод получения данных. Это GraphQL-запрос. Именно GraphQL в данном случае спасает, потому что через него можно одним запросом получить сразу несколько дата-сущностей с различной вложенностью. Полученный результат возвращается в обработчик запроса, который тогда только вызывает непосредственно реакт-компонент через react-dom-server с непосредственной отрисовкой HTML. Тут он уже получает не только HTML, но и конечный снимок глобального стейта (то есть в этот момент в самом рекат-компоненте может выполниться дополнительная логика на основании переданного стейта, которая не требует ожидания асинхронных запросов и ре-рендеринга). Этот уже HTML передается вместе со снимком стейта в брайзер и в этот момент, даже после выполнения реакт-компонента на стороне браузера, мы получаем точную копию того, что произошло на сервере. А далее уже в браузере работает полноценное веб-приложение со всеми асинхронными запросами, отсутствием перезагрузки страницы и т.п. Попробуйте отключить JS и зайти на сайт бань, 95% сайта будет работать без JS, вы почти не заметите разницы, все ссылки рабочие, и даже если вы будете авторизованы, с сервера будет приходить код с вашей аватаркой, учетом уровней доступов и т.п.

На самом деле не думаю, что reflux, redux или flux

Николай приветствую! Очень обрадовала твоя статья! В целом динамика твоих изысканий все круче и все выше! Познавательно и реально интересно! Такой вот вопрос, я взялся изучать Angular 4, как ты смотришь на возможности этого фреймворка, в том числе в свете твоих работ? Может смысл есть его функционал задействовать?

Николай приветствую! Очень обрадовала твоя статья!

С ангулар в бою так и не столкнулся, и нет особого желания. Это готовый фреймворк, а мне больше нравится низкоуровневость. К тому же помимо реакта, фейсбук предлагает целый спектр попутных технологий: react, draft-js, graphql, flux, immutable, react-native, а теперь еще и react-vr. Это очень широкий и объемный спектр технологий. На мой взгляд это направление перспективно, не вижу сейчас смысла дергаться еще куда-то. 

Сергей, добрый день. С ангулар в бою так и не столкнулся, и нет особого желания. Это готовый фреймворк, а мне больше нравится низкоуровневость. К тому же помимо реакта, фейсбук предлагает целый спектр попутных технологий: react, draft-js, graphql, flux, immutable, react-native, а теперь еще и react-vr. Это очень широкий и объемный спектр технологий. На мой взгляд это направление перспективно, не вижу сейчас смысла дергаться еще куда-то.

Сергей, добрый день. С ангулар в бою так и не стол

Обана... Не уж то существует в интернете место, где есть что-то интересное на счет совместной работы nodeJS и MODX... У меня сейчас мало времени, чтобы успеть нормально пробежаться по всем статьям, по поводу них, но 100% уже завтра вечером сяду и все прочитаю.  Сам сейчас просто в неописуемом восторге от JavaScript. Все началось с ознакомления с Google'овским Progressive WebApp (https://developers.google.com/web/progressive-web-apps/ ), а в частности ServiceWorker и его возможностями для работы сайтов из оффлайна + бешеная скорость загрузки/работы за счет асинхронности у всех элементов сайта... И с тех пор пошло-поехало... Но все это время меня удивляла одна простая вещь: если взять тот же самый Gulp, то на самом деле сборка шаблонов на нем не такая уж и сложная задача... Но при этом на том же modx.pro ни слова на эту тему... А тут на тебе, аж целый React :-) Если где-то еще будет информация про Polyfill, то жизнь уж совсем станет сказкой :-) 

P.S. ReactVR - это реализация виртуальной реальности...  И это не просто "очень широкий и объемный спектр технологий" , но так же и ОЧЕНЬ не слабых знаний геометрии, как всей остальной математики.

Обана... Не уж то существует в интернете место, где есть что-то интересное на счет совместной работы nodeJS и MODX... У меня сейчас мало времени, чтобы успеть нормально пробежаться по всем статьям, по поводу них, но 100% уже завтра вечером сяду и все прочитаю.  Сам сейчас просто в неописуемом восторге от JavaScript. Все началось с ознакомления с Google'овским Progressive WebApp (https://developers.google.com/web/progressive-web-apps/ ), а в частности ServiceWorker и его возможностями для работы сайтов из оффлайна + бешеная скорость загрузки/работы за счет асинхронности у всех элементов сайта... И с тех пор пошло-поехало... Но все это время меня удивляла одна простая вещь: если взять тот же самый Gulp, то на самом деле сборка шаблонов на нем не такая уж и сложная задача... Но при этом на том же modx.pro ни слова на эту тему... А тут на тебе, аж целый React :-) Если где-то еще будет информация про Polyfill, то жизнь уж совсем станет сказкой :-) P.S. ReactVR - это реализация виртуальной реальности...  И это не просто "очень широкий и объемный спектр технологий" , но так же и ОЧЕНЬ не слабых знаний геометрии, как всей остальной математики.

Обана... Не уж то существует в интернете место, гд

Реакта здесь будет много. Я сейчас заканчиваю перенос довольно крупного тематического портала на свой движок (готовых комплексных решений под себя так и не нашел, поэтому пилю свое сам. С учетом того, что на базе того, на чем работают городские бани, у меня еще один крупные проект создается, и за эти выходные, за два дня, я почти полностью переписал 10-ти летный проект, который крутился на самописке, на эту новую платформу, думаю, могу уже называть это движком). В начале года будет очередное масштабное обновление сайта Клуба на этот движок, так что все это будет неотъемлемой частью MODX-Клуба, и будет довольно подробно освещаться.

Я не рассматриваю MODX и Javascript как конкурирующие взаимозаменяемые технологии. Они вполне могут существовать совместно. MODX более проще и более предсказуемый, и вполне годится для бэкэнда. А Javascript можно использовать для обновления проекта, создания более современного фронта. Собственно, так же как ангулар и все остальное используется в связке с ларавелем. Далеко же не все, кто использует их в связке, говорит "Так, от ларки отказываемся, теперь только кашерный javascript!".

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

VR всерьез заинтересовался после вот это статьи: 

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

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

>> бешеная скорость загрузки/работы за счет асинхронности у всех элементов сайта...

Бани - довольно тяжеловесный проект получился. Там полно мест еще, где надо оптимизировать. Но даже при этом гугл-спид показывает для компьютеров 97/100 

Для мобильников результат похуже, но тоже не плохой, 75-85.

Реакта здесь будет много. Я сейчас заканчиваю перенос довольно крупного тематического портала на свой движок (готовых комплексных решений под себя так и не нашел, поэтому пилю свое сам. С учетом того, что на базе того, на чем работают городские бани, у меня еще один крупные проект создается, и за эти выходные, за два дня, я почти полностью переписал 10-ти летный проект, который крутился на самописке, на эту новую платформу, думаю, могу уже называть это движком). В начале года будет очередное масштабное обновление сайта Клуба на этот движок, так что все это будет неотъемлемой частью MODX-Клуба, и будет довольно подробно освещаться. Я не рассматриваю MODX и Javascript как конкурирующие взаимозаменяемые технологии. Они вполне могут существовать совместно. MODX более проще и более предсказуемый, и вполне годится для бэкэнда. А Javascript можно использовать для обновления проекта, создания более современного фронта. Собственно, так же как ангулар и все остальное используется в связке с ларавелем. Далеко же не все, кто использует их в связке, говорит "Так, от ларки отказываемся, теперь только кашерный javascript!". Про полифил читал, но пока не вижу для себя необходимости его использовать. Мне достаточно того, что реакт позволяет очень быстро менять свойства выводимого компонента, и нагромождать технологии - это скорее всего лишнее будет. VR всерьез заинтересовался после вот это статьи: Немного поигрался как пользователь, показалось очень занятным направлением. Математики и геометрики за нас уже все сделали. К слову, после того. как это чуть изучил, открыл для себя, что в ютубе очень много 3D-контента. В тот момент немного приуныл, ощутил, как будущее проходит мимо меня. То есть сидишь, делаешь такой что знаешь, а тут уже вокруг много того появляется, чего ты просто не заметил. P.S. >> бешеная скорость загрузки/работы за счет асинхронности у всех элементов сайта... Бани - довольно тяжеловесный проект получился. Там полно мест еще, где надо оптимизировать. Но даже при этом гугл-спид показывает для компьютеров 97/100 Для мобильников результат похуже, но тоже не плохой, 75-85.

Реакта здесь будет много. Я сейчас заканчиваю пере

По поводу рейтинга бань могу дать пару советов:

1) Gulp - для сборки фронта - это наше все. Глянь модули gulp-critical-css (Крит. CSS думаю знаешь, что такое) + gulp-uncss ( анализирует HTML код и находит все неиспользуемые и продублированные стили).

2) На счет кэша браузера, если не путаю, то вроде как, если в редакторе счетчика метрика на Яндексе выбрать "Альтернативный CDN", то проблема уходит.

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

P.S. Когда узнал про gulp-uncss и то, что он "анализирует HTML код и находит все неиспользуемые и продублированные стили и удаляет их", то ,в отличии от тебя, не просто " В тот момент немного приуныл"... Я конкретно о&$%ел. Я несколько лет назад понял, что наступает новая глава в истории программирования, когда сидел за очень слабым офисным компьютером и играл в Quake 3 прямо в браузере...  Ну а далее зайдя в Google Experiments я окончательно сформулировал для себя, что пришла эра JavaScript... 

UPD: Глянул сайт и еще добавлю gulp-autoprefixer... т.к. нет "-webkit-" , "-moz-" и т.п. для поддержки старых браузеров... Работал как-то раньше с банькой одной и могу сказать со 100% уверенностью: публика там и на 8 Internet Explorer может сидеть :-)))))

По поводу рейтинга бань могу дать пару советов: 1) Gulp - для сборки фронта - это наше все. Глянь модули gulp-critical-css (Крит. CSS думаю знаешь, что такое) + gulp-uncss ( анализирует HTML код и находит все неиспользуемые и продублированные стили). 2) На счет кэша браузера, если не путаю, то вроде как, если в редакторе счетчика метрика на Яндексе выбрать "Альтернативный CDN", то проблема уходит. 3) На счет картинок не думаю, что смогу что-то новое для тебя сказать... Мне почему-то кажется, что скорее всего ты тут банально схалтурил :-) P.S. Когда узнал про gulp-uncss и то, что он "анализирует HTML код и находит все неиспользуемые и продублированные стили и удаляет их", то ,в отличии от тебя, не просто " В тот момент немного приуныл"... Я конкретно о&$%ел. Я несколько лет назад понял, что наступает новая глава в истории программирования, когда сидел за очень слабым офисным компьютером и играл в Quake 3 прямо в браузере...  Ну а далее зайдя в Google Experiments я окончательно сформулировал для себя, что пришла эра JavaScript... UPD: Глянул сайт и еще добавлю gulp-autoprefixer... т.к. нет "-webkit-" , "-moz-" и т.п. для поддержки старых браузеров... Работал как-то раньше с банькой одной и могу сказать со 100% уверенностью: публика там и на 8 Internet Explorer может сидеть :-)))))

По поводу рейтинга бань могу дать пару советов: 1)

Картинок там только две, на которых он ругается - аватарки 150 на 150, там, где они реально меньше нужны. На счет "схалтурил", ты вообще погорячился. С картинками как раз у меня там все вполне нормально. В модели прописаны сразу несколько вариаций картинок.

Для топиков еще больше вариаций.

Основное, на что ругается гугл, так это на объем HTML-кода "Для показа верхней части страницы понадобилось 156,8 КБ данных с сервера" и долгий ответ сервера - +-1 секунда. Но я не планирую в угоду этого архитектуру менять. С мобильника я пробовал, уже через 2 секунды я могу взаимодействовать со страницей, до того, как 15% контента подгрузилось (имеется ввиду со скриптами и т.п.), я считаю, что это вполне нормально. Я без 100/100 вполне переживу :)

С советами этими чуть опоздал. 

1. Галп, ИМХО - прошлый век. От него аж корежит. Отладка в нем - вообще Адовый АДъ. Пока webpack. Позже может на фейсбуковый сборщик пересяду, если станет стандартом.

2. Стили - вообще не актуально. Глянь CSS. Там fontawesome и бутстрап. От одного и второго откажусь скоро, они просто прилетели наследием, просто потому что мне было лень переделывать шапку. А основные стили в теле документа ищи. Ты их не зачистишь сторонними решениями, там все уникальное. Фишка в том, что это динамические стили. Раз правило в документе есть, значит есть какой-то элемент, для которого это правило нужно. jscss слышал? material-ui@alpha/beta

      "image": "assets/images/lazy/3db3624b49a80589c6704af6759ecdff.jpeg",
      "imageFormats": {
        "thumb": "images/resized/thumb/assets/images/lazy/3db3624b49a80589c6704af6759ecdff.jpeg",
        "small": "images/resized/small/assets/images/lazy/3db3624b49a80589c6704af6759ecdff.jpeg",
        "middle": "images/resized/middle/assets/images/lazy/3db3624b49a80589c6704af6759ecdff.jpeg",
        "big": "images/resized/big/assets/images/lazy/3db3624b49a80589c6704af6759ecdff.jpeg"
      },

Картинок там только две, на которых он ругается - аватарки 150 на 150, там, где они реально меньше нужны. На счет "схалтурил", ты вообще погорячился. С картинками как раз у меня там все вполне нормально. В модели прописаны сразу несколько вариаций картинок. Для топиков еще больше вариаций. Основное, на что ругается гугл, так это на объем HTML-кода "Для показа верхней части страницы понадобилось 156,8 КБ данных с сервера" и долгий ответ сервера - +-1 секунда. Но я не планирую в угоду этого архитектуру менять. С мобильника я пробовал, уже через 2 секунды я могу взаимодействовать со страницей, до того, как 15% контента подгрузилось (имеется ввиду со скриптами и т.п.), я считаю, что это вполне нормально. Я без 100/100 вполне переживу :) С советами этими чуть опоздал. 1. Галп, ИМХО - прошлый век. От него аж корежит. Отладка в нем - вообще Адовый АДъ. Пока webpack. Позже может на фейсбуковый сборщик пересяду, если станет стандартом. 2. Стили - вообще не актуально. Глянь CSS. Там fontawesome и бутстрап. От одного и второго откажусь скоро, они просто прилетели наследием, просто потому что мне было лень переделывать шапку. А основные стили в теле документа ищи. Ты их не зачистишь сторонними решениями, там все уникальное. Фишка в том, что это динамические стили. Раз правило в документе есть, значит есть какой-то элемент, для которого это правило нужно. jscss слышал? material-ui@alpha/beta

Картинок там только две, на которых он ругается - 

 >>>  На счет "схалтурил", ты вообще погорячился

Это была шутка :-) Я прекрасно понимаю, что было что-то из серии:

>>>  аватарки 150 на 150, там, где они реально меньше нужны. 

>> Основное, на что ругается гугл, так это на объем HTML-кода "Для показа верхней части страницы понадобилось 156,8 КБ данных с сервера" и долгий ответ сервера - +-1 секунда. 

Это-то понятно... В будущем Google видит Progressive WebApp, а у них как раз по ним и приколы главные. Вот, к примеру результаты прогона сайта бань в LightHouse:

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

https://developers.google.com/web/tools/lighthouse/audits/http-200-when-offline 

Если мало-ли вдруг понадобится, то вот чеклист:
https://developers.google.com/web/progressive-web-apps/checklist 

>>>  На счет "схалтурил", ты вообще погорячился Это была шутка :-) Я прекрасно понимаю, что было что-то из серии: >>>  аватарки 150 на 150, там, где они реально меньше нужны. >> Основное, на что ругается гугл, так это на объем HTML-кода "Для показа верхней части страницы понадобилось 156,8 КБ данных с сервера" и долгий ответ сервера - +-1 секунда. Это-то понятно... В будущем Google видит Progressive WebApp, а у них как раз по ним и приколы главные. Вот, к примеру результаты прогона сайта бань в LightHouse: https://yadi.sk/i/ohsPgjQQ3QHJXd Но тут уже из другой оперы, конечно, тестирование. Особенно меня радует кэширование на стороне клиента и за счет этого работа даже без интернета: https://developers.google.com/web/tools/lighthouse/audits/http-200-when-offline Если мало-ли вдруг понадобится, то вот чеклист:
https://developers.google.com/web/progressive-web-apps/checklist

>>>  На счет "схалтурил", ты вообще погорячился Эт

>>> Раз правило в документе есть, значит есть какой-то элемент, для которого это правило нужно. jscss слышал? material-ui@alpha/beta 

Про jscss нет, не слышал... Я особо в React не лазал...  Пока что в сторону Polymer буду курс держать... Там уж точно:

>>> Раз ... в документе есть, значит есть какой-то элемент, для которого это ... нужно

Да и на счет... >>> Раз правило в документе есть, значит есть какой-то элемент, для которого это правило нужно. jscss слышал? material-ui@alpha/beta Про jscss нет, не слышал... Я особо в React не лазал...  Пока что в сторону Polymer буду курс держать... Там уж точно: >>> Раз ... в документе есть, значит есть какой-то элемент, для которого это ... нужно :-)

Да и на счет... >>> Раз правило в документе есть, 

ОК, возьму на заметку, но сейчас для меня это пока рановато. Я развиваю самую логику, и только когда она будет окончена, можно будет заниматься оптимизацией. Сейчас в таком случае это будет Разработка-Оптимизация-Тестирование-Разработка и так далее в цикле. Лишнее звено, при чем весьма ресурсоемкое. 

ОК, возьму на заметку, но сейчас для меня это пока

Вот еще один проект запустил на этом движке: http://pivkarta.ru/ 

Этот проект уже гораздо сложнее и объемней, чем городские бани. Яндекс в результаты выдает 83 000 страниц. 

- 555 + 175 записей в блоги и событий.

- 26 500 пользователей (не вычищал фейков, пока не знаю долю реальных пользователей, но их большая часть).

В общем, сайт предъявил серьезные требования к разработке и оптимизации. Когда запустил первичную версию, нода на запуске съедала больше 2 Гб оперативки (затем в стабильном режиме 700+ метров), получение всех API-данных занимало более 40 сек, и страницу отдавало за 1-10 сек. 

Сейчас штатный режим менее 500 метров требует (на запуске пик чуть более гига), страницу отдает 0.4-1 сек (на паре страниц до 1,5 сек, но это поправлю).

Вот еще один проект запустил на этом движке: http://pivkarta.ru/ Этот проект уже гораздо сложнее и объемней, чем городские бани. Яндекс в результаты выдает 83 000 страниц. Сущностей на сайте: - 1 500 видов пива. - 555 + 175 записей в блоги и событий. - 3 300+ комментариев. - 3 500+ заведений. - 8 300+ фотографий. - 26 500 пользователей (не вычищал фейков, пока не знаю долю реальных пользователей, но их большая часть). В общем, сайт предъявил серьезные требования к разработке и оптимизации. Когда запустил первичную версию, нода на запуске съедала больше 2 Гб оперативки (затем в стабильном режиме 700+ метров), получение всех API-данных занимало более 40 сек, и страницу отдавало за 1-10 сек. Сейчас штатный режим менее 500 метров требует (на запуске пик чуть более гига), страницу отдает 0.4-1 сек (на паре страниц до 1,5 сек, но это поправлю).

Вот еще один проект запустил на этом движке: http:

Прямо в тему оповещение пришло про комментарий. Сейчас изучаю сайт один, который после 2-3 месяцев разработки ... Мне вот интересно , а степень моего веселья понять можно всего лишь по скрину файлового менеджера из админки сайта? 34к взял чел за натяжку на MODX. 

P.S. почему-то правда картинка через место одно выводится в теле комментария, поэтому надо смотреть по ссылке.

P.P.S. !!!! 2-3 МЕСЯЦЕВ НЕ МОЕЙ РАЗРАБОТКИ  !!!!! 

Прямо в тему оповещение пришло про комментарий. Сейчас изучаю сайт один, который после 2-3 месяцев разработки ... Мне вот интересно , а степень моего веселья понять можно всего лишь по скрину файлового менеджера из админки сайта? 34к взял чел за натяжку на MODX. P.S. почему-то правда картинка через место одно выводится в теле комментария, поэтому надо смотреть по ссылке. P.P.S. !!!! 2-3 МЕСЯЦЕВ НЕ МОЕЙ РАЗРАБОТКИ  !!!!! https://yadi.sk/i/jKGUTsCK3QKcKm

Прямо в тему оповещение пришло про комментарий. Се

Чтот я не уловил посыла. Можно чуть разжевать?

Посыл в том, что хочу узнать твое мнение, т.к. не могу понять: JS кретинизм- это проблема только среди MODX разрабов или сейчас вообще везде острая нехватка Frontend разрабов? В последнее время все больше поражает, какие все крутые/важные на modx.pro , хотя кроме пыхи и AjaxForm/AjaxSnippet от Васи не знают ничего. Трындец какой-то. 

Посыл в том, что хочу узнать твое мнение, т.к. не 

Я все равно не уловил в чем JS-кретинизм. Ты про то, что кто-то накидал все в корень сайта? Ну да, это фигня полная. Но это не только касаемо JS косяк. Кидать в корень что угодно - глупость.

Я все равно не уловил в чем JS-кретинизм. Ты про т

ajax

modxSmarty

node.js

react

smarty

интернет-магазин

ищу

каталог

парсер

работа

смарти

шаблонизация

# Николай Ланец aka Fi1osof
**Lead Fullstack Developer / Ментор / Евангелист современного JS‑стека**

---

## О себе

Я — не просто Senior Developer с 2007 года. Я — тот, кто строит продукты будущего на базе современных технологий и помогает другим подниматься на новую ступень айти-карьеры. Создатель и идейный вдохновитель freecode.academy — платформы, где обучение перестает быть скучной обязаловкой и становится настоящим технологическим приключением.

---

## Мой стек и философия разработки

Основу моего рабочего арсенала составляют:

- [Javascript](/technologies/ck1faudv928l40a89c4u9zxlm), [TypeScript](/technologies/ckcvwwx010kov08009u7y2rav)
- [React](/technologies/ck1fawbdw28v20a891k4wlh27), [Next.js](/technologies/ckg2jd4ffr9260730aog66dri)
- [Node.js](/technologies/ckt55wm59272831wo9gg9r8ynx), [GraphQL](/technologies/ck1fawhqk28vu0a8995lqvlsj), [Apollo Client](/technologies/ck2zdcg0vpvc10a89xjmhj1e0), [Nexus](/technologies/ckl2pbh0fxew60730ifl3zozp), [Prisma](/technologies/ck2zdbmi7pv8r0a89ntc2r0f1)
- DevOps: [Docker](/technologies/ck2y1x9lho9cy0a8953xzfjr8), [docker-compose](/technologies/ck2y1xqino9g80a89tsftxin2), [Caddy](/technologies/ck2zd8ovqpuyl0a8909748sbu), [Ubuntu](/technologies/cktu8giks3593911vmle30ztqxt)
- UI-инструменты: [Styled-Components](/technologies/ckk8myysio7lw0730csszvrdw), [Material-UI](/technologies/ckljv3jwd7bgf0730huxlko9n), [react-hook-form](/technologies/ckmx8cn9fmwrv073032e67722)
- Всё актуальное для разработки, CI/CD и автоматизации 
- Эксперименты с [WebGL](/technologies/ckan9anntc12f08003saqttrq), [A‑Frame](/technologies/ck2tgoiz8j37y0a89c7gxsrxc), [Three.js](/technologies/ck2tgns1nj32z0a89vmw7xw3f), [Unreal Engine 4](/technologies/ck7puswy6g4yb07004cdp6lbr), [Elixir](/technologies/ckn0olavrnnzi0730xs8rctn8), [C++](/technologies/cknin1y8lu2fr07307mskn2fn)

---

## Разработка и менторство

- Более 15 лет **hands-on** разработки и проджект‑менеджмента
- Главный разработчик и преподаватель платформы [freecode.academy](https://freecode.academy)
- **Ведущий менти-пул на платформе** — лично выращиваю новых звезд отрасли

### Мои менти и их результаты

| Менти (ФИО \| username)                               | Уровень | Рейтинг |
|-------------------------------------------------------|---------|---------|
| [Попов Дмитрий \| linklib](/users/cjoe890c706ji0d962oismzoe)           | 3       | 315     |
| [Сэт \| defk1lla](/users/ckzh1ita312978121imr9hpqfc64)                 | 3       | 670     |
| [Ксения Матвеева \| Ксения Матвеева](/users/ckz4awwlh10627771imr4wvpb7cj) | 2       | 0       |
| [Михаил \| Balamut](/users/cl1npq92z10258261vmbq0w6vfh2)               | 2       | 0       |
| [Ольга Ершова \| angel](/users/cjoe87zhk00250d969arluevk)              | 1       | 0       |
| [Егор \| rogedkone](/users/cksrdp47d3308261ijuq7wfrxdl)                | 3       | 0       |
| [Roman \| Roman43](/users/ckur2qtt64721431xoboyjcte52)                 | 2       | 0       |
| [Бут Игорь \| santiment](/users/ckttd9x20893951vmltb8t7sha)            | 1       | 0       |

**Доношу простую мысль: успех — это не магия, это осознанная системная работа и кайф от роста.**
Мои менти выводят решения в продакшн, пробиваются в лидеры рейтингов — кому не хочется быть в такой команде?

---

## Почему я?

- **Прокачаю проект** — от TDD архитектуры до культурного CI/CD
- **Вдохновлю команду** — и научу мыслить по‑новому, где ИИ — напарник, а не угроза
- **Выращу мидлов и сеньоров** — доказано платформой и рейтингами моих учеников

**Сила — в сообществе, а техника — это просто смазка для ваших побед. Присоединяйтесь!**

---

## Контакты

- 📧 [n.lanets@freecode.academy](mailto:n.lanets@freecode.academy)
- Телеграм: [@freecode_academy](https://t.me/freecode_academy)

---

**P.S.**: Мой опыт — ваш драйвер роста. Хотите в команду? Ищете менторство? Пишите. Растём вместе!