Редактирование на странице и CSS

Архитектура CMS, новые задачи

Кажется, мы могли бы работать с предельно простой системой разделения кода по файлам: один файл php, один js и один css. Это возможно – если один раз написать весь код и забыть (а потом всё будет работать само, без вмешательства программиста).

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

Мы уже сделали незаметный шаг – стали помещать версии в отдельные папки (05, 06), потому что потребовалась активная работа с файлами js, css. Мы отделили также два файла настроек: core.php, dns.php (для подключения mysql). Дальнейшее разделение php-кода связано с двумя направлениями:

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

Добавим также префиксы таблицам mysql, так как таблицы будут сильно меняться по структуре (и эти изменения могут повредить работе предыдущих версий).

Мы наметили структурное, "архитектурное" направление изменений. Теперь перечислим практические задачи развития CMS, стоящие на очереди.

1. Управление файлами (загрузкой, удалением, привязкой к страницам сайта).
2. Создание фотогалереи (вывод списков изображений на страницах сайта).
3. Добавление возможности комментариев на сайте и управление комментариями.
4. Изменение системы навигации на ЧПУ ("человеко-понятные УРЛ") – вместо адресов страниц вида "index.php?id=1" использовать что-то вроде "main-1.html", "contacts-2.html".
5. Разделение прав пользователей (admin, например, может только просматривать возможности CMS без права изменений данных, author – править тексты, editor – загружать и менять изображения...).
6. Добавление быстрой обратной связи – всплывающей формы типа "Заказ обратного звонка", при отправке которой владелец сайта будет получать уведомление на e-mail.
7. Заголовки http (кодировка, кэширование). Валидация http-кэша (установка времени изменения страницы с учётом всех выводимых на странице сущностей – комментариев, фото...).

После реализации этих изменений общий код сайта (php, js, css) вырастет в два-три раза (будет примерно 100 килобайт).

И так получается, что многие из этих изменений выгодней делать "оптом", а не по отдельности. Скажем, нам понадобится 2-3 новых таблицы mysql. Лучше сразу продумать их структуру, написать запросы на создание таблиц и выполнить их за один раз. Их можно выполнить теперь, кстати, без phpMyAdmin: у нас есть кнопка "Загрузить sql", можно нажать на неё, выбрать файл с написанным заранее sql-кодом и отправить его на сервер – он там выполнится, и мы увидим отчёты о выполнении (сколько строк затронуто, были ли ошибки).

Или, скажем, нам понадобятся таблицы для хранения а) комментариев и б) обращений через форму обратной связи. Мы можем продумать структуру и понять, что здесь будет достаточно одной таблицы, но в ней должно быть поле "статус", в котором цифра будет указывать на назначение записи в таблице (например, цифра "1" – комментарий, а цифра "2" – "обратный звонок").

И лучше начать с ЧПУ (чтобы потом меньше переделывать), так как система адресации на сайте используется во всех остальных подсистемах.

CMS: разделение кода по файлам

После реализации большинства задач предыдущей главы получилось примерно вот что: http://nichtig.ru/07/ (можно авторизоваться с данными admin, admin и скачать zip и sql этой версии себе на компьютер).

Код php между разными файлами распределился так:

1. exe/common.php – классы Config, Route, Mysql, Norm, Page. Класс Config очень простой – он хранит 4 массива: public, private, fields, subjects. Идея такая: public выгружается в javascript для использования на стороне клиента; private используется только в Php, fields описывает поля разных таблиц Mysql (эта информация потом используется для создания HTML-форм и для валидации данных); subjects описывает разные сущности, используемые в работе CMS.

   А сущности, кстати, такие: page, file, msg, command. Для первых трёх создаются соответствующие таблицы для хранения данных, сущность command не имеет хранимых данных, она воплощена только в php-коде – это набор функций для управления содержимым сайта.
2. exe/Command.php – класс Command. Содержит функции для записи данных, вызываемые всегда через "обёртку" write_wr() (вместо "конструктора"); функции для организации выгрузки и загрузки sql и файлов всего сайта.
3. exe/config.php – просто массив; загружается в соотв. разделы класса Config при инициализации сайта (функцией _init(), вызываемой из Route::response()).
4. index.php – единственный php-файл в корне сайта, содержит минимальные важные настройки: debug mode (надо ли включать отладку и на каком уровне отлаживать, как много информации о работе программы выводить); префикс mysql-таблиц TPREFIX (позволяет в одной БД хранить данные разных версий сайта) и некоторые другие константы (посмотрите сами). Подключает явно и "поимённо" (через "include") остальные php-файлы CMS.
5. exe/functions.php – просто функции, которые сложно отнести к какому-либо конкретному классу. Или они "слабо" связаны с кодом класса и вынесены в общую кучу, чтобы лучше была видна логика внутри класса (чтобы в самом классе было меньше "отвлекающего от сути" кода).
6. exe/Site.php – "наследник" класса Page, на каждом сайте может меняться полностью, так как именно этот класс отвечает за отображение, за внешний вид информации на сайте. Может быть совершенно пустым, тогда для вывода информации в HTML используется "по умолчанию" шаблон simple_tpl из класса Page.
7. exe/Abadon.php – аналог Site.php для административных команд, содержит класс Ab – наследник класса Command. Имя класса отличается от имени файла для шутки (мы не соблюдаем PSR в нашей маленькой CMS).
8. exe/users.php – массив с описанием пользователей (редакторов и администраторов); решили хранить его так, а не в Mysql, чтобы надёжнее можно было авторизоваться (удобно, когда таблиц mysql ещё нет и их надо создать загрузкой sql-файла с помощью встроенных функций нашей CMS).
9. exe/dns.php – массив с информацией для подключения Mysql (пользователь, пароль, кодировка...).

Код javascript и CSS не разделяется по разным файлам и содержится в соответствующих единственных файлах: site.js, site.css.

Файл .htaccess в корне сайта содержит достаточно стандартные инструкции: перенаправляет все запросы (если не существует соответствующий реальный файл на сервере) на файл index.php; запрещает вариант сайта, начинающийся с www. (перенаправляет такие запросы на "обычный" адрес); запрещает сканирование директорий (options -Indexes).

Файл .htaccess в папках img, files, source запрещает запросы HTTP к файлам php.

Файл .htaccess в папке exe запрещает любые запросы HTTP в эту папку.

Эту часть защиты можно было сделать проще: запретить вообще любые запросы к файлам php (кроме index.php) на всём сайте. Это на ваш вкус. Это защита от довольно редкого случая, когда кому-то удастся загрузить на ваш сайт свой файл php и с помощью этого файла выполнять там любые команды. Случай редкий, потому что даже если ОН украдёт ваш пароль от CMS, php-файл он загрузить на сайт незаметно не сможет:

1. мы явно перечислили расширения файлов, которые можно загружать в параметре 'upload_ext' в файле config.php;
2. наша CMS построена с расчётом на то, что ни редактору, ни программисту после установки не надо будет пользоваться загрузкой по (s)ftp – все файлы можно загружать через функцию CMS "Загрузить файл sql или zip". Вы можете так настроить права пользователей, чтобы даже через http никто не мог бы загрузить zip (а загружались бы только файлы картинок). Zip (с файлами программы) в общем-то уже и не нужно загружать, когда процесс отладки закончился и сайт начал работать стабильно.