Лайфхак по config.inc
В modx есть файл с конфигом core/config/config.inc.php, в нем кроме установки имени базы, есть еще возможность переопределять настройки:
1. Удаляем запись в системных настройках с ключом site_name
2. Добавляем ключ удаленной настройки
И воулия))) У нас на сайте появляется название из конфига)
P.S.: только помните о том что при обновлении компонентов или системы у вас ключи заново будут созданы в БД (не забудьте удалить).
Например есть сайты dev и product, для каждого вы можете завести свой конфиг.
прописав название в файлах:
Для dev:
Помимо того что вы можете переопределять старые настройки. Также вы можете создать новые:
[[++site_name]]
{'site_name'| config}
<?php
$modx->getOption('site_name');
Но как?
1. Удаляем запись в системных настройках с ключом site_name
2. Добавляем ключ удаленной настройки
<?php
#core/config/config.inc.php
...
$config_options = array (
'site_name' => 'Новое имя сайта', // удалить запись с этим ключем из системных настроек
);
..
И воулия))) У нас на сайте появляется название из конфига)
P.S.: только помните о том что при обновлении компонентов или системы у вас ключи заново будут созданы в БД (не забудьте удалить).
Применение
Например есть сайты dev и product, для каждого вы можете завести свой конфиг.
прописав название в файлах:
config.core.php
manager/config.core.php
connectors/config.core.php
Для dev:
<?php
...
define('MODX_CONFIG_KEY', 'dev');
...
Для product:<?php
...
define('MODX_CONFIG_KEY', 'product');
...
Добавление своих настроек
Помимо того что вы можете переопределять старые настройки. Также вы можете создать новые:
<?php
#core/config/config.inc.php
...
$config_options = array (
'site_name' => 'Новое имя сайта', // удалить запись с этим ключем из системных настроек
'site_new_phone' => '88009000622',
'site_new_work_days' => 'Каждый день с 10 до 21',
'site_new_work_days_array' => ['Пн','Вт'] // причем можно использовать даже массив
);
..
на сайте:[[++site_new_phone]]]
[[++site_new_work_days]]]
<?php
$modx->getOption('site_new_phone');
$modx->getOption('site_new_work_days');
Поблагодарить автора
Отправить деньги
Комментарии: 29
Есть суть в версионировании, что мешает написать резолверы?
Для чего?
Может я ошибся, но вчера видел тут (вроде тут) что основная причина такого хака — версионирование. Мол ClientConfig сложнее версионировать. Так можно же написать резолвер, который будет гонять данные в ClientConfig
про ClientConfig смысла наверное нету все таки упоминать.
Тут идея в том чтобы иметь разные настройки у сайтов и добавлять новые через файл.
С файлом куда проще работать чем с БД, это еще даже если не брать во внимание работу с git.
Тут идея в том чтобы иметь разные настройки у сайтов и добавлять новые через файл.
С файлом куда проще работать чем с БД, это еще даже если не брать во внимание работу с git.
При всём уважении, делать так не нужно. Просто создайте php файлик со своими системными настройками и загружайте его на событие OnMODXInit /OnHandleRequest. И тогда не нужны все эти манипуляции и проблемы с обновлением MODX. Как это сделать я говорил ещё в 2016 году.
- Указывать через конфиг config.inc.php (с удалением записи в бд.)
- Добавить плагин через modzone.ru/blog/2016/12/23/downloaded-configs-from-files/
То же хороший вариант.
А cache_path кажется не получиться сменить?
А cache_path кажется не получиться сменить?
Почему?
а как?))
Пытался найти как изменить cache_path у класса xPDOCacheManager не нашел)
Пытался найти как изменить cache_path у класса xPDOCacheManager не нашел)
Посмотрел в код. Конкретно эту настройку через системные настройки не изменить. Нужно или прописывать в $config_options
$config_options = array (
'cache_path' => 'path/to/cache/folder/',
);
или в своих коннекторах, где создается объект $modx указать параметры инициализации<?php
// Boot up MODX
require_once dirname(dirname(__FILE__)) . '/config.core.php';
require_once MODX_CORE_PATH . 'model/modx/modx.class.php';
$modx = new modX('', ['cache_path' => 'path/to/cache/folder/',]);
+@Сергей Шлоков А можно уточнить почему. Я уже много лет читаю твой ресурс. И статью твою читал. Но почему данный способ не рекомендованный. Как дойти до данного утверждения?
Потому что не будет проблем с обновлением MODX
проблем с обновлением в любом случае не будет))
Тут проблем в том что если удалишь site_name то при обновлении он заново будет создан.
Тут проблем в том что если удалишь site_name то при обновлении он заново будет создан.
Я понимаю, конфиг не перезапишется. Хорошо — назовем это словом неудобство. Лишние манипуляции программисту. А вот если не будет программиста — попробуй разберись — чего это вдруг другая системная настройка появилась и где она определяется.
Это да, но для работы с двумя сайтами одновременно у тебя в любом случае настройки у dev версии будут отличатся от product
Варианты:
Варианты:
Оба вариант подходящие. Но они 100% не рассчитаны на менеджеров сайта))
Автор в постскриптуме указал почему. Плюс не очень удобно. Нужную настройку нужно обязательно удалить, иначе данный способ переопределения настройки не сработает. Т.е. придется лезть в админку.
В моем варианте можно переопределять любые системные настройки. Они сразу будут применены. Кроме того, новые файлы подключаются автоматом.
П.С. Файл конфига редактировать никто не запрещает. Он индивидуальный и его при обновлении никогда не трогают.
В моем варианте можно переопределять любые системные настройки. Они сразу будут применены. Кроме того, новые файлы подключаются автоматом.
П.С. Файл конфига редактировать никто не запрещает. Он индивидуальный и его при обновлении никогда не трогают.
Почти все:
cache_path — однозначно нужно в файле config.inc.php заменять
cache_path — однозначно нужно в файле config.inc.php заменять
Почти все:Ну мы же понимаем, что говорим об открытых системных настройках, доступных к изменению. ;)
cache_path — однозначно нужно в файле config.inc.php заменятьОсталось только понять зачем?
Делаю чтобы на основе домена подменялась папка с кэшем, чтобы не вызывало проблем с кэшем на страницах.
Написал плагин, который во время сброса кэша срабатывает и удаляет директории с кэшем городов.
Ну и по аналогии обновление ресурсов при сохранении.
В папке
Есть другие разные ухищрения как можно реализовать подобный функционал, сейчас не об этом.
Текущее решение очень простое и работает)
Написал плагин, который во время сброса кэша срабатывает и удаляет директории с кэшем городов.
Ну и по аналогии обновление ресурсов при сохранении.
В папке
/core/cache/
создаются папки /core/cache/city/kemerovo
/core/cache/city/moskva
Собственно так и выяснялось что в классе xPDOCacheManager невозможно изменить cache_pathЕсть другие разные ухищрения как можно реализовать подобный функционал, сейчас не об этом.
Текущее решение очень простое и работает)
В списке городов хранятся синонимы (Москва, Москве) которые так же пишутся в настройки. Ну это уже здесь не обязательно, можно уже ниже вынести в базу или как в твоем варианте в отдельные файлы.
@Олег Щавелев Плюс, хорошим тоном считается разделять настройки. Пример — Ларавел.
Пользовательские настройки также лучше не мешать с системными, а вынести в отдельный файл. Тогда другой программист поймёт, какие настройки устанавливает система, а какие — переопределил пользователь.
Пользовательские настройки также лучше не мешать с системными, а вынести в отдельный файл. Тогда другой программист поймёт, какие настройки устанавливает система, а какие — переопределил пользователь.
В общем вот решение для dev и product
<?php
switch ($modx->event->name) {
case 'OnHandleRequest':
// Загрузка общих настроек
$site_all = MODX_CORE_PATH . 'config/settings/';
if (file_exists($site_all) and is_dir($site_all)) {
foreach (glob($site_all . '*.inc.php') as $file) {
$response = require($file);
if (is_array($response)) $modx->config = array_merge($modx->config, $response);
}
}
// Конфигурация для сайта с конфигом MODX_CONFIG_KEY
$site_dir = MODX_CORE_PATH . 'config/settings/' . MODX_CONFIG_KEY.'/';
if (file_exists($site_dir) and is_dir($site_dir)) {
foreach (glob($site_dir . '*.inc.php') as $file) {
$response = require($file);
if (is_array($response)) $modx->config = array_merge($modx->config, $response);
}
}
break;
}
Структура папокcore/config/dev.inc.php
core/config/settings/*.inc.php # здесь общие настройки
core/config/settings/dev/*.inc.php # здесь настройки персонально для dev (MODX_CONFIG_KEY)
А возможно ли и настройки контекстов сюда вынести?
Отвечаю на свой же вопрос — можно вот так
core/config/settings/en/en-settings.inc.php
<?php
switch ($modx->event->name) {
case 'OnHandleRequest':
// Загрузка общих настроек
$site_all = MODX_CORE_PATH . 'config/settings/';
if (file_exists($site_all) && is_dir($site_all)) {
foreach (glob($site_all . '*.inc.php') as $file) {
$response = require($file);
if (is_array($response)) {
$modx->config = array_merge($modx->config, $response);
}
}
}
// Конфигурация для сайта с конфигом MODX_CONFIG_KEY
$site_dir = MODX_CORE_PATH . 'config/settings/' . MODX_CONFIG_KEY . '/';
if (file_exists($site_dir) && is_dir($site_dir)) {
foreach (glob($site_dir . '*.inc.php') as $file) {
$response = require($file);
if (is_array($response)) {
$modx->config = array_merge($modx->config, $response);
}
}
}
// Конфигурация для текущего контекста
$context_key = $modx->context->get('key');
$context_dir = MODX_CORE_PATH . 'config/settings/' . $context_key . '/';
if (file_exists($context_dir) && is_dir($context_dir)) {
foreach (glob($context_dir . '*.inc.php') as $file) {
$response = require($file);
if (is_array($response)) {
$modx->config = array_merge($modx->config, $response);
}
}
}
break;
}
?>
Структура папокcore/
└── config/
└── settings/
├── common.inc.php // Общие настройки
├── config1/
│ └── config1-settings.inc.php // Настройки для MODX_CONFIG_KEY = config1
├── config2/
│ └── config2-settings.inc.php // Настройки для MODX_CONFIG_KEY = config2
├── web/
│ └── web-settings.inc.php // Настройки для контекста web
└── en/
└── en-settings.inc.php // Настройки для контекста en
Вид настроек например для core/config/settings/en/en-settings.inc.php
<?php
return [
'site_url' => 'https://your-uz-site-url.com/',
// Добавьте другие настройки контекста здесь
];
?>
Докрутил, ранее не подтягивались настройки если запрашивать из одного контекста настройки другого
<?php
switch ($modx->event->name) {
case 'OnHandleRequest':
// Функция для загрузки настроек из файлов
function loadSettings($directory) {
$settings = [];
if (file_exists($directory) && is_dir($directory)) {
foreach (glob($directory . '*.inc.php') as $file) {
$response = require($file);
if (is_array($response)) {
$settings = array_merge($settings, $response);
}
}
}
return $settings;
}
// Загрузка общих настроек
$site_all = MODX_CORE_PATH . 'config/settings/';
$globalSettings = loadSettings($site_all);
// Конфигурация для сайта с конфигом MODX_CONFIG_KEY
$site_dir = MODX_CORE_PATH . 'config/settings/' . MODX_CONFIG_KEY . '/';
$configKeySettings = loadSettings($site_dir);
// Конфигурация для текущего контекста
$context_key = $modx->context->get('key');
$context_dir = MODX_CORE_PATH . 'config/settings/' . $context_key . '/';
$contextSettings = loadSettings($context_dir);
// Объединение всех настроек
$allSettings = array_merge($globalSettings, $configKeySettings, $contextSettings);
// Применение настроек к текущему контексту
foreach ($allSettings as $key => $value) {
$modx->context->setOption($key, $value);
// Сохранение настроек в базе данных
$setting = $modx->getObject('modContextSetting', [
'context_key' => $context_key,
'key' => $key
]);
if (!$setting) {
$setting = $modx->newObject('modContextSetting');
$setting->set('context_key', $context_key);
$setting->set('key', $key);
}
$setting->set('value', $value);
$setting->save();
}
break;
}
?>
Лучше так
<?php
switch ($modx->event->name) {
case 'OnHandleRequest':
foreach (glob(MODX_CORE_PATH . 'config/settings/*.php') as $file) {
$response = require ($file);
if (is_array($response)) $modx->config = array_merge($modx->config, $response);
}
break;
}
а то если несколько конфигов будет, то MODX_CONFIG_KEY не поможет.
Только так работать не должно, потому что require возвращает true или падает с ошибкой.
А переменные, определённые в файле становятся доступны в текущей области действия.
Если же массив с настройками там называется $config_options, то получать его лучше так:
А переменные, определённые в файле становятся доступны в текущей области действия.
Если же массив с настройками там называется $config_options, то получать его лучше так:
//...
require $file;
if (isset($config_options) && is_array($config_options)) {
$modx->config = array_merge($modx->config, $config_options);
}
//...
в этом коде нету переменных, там return
Действительно, а я подумал, что все файлы имеют такой же вид, как в статье описан пример конфига.
Ну теперь это очевидно для всех, что в тех файлах настроек должен быть return, чтобы способ сработал.
Но даже если там будут переменные, они также включатся в эту область.
Ну теперь это очевидно для всех, что в тех файлах настроек должен быть return, чтобы способ сработал.
Но даже если там будут переменные, они также включатся в эту область.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.