Избавляемся
от подключения mainfile.php
Некоторые модули PHP-Nuke в самом начале файла подключают сценарий
mainfile.php:
require_once(«mainfile.php»);
// или include(«mainfile.php»);
Нужно избавиться от вызова этого файла — в Slaed он не используется.
Гпава 12. Создание собственных модулей 147
12.5.6. Ссылки на modules.php
Обычно модули PHP-Nuke ссылаются на файл modules.php. Все такие ссылки
нужно заменить ссылками на файл index.php.
12.5.7. Цветовые переменные
В модулях PHP-Nuke могут встречаться цветовые переменные $bgcoiorN, где
? — это номер переменной:
bgcolor=»$bgcolorl»
В Slaed переменные остаются теми же, что и в PHP-Nuke, но их параметр
bgcolor нужно заменить параметром class, например:
bgcolor=»$bgcolorl» -> class=»bgcolorl»
12.5.8. Переменная $nukeurl
Если в старых модулях встречается переменная $nukeuri, то ее нужно
заменить переменной $conf [ 'homeurlf ].
ЧАСТЬ IV
Разработка
собственной CMS
Четвертая часть книги полностью посвящена разработке собственной системы
управления содержимым сайта. В ней мы рассмотрим все этапы разработки —
от концепции нашей CMS до ее воплощения в реальность.
ГЛАВА 13
функции и возможности
будущей CMS.
Разработка шаблонизатора
13.1. Зачем нужно разрабатывать
собственную CMS
В предыдущих частях книги мы рассмотрели три великолепные системы
управления контентом сайта— Joomla!, PHP-Nuke и Slaed. Вполне может
быть, что ни одна система вам не подошла. Возможно, ни одна система не
обладает нужными вам функциями. А может, вы боитесь, что «стандартные»
системы «стандартно» и взламываются. Хотя причина может быть и
другая — вам нужна простая и «легкая» CMS.
Все три причины имеют под собой почву. Стандартные системы на то они и
стандартные: их основная задача — удовлетворить большинство
пользователей. Но довольно часто бывает так, что ни одна CMS не может выполнить
поставленную перед ней задачу.
Для своего сайта я решил не использовать уже готовые решения, а написать
собственную CMS. Почему? Во-первых, мне нравится сам процесс
разработки. Но это, сами понимаете, не основная причина. Во-вторых, мне была
нужна универсальная система, которая могла бы работать на почти любом хос-
тинге. Первоначально мой сайт был размещен на бесплатном хостинге
^ww.narod.ru. Данный хостинг не поддерживал РНР, поэтому ни о какой
^MS и речи быть не могло. Весь сайт представлял собой набор HTML-
файлов, связанных между собой перекрестными ссылками. Когда страниц
^Ыло мало, поддержание сайта особого неудобства не доставляло. Но со
временем поддержание сайта стало занимать много времени. Нужно было
автоматизировать процесс управления страницами. Понятно, что на HTML орга-
6^а* 284
152 Часть IV. Разработка собственной CMS
низовать автоматизацию невозможно. Нужен был РНР (или любой другой
Web-ориентированный язык программирования, например Perl, но свой вы-
бор я остановил на РНР). Исследовав предложения других хостинг-
провайдеров, я пришел к выводу, что далеко не всегда бесплатный хостинг
поддерживал базу данных MySQL. Поэтому ни одна из рассмотренных в
книге систем не подошла— ведь все они ориентированы на работу с MySQL.
Было принято решение создать CMS, основанную на файлах (позже я
приобрел нормальный хостинг— с РНР, MySQL и другими функциями, но при
разработке CMS я о нем и не мечтал).
Да и, если честно, мне было лень создавать базу данных со своими
страницами— ведь они все уже были готовы и хранились на диске в виде HTML-
файлов.
Мне нужна была CMS, ориентированная на работу без базы данных. Были
готовые решения, но, попробовав несколько из них, я понял, что будет проще
и надежнее написать свою CMS, которую можно будет впоследствии
развивать и дорабатывать.
Итак, с нестандартной функцией мы разобрались. Теперь приступим к
обсуждению безопасности и надежности стандартных CMS. С одной стороны,
рекомендации по взлому той или иной CMS (если взлом таки возможен),
можно найти в Интернете, поэтому вам придется постоянно следить за
обновлениями CMS — вдруг одно из них устраняет огромную «дыру» в системе
безопасности вашего сайта.
|
5th Фев 2011
|
Теги:
|