Государственное бюджетное образовательное учреждение высшего образования Московской области Университет «Дубна»
инженер-программист
Филозова Ирина Анатольевна, старший преподаватель кафедры распределённых информационно-вычислительных систем Института системного анализа и управления государственного университета
УДК 004.7
Введение
В настоящее время существует множество различных технологий разработки и управления WEB-сайтами и приложениями с клиент-серверной архитектурой. Это многообразие технологий предоставляет выбор разработчикам, для обеспечения наилучшей эффективности, надёжности и безопасности, однако имеется множество трудностей с выбором тех или иных средств, для выполнения конкретной задачи.
Зачастую, неправильный выбор и настройка различных средств, дают ошибки, которые имеют не менее тяжкие последствия, чем те, что допущены при непосредственной разработке и реализации конкретных модулей. Опытный программист должен не только грамотно реализовать наиболее эффективные алгоритмы, но и корректно выбрать технологию реализации.
В большинстве современных проектов, разработчики используют и ручное написание кода, и готовые модули. Также разработчики часто обращаются к различным системам, на базе которых ведутся разработки WEB-приложений. Положительными аспектами такого подхода являются: 1) облегчение разработки собственных модулей; 2) возможность эффективного повторного использования кода. Это существенно снижает сложность при разработке системы в целом.
Несмотря на то, что при использовании наработок человечества, задача разработчика в некоторых ситуациях облегчается, это может давать и множество «подводных камней», поскольку не весь код зависит от конкретной команды разработчиков, да и при работе над сложными проектами возникают новые ошибки. Несмотря на то, что при грамотном использовании опыта сообщества web-программистов, перенимаются и ошибки, отказаться от готовых модулей, а также систем разработки и управления контентом - практически невозможно, ввиду большой сложности и высокого объёма работ при создании крупных проектов. Встаёт вопрос о достоинствах и недостатках различных средств и технологий.
Цель
Предоставление дополнительных возможностей WEB-разработчикам для эффективной реализации приложений различной сложности.
Анализ предметной области
Описание общих принципов работы сайта
В общем случае сайт состоит из двух основных частей – клиентской и серверной.
На стороне клиента работает браузер, который интерпретирует связку из языков HTML, CSS и JavaScript.
HTML(Hyper Text Markup Language) содержит разметку WEB-страницы.
CSS(Cascade Style Sheet) содержит стили оформления различных элементов разметки WEB-страницы.
JavaScriptсодержит программную часть, выполняемую браузером на стороне клиента.
На стороне сервера, в общем случае, имеется программа-WEB-сервер, содержащая интерпретатор какого-либо серверного языка (например, PHP, Python, Ruby и т.д.) и программа, выполняющая роль сервера баз данных (как правило – содержит интерпретатор какого-либо диалекта языка SQL, но могут быть и другие языки для работы с базами данных).
В общем случае, сайт работает следующим образом:
Как правило, web-приложение содержит как код серверной части, так и клиентскую часть — HTML, CSS и JavaScript код. Серверная часть кода не передаётся клиенту и ни как им не интерпретируется. В общем случае, частично клиентская часть приложения генерируется динамически серверными скриптами.
Общее описание назначения CMS
CMS(Content Management System) или – система управления содержимым (контентом) представляет из себя информационную систему с WEB-архитектурой, в которой реализованы функции:
По своей сути, CMS является сайтом, состоящим из двух основных частей – бэкэнда и фронтэнда.
Бэкэнд – часть, которую видят администраторы, модераторы и авторизированные пользователи. В этой части содержатся инструменты для управления и создания содержимого, а также для настройки его представления другим пользователям. В зависимости от прав и ролей пользователя, ему могут быть доступны различные функции и модули бэкэнда, а также различное содержимое.
Фронтэнд – часть, которую видит конечный пользователь. В ней отображается общедоступное содержимое, которое было опубликовано и выведено в соответствии с настроенными в бэкэнде параметрами.
Для примера рассмотрим форум, построенный на базе форум-ориентированной CMS phpBB. В данной ситуации, бэкэндом является часть, в которой пользователи, администраторы и модераторы создают и редактируют темы, разделы, объявления и т.д. В зависимости от роли конкретного пользователя (обычный пользователь, администратор или модератор), ему доступны разные права. Фронтэндом же является часть, которую видит и может использовать на сайте данного форума любой незарегистрированный пользователь.
Сравнительный анализ CMS систем
Для сравнения были выбраны наиболее популярные, но существенно отличающиеся CMS. Сначала был проведён анализ двух наиболее популярных PHP CMS – WordPress и Joomla, после чего они были сравнены отдельно с CMS MODx, так как её концепция кардинально отличается от концепции WordPress, Joomla и большинства других CMS.
При выборе CMS следует чётко понимать задачу, которую должен будет выполнять разрабатываемый WEB сайт. Существует давно сложившиеся мнение, что WordPress применяется преимущественно для сайтов со структурой блога, а Joomla – наиболее универсальное решение. Не так давно это было справедливо, однако сейчас – всё уже не так очевидно. Рассмотрим поподробнее.
Во-первых, WordPress имеет наиболее простой и интуитивно понятный интерфейс, который позволяет вносить ручные изменения кода, практически в любом месте шаблона, в следствие этого, для разработчиков не составит большого труда создать структуру, отличную от блога. Конечно же и Joomla имеет довольно большой и вариабельный функционал для работы с различными частями шаблона, позволяя размещать их на разные позиции и редактировать. Однако, гораздо сложнее добавлять, удалять и изменять код этих модулей. Например, в Joomla нет возможности просто прописать “служебные тэги” прямо через редактор исходного кода (style, link и т.д.), а также скриптовые (Script). Это усложняет возможность подключения скрипта или внешней таблицы стилей к конкретной странице. Также отсутствует возможность прямого получения постоянных ссылок на материал. Все эти нюансы усложняют действия в нестандартных ситуациях, которые нельзя решить по средствам плагинов или встроенного функционала. Поэтому, несмотря на более сложный и функциональный интерфейс Joomla, ручное кодирование в ней сложнее, чем в WordPress. Это усложняет жизнь разработчикам, однако в стандартных случаях, с которыми чаще сталкиваются начинающие, это может помочь добиться более эффективного результата, с наименьшими усилиями. В целом - Joomla имеет менее понятный интерфейс.
Преимущества и недостатки Joomla
Одним из наиболее весомых преимуществ Joomla является универсальность. Её можно использовать для создания сайтов с различными структурами. Не менее важным преимуществом является и большая функциональность, в том числе и гибкая настройка прав пользователей. Третьим, и последним явным преимуществом является визуальная модульная настройка страниц, а, именно, размещение модулей на различных позициях (местах) страницы и независимая настройка каждого модуля.
Рис. 1. Отображение позиций в Joomla
Одним из наиболее важных недостатков Joomla является несовместимость версий. А именно, если Вы берёте шаблон для Joomla 2.5, то корректно установить его на Joomla других версий будет очень сложно, или практически невозможно (потребуются множественные изменения кода — фактически создание шаблона заново). Это бывает очень часто, и не только для шаблонов, но и для других компонентов (например, плагинов).
Рис. 2 Панель управления Joomla 2.5
Рис. 3 Панель управления Joomla 3
Преимущества и недостатки WordPress
В отличии от Joomla, в WordPress доступна практически 100%-я возможность ручного кодирования (как страниц, так и модулей). Это преимущество сильно выручает тогда, когда нужна очень тонкая настройка, которой нет в средствах самой системы (или шаблона), а также, когда требуется добавление сторонних компонентов, не представленных в виде плагинов или других модулей. Например, можно без труда подключить свою таблицу стилей на конкретную страницу (или свой скрипт), не регистрируя их в самой CMS. Это сильно облегчает задачу работы с нестандартными, но мелкими частями, которых нет в установленных темах (или плагинах), но они малы (или редко используются), чтобы регистрировать их, или писать отдельную тему (или плагин). Второе важное преимущество – это обратная совместимость версий. То есть, если вы используете шаблон (или другой компонент) для конкретной версии WordPress, а потом обновляете свою CMS, то в большинстве случаев всё будет работать корректно. Также не вызовет проблем установка более старого шаблона и/или другого компонента на более новую версию WordPress. Ещё одним преимуществом является схожесть интерфейсов различных версий этой CMS, что упрощает жизнь модераторам сайта. Ниже приведены снимки экранов рабочих сред у разных версий WordPress.
Рис. 4 Панель управления WordPress 3.3
Рис. 5 Панель управления WordPress 4.2.2
Немаловажным положительным аспектом является и то, что большинство устанавливаемых компонентов не требуют индивидуальной регистрации. То есть для того, чтобы установить новый шаблон (или плагин), нужно просто скопировать папку, содержащую его, в соответствующую папку в структуре сайта. Это облегчает настройку прав доступа, непосредственно на уровне сервера, а также упрощает задачу переноса сайта и смены доменного имени. Интерфейс WordPress более логичен, чем интерфейс Joomla. Один из примеров — при создании новой страницы, вы получаете постоянную ссылку на неё, чего по умолчанию нет в Joomla.
Одним из наиболее важных недостатков данной системы является её направленность на блоговую структуру, однако этот недостаток легко исправляется добавлением и настройкой различных шаблонов, плагинов и ручной правкой кода. Второй недостаток – менее гибкая, по сравнению с Joomla, настройка прав доступа и ролей пользователей, однако и он легко исправляется, также как и в предыдущем случае. Третьим недостатком является отсутствие визуальной модульной настройки сайта (как в случае с позициями в Joomla), однако этот недостаток весьма спорный, так как при большом количестве модулей, довольно часто, легче использовать ручное изменение кода.
В целом, современные системы Joomla и WordPress имеют схожий функционал, при соответствующей настройке и дополнительных компонентах. Однако, по умолчанию, функционал у Joomla выше, чем у WordPress. Это может быть положительной чертой, когда от начинающего разработчика требуется создание и поддержка сложного проекта, но учитывая сложность и частичную нелогичность интерфейса Joomla, это не так однозначно. Несмотря на кажущуюся простоту WordPress, она может отлично показать себя, как в учебных целях (простой интерфейс), так и в сложных проектах (широкие и мало ограниченные возможности редактирования кода, плюс обратная совместимость).
Исходя из всего вышесказанного, можно сделать вывод, что применение Joomla достаточно трудоемко как при разработке, так и при дальнейшем использовании сайта. Поэтому, если при разработке конкретного web-приложения нет каких-либо специфических задач, легко реализуемых на Joomla, то стоит обратить внимание на WordPress.
Преимущества и недостатки MODx
Одной из наиболее удобных универсальных CMS является MODx. В отличии от большинства других наиболее популярных CMS, например, таких как WordPress или Joomla, MODx имеет существенное отличие, которое является преимуществом в сложных и нестандартных проектах.
При использовании MODx можно произвести установку абсолютно любого шаблона. Для MODx не нужно специально адаптированных тем, шаблон может быть написан вручную средствами HTML, CSS и JavaScript. Так же шаблон может быть получен из любого сайта или шаблонов для других CMS.
Шаблоны для большинства CMS написаны по их правилам, вызывая различные функции CMS и используя её библиотеки. Такой подход даёт возможность установки и настройки шаблона не по средствам написания кода, а через графический интерфейс самой CMS, однако этот способ накладывает ограничения на шаблон, ведь он должен быть написан по стандартам конкретной модели (а у некоторых CMS и конкретной версии). Можно провести аналогию с ОС. Для установки приложения, например, на ОС Windows, это приложение должно соответствовать определённой архитектуре и его установка на MacOS или Linux будет невозможна без специальных дополнений и/или эмуляторов ядра Windows.
Рассмотрим установку и настройку шаблона в MODx. Допустим, был скачен понравившийся шаблон или написан самостоятельно. Пусть этот шаблон содержит HTML CSS и JavaScript. Для установки шаблона потребуется выполнить следующий набор действий:
1. Скопировать папку с шаблоном в произвольную папку, лучше, чтобы она находилась внутри папки CMS, как и другие элементы структуры сайта (обычно, шаблоны в MODx хранят в папке assets/[имя папки для шаблонов]/[имя папки с конкретным шаблоном]. Однако, можно хранить содержимое шаблона и в других папках.
2. В пункте элементы, шаблоны создать новый шаблон (названия пунктов могут незначительно отличаться в зависимости от версии). Указать имя шаблона и вставить его код.
4. Получить код шаблона из его главной HTML-страницы: копируем его и вставляем в соответствующее поле в MODx.
5. Сохранить шаблон.
6. Отредактировать пути подключаемых ресурсов (JavaScript, CSS и т.д). По умолчанию корневой папкой конкретного сайта считается папка с самим MODx, соответственно, если шаблон хранится, например, в папке “шаблон”, а папка “шаблон” хранится в папке “assets”, то путь к содержимому будет assets/шаблон/. Допустим, создаваемый шаблон, находящийся внутри папки “шаблон” имеет папки “CSS” и “JS”, внутри которых находятся стили и скрипты соответственно, так же имеется файл index с расширением HTML. Кодом этого шаблона будет содержимое индексного файла, а в путях подключения стилей напишем assets/шаблон/CSS/[название файла стилей].css. Аналогично редактируем пути к скриптам и другим ресурсам шаблона. После правильного редактирования путей, страница, использующая данный шаблон должна выглядеть как он сам, однако при её редактировании средствами MODx, не будет видно никаких изменений, они будут видны только при условии внесения их в код самого шаблона, ведь, по сути он и становится кодом страницы, которая его использует.
7. Для того, чтобы это исправить, потребуется адаптировать шаблон к работе в MODx. В системе MODx имеется такая сущность как “поля”. Каждое поле имеет своё название. Например, в MODx Revolution, поле для имени страницы (заголовка (не путать с понятием заголовка в HTML)) имеет название [[*pagetitle]]. Следовательно, для того, чтобы введённый в графу “заголовок” текст стал именем страницы, требуется удалить из тега его содержимое и вставить название данного поля. Это будет выглядеть так:
Теперь название страницы, использующей данный шаблон, будет браться из поля заголовок. По аналогии требуется поступить и с остальными полями. В MODx можно также создавать дополнительные поля и задействовать их в разных секциях шаблона.
Это описана общая схема настройки шаблона, более тонкая настройка зависит от ситуации [5].
Теперь рассмотрим варианты с получением шаблона из другого сайта, или другой CMS. Допустим, была найдена понравившаяся страница какого-то сайта. Для того, чтобы получить из неё HTML шаблон, требуется скопировать её исходный код, а также коды и файлы ресурсов, которые она использует (нужно для дальнейшего их редактирования). Далее необходимо сохранить скопированные коды в соответствующие файлы и разместить в соответствующих папках. Полученный шаблон настраивается по классической схеме. Для получения шаблонов для работы с MODxиз других CMS требуется создать страницу с использованием понравившегося шаблона на CMS-доноре, а после выполнить те же действия, что и в предыдущей ситуации.
Также, MODx имеет понятный интерфейс, который не изменяется радикально при появлении новых версий.
Рис. 6 Вид панели управления MODx Revolution 2.2.7
Рис. 7 Вид панели управления MODx Revolution 2.4.2
Несмотря на то, что в MODx нет некоторого функционала, который практически обязателен (например – очень мало-функциональный редактор содержимого страницы), это легко устраняется, так как для MODx (как для Revolution так и для Evolution) написано множество плагинов, сильно расширяющих функционал.
Список плагинов, которые желательно установить сразу после установки MODx, независимо от направленности разрабатываемого сайта:
CKEditor – “продвинутый” редактор содержимого страницы. Добавляет множество функций, присущих популярным текстовым процессорам (таким как Microsoft Word или LibreOffice Writer). Этот плагин имеет множество альтернатив, и несмотря не его простоту, он также имеет определённые недостатки. Основной недостаток заключается в использовании нежелательных стилевых конструкций HTML (см. раздел “Задача унификации и оптимизации вёрстки”);
CodeMirror – удобный плагин для кодирования элементов шаблона. Подсвечивает незакрытые HTML-тэги, и некоторые другие ошибки кода;
SimpleSearch – простой плагин для реализации функции поиска по сайту (на фронтэнде);
Wayfinder – не менее простой и удобный плагин для реализации меню сайта;
Преимущества концепции MODx в том, что имеется полный контроль над различными элементами и гибкие инструменты для их разработки в самой CMS, в то время как в некоторых других CMS гораздо меньше таких возможностей. В MODx имеются штатные средства не только для установки и настройки таких элементов как шаблон, плагин и так далее, но и для их создания.
Есть так же популярная CMS-конструктор WiX, которая использует противоположную MODx концепцию. Конечно для создания простых проектов WiX может показаться легче, так как в ней реализована 100% генерация кода, и пользователь работает только через средства графического интерфейса, однако отойти от возможностей, которые заложены разработчиком практически невозможно, что очень затрудняет разработку индивидуальных проектов на WiX. При этом разработка новых элементов, работающих на WiX будет весьма затратной, так как в коде своего компонента нужно будет реализовать множество конструкций, работающих по правилам функций WiX, для обеспечения полной функциональности, которая отображается в интерфейсе данной CMS.
CMS Joomla и WordPress используют некую среднюю концепцию между MODx и WiX, как и большинство других популярных CMS.
Обобщённые результаты сравнительного анализа CMS приведены в таблице 1.
Критерий Сравнения CMS |
Логичность интерфейса |
Обратная совместимость версий |
Нет обязательной регистрации пакетов |
Средства адаптации любых модулей |
Прямое подключение скриптов и стилей |
Бесплатная лицензия
|
WordPress |
+ |
+ |
+ |
- |
+ |
+ |
Joomla |
- |
- |
- |
- |
- |
+ |
MODx |
+ |
+ |
+ |
+ |
+ |
+ |
Преимущества и недостатки WiX
WiX – это не просто CMS, а полноценная платформа для создания сайта, предоставляющая не только саму CMS, но и хостинг со всем необходимым ПО. WiX использует методику drag-and-drop, которая предполагает манипуляцию всеми элементами сайта, по средствам графического интерфейса, со 100% генерацией кода. Пользователю не предоставляется возможность ручного кодирования[7]. Это может быть достоинством для тех, кто не занимается WEB-разработкой профессионально, но имеет задачу разместить свой несложный сайт в Интернете с наименьшими затратами, не углубляясь в безопасность и персонализацию. Например, при создании сайта-визитки.
Рис. 8 Внешний вид интерфейса WiX
WiX не подойдёт для сложных и крупномасштабных проектов, так как она не имеет возможности для настройки и разграничения прав, персонализации бэкэнда, адаптации собственных модулей, а так же при её применении возникают большие сложности с поисковой оптимизацией (SEO).
Весьма сложной задачей является разработка собственных модулей, для дальнейшей публикации и использования на WiX.com, так как для корректной работы каждого элемента в среде графического интерфейса WiX, её шаблон должен соответствовать большому количеству встроенных правел, максимально предусматривающих множество возможных вариантов действий пользователей.
Выбор технологии серверного программирования
При выборе языка программирования для серверной части сайта следует учесть несколько факторов. Во-первых, сайт может быть написан как с использованием CMS, так и без неё. В первом случае – язык программирования выбирается исходя из требований нужной CMS. Во-вторых, на некоторых WEB-серверах могут быть только определённые интерпретаторы для конкретных языков программирования. В-третьих, некоторые WEB-сервера работают под управлением определённых ОС.
Рассмотрим пример:
И если на некоторых WEB-серверах могут работать различные интерпретаторы для разных языков программирования, а варианты самих WEB-серверов могут выпускаться под разные ОС, то в случае с ограничением, которое накладывает CMS – вариант один – выбрать язык программирования, работающий с конкретной CMS.
Зачастую может быть так, что некоторый функционал будущего сайта уже реализован в конкретной CMS, или его реализация сильно упрощена, в этом случае следует задуматься о выборе конкретной CMS, а потом выбрать среду под неё, в остальных случаях целесообразно начать с выбора серверного языка, а потом выбирать CMS из полученного диапазона, так как в сложных проектах придётся программировать вручную множество модулей различной направленности.
Немаловажным фактором является и ОС, на которой будет работать WEB-сервер, так как неправильная настройка и возможные уязвимости в её политики безопасности могут поставить под угрозу работу ни только самого сайта, но и конкретного физического сервера или целой подсети. Подробнее об этом в пункте защиты сайтов.
По данным на 2015 год, популярность языка PHP состовляет около 80%. Такая высокая популярность обусловлена относительной простотой данного языка, в сравнении с большенством других популярных альтернатив (например, ASP.NET). Также, столь высокая популярность способствует тому, что наибольший выбор CMS, на сегодняшний день, имеется именно среди PHP-CMS.
Как было сказано выше, PHP – самый популярный язык серверной части WEB-сайтов. Это весьма весомый аргумент в пользу его выбора.
Во-первых: из-за его популярности его знают большинство разработчиков. Во-вторых: для него написано большинство библиотек и других решений, что сильно уменьшает затраты на выполнение различных проектов.
Несмотря на популярность PHP, для некоторых задач выгоднее использование альтернативных языков (например, для написания WEB-скрепперов часто используется Python).
Стоит упомянуть, что на сегодняшний день начинает набирать популярность серверный вариант JavaScript (Node.js). Так как JavaScript используется на стороне клиента, практически без альтернатив (технология java applet сильно устарела), то популярность серверного варианта данного языка может сильно возрасти за счёт того, что разработчики серверной и клиентской частей начнут лучше понимать друг друга, что приведёт к облегчению работы над проектом.
Задача защиты сайта
При разработке сайта, довольно часто возникает потребность в использовании баз данных. Как было описано выше, обычно контент генерируется динамически, путём извлечения из базы данных и вставки на нужные места шаблона. Из этого следует, что серверная часть сайта вынуждена постоянно обращаться к базе данных, при этом, сам серверный скрипт не участвует в работе с базой, а только составляет запрос к ней, который выполняется уже сервером баз данных. Это приводит к проблеме, которой подвержены практически все сайты – возможности SQL инъекции.
Инъекция (или внедрение кода) может быть произведено на любом языке, но в общем случае, большинство необходимой информации содержится в БД, которая, в свою очередь, часто реализована на языке SQL.
Общий алгоритм написания SQL-инъекции выглядит так:
Практически на всех сайтах есть поля для ввода информации, их можно использовать для SQL-инъекции. Рассмотрим простой вариант. Серверный скрипт строит запрос к базе данных:
Затем скриптом дописывается завершающая часть запроса. Далее вписывается закрывающая кавычка и точка с запятой (‘;), после чего вписывается внедряемый запрос, а потом ставится знак SQL-комментария – два коротких тире (--) для игнорирования остальной части SQL-запроса[1]. Таким образом сервер БД получит следующий запрос:
Рис. 9. Схематичное изображение SQL-инъекции
Задача защиты от SQL-инъекций является одной из наиболее сложных и важных, так как не существует универсального 100% способа закрытия данной уязвимости. Существуют некоторые стандартные способы защиты, однако они работают не во всех ситуациях. Например, в поле, где должен вводится возраст, логично ожидать целое число, а значит можно преобразовать введённые в поле данные в целое число, перед тем, как отправить запрос серверу БД. Если преобразование завершится неудачно, то передастся пустое значение или ошибка, что не даст возможности внедрить неправомерный код в данное поле. Однако, не везде заранее известен тип вводимых данных (например – комментарии), там могут содержаться различные символы, и данный способ не подойдёт.
Но даже если БД защищена относительно хорошо, в некоторых ситуациях можно внедрить в запрос команды для выполнения в самой ОС, что может поставить под удар ни только конкретную БД, приложение и/или сайт, но и весь сервер или целую подсеть. Зачастую может быть так, что через некоторые WEB-сервера или сервера БД можно отправлять команды ОС, и при этом эти сервера запущены под правами супер-пользователя (администратора), таким образом можно получить доступ ко всем функциям ОС. Защитой в этом случае является настройка и разграничение прав в ОС, в том числе и запуск программ-серверов с неполными правами.
Также проблемой является узнаваемость большого числа используемых технологий. Например, узнав CMS, на которой написан сайт, можно попытаться пройти через характерные для неё уязвимости, та же ситуация – если известно достоверное наименование WEB-сервера или языка серверной части. Необходимо шифровать такие данные, подменяя характерные признаки использования конкретных технологий. Например, переписать стандартные пути к панели управления CMS, сменить логотипы и так далее.
Ещё одним способом защиты может являться ограничение доступа к некоторым ресурсам по конкретным IP адресам. Например, закрыть доступ к административной панели для всех IP, кроме конкретных.
Все вышеперечисленные способы не могут дать 100% гарантии безопасности, однако их соблюдение существенно снижает возможность неправомерного доступа к информации.
Рекомендации
Запускать программы-сервера с ограниченными правами;
Преобразовывать введённые данные, если параметры заранее известны;
Использовать хранимые процедуры в SQL;
Скрывать модель CMS;
Скрывать модель WEB-сервера;
Привязывать некоторые ресурсы к конкретным IP;
Задача переноса сайта
В общем случае, сайт содержит структуру, расположенную на сервере, и БД. Рассмотрим общий универсальный алгоритм переноса:
Кэши требуется очищать для того, чтобы не применялись старые параметры.
Если на новом хостинге предоставляется возможность настройки параметров БД, а также создания и настройки новых пользователей, то можно настроить параметры работы с БД, идентичные тем, что были на старом хостинге. Так же, некоторые WEB-адреса и пути уровня файловой системы, могут быть записаны в БД сайта. Их так же необходимо переписать в соответствии с параметрами нового хостинга.
Данный способ универсален для различных технологий (серверных языков, CMS и так далее). Однако, в некоторых CMS имеются средства, которые позволяют облегчить данную задачу. Например, в CMS MODx можно выполнить следующее: перенести таблицы из старой БД в новую, скопировать файловую структуру сайта на новый хостинг, а потом скопировать в корень перенесённого сайта стандартный установщик MODx. Запустить установку MODx через скопированный установщик и выполнить обновление сайта, прописав параметры, в соответствии с теми, которые должны быть на новом хостинге. Установщик MODx сам перепишет все конфигурационные файлы теми настройками, которые будут заданы при обновлении. Остальная структура сайта и таблицы с записями в БД останутся нетронутыми. Однако, даже при этом способе требуется очистка кэшей, и перезапись путей в самой БД (если есть).
Рекомендации
Сохранять полный архив файловой структуры сайта и его БД до конца переноса;
По возможности, не менять кодировки;
Учитывать регистр клавиатуры при изменении путей к файлам;
Задача адаптации произвольной вёрстки к различным CMS
Некоторые CMS (например, MODx) могут содержать встроенные средства для создания и адаптации любой произвольной вёрстки, плагинов и так далее. Общий алгоритм этих операций в MODx описан в разделе “Преимущества и недостатки MODx”. Однако, в некоторых CMSможет вообще не быть средств для адаптации собственного кода (например в WiX), а в некоторых – эти возможности присутствуют частично (например в Joomla, WordPress и большинстве других CMS)[2].
Общий принцип работы шаблона заключается в том, что в конкретной его секции вызывается нужная функция серверной части сайта, отвечающая за вывод определённой информации. Далее, как правило, эта функция делает запрос к БД, получает нужную информацию, а после – вставляет возвращённые значения в ответную HTML-страницу. Динамически меняется только контент страницы, а сама вёрстка – является статичной частью, поэтому вставив соответствующие функции в любой HTML-шаблон, можно получить шаблон для конкретной CMS.
Рассмотрим пример. Допустим, есть произвольный шаблон, в котором в качестве имени страницы указано “шаблон”. В html коде это выглядит так:
… - недостающий код. Допустим шаблон предполагается адаптировать для использования в WordPress. В заголовке требуется вывести имя сайта. За выведение названия сайта в WordPress отвечает функция bloginfo. В этом случае, код будет выгладить следующим образом:
Теперь, вместо статичного текста, в качестве заголовка будет выводиться указанное название сайта[6]. Аналогичным образом нужно переделать остальные секции шаблона[3].
Так как в различных темах могут вызываться разные функции CMS, а также добавляться свои, вписывающиеся в правила конкретной CMS, то для адаптации своего шаблона на начальных этапах лучше взять наиболее простой готовый шаблон. Создать страницу, использующей этот шаблон. Посмотреть код, который сформировался на стороне клиента. Это позволит вычислить, в каких секциях шаблона выводится конкретная информация (например, логотип шапки сайта или контент). После этого нужно просмотреть файлы переделываемой темы и найти в них соответствующие HTML-секции. Это позволит вычислить названия функций, отвечающих за вывод конкретной информации, а также передаваемые в них параметры. Далее можно изменить имена селекторов и расположения секций, в соответствии со стилями адаптируемой вёрстки, либо вставить полученные функции в нужные секции HTML-шаблона.
Этот способ универсален, однако довольно сложен, так как названия блоков и селекторов также могут формироваться динамически, и не всегда быть явно видными в серверных скриптах темы. Так же одни и те же блоки могут дублироваться в различных файлах темы, например для надёжности, или вывода разной информации в зависимости от настройки[4]. Например, в одном и том же месте HTML документа может выводиться название или логотип сайта, в зависимости от того, что выбрал пользователь. Функции отвечающие за их вывод могут находиться в разных файлах.
Рекомендации
Алгоритм получения HTML-шаблона из страниц произвольных сайта или шаблонов различных CMS описан в пункте “преимущества и недостатки MODx”. Данный алгоритм универсален, так как браузер не интерпретирует серверную часть, а HTML, CSS и JavaScript, которые генерируются динамически при помощи серверных языков или передаются в готовом виде, для последующий обработки браузером - одинаковы. Языки клиентской части не зависят от того, при помощи какой технологии был получен код на них. Однако, для конкретной страницы могут быть сгенерированы не все блоки вёрстки, например, в шаблоне есть слайдер, а на конкретной странице он отключён, и сервер не сгенерирует его код в ответной клиентской странице. Поэтому, для полноценного получения вёрстки с произвольного сайта необходимо просмотреть как можно больше его страниц, вытащив максимальное число элементов шаблона. Так же, при генерации конкретной страницы могут подключаться стили и скрипты для других элементов сайта, которые не нужны для всей вёрстки в целом. При переносе вёрстки с произвольного сайта, лучше скопировать все дополнительные файлы, ссылки на которые есть в ответной странице. После того, как все файлы подключены корректно, можно преступать к выявлению и последующему удалению ненужных элементов.
Задача унификации и оптимизации вёрстки
Одной из основных проблем при разработке WEB-сайтов является – плохая кроссбраузерность. Зачастую, она может возникать не только из-за того, что некоторые браузеры по-разному понимают определённые правила CSS, но и из-за неоднозначного задания этих правил, а также из-за использования нежелательных конструкций. Наиболее часто встречающийся проблемой вёрстки является – смешение разметки со стилями. После того, как появился язык стилевого оформления CSS (Cascade Style Sheet), стало нежелательным писать стилевые свойства в качестве атрибутов для тегов HTML-разметки. Одним из примеров такой конструкции является
Также нежелательным является использование стилевых тегов HTML, таких как
и т.д. Наиболее правильным способом является чёткое разграничение стилей, разметки и скриптов. Во-первых, для того, чтобы не запутаться в сложных проектах с большим количеством кода, во-вторых, потому что браузеры чаще интерпретируют эти правила по-разному. Например, вышеупомянутая конструкция
может отобразиться как таблица с границей разных цветов, сплошной или пунктирной, а может и вообще отобразиться без границ. Для того, чтобы объединять стилевыми правилами конкретную группу элементов (например, ссылки или изображения, относящиеся к конкретной секции шаблона) в CSS существуют классы и идентификаторы. Но даже если стиль необходимо задать конкретному элементу, не создавая для него класса (для упрощения или исключения), правильным заданием стиля будет написание атрибута “style” внутри конкретного тега, а уже в нём – написание стилевых правил.
Пример правильной конструкции:
Пример неправильной конструкции:
Несмотря на то, что в правильном примере, стили заданы прямо в теге, это не является нежелательной конструкцией, так как все атрибуты, находящиеся внутри “style”, интерпретируются по обычным правилам CSS, таким образом стили и разметка разделены. Неправильный пример использует устаревшую конструкцию задания стилевых атрибутов непосредственно в теге. Вот ещё один пример, но уже с использование нежелательных тегов:
А вот – правильный эквивалент:
Все вышеупомянутые неверные примеры, в которых используется смешение стилей и разметки, были актуальны во времена, когда не было CSS, и функцию стилей также брал на себя HTML. Стилевые возможности HTML - менее гибкие, чем у CSS и оставлены только для большей совместимости и постепенного обновления сайтов. Их использование приводит к плохой кроссбраузерности и неоднозначной интерпретации. Интерпретация стилевых правил происходит по следующим приоритетам:
Ещё может возникнуть необходимость использования тегов не по прямому назначению. Например, для создания расписной рамки (границы) у фото или слайдера. Несмотря на то, что в CSS 3 появилась возможность создания рисованных рамок, путём применения свойства “border-image”, рамка может иметь непериодический орнамент, что не даёт возможности отобразить её как череду повторяющихся изображений, а вышеупомянутое свойство работает именно по этому принципу. В таком случае используется свойство “background-image”. Оно поддерживается и в более старых версиях CSS. Для того, чтобы сделать фон рамкой, нужно сделать блок, в котором будет размещено изображение. Высота и ширина изображения в этом блоке должны быть заданы с учётом габаритов рамки).
Также могут возникнуть ситуации, когда требуется нетипичная роль объекта в вёрстке. Например, если у того же фона-рамки есть неровные углы, которые нельзя задать простым закруглением изображения. В этом случае, нужно сделать фон поверх изображения. Для того, чтобы это сделать, в тег <img>, в котором обычно находится само искомое изображение, нужно прописать постоянный путь к рамке, а путь к самому изображению будет прописан в стилевом свойстве “background-image”. Не типичность заключается в том, что фон будет в роли искомого изображения, а само изображение – в роли фона.
Также может возникать проблема отсутствия объектов. Например, если в шаблоне, на определённом месте, был предусмотрен логотип сайта, который предполагался выбираться пользователем. В стилях задана определённая высота и ширина этого логотипа. Но если пользователь не выбрал ничего, а тег присутствует на результирующей странице, то будет значок не загрузившегося изображения. Если же не генерировать на результирующей странице сам тег, то остальные части вёрстки могут сместиться. Для того, чтобы это исправить, требуется поместить изображение в отдельный блок , и задать высоту и ширину не только для изображения, но и для этого блока. Он должен генерироваться в любом случае.
Рекомендации
Заключение
Приложение 1 общий принцип взаимодействия с сайтом в Интернет
Рис. 10 Иерархия работы DNS-серверов
Для того, чтобы снизить нагрузку на DNS-сервера, существуют несколько способов. Во-первых, в большинстве ОС существует файл, в котором содержится локальная таблица соотношения доменных имён с IP-адресами. Например, в Windows – это файл hosts, находящийся по адресу C:WindowsSystem32driversetc (где C: - имя системного диска). Во-вторых, по умолчанию большинство браузеров кешируют IP-адреса сайтов, и при следующем обращении смотрят туда. Общая схема приоритетов следующая: при обращении к сайту смотрятся адреса из кэша браузера, если есть нужный адрес, запрос отправляется по нему, если нет – смотрится файл с локальной DNS-таблицей (например – hosts), если нужного адреса нет и там, запрос отправляется по цепочке DNS-серверов.
У данного подхода есть несколько минусов. Во-первых, если в кэше браузера, или в локальном файле DNS-таблиц присутствует адрес сайта, который уже не актуален, то компьютер не будет посылать запрос на новый адрес с этим доменным именем, а будет ошибочно попадать на ненужный ресурс. Этот принцип используется и в некоторых вредоносных программах. Например, для блокировки социальных сетей или других сайтов. Так же вредоносное ПО может прописать адрес сайта-имитатора, например, крадущего данные при авторизации. Пользователь будет набирать верное доменное имя, и ничего не подозревая попадать не туда. Для того, чтобы этого избежать, можно создать в браузере несколько закладок, с часто посещаемыми сайтами, указав в прямую их IP-адреса. В таком случае компьютер не будет ничего соотносить, а сразу отправит запрос в нужное место. Узнать IP адреса сайтов можно, например на сайте 2ip.ru.
Приложение 2 . Рекомендации по выбору и настройке локальной среды
Рецензии:
24.06.2016, 21:13 Эрштейн Леонид Борисович
Рецензия: Несмотря на то, что общие рекомендации в статье отсутствуют и не ясна научная новизна, точнее ее нет, я считаю, что статью можно публиковать после следующих доработок.1. Привести сравнительную таблицу рассмотренных движков. 2. Указать тип лицензии этих движков. Тогда станет ясен вклад авторов. Но статья хорошая и работа проделана большая.