Cyrax_02
С нами с 04 августа 2013; Место в рейтинге пользователей: #247Вчера в 23:38
require_once $_SERVER['DOCUMENT_ROOT'] . '/core/config/config.inc.php';Это лишнее.
global $modx;и это тоже.
$modx->context->keyКак...
[miniShop2] - Ошибка при инициализации 1
Вчера в 11:44
Дак все на 2-й версии сидят, а эту только посмотреть порадоваться =)
mmxTwig - еще одна интеграция шаблонизатора 8
16 мая 2024, 20:02
Походу твое решение спустя 4 года все такие стало актуальным
github.com/modxcms/revolution/pull/16571#pullrequestreview-2061133420
Facade Laravel в Modx 2/3 21
16 мая 2024, 08:23
Всё норм работает, надо только заменить в файле core/components/msdsector/controllers/msdsectordeliveryhandler.class.php
if (!class_exists("ms...
[msdSector] - расчет стоимости доставки с учетом секторов. 10
15 мая 2024, 11:50
Немного дополню, для mSearch2 (может кому пригодится)
<script>
var lazyLoadInstance = new LazyLoad({
elements_selecto...
pdopage и vanilla-lazyload 7
15 мая 2024, 05:58
Добрый день,
Подскажите, написано, что «Добавлена автоматическая поддержка пользовательских множественных свойств»
Но при этом нигде не сказано...
[mSync] Новая версия синхронизации с 1С 87
14 мая 2024, 14:50
Спасибо!
Пробовал передать свой плейсхолдер — не работает такой подход.
Сейчас решение сделал в виде сниппета получающего id по pagetitle
cityFields внутри pdoResources и плейсхолдер id 2
14 мая 2024, 10:27
Решил, зашёл в контексты, web, и там создал новый контекст site_url, и там внутри добавил значение своего сайта на https.
Имя и ключ: site_url
Зна...
При добавлении <base href="[[++site_url]]"/>, не работают стили. 6
13 мая 2024, 23:47
Искал ответ примерно на тот же вопрос. Мне нужно было сделать file.php который будет выводить определенный ресурс из modx. Вот, может, кому то пригоди...
Как получить HTML код всей страницы в сниппете? 10
Вариант, работающий только при [merge_slashes = off]
Конструкция, которую вы привели, имеет логическую ошибку, из-за чего удалять она будет только по одному слешу (если подряд идущих слешей — несколько, будет несколько последовательных 301 редиректов), что не есть хорошо. В rewrite первая звёздочка захватит часть слешей, оставив конструкции //+ только 2 слеша.
Что нужно сделать, чтобы довести конструкцию до ума:
1. «Умерить» жадность этой звёздочки
2. Добавить символы начала и конца строки (не обязательно, но желательно)
3. Максимально упростить регулярное выражение в location (т.к. оно используется только для обнаружения факта присутствия в uri лишних слешей)
Вариант, работающий только при [merge_slashes = on]
А ещё лучше использовать конструкцию, которая не требует отключения merge_slashes (работает только при включенном merge_slashes):
Здесь переменная $request_uri содержит исходный uri с исходными аргументами запроса (до корректировки веб-сервером и до всяких внутренних редиректов). Конструкция ^[^?]* слева от слешей нужна, чтобы убедиться, что лишние слеши обнаружены именно в uri, а не в составе аргументов (слэши в составе аргументов не трогаем). И в самую последнюю очередь делаем 301 редирект на uri, который nginx уже самостоятельно очистил от лишних слешей (это значение содержится в переменной $uri).
Универсальный вариант, не зависящий от состояния [merge_slashes]
Если же нужен универсальный вариант, который не зависит от состояния директивы merge_slashes, то делаем так (слэши в составе аргументов не трогаем):
б) претендуя на "крупнейшее русскоязычное MODX сообщество", руководство данной площадки де факто берёт на себя обязательства по соблюдению общепринятых норм и правил приличия, предъявляемых к подобным ресурсам. В особенности, не допускаются переход на личности, оскорбление участников площадки и угрозы в их адрес.
в) как правило, каждый задаваемый вопрос или тема для обсуждения адресуется не одному или нескольким конкретным участникам, а всем участникам сообщества, компетентным в данном вопросе. При этом никто никого не заставляет принимать участие в открываемых вопросах и темах.
г) реплики типа "ты на моём сайте — что хочу, то и делаю" — мягко говоря, не соответствуют тому заявленному руководством уровню, который сформулирован в title-заголовке сайта ("крупнейшее русскоязычное MODX сообщество").
modhost.pro/auth/register?action=auth%2Flogin&email=publ.n.a%2540mail.ru&hash=dc4c99f9a09ee447e48c1a8fb5412d05%3A12345678
Посмотрел в режиме отладки: на такой запрос получаю от вашего сервера 302 редирект на modhost.pro/auth/register.
Вы еще не активировали свой аккаунт, поэтому мы снова отправили вам ссылку на активацию.
В итоге получаю письмо с заголовком «Ссылка для авторизации», которое содержит… информацию о сбросе пароля. Который я не запрашивал.
В самый первый раз получил письмо с таким же заголовком, но которое содержало ссылку для активации учётной записи (переход по ссылке привёл на страницу создания нового аккаунта). Из другого браузераещё раз перешёл по ссылке — снова попадаю на страницу создания нового аккаунта…
Согласно спецификации FHS, директория /home содержит домашние директории пользователей. Директория /var — часто меняющиеся данные (кэш, логи, временные файлы и пр.). В сабже мы имеем дело с файлами сайтов. Файлы сайтов — одновременно принадлежат пользователям (должны размещаться в домашней директории пользователя) и вместе с тем часто меняются.
Логическим фактором, влияющим на выбор места размещения сайтов, является преобладание более детерминированного определения (назначения) директории /home над /var. Т.е. в данном случае директорию /var нужно связывать не просто с "часто меняющимися данными", а "прочими часто меняющимися данными" (не соотнесёнными однозначно с другими директориями).
Формальным фактором, влияющим на выбор места размещения сайтов, является грубое нарушение стандарта в случае размещения домашней директории пользователя НЕ в /home.
Это моё обоснование необходимости размещения сайтов в директории /home/user/www/, а не в /var/www/user/www/. В Интернете не нашёл никаких доводов в пользу того или иного варианта. В итоге удалось сформировать свои собственные доводы. Теперь можно спать спокойно…
P.S. Поддиректория /var/www/ в спецификацию FHS не входит. При этом в отношении директории /var в спецификации указано:
Таким образом, Apache, создавая файл /var/www/html/index.html в этой папке, нарушает спецификацию. Nginx — не нарушает (создаёт файл index.html в /usr/share/nginx/html/).
Т.е. я рассматриваю 2 варианта:
1. Домашняя директория /var/www/user/, корневая директория для сайтов = /var/www/user/www/
2. Домашняя директория /home/user/, корневая директория для сайтов = /home/user/www/
Раньше вы придерживались 1-го варианта, сейчас — 2-го. С чем связан «переезд» места размещения домашних директорий пользователей (с их сайтами)?
Сейчас — /home/$USERNAME?
— Apache по умолчанию тестовую страницу в /var/www/html/index.html, nginx — в свои директории (/usr/share/nginx/html/index.html)
5. И где лежат php.ini конкретного пользователя?
2. И в какой директории у вас расположены сайты?
3. При этом какими являются домашние директории пользователей — /home/user/, /var/www/user/ или иные?
Получаем запрос:
Это нормально?
Почему-то xPDO не получает мета-информацию о присоединённых таблицах. В итоге все поля присоединённых таблиц он типизирует как строковые.
Получается, что создавать условия по присоединённым полям по стандартам xPDO (ассоциативный массив) нельзя — только на чистом SQL.