CMS. Админ-панель

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

Подход, который я решил применить заключается в том, чтобы отказаться от тяжеловесных админских функций и перенести «физическую нагрузку» на плагины (или что-то аналогичное).

Получилась такая схема.

1. Вход в админку происходит по адресу http://site/admin/действие/параметры

2. «Действие» - это плагин или какая-то функция, которой передается управление. «Параметры» - с этим уже сама функция будет разбираться.

3. Сама же админка представляет собой html-темплейт, где прописаны четыре функции: mso_admin_header(), mso_admin_menu(), mso_admin_content(), mso_admin_footer(). Из названий понятно для чего они предназначены.

4. Теперь для того, чтобы вывести скажем настройки какого-либо плагина, мы просто вешаем (в плагине) хук на admin_content, а пункт меню добавлем как хук на admin_menu.

5. Таким образом подключить любой плагин к админке очень просто. Это буквально пара функций.

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

Следующая проблема с которой мне пришлось столкнуться - это админские функции по управлению базой. «Классический» подход заключается в том, чтобы наделать функций по управлению, создать html-формы и все это автоматом вызывать при входе в админ-панель.

Проблема здесь в том, что этих функций будет много и они будут между собой взаимосвязаны. Если нужно будет что-то изменить, то эта цепочка может протянуться очень далеко. В том же WordPress'е админка - это что-то невообразимое: огромное количество функций, которые не только переплетены между собой, но еще и тянутся к функциям в wp-include. Понятно, что изменить админку в WordPress очень и очень сложно. Всё, на что можно «позариться», так это смена css-стилей.

Лично мне такой подход не нравится, поскольку он очень сильно сужает рамки функциональности. Предположим нам нужно сделать страницу списка записей. В «классическом» варианте нам нужно было бы сделать отдельный php-файл, жестко его «прикрепить» к админке, написать все функции, выполнить SQL-запрос и выполнить форматирование полученных данных. Если пойти по такому пути, то неизбежно прийдем к «тяжелой» админке.

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

Таким механизмом является XML-RPC. В кратце я расскажу что это такое.

В XML-RPC есть две стороны: сервер и клиент. Сервер - это некий php-скрипт, который принимает входящие данные (запрос) и, согласно этому запросу, выполняет определенное действие (метод, функцию). Клиент в свою очередь - это обычный POST, только данные в нем передаются в виде XML-структуры. Например нам нужно получить список последних записей. В запросе мы указываем свой логин, пароль, название метода и количество записей. Отправляем этот запрос и в ответ получаем список последних записей.

Именно так работают оффлайн-клиенты (блог-клиенты). Как видите клиенту совершенно не обязательно знать все тонкости внутренней реализации методов. Все, что ему требуется, так это название метода и его параметры.

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

Что же получается в итоге.

1. Админка не несет «тяжелых» функций.

2. Простое подключение любых плагинов к админке.

3. Перенос функций для визуального отображения данных в отдельные плагины.

4. Получение данных выполняется через универсальный XML-RPC.

5. В «комплекте» мы сразу же получили работу с блог-клиентами.

На долю самой админки выпадают помимо функции менеджера, еще и работа с разграничением доступа (роли, группы, права), базовые настройки плагинов (включение, отключение, деинсталяция), базовые настройки сайта (выбор шаблона, название, описание и т.п.), то есть только то, что входит в самый минимум: таблицы options и users.