Мы будем Вам признательны, если Вы поддержите проект Open SLAED и используя Ваши возможности, разместите наш пресс-релиз на страницах своих сайтов, проектов, форумов, блогов. Текст пресс-релиза, возможно, видоизменить под Ваш формат, не искажая смысл. Пресс-релиз можно взять на данной странице.
Я встречал много вопросов связанных с интеграцией обычных шаблонов под шаблоны SLAED CMS. У многих нету ни денег, ни опыта. В бесплатной помощи отказываю, в результате чего все плохие, никто не помогает. Для создания шаблонов последних версий SLAED CMS требуются только знания HTML и CSS. Нестандартный шаблон можно сделать и без внутренних изменений системы, т.е. без вмешательства php, для этого существуют переменные в шаблонизаторе системы
Если внимательно прочитать слова Гроссмана "Сложные проблемы всегда имеют простые, легкие для понимания неправильные решения", то можно понять, что на первый взгляд это всё трудно, но поняв сутьсмысл это можно будет щелкать как орешки. Вернемся к самой статье. Лично я выделяю два вида интеграций: 1 - внедрение в стандартную тему (интеграция на существующую тему), 2 - преобразование HTML (интеграция с нуля).
Очень важную роль играет то, какой шаблон Вы выбрали. Не каждый шаблон можно интегрировать без головные боли. Некоторые авторы шаблонов создают их так, что они не пригодны даже даже для использования их как обычных HTML шаблонов без полной смены структуры.
Когда Вы подобрали HTML, выбираем наиболее доступные для Вас способ интеграции:
Внедрение в стандартную тему (интеграция на существующую тему)
Этот способ включает в себя замены в стандартной темы index.html, и доработкой в style.css, ну а так же где потребуется в остальных файлах .html чтобы придать законченный вид шаблону.
1) Для начала нужно проанализировать структуру HTML шаблона.
2) Далее пожалуй самый сложный этап: из шаблона нужно удалить так называемое лишние (java-срипты, коментарии, лищние рисунки), при этому не нарушая структуру сайта, что является очень частой ошибкой начинающих, в результате чего итоговый templates будет кривой (не правильная структура сайта).
3) Заменяем index.html в стандартном шаблоне SLAED CMS (Default)
4) Включаем страницу и видим «Daring copyrights of system, you break the license of use!». Не надо пугаться, на данном этапе так и должно быть.
5) Изменяем путь до изображений. Перед изображением вписывает такой путь: "/templates/$ThemeSel/images/"
6) Слудующий этап будет заключаться в внедрении переменных. index.html должно содержать следующие: {%HEAD%}, {%BLOCKS left%}, {%BLOCKS message%}, {%BLOCKS center%}, {%MODULE%}, {%BLOCKS down%}, {%BLOCKS foot%}, {%BLOCKS time%}, {%LICENSE%}, {%BLOCKS variables%}, {%BLOCKS query%}.
7) Подстраиваем остальные .html файлы под дизайн.
8) Самым последнем моментом ювелирная работа с style.css (кстати часть style.css можно вырвать из <head> начального HTML шаблона)
Преобразование HTML (интеграция с нуля)
Этот вид более трудоемкий и требует больших знаний. Но он даст Вам желаемый результат. Как говорится «Без труда, не вытащишь и рыбку из пруда». Суть этого вида заключается в том, что Вы практически «создаете» тему. Если быть точнее то Вы вставляете код шаблона в index.html бедующей темы, а остальные части сайта прорабатываете сами.
В двух предыдущих частях мы познакомились с основами «правил перезаписи» URL и «условиями правил». Позвольте предложить к рассмотрению два примера, иллюстрирующих более сложные приложения. Первый пример имеет дело с динамическими страницами, а второй показывает возможности вызова «.txt» файлов и произведение различных действий над ними.
Предположим, что у нас есть виртуальный магазин по продаже каких-то товаров. Клиенты обращаются к описаниям товаров через скрипт:
Эти адреса представлены как ссылки на большинстве страниц сайта.
А теперь допустим, что вы решили добавить сайт для индексации в поисковые системы. Тут вас поджидает небольшая неприятность – не все поисковики принимают, понимают и индексируют URL, в которых содержится символ «?».
Более естественным и приемлемым для поисковика является URL вида:
http://www.yoursite.com/cgi-bin/shop.cgi/product1
В данном случае символ «?» заменяется на «/».
Еще более комфортабельный URL с точки зрения поисковика будет иметь вид:
http://www.yoursite.com/shop/product1
Для поисковика, «shop» теперь как-бы является директорией, содержащей товары product1, product2 и т.д.
Если пользователь, со страницы результатов запроса в поисковике проследует по такой ссылке, то эта ссылка должна будет трансформироваться в ссылку: shop.cgi?product1.
Чтобы добиться такого эффекта можно использовать mod_rewrite, используя следующую конструкцию в файле .htaccess:
Переменные $1 и $2 составляют так называемые "backreferences". Они связаны с текстовыми группами. Вызываемый URL разбивается на части. Все, что находится перед «shop», плюс все что находится после «shop/» определяется и хранится в этих двух переменных: $1 и $2.
До этого момента, наши примеры использовали «правила» типа:
Однако мы еще не достигли истинной перезаписи URL адресов, в смысле того, что один URL должен перенаправлять посетителя на другой.
Для нашей записи вида:
применяется общий синтаксис: RewriteRule текущийURL перезаписываемыйURL
Как видите, эта директива выполняет действительную «перезапись» URL адреса.
В дополнение к записям в файл .htaccess, нужно еще заменить все ссылки на сайте, которые имеют формат «cgi-bin/shop.cgi?product», на ссылки вида: «shop/product»
Теперь, когда поисковик найдет страницу с подобными ссылками, он проиндексирует сайт без всяких видимых проблем.
Таким образом вы можете превратить чисто динамический сайт в сайт, имеющий статическую структуру, что явно принесет пользу в вопросе индексирования различными посковыми машинами. Обратите внимание на вид URL адресов на данном сайте. Вдобавок ко всему, они имеют еще и легкочитамую для человека структуру - ЧПУ (человекопонятный УРЛ). Но об этом мы поговорим в другой статье.
В нашем втором примере мы обсудим, как переадресовать запросы «.txt» файлов к сценарию программы.
Многие хостинг провайдеры, работающие с Apache предоставляют лог-файлы в общем формате. Это означает то, что они не будут соджержать поля с ссылающимися страницами и юзер-агентами.
Однако, относительно запросов к файлу «robots.txt», предпочтительно иметь доступ ко всем этим данным, чтобы иметь больше информации о посещении поисковиков, чем просто знать их IP адреса. Для того, чтобы оганизовать это, в «.htaccess» должны быть следующие записи:
Теперь при запросе файла «robots.txt» наш RewriteRule переадресует посетителя (робота) к обрабатывающему запросы скрипту text.cgi. Кроме того, переменная передается скрипту, которая будет обработана в соответствии с вашими нуждами. «REQUEST_URI» определяет имя запрашиваемого файла. В данном примере это – «robots.txt». Скрипт прочтет содержание «robots.txt» и отправит его web-браузеру или роботу поискового сервера. Таким образом, мы можем считать хиты посетителей и вести свои лог-файлы.
С этой целью, скрипт будет использовать переменные окружения «$ENV {'HTTP_USER_AGENT'}» и т.д. Это обеспечит получение всей требуемой информации. Вот исходный текст для сценария cgi, упомянутого выше (пример взят с сайта http://fantomaster.com):
Загрузите файл с данным содержимым в корневую или в DocumentRoot директорию сервера и установите права доступа у файлу (chmod) 755. Затем, создайте каталог «stats». Более детальное описание о том, как установить скрипт вы можете получить на сайте разработчика.
Если настройки вашего сервера не позволяют исполнять cgi-сценарии в главной директории (DocumentRoot), то попробуйте следующий вариант:
Обратите внимание, что в этом случае, будет необходимо изменить пути в коде скрипта!
Наконец, вот решение задачки, данной в предыдущей части этой публикации:
Если мы пишем в регулярном выражении «^212.37.64» вместо «^212.37.64.» (с точкой в конце), то даст ли это тот же самый эффект, и будут ли исключены те же самые IP адреса?
Регулярное выражение ^212.37.64 удовлетворяет и применимо к следующим строкам:
Следовательно, последняя цифра «4» может сопровождаться любой символьной строкой. Однако, максимальным значением IP является адрес 255.255.255.255 – который подразумевает, что например 212.37.642.12 – неправильный (недопустимый) IP. Единственный допустимый IP в вышеприведенном списке – 212.37.64.12!
