Кто этот ужас Вам подсказал? @Баха Волков выше написал правильное решение именно для смены шаблона на лету. И не надо ничего писать в базу. Во-первых, +1 запрос на сервер при каждом просмотре страницы. А если уже установлен нужный шаблон? Во-вторых, это уже не «на лету».
Лично я не вижу особой необходимости в объекте $_modx как ограничителе функциональности для безопасности. Этого нет ни в одном шаблонизаторе. Видимо никому не понадобилась такая фича. А вот как объект для работы со вьюхами (шаблонами, чанками, ресурсами) он хорош. Для правильной работы, если можно так выразится. И юзер $_modx->user там нужен! Хотя я бы сделал юзера отдельным объектом для удобства. Но считаю, что кэшменеджер тут лишний. Вот такое имхо. Но, как правильно сказал Павел, ты может делать что хочешь и как хочешь. Fenom позволяет юзать даже объект $modx. It's up to you.
... // инициализация MODX
// Лучше указать отдельную папку для хранения данных. Иначе данные будут лежать в папке cache/default, которая очищается при сохранении любого объекта MODX.
$options = array(
cache_key => 'mysnippet_cache',
cache_expires => 604800,
);
cache()->delete("mySnippet", $options);
snippet("mySnippet", ["param" => "value"], $options);
Что важно! В данном случае сам сниппет на странице вызывается некэшированным. Поэтому кэш самой страницы обновлять не нужно. Только кэш сниппета!!! Обратите внимание, насколько код стал проще.
Функция snippet() сама проверит кэш. Если его нет, то выполнит указанный сниппет и результат сохранит в кэш. И не нужно вычислять все эти секунды. Cron каждую неделю будет обновлять кэш независимо от того, есть он или нет. Поэтому сниппет differenceBetweenDatesInSeconds не нужен. И даже вреден. Ибо делает ненужную работу для каждого запроса страницы.
П.С. И ещё совет. Не пихайте логику во вьюхи. Это бад практис! Перенесите логику в сниппет и вызывайте его на странице.
1. Добавлять ресурс в группу ресурсов, для которой настроены права. Для автоматизации делать это через плагин на сохранение ресурса на событие OnDocFormSave.
2. Проверять пользователя в каждом запросе в плагине на событие OnHandleRequest.
Как минимум 3 страницы: главная, страница ошибок и страница с формой аутентификации должны быть доступны всем.
2. Сохраняешь наработки, клонируешь, создаешь ветку, закидываешь старые файлы.
3. Ну вы же не конкуриренты. Вы должны согласовывать свои действия. Кто что делает.
4. Можно создать общий сайт разработки dev.site.ru, который подключить к рабочей БД только для теста!!! А программистам можно поднять свои локальные версии для работы.
Спроси у Алисы. ))
Новую функциональность принято разрабатывать в отдельных ветках. Тогда два твоих программиста не зависят друг от друга. Но всегда могут посмотреть, что у другого просто зафетчив другую ветку. Ну и базовая версия остается чистая. Только для хотфиксов. Это два.
В сообществе постоянно есть потребность протестировать тот или иной функционал. Там бы ты всё это и узнал. Ваня Климчук даже инструкцию сделал как работать с гитхабом. Правильно @Иван Бочкарев?
Многому тебя Шифу научил, да видно не всему ))
Уверен, долго будешь искать ))
Смешно. Сам же выше на Владимира ругаешься, а сам бездумно его код скопипастил.
П.С. Я не про то, что для получения одного поля нужно запрашивать объект целиком.
Мы все с этого начинали. Главное — желание это исправить.
pdoResources будет работать как getCollection только в режиме проверки прав. Изначально он работает в облегченном режиме с массивом данных.
В твоём варианте все ресурсы указанного родителя (все!!!) с сервера полетят на клиента, а getCollection для каждой записи будет поднимать объект со всеми проверками. И всё это для того, чтобы получить одно поле одной записи. Т.е. хуже придумать нельзя.
Я выше давал ссылку как сделать это самым простым и быстрым способом.
Сергей, если установлен pdoTools, то используйте pdoResources с limit=1.
Боюсь тебя расстроить, но MODX — это синтаксический сахар над PHP. Юзай последний. Не отказывайся от своих принципов.
Не используй. Сделай мне больно.
П.С. Только щас заметил, что мой коммент почему-то попал не в корень, а залетел в ответ на твой коммент. Видимо глаза уже подводят.
Лично я не вижу особой необходимости в объекте $_modx как ограничителе функциональности для безопасности. Этого нет ни в одном шаблонизаторе. Видимо никому не понадобилась такая фича. А вот как объект для работы со вьюхами (шаблонами, чанками, ресурсами) он хорош. Для правильной работы, если можно так выразится. И юзер $_modx->user там нужен! Хотя я бы сделал юзера отдельным объектом для удобства. Но считаю, что кэшменеджер тут лишний. Вот такое имхо. Но, как правильно сказал Павел, ты может делать что хочешь и как хочешь. Fenom позволяет юзать даже объект $modx. It's up to you.
А в cron удаляем кэш и парсим страницу сниппетом
Что важно! В данном случае сам сниппет на странице вызывается некэшированным. Поэтому кэш самой страницы обновлять не нужно. Только кэш сниппета!!! Обратите внимание, насколько код стал проще.
Функция snippet() сама проверит кэш. Если его нет, то выполнит указанный сниппет и результат сохранит в кэш. И не нужно вычислять все эти секунды. Cron каждую неделю будет обновлять кэш независимо от того, есть он или нет. Поэтому сниппет differenceBetweenDatesInSeconds не нужен. И даже вреден. Ибо делает ненужную работу для каждого запроса страницы.
П.С. И ещё совет. Не пихайте логику во вьюхи. Это бад практис! Перенесите логику в сниппет и вызывайте его на странице.