LiveStreet CMS

Давайте разберемся: есть страница, на которой используется один дополнительный ява скрипт. Используется он только на этой странице. На остальном сайте он используется стандартный набор скриптов, которую CMS объединяет в один файл в 300 Кб. Итого, при заходе на главную страницу сайт клиент скачивает этот 300 Кб файл, при переходе на страницу, он скачивает объединенный с этим скриптом файл в 301 Кб, а значит имеем 2 запроса файла — первый при открытии любой страницы файла и второй, при открытии страницы файла с дополнительным скриптом. Суммарно клиент скачал 601 Кб и сделал 2 запроса.

В моём вариант клиент качает те же 300 Кб при открытии страниц сайта и еще 1 Кб при открытии страницы с дополнительным файлом. В результате те же 2 запроса, но трафика ушло почти в раза меньше.

Теперь объясните мне преимущество вашего варианта.

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

Может поделитесь реализацией центрального крона? Честно говоря сам уже хотел писать, но если есть готовое решение — то было бы просто замечательно.

Что касается нагрузки, то я не специалист в этой области, возможно вы и правы, спорить не буду. Мои высказывания базируются всего лишь на догадках.

1. При использовании плагинов с этим нету никаких проблем
2-3. С конфигурационными файлами можете делать что угодно, они точно не перезаписываются при обновлении движка, там ведь настройки сайта хранятся
4. Как вариант, можно просто в плагине переопределить методы класса ActionIndex

предложенное вами решение вроде как у ВП релизовано.

Тоже что-то такое припоминаю, может этот вариант я оттуда и почерпнул.

Кстати только что понял, что вариант псевдокрона легко реализовывается и внутри плагина, ведь всё что нужно уже есть. Но минусы этого подхода остаются: всё таки не очень хорошо, при загрузке каждой страницы проверять «а не нужно ли нам что-то сделать», особенно это будет проектах с большой посещалкой. Да и чем больше плагинов используют этот подход, тем больше мы нагружаем сервер, так что моё мнение не изменилось — этим должно заниматься ядро CMS и желательно в виде варианта с центральным кроном.

Возможно. Но на вопросы нужно ждать ответ, а время на ожидание не всегда есть. Да и как-то привык искать ответы сам, лучше в памяти откладывается.

Спасибо за ссылку, добавил в избранное, обязательно изучу.

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

Кстати, что скажите по поводу кроне, я опять промахнулся?

Всем, кто дал подсказки по решению интересующих меня проблем — большое спасибо, обязательно возьму на заметку. Жаль только, что так поздно узнал об этом

Это давно уже реализовано в плагине-библиотеке Config Engine — хранилище «ключ=значение», а также сохранение конфигов плагинов в БД и их автоматический старт. Плагин использует 

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

З.Ы. Все Многое уже реализовано, вопрос только в том нашил ли вы это или нет) 

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

Нужно работать с базой данных:
1. Чтобы всем новым пользователям по умолчанию не активировались эти опции, нужно в таблице user, для нужных полей (они начинаются на «user_settings_notice_») для значения по умолчанию поставить 0
2. Чтобы изменить настройки уже существующих пользователей, необходимо в этих же полях для всех пользователей установить 0. Пример SQL запроса, который отключает все опции уведомления для всех пользователей:

UPDATE `prefix_user` SET 
user_settings_notice_new_topic = 0,
user_settings_notice_new_comment = 0,
user_settings_notice_new_talk = 0,
user_settings_notice_reply_comment = 0,
user_settings_notice_new_friend = 0

prefix необходимо изменить на префикс ваших таблиц в базе данных.