Редактор сайта

Редактор сайта: выбор стратегии

Наиболее примитивный редактор похож на phpmyadmin: он выводит на экран строки таблицы mysql с кнопками "Редактировать"; при нажатии на кнопку открывается html-форма, в которой можно поменять значения полей текущей строки, а потом нажать кнопку "Сохранить" – и всё запишется в БД.

В большинстве случаев такая схема работы пугает пользователя – в Редакторе информация выглядит совсем не так, как на сайте. Прямой доступ к mysql-таблицам чаще бывает нужен программисту. Для небольших сайтов разумнее не создавать "двойной доступ" (отдельно в Редакторе), а организовать редактирование "как есть": пользователь уже видит нужный фрагмент информации на публичной странице сайта – можно прямо к этому фрагменту присоединить кнопку "Редактировать" (которая будет, например, всплывать при наведении мыши и при щелчке вызывать форму редактирования, всплывающую поверх страницы). Вверху страницы можно добавить всплывающую кнопку "Добавить страницу", если логика сайта это позволяет. А более сложные операции, как показывает практика, всё равно пользователи стараются перекладывать на веб-студию, заказывая услугу "сопровождение сайта".

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

Хотя "прямое редактирование" кажется более простым и естественным, оно часто преподносится в CMS как бонус, как нечто очень необычно удобное, дополнительное, а первичным и наиболее разработанным является "настоящий", "внутренний" редактор. Так происходит по той же причине, что и ошибки в HTTP-протоколе – из-за всё более сильно развивающейся специализации. Доступ к редактированию через публичную часть сайта требует хорошего знания javascript, а php-разработчики обычно им пренебрегают, считая, что со всеми задачами спокойно можно справиться с помощью прилепленной сверху jQuery. Но не с этой задачей, требующей чёткого взаимодействия серверных и клиентских скриптов (а также CSS).

Пользователи и авторизация

Первое, что всегда требуется для редактирования сайта, – это система авторизации: понятно ведь, что мы не можем дать доступ к изменению и удалению материалов любому посетителю (хотя иногда так делают – например, в Википедии).

1. Наиболее распространённый способ отличить авторизованного пользователя – хранить информацию об авторизации в php-сессии. Сессию php надо открывать специальной командой. Наш код сейчас начнёт стремительно разрастаться в разные стороны, поэтому лучше сразу начать при открытии сессии проверять, не давали ли мы такую команду раньше (чтобы не вызвать ошибки Php):

if (!session_id()) session_start();

2. Для тестовой версии мы заведём только одного пользователя admin с паролем admin, и "зашьём" его в код:

<?php
$pw = _es($_POST, 'password');
if ($pw && md5($_POST['user'] . $pw) == md5('adminadmin')) {
	$_SESSION['user'] = $user;
	header('Location: index4.php');
}

/**** функции *******/
function _es ($arr, $key, $def = null) {
	return isset($arr[$key]) ? $arr[$key] : $def;
}
?>

md5 здесь как бы намекает нам, что реальный пароль надо хранить в зашифрованном виде (в нашем случае пока не имеет смысла).

3. Мы обращаемся к новой сущности кода – функции. До этого времени наш код был "плоским", команды шли сплошным потоком (иногда разветвляясь с помощью инструкций if-else). Какова причина создания нашей первой пользовательской функции (_es)? Фукнции нужны для удобства, для экономии усилий: один раз мы использовали конструкцию проверки параметра $_GET для установления ID страницы по умолчанию; сейчас нам второй раз понадобилось делать ровно то же самое – проверить параметр $_POST.

Это общее правило: если задача встречается в коде больше одного раза, эту задачу надо оформлять отдельной функцией. Кажется, функция _es очень мало упрощает работу, но это "мало" при многократном использовании начинает приносить пользу. Эта функция ещё и будет замедлять работу программы (тратится время на вызов дополнительной функции). Это общие проблемы "конструктивного" кода: мы усложняем, укрупняем блоки для удобства управления кодом (через новые абстракции) и платим за это производительностью.

4. После успешной авторизации мы возвращаем пользователя на Главную страницу сайта (сейчас это index4.php, но вообще будет что-то вроде "./").

5. Мы подготовились к приёму post-данных для авторизации, теперь надо организовать отправку этих данных через форму. Мы будем выводить эту форму на странице по знаку – если в параметрах url появится 'edit': http://nichtig.ru/index4.php?edit

А всё, что получилось, вы можете посмотреть с помощью параметра code: http://nichtig.ru/index4.php?code