Василий Наумкин

На miniShop1 этого нормально не сделать.

На miniShop2 сделать, но там еще нет инструмента связи товаров через контексты, придётся юзать Babel.

Про остальных не знаю.

Если ты хочешь заменить дефолтный id, то нужно наследовать таблицу от xPDOObject.

Если ты хочешь именно копировать из id в reg_nomer, когда не прислано значение — через xml этого не сделать.
Нужно изменить в классе ATPItem метод save(), чтобы он проверял reg_nomer на пустоту и если что — копировал туда id перед сохранением.

Просто увеличение. Со скоростями там и так всё окей, вроде.

Вот не знаю, как такое может быть, если Ticket — это расширенный modResource, который хранится в той же таблице modx_site_content и по тем же правилам.

Там конечно отличаются всякие процессоры и внутренние методы, но как это может влиять на бэкап\восстановление — я без понятия. Видишь, переопределения полей нет.

Так что, не знаю, чем тебе помочь. Как там насчет других дат, типа createdon, updatedon?

Если ubuntu просит перезагрузки, это значит, что иначе никак.

Обычно такое при обновлении ядра или особо важных либ. Просто выбери время и ребутни машину.

Пока только своим сниппетом, через xPDO.

В будущем запланирована такая возможность при работе через TicketLatest.

Если речь про miniShop, то там корзина хранится только в сессии, никаких кук.

И если сессия у вас не сохраняется, а пропадает только корзина — значит что-то ее чистит. Например плагин какой-то, или еще кто.

У меня на демо-сайте товары в корзине лежат очень долго.

Если параметры фильтра передавать через $_GET, то getPage их бережно сохранит.

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

$c = $modx->newQuery('modUser');

index.php лучше убрать, иначе /manager/index.php зациклит и ты не сможешь войти в админку.

Есть одна проблема: wget добавляет index.html для контеёнеров и получает 404.

Если ты используешь Nginx — то добавь своему сайту правило

location ~ ^\/(.*?)\/index\.(html|php)$ {
	rewrite	^\/(.*?)\/ /$1/ permanent;
}

Немного почитал еще маны и вот итоговая команда:

wget -m -np -nv --spider -l 10 http://sitename.ru/

Здесь wget работает в режиме «паука» и просто дёргает страницы, не загружая их.

Еще можно еще придумать скрипт, который будет одновременно запускать несколько копий wget, направленных на разные разделы сайта для ускоренной генерации кэша.

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

Лично у меня только один вариант — консольный скрипт с wget, который пробежит по всем страницам и закачает их, генерируя тем самым кэш.

wget -m -np -nv -A .html http://sitename.ru/ > /dev/null

Это не быстро, но гарантированно загонит в кэш ВСЕ страницы, которые доступны по ссылкам. То есть, даже динамические, типа вывода каталога с разбивкой на страницы.

Спасибо за подтверждение, добавил в документацию.

Не нужно так делать. Для логики нужно писать сниппеты, а не программировать на фильтрах.

switch ($modx->context->key) {
	case 'en' : $chunk = 'en-company-name'; break;
	case 'de' : $chunk = 'de-company-name'; break;
	default: $chunk = 'company-name'; break;
}
return $modx->getChunk($chunk);

И выглядит понятнее, и работает быстрее, и добавить еще 10 условий\проверок — не вопрос.

Написать самому и прислать коммит на github.

Может, сниппет вызываешь кэшированным? То есть, нужно [[!HybridAuth, а не [HybridAuth

Еще полезно посмотреть в системный журнал, если есть ошибки — то они там.

Смотри исходники компонента Gallery — там приделано.

Узнаю, когда начну делать. Пока несколько иным занят.

Скорее всего, будет xml.

Нет, не будет тормозить. Таблицы ключ\значения очень быстренькие.

А лишний join при каждой операции нафиг не сдался. Да и вообще, всё это фигня по сравнению с тормозами карты ресурсов и php.