Событие "user_profile_update" в системе из коробки обрабатывает только один контроллер "auth" в \system\controllers\auth\hooks\user_profile_update.php.
Непонятно, какую именно валидацию Вам нужно сделать, kreator. Но поскольку для вызова хука используется cmsEventsManager::hookAll(), то Вы действительно можете сделать свой обработчик с нужными проверками и он будет вызван до или после хука в user_profile_update.php. Если вызов будет после, то вы можете даже переопределить результат true от предыдущего обработчика на своё значение false. Если Ваш хук сработает первым и вернёт false, то true от следующих хуков Ваш false не изменят. Пока последовательность вызова обработчиков никак не регулируется. Судя по всему обработчики вызываются по алфавитной сортировке имён контроллеров. Но может быть и иначе, например, по расположению записей папок контроллеров в файловой системе.
Также в своём обработчике Вы тем же способом (через cmsUser::addSessionMessage) можете вывести желаемое сообщение пользователю.
InstantCMS 2.4.0 уже достаточно хорошо оптимизирована по коду. Структура CMS очень хорошо продумана. При работе выполняется минимум лишнего кода. Обращений к БД мало и они оптимизированы. Максимум, что Вы можете сделать с минимальными усилиями в этом направлении — отключить неиспользуемые компоненты и использовать меньше виджетов. 😊
А вот кэширование пока находится в базовом состоянии. База очень хорошая, но нет управления, как такового, и нет глубокого кэширования. Но пока это не приоритетно, я думаю. Вряд ли сейчас есть реальные работающие проекты, нуждающиеся в таком кэшировании.
Тестирование на моём домашнем компе показывает, что файловое кэширование даёт прирост скорости примерно на 25%, а memcached — чуть больше 30%. Возможно эта небольшая разница между файлами и кэшем обусловлена тем, что у меня винт с промежуточным флэш-кэшем. Полагаю, что на хорошем сервере с правильным рэйдом или SSD соотношение будет похожим. Так что кэширование в память будет чуть быстрее, но не намного.
"Рассширенная отладка" показывает, что около 90% времени создания страницы тратится на работу PHP. Причём примерно треть от этого времени уходит на загрузку файлов скриптов и интерпретацию кода, а остальные две трети — на его выполнение. Поэтому если Вас реально заботит скорость работы Ваших сайтов на Двойке, самое критичное, на что я бы обратил внимание — производительность ядер процессора и хороший кэширующий интерпретатор. Выбрав сервер с многоядерным процессором последнего поколения с большим кэшем третьего уровня, а также настроив акселератор PHP, Вы получите ускорение намного большее, чем при кэшировании. И даже сохраните полностью динамическое построение страниц. При этом Вы всегда сможете дополнительно включить кэширование в CMS, если на Ваш сайт вдруг неожиданно обрушится счастье в виде сотни тысяч уников в день. 😊
Ну и естественно, прокси-сервер на входе и статика на отдельном сервере — это классика.
Azami, править файл ядра в данном случае необходимости нет. Вы можете перехватить событие "error_404" хуком в любом своём компоненте и сделать в этом хуке все желаемые проверки и редиректы.
В документации есть описание "Обработки событий".
apple-touch-icon — это специальные иконки для эппловских устройств. При заходе с яблочного планшета/компа/телефона браузер их ищет и у Вас не находит. Можете или почитать про них и сделать себе на сайт эти иконки, или проигнорировать.
По второму виду ссылок на xml ничего сказать не могу.
По графику памяти можно сказать лишь то, что периодически (от раза в пару часов до пары раз в час) у Вас расходуется много памяти. По какой причине — сказать трудно. Может много одновременных просмотров, может открываются какие-то "тяжёлые" страницы. Может боты сканируют. Может ещё что-то.
Какая посещаемость ресурса? Сколько показов страниц в день?
Тормоза наблюдаются на всех страницах сайта или только на некоторых?
Какие запросы в логе тяжёлых запросов?
Скорее всего это вопрос к админам сервера/хостинга. Если хостинг шаровый или свой с несколькими сайтами на нём, то такая картина может быть при наличии высоконагруженных соседних сайтов. Админы сервера могут увидеть кто так сильно нагружает. Возможен вариант и с неверно настроенным SQL-сервером, как тут уже сказали. Есть ещё вариант — DDOS-атака. Но это также вопрос к админам сервера.
На нормальном сервере при правильных SQL-запросах Единичка показывает время несколько меньшее, чем Двойка. К примеру, у меня на сайте с дефолтными двумя десятками запросов время создания страниц меньше 100 мс. При количестве правильных запросов под 200 штук, на моём сервере время увеличилось бы примерно на 75 мс (по пол мс на каждый запрос). То есть, суммарно в пределах 200 мс. Всё сильно зависит от того, какие это запросы и как организованы. Так что даже для нешустрого хостинга время больше 1 секунды — это слишком много.
Просто так взять и опубликовать контент от имени пользователя без id (незалогиненного) не получится, насколько я знаю. Нужен пользователь. Проверял давно, ещё на InstantCMS 2.1, поэтому на сегодня что-то могло измениться.
Если не пустит добавлять от гостя, то можно пойти по такому алгоритму:
1. Создать нужный тип контента.
2. В Админке создать обычного пользователя с именем "Гость". Дать ему права на создание нужного контента. Почта и пароль не важны. Просто чем сложнее — тем лучше.
3. Хуком перехватывать событие добавления контента этого типа, менять в данных id пользователя с 0 (незалогиненный пользователь) на id "Гостя" и далее возвращать данные для добавления в контент.
Я делал подобным образом на 2.1 добавление данных из iForms в нужный тип контента. Работает.
Это пример добавления поста блога в демо. В левой колонке — доступные поля. В правой колонке видны значения переменных из примера.
Ваш шаблон генерации URL: {user_nickname}/{id}
Поддержки кириллических адресов пока нет. Русский ник будет транслитерирован и переведён в нижний регистр. "Администратор" -> "administrator"
Обратите внимание, что в текущей версии InstantCMS2 это очень проблемный вариант!
Первая проблема. На данный момент в Двойке реализована уникальность полей в пользовательском профиле только для id и email. Для ников это пока не сделано. Это значит, что при Вашем шаблоне адреса Вы рискуете получить ситуацию с материалами разных пользователей в одной и той же "папке". Во-первых, из-за транслитерации (например, для пользователей Виктор и Viktor). Во-вторых, из-за невозможности запретить разным пользователям задавать себе одинаковые имена. Эта тема уже несколько раз поднималась на форуме.
Вторая проблема Вашего варианта на данный момент в том, что любой пользователь в любой момент может изменить своё имя (ник). А значит, его старые материалы по прежним адресам останутся, а новые материалы уже будут создаваться в "папке" с другим именем. Получите несколько "папок" для одного и того же пользователя.
Единственный вариант, который я вижу для Вас, если очень нужно сделать именно так, как Вы описали — создание отдельного уникального поля, которое обычно называют "Логин". Стандартными средствами поле в профиле можно добавить в Админке. Но оно уникальным не делается, значит это уже хак системы или, если возможно, хук. Это поле должно попадать в вышеприведённый набор переменных — это либо второй хак, либо, если возможно, ещё хук. Это поле должно вводиться пользователем один раз и далее быть недоступно для изменения им — тоже хак или хук. Если получится только хуками — это лучше. Возможно ли это, я не знаю, так как ещё не разбирался со всеми событиями в системе.
Я сейчас столкнулся с аналогичной задачей, только более широкой. Буду её решать через создание системного поля "Логин" и несколько хаков. Что из этого получится и когда закончу — пока не знаю. Если разработчики будут не против, выложу то, что получится в свой блог.
Стандартизация — это, чаще всего, хорошо. Если разработчики озвучат какие-то стандарты или требования, я постараюсь их придерживаться.
А пока для себя использую такую систему версий: мажорная.минорная.для_какой_версии_движка. Например, 10.1.240 для версии InstantCMS 2.4.0.
Обозначать компоненты/виджеты/и т.д. номером не вижу смысла. Это можно легко вписать в название. А вот название можно стандартизировать. Например, название_install — инсталляшка, название_update — обновление. Или ещё как-то.
Да, странная ситуация. У меня был пример, когда дешёвый шаровый хостинг за несколько баксов в месяц со старым сервером и кучей других клиентов вообще без каких-либо заметных тормозов выдерживал 5 тысяч просмотров в сутки в течение нескольких месяцев. И поддержка ничего не писала. Правда, там движок был очень лёгкий, самописный.
