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

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

Был в сети 10 июня 2026, 17:44
Заказы не принимаю
Great!

But I suggest you to check the state of your users:
case 'OnBeforeUserFormSave':
	if ($mode != 'new') {
		return;
	}
	// ...
break;
Otherwise you could override their «extended» field on usual profile editing.

And if you would like to update «extended», it is very easy too:
if (...) {
	$extended = $user->Profile->get('extended');
	$extended['key'] = 'value';
	$user->Profile->set('extended', $extended);
}

Now you know how to control any data of your users. With Office, or without it.
Бэкапы клиентам вообще не считаются. То, что ты видишь в занятом месте — это только твои файлы и БД, бэкапов там нет.

Если мы начнём вам считать бэкапы — вы офигеете, потому что для сайта на 2 гига хранится 5 гигов бэкапов.
Да, верно. Элементы в файлах и новый шаблонизатор можно установить самостоятельно даже на текущей версии.

Мы же не хотим сломать сразу весь опыт текущих пользователей новой версией, не правда ли?
Да, там какие-то проблемы с лицензиями, насколько я знаю.

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

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

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

2) Да, верно. pdoTools 3 уже есть на GitHub, на нём я отрабатывал работу с composer из дополнений. В новой версии
Fenom вынесен из pdoTools и ставится через composer самого сайта.
/** @var $modx modX */
    $modx =& $transport->xpdo;
    $path = MODX_BASE_PATH;
    $composer = $path . 'composer.phar';
    $params = "--working-dir {$path} --no-progress 2>&1";
    switch ($options[xPDOTransport::PACKAGE_ACTION]) {
        case xPDOTransport::ACTION_INSTALL:
            $message = shell_exec("php {$composer} require fenom/fenom:2.* {$params}");
            break;
        case xPDOTransport::ACTION_UPGRADE:
            $message = shell_exec("php {$composer} update fenom/fenom {$params}");
            break;
        case xPDOTransport::ACTION_UNINSTALL:
            $message = shell_exec("php {$composer} remove fenom/fenom {$params}");
            break;
    }
Да, большинство хочет с ним что-то сделать, но понимает, что сейчас это нереально.

Самый реалистичный план, который я знаю — перевести все контроллеры и процессоры админки на REST, и тогда любой желающий сможет написать свою админку на любом JS фреймворке (потому что это очень холиворная тема).
У нас 10 серверов в разных частях света, плюс возможность переезжать с одного сервера на другой в любой момент, со всеми бэкапами.

Если их вынести на внешнее хранилище, то работа с ними будет занимать оочень много времени, возможно даже за ночь просто не получится их все выгрузить. Просто потому, что хранилище в одном ЦОД, а большинство серверов — в другом.

Есть вариант работать с Selectel Cloud Storage, там CDN и типа должно быть всё быстро в любой точке планеты — но цены за хранение 2 ТБ бэкапов такие, что хостинг выйдет нерентабельным (и это я еще не уверен, что CDN поможет при upload).

Так что, нынешний вариант мне видится пока самым лучшим.
Настройки minishop2 он не переписывает, а лишь временно устанавливает свою настройку на ms2_frontend_js

Не лучше ли просто проверять наличие ms2 и регистрировать свой скрипт после него — а в скрипте уже перезаписывать объект miniShop2.Message на свой?
miniShop2.Message = App.Message;

На modhost / modstore ведь тоже используются не стандартные всплывашки, а Alertify — именно так там и сделано.