Сергей Шлоков

Кабы понять какая задача?

2 варианта.
1. Добавлять ресурс в группу ресурсов, для которой настроены права. Для автоматизации делать это через плагин на сохранение ресурса на событие OnDocFormSave.
2. Проверять пользователя в каждом запросе в плагине на событие OnHandleRequest.

Как минимум 3 страницы: главная, страница ошибок и страница с формой аутентификации должны быть доступны всем.

Шифу переводится как наставник. Мастер Наставник )) Масло масляное.

1. Не может сайт занимать 150 Г. Это же не Windows. Основной объем занимает база с 17 млн записей. Небось ещё и резервные копии там лежат. Вам для работы вполне хватит и тысячи записей. Поэтому весь сайт вполне уместиться даже на локалке. Один программист делает копию сайта, пушит её на гитхаб (или др. систему управления версиями). А другой тянет её себе. Тут сложно объяснить, если не знаешь матчасть.
2. Сохраняешь наработки, клонируешь, создаешь ветку, закидываешь старые файлы.
3. Ну вы же не конкуриренты. Вы должны согласовывать свои действия. Кто что делает.
4. Можно создать общий сайт разработки dev.site.ru, который подключить к рабочей БД только для теста!!! А программистам можно поднять свои локальные версии для работы.

ps.Кто такой Шифу?

Спроси у Алисы. ))

А вот помогал бы сообществу, то и не было бы таких вопросов! Ты бы узнал, что совместная разработка ведётся не через деплой файлов, а через пулл реквесты (Pull Reqest, PR). Принял PR, если что-то сломалось, откатил назад. Это раз.
Новую функциональность принято разрабатывать в отдельных ветках. Тогда два твоих программиста не зависят друг от друга. Но всегда могут посмотреть, что у другого просто зафетчив другую ветку. Ну и базовая версия остается чистая. Только для хотфиксов. Это два.

В сообществе постоянно есть потребность протестировать тот или иной функционал. Там бы ты всё это и узнал. Ваня Климчук даже инструкцию сделал как работать с гитхабом. Правильно @Иван Бочкарев?

Многому тебя Шифу научил, да видно не всему ))

Кто этот ужас Вам подсказал? @Баха Волков выше написал правильное решение именно для смены шаблона на лету. И не надо ничего писать в базу. Во-первых, +1 запрос на сервер при каждом просмотре страницы. А если уже установлен нужный шаблон? Во-вторых, это уже не «на лету».

Респектище! Желаю, чтоб взлетело. Может теперь за REVO возмёшься? ))

Учим PDO и в частности отличие метода fetch от метода fetchAll. Так что живем радостно ))

А можешь показать место в коде, где

А getObject просто добавит limit=1

Уверен, долго будешь искать ))

Контент-менеджер сохранил недописанную или заранее заготовленную статью. Что увидит пользователь на странице?

Смешно. Сам же выше на Владимира ругаешься, а сам бездумно его код скопипастил.

Уверен, что больше ничего не упустил?

П.С. Я не про то, что для получения одного поля нужно запрашивать объект целиком.

Первый комментарий я вообще не понял. А по второму — учи матчасть и почитай, что значит клиент-серверная архитектура.

я просто дурак и не догоняю

Мы все с этого начинали. Главное — желание это исправить.

А вот нет пока ни одной записи. Fatal Error!

то получается она и таже каша, а не самый худший вариант…

Выглядит одинаково только для тех, кто не знает матчасть. В данном случае нет знаний ни в xPDO, ни в SQL.
pdoResources будет работать как getCollection только в режиме проверки прав. Изначально он работает в облегченном режиме с массивом данных.
В твоём варианте все ресурсы указанного родителя (все!!!) с сервера полетят на клиента, а getCollection для каждой записи будет поднимать объект со всеми проверками. И всё это для того, чтобы получить одно поле одной записи. Т.е. хуже придумать нельзя.

Я выше давал ссылку как сделать это самым простым и быстрым способом.

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

Наихудший вариант из всех возможных.

Сергей, если установлен pdoTools, то используйте pdoResources с limit=1.

ЧТО делает сниппет differenceBetweenDatesInSeconds все разобрались. Осталось только понять ЗАЧЕМ?

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

Такое впечатление, что это просто синтаксический сахар. То есть, ничего особо полезного не несет.

Боюсь тебя расстроить, но MODX — это синтаксический сахар над PHP. Юзай последний. Не отказывайся от своих принципов.

И, соответственно, его не стоит использовать. Это помешает другим работать над проектом.

Не используй. Сделай мне больно.

П.С. Только щас заметил, что мой коммент почему-то попал не в корень, а залетел в ответ на твой коммент. Видимо глаза уже подводят.

Не путай логику отображения с логикой приложения. Последней не место во вьюхах. Вот пример логики отображения.

Лично я не вижу особой необходимости в объекте $_modx как ограничителе функциональности для безопасности. Этого нет ни в одном шаблонизаторе. Видимо никому не понадобилась такая фича. А вот как объект для работы со вьюхами (шаблонами, чанками, ресурсами) он хорош. Для правильной работы, если можно так выразится. И юзер $_modx->user там нужен! Хотя я бы сделал юзера отдельным объектом для удобства. Но считаю, что кэшменеджер тут лишний. Вот такое имхо. Но, как правильно сказал Павел, ты может делать что хочешь и как хочешь. Fenom позволяет юзать даже объект $modx. It's up to you.

Эх, молодежь. Всё делается гораздо проще. Ставим modHelpers и используем функцию snippet.

{snippet("mySnippet", ["param" => "value"], 604800)}  // сохраняем на неделю. Третий параметр лучше указать через массив (см. ниже)

А в cron удаляем кэш и парсим страницу сниппетом

... // инициализация 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 не нужен. И даже вреден. Ибо делает ненужную работу для каждого запроса страницы.

П.С. И ещё совет. Не пихайте логику во вьюхи. Это бад практис! Перенесите логику в сниппет и вызывайте его на странице.