Не пользуюсь getImageList. Но уверен на 98%, он формирует SQL-запросы стандартным xPDO-механизмом, а не как у Василия. И на сколько я могу судить по документации, getImageList не умеет принимать параметр includeTVs и ему в принципе пофиг на &includeTVs=`id_pages`. Таким образом колонки id_pages в запросе просто не будет. Но повторюсь, могу ошибаться, так как ни с pdoPage, ни с getImageList не работаю. Может кто другой подскажет.
Так или иначе, в любом случае при генерации кеша такого количества страниц придется столько ждать. Ведь генерация кеша страниц — это по сути заход на страницу, и если у вас страницу не из кеша отдает за секунду, то все страницы перегенерить — 1 сек * кол-во страниц, в вашем случае это 2000 секунд. Если отдает за 0.2 сек, то в пять раз меньше времени.
В общем, я тут думал как вам помочь, и вспомнил, что давным-давно Илья Уткин дописывал функционал циклического выполнения кода в консоль (За что Илье отдельное спасибо). ilyaut.ru/cheats/step-by-step-the-script-in-console/
В итоге я написал вот такой скрипт: gist.github.com/Fi1osof/398e64212f1c527958adce83734ddf4b
Его можно использовать для ручной перегенерации кеша всех страниц. Если его запустить, он получит ID-шники всех целевых страниц и перегенерирует их кеш. Выглядит процесс довольно симпатично.
Вот можете воспользоваться этим скриптом. Сохраните его в консоли (функционал такой добавил Сергей Шлоков) и выполняйте когда вам надо.
Повторю логику: для того, чтобы не сбрасывался кеш на каждый чих, сделайте как я написал выше. А если вам надо вдруг сбросить кеш всего сайта вручную, то можете запустить потом этот скрипт. Если вам не хочется ждать по полчаса каждый раз, вы можете добавить в условие выборки только самые нагруженные ресурсы (к примеру, по определенным шаблонам).
Кстати, здесь сразу идея возникает связки этого скрипта с modMonitor. Монитор собирает статистику какие страницы не из кеша отдаются долго, и потом при запуске этого скрипта перегенерируются только те страницы, время генерации которых превышает заданный парог. Получится интеллектуально.
Важно: Для работы требуется минимум console-2.2.1
Ее я отправил на modx.com, но пока еще не опубликовали. Можно вручную подправить в консоли вот этот код.
Как я и говорил, на таком количестве не стоит включать настройки cacheregenerator.regenerate_docs_on_site_refresh и cacheregenerator.regenerate_docs_on_doc_save, иначе на сохранение документа и на сброс кеша сайта у вас будет запускаться механизм регенерации страниц, который в среднем занимает 1 сек на страницу (в зависимости от скорости работы сайта). Таким образом полчаса ждать после сохранения документа — вообще не вариант.
Вариант только такой: отключаете системную настройку syncsite_default и при сохранении редактируемого документа не будет сбрасываться кеш остальных документов, а только текущего, при чем у текущего документа кеш сразу будете перегенерирован. Таким образом вы получаете измененное содержимое страницы сразу в кеше.
Речь же не о каком-то злом соперничестве, а просто о желании что-то сделать лучше. Я тоже рад, что ты это сделал. Реально. И есть с кем что обсудить, и появление таких продуктов говорит о том, что рынок движется к этому. Так что я только за все это. Но идеи мои идут вообще в другую сторону, я позже их распишу.
Блин, если перенести это подключение в отдельный класс, который будет подключаться как MODX-сервис, то будет так же запрос выполняться (просто это был единственный эксперимент на уровне MODX-сайта, и он еще не перешел в отдельный пакет). Но речь же о том, что происходит внутри самого класса. У тебя так и останется много строчек, или превратится в подключение сторонней библиотеки + пара строк на вызов? А то у тебя там столько всего, и пока, как я понимаю, это GET-запросы. А когда будет POST и прочее? Это еще разрастется?
Я не придираюсь, я просто пытаюсь понять для себя. Это и для меня все новое и я не один час потратил на поиски подходящего механизма для отправки запросов на сервер средствами php. Меня мой способ устраивает, потому что он отправляет запросы именно по протоколу ws://, ровно так же, как эти же запросы идут из браузера. Крайне не радует перспектива использовать два отдельных протокола и формировать разные форматы данных.
Ты меня несколько опережаешь в реализации идей.))) Я тоже такое мыслил. Но я ушел в более глубокие задумки (включая криптографию). Так что постараюсь отыграться позже :)
Ясно. Ну посмотри, может какие идеи возникнут. Просто для меня вот столько кода — это много. Всегда сложности были с функциями типа fsockopen. Вот так же проще?:
Кстати, дополнительно обозначу идею: это клиент с исходным кодом. Каждый может изменить внешний вид под себя. Используется twig-шаблонизатор.
Весь JS/HTML-фронт тоже имеется, включая JS-чата.
Там, конечно, немного АДъ, так как это все еще эксперименты, но разобраться, думаю, не дофига дело. Чтобы пересобрать фронт со своим измененным кодом просто переходим в папку /public/chat, выполняем команду npm install, чтобы установились все пакеты нужные.
Придется подождать не одну минутку, там много пакетов устанавливается. Когда все установится, вы увидите подобное:
После этого выполняем команду webpack -w (запустится сборщик, прослушивая изменения файлов). Когда вы увидите такое (опять-таки, возможно через пару-тройку минут):
можно будет файлы править.
К слову, использовалась вот эта заготовка фронта: github.com/MODX-Club/modx-shopmodx-frontend
Она же используется и в ShopModxBox, то есть там можно таким же образом пересобирать фронт.
То есть, если кому интересно, может сап попробовать поправить фронт (к примеру, добавить звуковые уведомления о новых сообщениях). И даже не лезя в серверную часть самого чата, можно получить свой собственный клиент (с оговорками, конечно, но все же).
Никита, socket.io — сторонний сервис? Мне не улыбнулось использовать сторонние сервисы для запросов php-websocket. Вот смотри какую либу нарыл: github.com/Textalk/websocket-php
С ее помощью запросы на node-сервер без проблем слать. Сампл:
Ну понеслась...)))
Только хотел написать отдельный топик про выложенный node-клиент для нашего чата, а тут такое… Ну, тогда не буду писать отдельного топика, просто ограничусь комментом (сорри за оффтоп).
Итак, на днях я писал, что мы разрабатываем автономный node-чат (его работу можно увидеть на главной странице нашего сайта). Вопрос: хочет кто-нибудь себе такой же? Если да, то вот он: www.npmjs.com/package/node.social-client
Конкретно этот компонент — не полная версия всей системы, а только веб-сервер с чат-клиентом. Для полноценной работы ему еще нужен отдельный сервер, обрабатывающий непосредственно запросы. Как написано в ридми, вы можете использовать для этого наш сервер wss://modxclub.ru:8100 (эти сообщения будут видны на главной странице нашего сайта). Если кому-то нужен выделенный сервер для тестов, пишите в личку, подниму (бесплатно только сегодня). Вторая часть системы (уже сам чат-сервер) появится чуть позже.
Если вдруг кто пропустил сообщение Василия по поводу где можно развернуть такой сервер, уточняю: на modhost.pro
Добрый день.
И посуточно можно, и по часам, и даже по минутам можно.
1) Возможность оплаты онлайн (с возможностью автоматического аннулирования бронирования в течение некоторого времени, в которое не осуществлена оплата)
2) Отправка посетителю инвойса (pdf) на электронный ящик с данными о бронировании
4) Возможность экспорта бронирований в Excel
Да.
3) Наличия скидок на определенные дни недели
Это скорее на плечах движка магазина, того же minishop или shopmodx.
Я уже писал выше, что сейчас хостинги дают node.js. Это становится так же естественно, как git. На том же бегете можно в саппорт написать и они поставят ноду, у нас Саша Марков запрашивал, ему без проблем поставили.
В моем понимании не лучше. Я хочу выйти за пределы MODX. Не уйти от MODX, а расширить сферу, не ограничиваясь одной платформой. Для примера представьте, что с телефона можно было бы звонить только на телефоны того же производителя, и нельзя с самсунга позвонить на ксиоми и наоборот. Это же бред? Так почему у нас модули должны быть заточены только под MODX. Я вам скажу так, что здесь сложность падает на плечи разработчика, а не конечного пользователя. Конечный пользователь только выигрывает от универсальности и большего охвата. Еще один яркий пример: платежные системы. В том же модсторе под них лежит куча модулей. Так вот, то, что лежит в модсторе, не является как таковой платежной системой, это только тонкий клиент. Сама же платежная система не заточена конкретно под MODX и не работает только на нем. Так же и здесь, я буду писать теперь обособленные самостоятельные модули, которые можно использовать много где, а не только на MODX. Но к ним в обязательном порядке писать клиента под MODX. И все довольны.
Опережая чей-то возможный вопрос «А почему такой универсальный компонент не писать на базе самого MODX-а?», я отвечу:
1. MODX сложнее в переносе. Если вы его из одной папки в другую перенесете, он у вас уже работать перестанет, надо конфиги править. node.js-проект этим не страдает, его просто перекидываешь в любую папку (или на любой другой комп, где стоит подходящая версия node.js) и все, запускаешь.
2. node.js один компонент можно запустить сразу кучу инстансов, просто указав разные порты. Это круто. Имея тот же модуль чата, можно из одной папки запустить несколько сотен отдельных комнат.
3. Установка компонентов там и там — просто небо и земля. В ноде прописал нужный компонент в package.json, выполнил npm install и все (или вообще просто npm install package). После этого в любом месте кода пишешь var module = require(module); и полетело.
В общем, я несколько лет пишу компоненты под MODX, делал не мало интеграций с различными сторонними системами, и знаю что делаю.
Народ и обычные-то модули не особо поправляет, хотят чтобы просто поставил, конфиги подправил и все. Здесь ориентир на то же самое будет (конфиги править). В мозги лезть не надо. Единственная сложность возникает — это на хостинге надо node.js и composer иметь.
Немного корректировок:
1. В node.js используется крутой механизм подгрузки и переопределения компонентов, например var booking = require($path_to_module);
По умолчанию будет использоваться автономный модуль работы без каких-то внешних систем. Но его можно будет легко переопределить другим модулем типа var booking = require($path_to_extra_module); в котором прописано var extra_booking = require($path_to_module); export extra_booking; (Это в общих чертах). И в этом переопределяющем компоненте будет перехват штатных событий и взаимодействие с MODX-сайтом (типа запросить имеющийся объект, отправить уведомление и т.п.).
2.
работает со своей бд
Мы умеем читать конфиги MODX-а и работать с базой сайта, включая префиксы таблиц. В MODX-модель компонента мы добавим нужные классы и мап-файлы, чтобы легко можно было средствами xPDO работать с таблицами компонента напрямую, при желании.
3. Даже при работе с сайта напрямую в ноду, не придется выполнять никаких лишних проверок доступа пользователя (авторизован или нет) и т.п. Мы пересылаем запрос на сам сайт с передачей кукисов, так что даже получая запрос из браузера не напрямую, а через ноду, MODX будем воспринимать это как прямой запрос себе из браузера, так что все авторизации и сессии пользователей будут учитываться как есть.
В общем, я тут думал как вам помочь, и вспомнил, что давным-давно Илья Уткин дописывал функционал циклического выполнения кода в консоль (За что Илье отдельное спасибо). ilyaut.ru/cheats/step-by-step-the-script-in-console/
В итоге я написал вот такой скрипт: gist.github.com/Fi1osof/398e64212f1c527958adce83734ddf4b
Его можно использовать для ручной перегенерации кеша всех страниц. Если его запустить, он получит ID-шники всех целевых страниц и перегенерирует их кеш. Выглядит процесс довольно симпатично.
Вот можете воспользоваться этим скриптом. Сохраните его в консоли (функционал такой добавил Сергей Шлоков) и выполняйте когда вам надо.
Повторю логику: для того, чтобы не сбрасывался кеш на каждый чих, сделайте как я написал выше. А если вам надо вдруг сбросить кеш всего сайта вручную, то можете запустить потом этот скрипт. Если вам не хочется ждать по полчаса каждый раз, вы можете добавить в условие выборки только самые нагруженные ресурсы (к примеру, по определенным шаблонам).
Кстати, здесь сразу идея возникает связки этого скрипта с modMonitor. Монитор собирает статистику какие страницы не из кеша отдаются долго, и потом при запуске этого скрипта перегенерируются только те страницы, время генерации которых превышает заданный парог. Получится интеллектуально.
Важно: Для работы требуется минимум console-2.2.1
Ее я отправил на modx.com, но пока еще не опубликовали. Можно вручную подправить в консоли вот этот код.
Как я и говорил, на таком количестве не стоит включать настройки cacheregenerator.regenerate_docs_on_site_refresh и cacheregenerator.regenerate_docs_on_doc_save, иначе на сохранение документа и на сброс кеша сайта у вас будет запускаться механизм регенерации страниц, который в среднем занимает 1 сек на страницу (в зависимости от скорости работы сайта). Таким образом полчаса ждать после сохранения документа — вообще не вариант.
Вариант только такой: отключаете системную настройку syncsite_default и при сохранении редактируемого документа не будет сбрасываться кеш остальных документов, а только текущего, при чем у текущего документа кеш сразу будете перегенерирован. Таким образом вы получаете измененное содержимое страницы сразу в кеше.
Я не придираюсь, я просто пытаюсь понять для себя. Это и для меня все новое и я не один час потратил на поиски подходящего механизма для отправки запросов на сервер средствами php. Меня мой способ устраивает, потому что он отправляет запросы именно по протоколу ws://, ровно так же, как эти же запросы идут из браузера. Крайне не радует перспектива использовать два отдельных протокола и формировать разные форматы данных.
У тебя так же и на стороне браузера формируются запросы?
P.S. на ноде сокеты реализованы на вот этим модулем: www.npmjs.com/package/ws
Весь JS/HTML-фронт тоже имеется, включая JS-чата.
Там, конечно, немного АДъ, так как это все еще эксперименты, но разобраться, думаю, не дофига дело. Чтобы пересобрать фронт со своим измененным кодом просто переходим в папку /public/chat, выполняем команду npm install, чтобы установились все пакеты нужные.
Придется подождать не одну минутку, там много пакетов устанавливается. Когда все установится, вы увидите подобное:
После этого выполняем команду webpack -w (запустится сборщик, прослушивая изменения файлов). Когда вы увидите такое (опять-таки, возможно через пару-тройку минут):
можно будет файлы править.
К слову, использовалась вот эта заготовка фронта: github.com/MODX-Club/modx-shopmodx-frontend
Она же используется и в ShopModxBox, то есть там можно таким же образом пересобирать фронт.
То есть, если кому интересно, может сап попробовать поправить фронт (к примеру, добавить звуковые уведомления о новых сообщениях). И даже не лезя в серверную часть самого чата, можно получить свой собственный клиент (с оговорками, конечно, но все же).
С ее помощью запросы на node-сервер без проблем слать. Сампл:
Только хотел написать отдельный топик про выложенный node-клиент для нашего чата, а тут такое… Ну, тогда не буду писать отдельного топика, просто ограничусь комментом (сорри за оффтоп).
Итак, на днях я писал, что мы разрабатываем автономный node-чат (его работу можно увидеть на главной странице нашего сайта). Вопрос: хочет кто-нибудь себе такой же? Если да, то вот он: www.npmjs.com/package/node.social-client
Конкретно этот компонент — не полная версия всей системы, а только веб-сервер с чат-клиентом. Для полноценной работы ему еще нужен отдельный сервер, обрабатывающий непосредственно запросы. Как написано в ридми, вы можете использовать для этого наш сервер wss://modxclub.ru:8100 (эти сообщения будут видны на главной странице нашего сайта). Если кому-то нужен выделенный сервер для тестов, пишите в личку, подниму (бесплатно только сегодня). Вторая часть системы (уже сам чат-сервер) появится чуть позже.
Если вдруг кто пропустил сообщение Василия по поводу где можно развернуть такой сервер, уточняю: на modhost.pro
И посуточно можно, и по часам, и даже по минутам можно.
Да.
Это скорее на плечах движка магазина, того же minishop или shopmodx.
Опережая чей-то возможный вопрос «А почему такой универсальный компонент не писать на базе самого MODX-а?», я отвечу:
1. MODX сложнее в переносе. Если вы его из одной папки в другую перенесете, он у вас уже работать перестанет, надо конфиги править. node.js-проект этим не страдает, его просто перекидываешь в любую папку (или на любой другой комп, где стоит подходящая версия node.js) и все, запускаешь.
2. node.js один компонент можно запустить сразу кучу инстансов, просто указав разные порты. Это круто. Имея тот же модуль чата, можно из одной папки запустить несколько сотен отдельных комнат.
3. Установка компонентов там и там — просто небо и земля. В ноде прописал нужный компонент в package.json, выполнил npm install и все (или вообще просто npm install package). После этого в любом месте кода пишешь var module = require(module); и полетело.
В общем, я несколько лет пишу компоненты под MODX, делал не мало интеграций с различными сторонними системами, и знаю что делаю.
1. В node.js используется крутой механизм подгрузки и переопределения компонентов, например var booking = require($path_to_module);
По умолчанию будет использоваться автономный модуль работы без каких-то внешних систем. Но его можно будет легко переопределить другим модулем типа var booking = require($path_to_extra_module); в котором прописано var extra_booking = require($path_to_module); export extra_booking; (Это в общих чертах). И в этом переопределяющем компоненте будет перехват штатных событий и взаимодействие с MODX-сайтом (типа запросить имеющийся объект, отправить уведомление и т.п.).
2. Мы умеем читать конфиги MODX-а и работать с базой сайта, включая префиксы таблиц. В MODX-модель компонента мы добавим нужные классы и мап-файлы, чтобы легко можно было средствами xPDO работать с таблицами компонента напрямую, при желании.
3. Даже при работе с сайта напрямую в ноду, не придется выполнять никаких лишних проверок доступа пользователя (авторизован или нет) и т.п. Мы пересылаем запрос на сам сайт с передачей кукисов, так что даже получая запрос из браузера не напрямую, а через ноду, MODX будем воспринимать это как прямой запрос себе из браузера, так что все авторизации и сессии пользователей будут учитываться как есть.