Опубликован: 22.10.2016 | Уровень: для всех | Доступ: платный
Лекция 2:

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

< Лекция 1 || Лекция 2: 1234 || Лекция 3 >

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

Наиболее примитивный редактор похож на 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

< Лекция 1 || Лекция 2: 1234 || Лекция 3 >
Михаил Гутентог
Михаил Гутентог

Этот курс ( Практикум по разработке CMS ) создавался, когда у PHP была версия 5.3 или 5.4. Со временем какие-то функции PHP устаревают (mysql, each), какие-то начинают работать по-другому (empty). Пожалуйста, следите за изменениями в PHP по сайту php.net!

Александр Мельников
Александр Мельников

Изучаю курс "Практикум по созданию CMS" в листинге 4.3

$n = count($_GET); if ($n > 0) { $param = each($_GET); // самое простое: пропускаем только первый параметр if ($n > 1 || !isset($valid[$param['key']])) { _404(); }

При попытке просмотра в браузере получаю ошибку: Deprecated: The each() function is deprecated.  И не пойму как исправить ситуацию.

Елена Суханова
Елена Суханова
Россия, Москва, МИЭТ, 2011
Анастасия Щитова
Анастасия Щитова
Россия, Москва, ФГБОУ ВО "Московский государственный юридический университет имени О.Е. Кутафина (МГЮА)", 2016