Cyrax_02

Да, при [merge_slashes = on] nginx удаляет слеши из uri, но только на внутреннем уровне — без внешних (301) редиректов.

Вариант, работающий только при [merge_slashes = off]
Конструкция, которую вы привели, имеет логическую ошибку, из-за чего удалять она будет только по одному слешу (если подряд идущих слешей — несколько, будет несколько последовательных 301 редиректов), что не есть хорошо. В rewrite первая звёздочка захватит часть слешей, оставив конструкции //+ только 2 слеша.

Что нужно сделать, чтобы довести конструкцию до ума:
1. «Умерить» жадность этой звёздочки
2. Добавить символы начала и конца строки (не обязательно, но желательно)
3. Максимально упростить регулярное выражение в location (т.к. оно используется только для обнаружения факта присутствия в uri лишних слешей)

location ~ // {
    rewrite ^(.*?)//+(.*)$ $1/$2 permanent;
}

Вариант, работающий только при [merge_slashes = on]
А ещё лучше использовать конструкцию, которая не требует отключения merge_slashes (работает только при включенном merge_slashes):

if ($request_uri ~ ^[^?]*//) {
    rewrite ^ $uri permanent;
}

Здесь переменная $request_uri содержит исходный uri с исходными аргументами запроса (до корректировки веб-сервером и до всяких внутренних редиректов). Конструкция ^[^?]* слева от слешей нужна, чтобы убедиться, что лишние слеши обнаружены именно в uri, а не в составе аргументов (слэши в составе аргументов не трогаем). И в самую последнюю очередь делаем 301 редирект на uri, который nginx уже самостоятельно очистил от лишних слешей (это значение содержится в переменной $uri).

Универсальный вариант, не зависящий от состояния [merge_slashes]
Если же нужен универсальный вариант, который не зависит от состояния директивы merge_slashes, то делаем так (слэши в составе аргументов не трогаем):

if ($request_uri ~ ^(?P<left>[^?]*?)//+(?P<right>[^?]*)) {
    rewrite ^ $left/$right permanent;
}

В каком таком «духе»? Я спросил, с чем связан переезд пользователей из /var/www/ в /home/www/. Вы сказали, что связан с желанием разместить пользователей в их домашней директории и что /var/www/user/ ранее не была домашней директорией. Я указал на ваши исходники, где /var/www/user/ создавалась в качестве домашней директории. В ответ вы перешли на личности и начали меня оскорблять. Я ответил, что переходить на личности и оскорблять меня не стоит. Вы стали мне угрожать. Поясните, что вы имеете ввиду под «продолжать в том же духе»?

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

Здесь можно задавать различные вопросы про MODX, хостинги, базы данных, программирование и вообще — что угодно.

Вы можете задавать вопросы по любым темам, но имейте в виду, что инженеров-радиоэлектронщиков, специалистов по маркетингу и MODX Evolution в нашем сообществе очень мало.

б) претендуя на "крупнейшее русскоязычное MODX сообщество", руководство данной площадки де факто берёт на себя обязательства по соблюдению общепринятых норм и правил приличия, предъявляемых к подобным ресурсам. В особенности, не допускаются переход на личности, оскорбление участников площадки и угрозы в их адрес.

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

г) реплики типа "ты на моём сайте — что хочу, то и делаю" — мягко говоря, не соответствуют тому заявленному руководством уровню, который сформулирован в title-заголовке сайта ("крупнейшее русскоязычное MODX сообщество").

А вот на личности переходить не нужно. Выдерживайте нейтральный тон.

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

А конструктива не будет? Ещё раз: при переходе по ссылке «активировать учётную запись» открывается страница создания нового аккаунта modhost.pro/auth/register. При этом активации учётной записи не происходит. Ссылка такая:
modhost.pro/auth/register?action=auth%2Flogin&email=publ.n.a%2540mail.ru&hash=dc4c99f9a09ee447e48c1a8fb5412d05%3A12345678

Посмотрел в режиме отладки: на такой запрос получаю от вашего сервера 302 редирект на modhost.pro/auth/register.

…

Попробовал в другом браузере. То же самое. при попытке входа — получаю сообщение:
Вы еще не активировали свой аккаунт, поэтому мы снова отправили вам ссылку на активацию.
В итоге получаю письмо с заголовком «Ссылка для авторизации», которое содержит… информацию о сбросе пароля. Который я не запрашивал.

В самый первый раз получил письмо с таким же заголовком, но которое содержало ссылку для активации учётной записи (переход по ссылке привёл на страницу создания нового аккаунта). Из другого браузераещё раз перешёл по ссылке — снова попадаю на страницу создания нового аккаунта…

Раньше во 2м случае домашняя директория пользователя была так же в /home, а сайт в /var/www.

Согласно вашему скрипту, домашняя директория тоже создавалась в /var/www/user/:

useradd $USERNAME -m -G sftp -s "/bin/false" -d "/var/www/$USERNAME"

Инициировал процедуру создания аккаунта. На почту пришло письмо — жму по ссылке «активировать аккаунт» — попадаю на страницу регистрации. Жму «вход», набираю логин/пароль — получаю сообщение, что нужно активировать учётную запись.

1. Домашняя директория /var/www/user/, корневая директория для сайтов = /var/www/user/www/
2. Домашняя директория /home/user/, корневая директория для сайтов = /home/user/www/

Согласно спецификации FHS, директория /home содержит домашние директории пользователей. Директория /var — часто меняющиеся данные (кэш, логи, временные файлы и пр.). В сабже мы имеем дело с файлами сайтов. Файлы сайтов — одновременно принадлежат пользователям (должны размещаться в домашней директории пользователя) и вместе с тем часто меняются.

Логическим фактором, влияющим на выбор места размещения сайтов, является преобладание более детерминированного определения (назначения) директории /home над /var. Т.е. в данном случае директорию /var нужно связывать не просто с "часто меняющимися данными", а "прочими часто меняющимися данными" (не соотнесёнными однозначно с другими директориями).

Формальным фактором, влияющим на выбор места размещения сайтов, является грубое нарушение стандарта в случае размещения домашней директории пользователя НЕ в /home.

Это моё обоснование необходимости размещения сайтов в директории /home/user/www/, а не в /var/www/user/www/. В Интернете не нашёл никаких доводов в пользу того или иного варианта. В итоге удалось сформировать свои собственные доводы. Теперь можно спать спокойно…

P.S. Поддиректория /var/www/ в спецификацию FHS не входит. При этом в отношении директории /var в спецификации указано:

Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication, and in consultation with the FHS mailing list.

Таким образом, Apache, создавая файл /var/www/html/index.html в этой папке, нарушает спецификацию. Nginx — не нарушает (создаёт файл index.html в /usr/share/nginx/html/).

При использовании в качестве корневой директории для сайта /var/www/user/ — её же делают и домашней директорией пользователя. Т.е. в этом случае сайт тоже будет лежать в домашней директории пользователя.

Т.е. я рассматриваю 2 варианта:
1. Домашняя директория /var/www/user/, корневая директория для сайтов = /var/www/user/www/
2. Домашняя директория /home/user/, корневая директория для сайтов = /home/user/www/

Раньше вы придерживались 1-го варианта, сейчас — 2-го. С чем связан «переезд» места размещения домашних директорий пользователей (с их сайтами)?

Да, сейчас всё добро юзера живёт в его директории, включая сайт.

А с чем связан такой «переезд»? Сейчас, вроде, «все» хранят сайты в /var/www/ (и её же делают домашней).

Юзеры живут в /home.

Раньше (2013 год) в качестве домашней директории вы использовали /var/www/$USERNAME.
Сейчас — /home/$USERNAME?

— Apache по умолчанию тестовую страницу в /var/www/html/index.html, nginx — в свои директории (/usr/share/nginx/html/index.html)

4. А логи сайтов где расположены — в /var/www/user/httpd-logs?
5. И где лежат php.ini конкретного пользователя?

Даже если на сервере работают моих 2-3 сайта, не клиентских, все равно они работают от разных пользователей. Во-первых, это удобнее.

1. Т.е. в указанном случае (все сайты — ваши) сайты работают от разных пользователей (настройки веб-сервера и php), но при этом физически они расположены в одной директории — так?

2. И в какой директории у вас расположены сайты?
3. При этом какими являются домашние директории пользователей — /home/user/, /var/www/user/ или иные?

Если в mSearch1 используется стандартный FULLTEXT-поиск, то что используется в mSearch2?

А чем сжимают скрипты разработчики плагинов? Стало быть, готовые средства имеются. Не вручную же переименовывают.

$query = $modx->newQuery('modResource');
$query->select(array('modResource.id AS resourceId'));
$query->innerJoin('modTemplateVarTemplate', 'TVValues', array('TVValues.contentid = modResource.id'));
$query->where(array('TVValues.tmplvarid:=' => 8));

Получаем запрос:

SELECT modResource.id AS resourceId
FROM `modx_site_content` AS `modResource`
JOIN `modx_site_tmplvar_templates` `TVValues` ON TVValues.contentid = modResource.id
WHERE `TVValues`.`tmplvarid` = '8'

Это нормально?
Почему-то xPDO не получает мета-информацию о присоединённых таблицах. В итоге все поля присоединённых таблиц он типизирует как строковые.

Получается, что создавать условия по присоединённым полям по стандартам xPDO (ассоциативный массив) нельзя — только на чистом SQL.

Текст ошибки?