Евгений Шеронов

Видел ваше письмо на почте касательно YandexMarket2.

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

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

Здравствуйте!

Поправьте настройки корневого элемента (на последней вкладке прайс-листа), добавив обработчик к атрибуту date так:


Сам код:

{$input | date: 'Y-m-d\TH:i:sP'}

Это стандартный обработчик даты средствами Fenom. Значение взято отсюда www.php.net/manual/ru/class.datetimeinterface.php (константа ATOM)

В следующем обновлении учту, и скорее всего автоматически поправлю дату и в ранее добавленных прайс-листах для Яндекс Маркета.

Можете прям здесь (или в тех поддержку на Modstore) приложить ссылку на сайт.
По классам для ajax замен или по ошибкам в консоли будет понятнее проблема.

Пожалуйста :)

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

P.S. а сам вопрос касательно того, что пока пишется файл поисковики могут получить не валидную часть — добавлю в TODO, чтобы из коробки файл писался с временным названием и после записи переименовывался.

А дальше напишете «не коммерс» вариант SeoFIlter или mSearch2 для своих нужд, которым решите поделиться?)

Где-то я уже видел такое (˘･_･˘)

s29588.h10.modhost.pro/catalog-sinenkij

[[*id:input=`<script src="[[++assets_url]]components/themebootstrap/js/jquery-3.5.1.min.js"></script>`:jsToBottom=`1`]]

Это что ещё за способ прописывать скрипты в чанк Head?) Я вполне мог что-то пропустить.
Можно просто по-человечески прописать в Footer, либо убрать этот jsToBottom (что я в общем-то и сделал).

В консоли браузера не только SeoFilter ругался на отсутствие jQuery (при подключении способ выше — он отрабатывает позже и скрипт jQuery становится ниже подключений из плагинов)

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

Что имеется ввиду под быстротой?)

Здесь я вижу самый медленный возможный поиск.
Он не использует индексов в БД вообще (так как с двух сторон навешаны %).

Опять таки query параметр никак не экранируется (привет SQL инъекция!).
Возможно pdoTools и обработает как-то where, но рассчитывать, а тем более привыкать так делать не нужно.

Сайт небольшой — это до 100 страниц?

Помимо этого, условие некорректно выполняется. Шаблон не будет учтён при совпадениях вне pagetitle)

Даже по заметке не особо стало понятно, почему работает на одной странице нормально, а на другой нет.

А вообще, если в вызове mFilter2 есть условия — то и в правилах SeoFilter их нужно повторить.

Если совет не поможет — пишите в поддержку. Там разберёмся.

Заметка уже закрыта. Разобрались?

Ну прям в браузере же видно, что в url не попадают псевдонимы, которые должны быть прописаныв параметр &aliases в вызове mFilter2 согласно документации.

А прописаны там только:

{
vendor: 'ms|vendor', 
spare_node: 'msoption|spare_node', 
equipment: 'msoption|equipment'
}

Добавьте необходимые и всё заработает.

Если мы храним сессии в файлах, то они там и остаются. Храним сессии в базе — они там и остаются.

А если жёсткий диск полетит?)

все будет потеряно

А в сессии ничего важного и не должно быть. Максимальные потери здесь — содержимое корзины да и выход из аккаунта. А если настроить сохранение на диск, то и потеряется только сессионные данные за последние n секунд)

У вас нет ссылок на примеры реализации?

Я делал. Для начала нужно установить на сервер github.com/phpredis/phpredis

В MODX нужно всего лишь очистить системную настройку session_handler_class — в этом случае за сессии будет отвечать PHP и по умолчанию будет хранить их в файлах.

Для хранения их в redis нужно в php.ini указать:

session.save_handler = redis
session.save_path = "tcp://host1:6379?weight=1, tcp://host2:6379?weight=2&timeout=2.5, tcp://host3:6379?weight=2&read_timeout=2.5"
; а для тех кто, как и я предпочитает подключение по сокету в пределах одной машины: 
session.save_path = "unix:///var/run/redis/redis.sock?persistent=1&weight=1&database=0"
; но в этом случае нужно ещё в redis.conf указать этот же путь в unixcocket

И теперь уже PHP будет отвечать за хранение сессий в redis.
Более подробнее уже несложно нагуглить)

Ещё правильнее хранить сессии в Redis.
При правильных настройках — у активных пользователей сессия не будет слетать (так как часто запрашивается).
А менее популярные сессии анонимов при большом размере кеша будут выталкиваться.

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

Но я не знаю и не делал сайтов на MODX, работающих одновременно на двух серверах)

Решение хорошее.

Но раз это готовое бесплатное решение, то позволите мне немного рекламы?)

Для тех кто хочет визуально управлять элементами с описаниями полей, выгружать большие объемы точно валидного XML и не трогать код — то выгрузка под похожий формат Google Rss 2.0 (это Гугл покупки, и что-то для Фейсбука) есть в компоненте YandexMarket2 (пост о добавлении такого типа выгрузок писать не стал, инфа была только в changelog)

Я сам с тобой делился настройкой CORS выше))
Там где ещё куки пишутся для авторизации.

И эта политика распространяется только на один контроллер компонента, а не на весь MODX, и только тогда, когда мне это нужно))

Я видимо слишком подробно и запутанно объясняю)

Не совсем так, у меня просто MODX стоит на сервере и все файлы синхронизируются туда.
По сути просто фронтенд приложение работает на localhost, а весь бэкенд на реальном домене.
Ещё через шторм часто пишу и проверяю SQL запросы подключаясь к БД через ssh туннель)

Да и не вставляю я руками скрипт) этот коннектор всегда такой в ветке dev. В ветке master всё чисто, на которую я и переключаюсь для вливания изменений и для сборки транспортного пакета (именно на ветке master я уже не могу из локального фронтенда подключиться к бэкенду на сервере из-за CORS).

Заготовки же MODX + Vue.js были в статьях на которые я ссылался в своей статье. Там даже установочный скрипт был, но я его не использовал.

Когда начну и допишу документацию по маркету — то попробую поделиться как раз своими конфигами или может целую заготовку сделаю modExtraVuetify. Но это не в ближайшие недели)

Вы не понимаете, это другое)

По axios с одной стороны да, привычка.
Но с другой стороны это более лаконичный синтаксис по сравнению с нативным fetch.
В axios проще засеттить значения по умолчанию: в моём случае адрес коннектора и заголовки именно там, где эти значения получены. Чуть проще обрабатывать HTTP ошибки (хотя к MODX это плохо относится, другая парадигма ответов).

Axios я использую не потому что привык это делать в мире MODX и jQuery, а потому что увидел его уже в мире Vue.js и видел регулярно. Да и вообще он появился раньше, чем появился fetch)

Переходя на другую технологию может и было бы легче использовать старые добрые инструменты (тот же jQuery.ajax()), но потом приходит понимание, что не просто так же используются другие решения (иногда просто так :) )

В своё время jQuery был прекрасным инструментом, но сейчас это уже legacy — развитие браузеров и JavaScript оставило его не у дел. И теперь уже нет такой нужды использовать его. Конечно, полно сайтов ещё долго будут использовать jQuery, но чем дальше — тем болезненнее слезать.

И уж точно не нужно его приносить в другой мир, где есть инструменты, которые решают те же задачи, но по-своему (обычно лучше, быстрее, надёжнее и т.д.).

И за модой тоже нужно следить. Мода это же не плохо, иногда она становится новым стандартом на много лет. За прекрасным пример отставания от моды и стандартов далеко ходить не нужно)

Не особо слежу за ютуб обучениями, но такой подход — это такой же трэш)

Даже если нужно будет фронтенд раскидать между командами — то это точно будет не так.
Варианты:
1) Разные фреймворки — но по разделам, админка например на одном фреймворке, пользовательская на другом.
2) Если прям хочется поделить одну страницу — то всё просто в пределах одного фреймворка, но использованием одного нормального хранилища с модульной структурой, типо Vuex или Redux. ​

Поэтому, что это видео, что то на английском — всё это жуткий bad practice. Остаётся надеяться, что все просмотревшие восприняли это как учебный эксперимент и никогда не подумают повторять.