Дом Figaroo

Исходные данные

Модульное web-приложение, которое использует шаблоны и плагины. Сюда можно отнести системы управления конентом, форумные движки, системы ведения блогов (тот же WordPress) и другие.

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

Ядро — это модель, предоставляющая базовый функционал всем остальным частям системы (нашего приложения).
Контроллер страницы — по сути скрипт, реализующий некую функциональность применительно к некой странице (например, проверку формы и добавление нового пользователя для страницы регистрации пользователей).
Шаблон — это представление страницы. Шаблон отвечает только за то, как выглядит страница.
Плагины — по сути скрипты, расширяющие функциональность контроллеров и шаблонов.

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

Проблема

Допустим, Вы разрабатываете такое веб-приложение. Ядром и контроллерами страниц управляете только Вы, поэтому их поведение Вы можете полностью контролировать. Но шаблоны, как правило, разрабатывает верстальщик или пользователь, а плагины — вообще посторонние люди.

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

Рассмотрим подробнее.
Допустим, Вы разработали систему ведения блогов типа WordPress (условимся, что на PHP). Система предоставляет базовый функционал за счёт контроллеров. Но пользователь захотел расширить функционал и поставил некий абстрактный плагин «Популярные записи», который находит пять наиболее популярных записей и отображает ссылки на них.

Всё бы хорошо, но, допустим, плагин вызвал фатальную ошибку. Что произойдёт в таком случае? Всё приложение немедленно завершит свою работу. Для некоторых плагинов это, может быть, и правильное поведение. Но для такого незначительного, как «Популярные записи» — недопустимое. Лучшей реакцией было бы отловить ошибку и завершить работу только данного плагина. В этом случае просто мы не увидели бы популярных записей, а всё остальное продолжало бы работать в штатном режиме.

Такому неконтролируемому поведению подвержены шаблоны и плагины.

Разберёмся с шаблонами

На мой взгляд, в данном случае решается всё довольно тривиально. Мы запрещаем использовать php-код в шаблонах, используя вместо него язык шаблонов. Для этого можно использовать шаблонизатор, например, Smarty. Холиварить на тему, какой шаблонизатор лучше, я не буду, здесь решать только Вам.

Шаблонизатор позволяет нам контролировать шаблоны.

Не всё так просто с плагинами

Плагины куда сложнее, чем шаблоны. Плагины пишутся на языке PHP и запретить его использование не представляется мне возможным (разве что только парсить код и проверять на допустимость, но это глуповато и слишком замедлит работу приложения).

Казалось бы, ну исполняют они PHP-код, ну и что? Приведу примеры.
Пример 1. Допустим, у Вас есть некий объект $DB для работы с базой данных. Если плагин выполнит инструкцию unset($DB), работа приложения будет нарушена. В результате, в плагинах могут содержаться как и простые ошибки-баги, нарушающие работу приложения, так и потенциальный вредоносный код.
Пример 2. Упомянутый выше плагин «Популярные записи» так или иначе обращается к базе данных. Допустим, у  нас есть два объекта $DB для низкоуровневой работы с БД и $DB_BLOG — для высокоуровневой работы с БД. Нам бы хотелось, чтобы плагин использовал в своей работе $DB_BLOG, а не $DB или же mysql_*-функции PHP. Ошибку обращения к $DB_BLOG мы можем считать незначительной и завершить работу плагина, её вызвавшего. Таким образом, это не приведёт к завершению всего приложения. Ошибку обращения к $DB мы можем отловить, но не можем определить степень её серьёзности, потому что мы не знаем, обычный плагин ли её вызвал или же само ядро, поэтому придётся завершить работу всего приложения.

Поэтому хотелось бы иметь kernel mode (режим ядра) и user mode (режим пользователя). В режиме пользователя можно предоставлять плагинам некий интерфейс, запрещая обращаться к низкоуровневым объектам приложения (мы их сами выбираем), а также использовать некоторые функции PHP.

Перехват ошибок в плагинах (даже фатальных) реализовать просто (почитать об этом можно, например, здесь), не понимаю, почему в WP такого не сделали.
С запретом обращения к определённым функциям всё обстоит несколько сложнее.

Итоги

Моделью и контроллерами управляем мы сами, они не нуждаются в таком жёстком контроле. Шаблоны можно контролировать с помощью шаблонизатора. А как быть с плагинами? Частично этот вопрос можно решить, но, к сожалению, пока не полностью.

Продолжение следует...