Мы будем Вам признательны, если Вы поддержите проект Open SLAED и используя Ваши возможности, разместите наш пресс-релиз на страницах своих сайтов, проектов, форумов, блогов. Текст пресс-релиза, возможно, видоизменить под Ваш формат, не искажая смысл. Пресс-релиз можно взять на данной странице.
На первый взгляд домен с приставкой www и без неё является одинаковым, на самом деле это не так. Сервером они инициируются как два разных домена и, как правило, на них можно установить два совершенно разных сайта. У некоторых хостеров слияние двух доменов предусмотрено изначально и производится автоматически, у некоторых данная настройка существует в панели управления хостингом, для хостингов у которых слияние не предусмотрено можно воспользоваться следующим методом.
1. Войдите в панель управления системой, отдел: Панель администратора >> Редактор
2. В файле конфигураций правил преобразований ЧПУ на серверном уровне: .htaccess
После:
Добавьте следующую запись:
Заместо: slaed укажите своё имя домена.
Заместо: net укажите своё окончание домена.
Для работы данного метода, сервер Вашего хостера должен поддерживать работу с .htaccess, Mod Rewrite должен быть установлен и активирован.
При использовании русской кодировки базы данных возможна не корректная работа системы с ней, на это есть ряд причин, как правило, конфигурации сервера. Для решения этой проблемы, необходимо принудительное подключение работы класса базы данных, для этого в файле системы: function/mysql.php в самом конце добавьте следующий код.
Вариант второй
Скорее всего, вы неправильно утановили дамп базы данных. Для того, чтобы правильно установить дамп, войдите в свою контрольную панель phpMyAdmin. В выпадающем списке «Сопоставление соединения с MySQL» выберите пункт utf8_general_ci. Затем выберите свою базу данных в левой части страницы и перейдите на вкладку «Операции». На открывшейся странице в выпадающем списке «Сравнение» выберите пункт cp1251_general_ci. Теперь при загрузке файла с базой данных (который, как правило, имеет расширение .sql) не забудьте выбрать в соответствующем выпадающем списке кодировку cp1251, и проблема должна исчезнуть.
В данном случае системой предусмотрено два варианта восстановления и сохранения базы данных.
Вариант первый
Войти в «Панель администратора», далее в блоке «DB Backup». После этого Вам необходимо ввести логин и пароль для базы данных. После успешного входа Вы можете сделать резервную копию базы данных или произвести её восстановление из копии сделанной до этого.
Вариант второй
Если нет возможности входа в панель администратора, системой предусмотрен прямой доступ к модулю сохранения или восстановления базы данных.
Введите в адресной строке Вашего браузера: http://www.ваш_сайт.com/modules/dumper/index.php
После этого Вам необходимо ввести логин и пароль для базы данных. После успешного входа Вы можете сделать резервную копию базы данных или произвести её восстановление из копии сделанной до этого.
Блоки вывода Лучших новостей с показом количества просмотров.
block-Top_News.php - Текстовой блок лучших новостей.
По умолчанию выводит 10 лучших новостей с ссылкой
на новость и показывает количество просмотров.
Есть в архиве почти такой же. Разница - я переделал
его под Slaed 2.1 Lite Final и добавил вывод просмотров.
block-Top_News_Jpg.php - Блок лучших новостей с выводом
картинок к новостям. По умолчанию показывает 10 лучших
новостей с выводом картинок к ним, а также ссылки на
сами новости и показывает количество просмотров.
Переделаный первый блок с выводом картинок.
В архиве 2 файла (block-Byn.php и block-Interesnoe.php). Первый блок выводит новости в виде текста, а второй в виде новостей с картинками. Второй блок нужно ставить По центру внизу.
У тебя появилась интересная идея? Хочешь поделиться её с окружающими и узнать их мнение? Тогда регистрируйся на сайте, размещай публичную идею.
Твоя идея еще не готова к огласке? Ты придумал что то интересное, но опасаешься, что твою идею присвоит кто то другой? Тогда создавай скрытую идею. Её не сможет увидеть ни кто, кроме тебя. Когда будешь готов, меняй статус своей идеи на публичную.
Обрати внимание, дата внесения идеи фиксируется сайтом, ты в любой момент сможешь доказать своим друзьям, что именно ты первый придумал...
Ты пока еще ничего не придумал? Тогда учавствуй в обсуждении идей других людей, голосуй в опросах, общайся!
Trumpet-Club.Org - первый в РУнете о трубе и корнете. Российский портал трубачей, на котором можно пообщаться с коллегами на форуме, послушать музыку, скачать ноты, узнать много нового о трубе и игре на ней и получить необходимую информацию о предстоящих конкурсах, концертах и мастер-классах.
На фоне стремительно растущего числа каталогов, заблокированных поисковыми системами, веб-мастера все больше внимания стали уделять прямому и перекрёстному обмену ссылками. Еще вчера твой сайт после прогона по белым каталогам имел ИЦ равный 500 и более 1000 обратных ссылок, а сегодня Яндекс устроил новую чистку. И сайт двукратно снизил свои показатели. Как следствие, резкое снижение позиций в выдаче поисковых систем по большинству среднечастотных и низкочастотных запросов. Подобные чистки линкопомоек, называемых зачастую белыми каталогами, теперь не редкость. Но у «бедного» веб-мастера все же остается основной инструмент повышения видимости сайта – обмен ссылками.
Ах, как хочется меняться...
Большинство веб-мастеров готовы произвести тематический обмен ссылками, но каждый из них в отдельности за то, чтобы ссылка на свой сайт стояла, а ответная со временем исчезла. Для целей SEO это прекрасный ход. Пусть на тебя ссылаются, а ты ни на кого ссылаться не будешь. Безусловно, такое положение вещей оценят поисковые системы. Но как это сделать? Обмануть своего партнера по обмену!
В Интернете есть немало веб-мастеров, готовых пойти на обман своих партнеров по обмену в ущерб своей деловой репутации. А всегда ли известно, чей это сайт и какие еще сайты есть у вашего партнера? Не слукавлю, если предположу, что многие веб-мастера держат «серенькие» и «временные» проекты, которые готовы продвигать любыми методами. Для достижения целей продвижения они не гнушаются способами обмана своих партнеров.
Способ первый – топорный.
Ты создаешь статический каталог в чистом HTML коде, куда и вносишь ссылки партнеров по обмену. По мере поступления новых ссылок по обмену, удаляешь старые. Представь, что за десять месяцев ты обменялся ссылками с тысячей сайтов. Но в свой каталог ты вносишь только те ссылки, которые поступили не позже двух месяцев назад. Остальные ты просто замещаешь новыми. Таким образом, на тебя ссылается тысяча сайтов, а ты оставил ссылки всего на двести сайтов – поступившие за два последних месяца. Минус такого обмена в нестабильности твоих ссылок. Ты не можешь быть уверен, что владелец сайта, где находится твоя ссылка, не поступит аналогично. Больше шансов, что он тоже удалит старые ссылки из каталога, включая твою.
Способ второй – методический.
Ты создаешь статический или динамический каталог и начинаешь активный обмен ссылками. Каждые три-шесть месяцев ты полностью удаляешь весь каталог, создаешь новый и опять занимаешься обменом. Через пару лет твой сайт обрастает некоторым количеством стабильных обратных ссылок, не ссылаясь при этом на другие ресурсы.
Способ третий – наивный.
Ты создаешь небольшой статический каталог, преимущественно из ссылок на свои же проекты. Начинаешь рассылать письма с предложением по обмену ссылками: «Разместите мою ссылку на сайте. В ответ я в течение трех-пяти дней размещу вашу ссылку у себя». И ничего в ответ не размещаешь. Расчет простой. Многие веб-мастера слишком заняты, чтобы контролировать каждое обратное размещение. А многие просто не делают этого совсем или забывают про некоторые ссылки. В общем, можешь рассчитывать, что 5%-15% ресурсов так и оставят твою ссылку у себя. Если постоянно и активно заниматься таким обменом, то твой сайт будет достаточно стабильно держаться в видимости поисковиков. Кроме того, мои наблюдения показывают, что появление твоей ссылки на новых сайтах прибавляет ценности ресурсу. Даже в том случае, если позже ссылка на твой сайт исчезает.
Способ четвёртый – прогрессивный.
Чтобы обезопасить себя от нечестного обмена, веб-мастера устанавливают каталоги, чьи скрипты способны контролировать размещение обратной ссылки. Контроль ведется как на этапе добавления новой ссылки, так и с помощью последующего сканирования твоих страниц на наличие ответной ссылки. Уже создано большое количество коробочных версий программ управления обменными каталогами. Если ты хочешь добавить свою ссылку в такой каталог, то предварительно должен разместить обратную ссылку у себя и указать точный URL, где она размещена. Размещение обратной ссылки периодически контролируется. Программа скачивает указанный тобой URL, проверяет его на видимость поисковыми системами и наличие кода ссылки. Если все в порядке, то твоя ссылка публикуется в каталоге. Но что стоит обмануть глупого робота?
Приступаем к прогрессивному обмену. Пишем или заказываем скрипт на PHP или CGI, который умеет подменять содержание страниц, основываясь на IP, с которого приходит запрос. Получится совершенно несложная программа. Когда робот определенного сайта запросит страницу, где должна быть размещена ссылка на этот сайт, программа определит IP запроса. Если IP соответствует заданному домену, то будет выдана страница с кодом ответной ссылки. Всем же остальным IP будет отдаваться не подменяемая постоянная страница. Нужно только предварительно добавить в программу сведения о том, какому хосту подменять содержание страницы и чем подменять, заранее определив IP сайта с каталогом, куда вы добавили ссылку. Эти функции также можно автоматизировать.
Остаются небольшие опасности, что трюк будет замечен, если программа каталога проверит наличие ответной ссылки по данным Яндекса. Но шансов невероятно мало. Страница хорошо индексируется поисковыми системами, а проверять каждую страницу, где «по мнению» поисковой системы не учтена ответная ссылка, веб-мастер не станет. Тем более, это накладно программными средствами с нынешней политикой поисковых систем и нереально вручную, если вы добавили ссылку в крупный обменный каталог.
В заключение хочется добавить, что я перечислил далеко не все способы обмана при обмене ссылками. Их может быть намного больше. Указанные мной способы активно используют неблагонадёжные партнеры. А четвёртый способ в последнее время встречается все чаще. Будь внимательнее при выборе партнёров. Не позволяй себя обмануть.
ЧПУ - термин, принятый среди веб-разработчиков для обозначения WWW-адресов, удобных для восприятия человеком (а также систем и методов построения таких адресов), является аббревиатурой от словосочетания «человекопонятный урл» («урл» - жаргонное для URL). С развитием и ростом Интернета ситуации, когда веб-сайт содержит страницы с очень длинными и трудночитаемыми адресами, стали реальной проблемой. Адрес вроде http://www.slaed.net/index.php?ext=83465&p1=some&p2=some крайне сложно запомнить или, скажем, продиктовать по телефону.
ЧПУ предполагает построение адресов по иерархической схеме, очевидной для человека: вместо http://www.slaed.net/index.php?ext=83465&p1=some&p2=some использовать http://www.slaed.net/doc/83465/some/some. При этом удаление части адреса («укорачивание» адреса на некоторое число секций, разделенных слешами) приводит к попаданию на более высокую ступень навигационной иерархии: http://www.slaed.net/doc/83465/ - документ под номером 83465, http://www.slaed.net/doc/ - список всех документов и т.п.
Первый способ
Cоздать для каждой заметки поддиректорию с соответствующим именем и помещать в нее index.html, то есть сделать так, чтобы по адресу http://www.slaed.net/php/user_urls лежал бы реальный файл.
Второй способ
Использование ошибочной страницы. Если страница не существует, то сервер выдает ошибку 404. Так что вторая идея - прописать в фале .htaccess страницу, которая будет выдаваться при ошибке 404, а уже эта страница будет смотреть на текущий УРЛ и выдавать нужный документ
Пользователь набирает http://www.slaed.net/php/user_urls, такая страница не найдена, и загружается файл index.php. Дальше - все просто. Переменная $REQUEST_URI дает нам адрес вызываемой страницы (в данном случае это будет /php/user_urls), вывести на экран соответствующий документ - дело техники.
Этого мало. В некоторых браузерах и с поисковиками такой фокус не пройдет: страница 404 будет выдавать соответствующий код, и страницы индексироваться не будут. Поэтому надо, чтобы страница, которая грузится в случае ошибки 404, изменяла бы код ошибки и сигналила, мол, все ОК, есть такая страница: <?php header("http/1.0 200 Ok"); ?>
Итого: прописываем в .htaccess страницу, которая, собственно, за все отвечает (у нас это index.php). В этой странице пишем php-скрипт, который работает с $REQUEST_URI, шлет заголовок «http/1.0 200 Ok» и отображает то, что надо.
Плюсы: Очень простой способ. Работает почти везде.
Минусы: При таком способе нельзя постить содержимое формы на несуществующие псевдоурлы. И если в Апаче ведется лог 404-ых ошибок, то он будет забит.
Третий способ
Основан на директиве FilesMatch, которая в Апаче является core feature. Все просто. Пишем опять же в .htaccess
После этого все УРЛы, которые подпадают под условие «^([^.]+)$», (то есть все урлы, в которых не содержится точка) будут передаваться на index.php. Вы можете написать свое условие, разумеется.
Плюсы: Простой и удобный способ.
Минусы: Говорят, что для того, чтобы ForceType работал, php должен быть подключен к апачу в виде модуля. Если php вызывается, как обыкновенный CGI — ForceType работать не будет.
Четвёртый способ
Для этих (и не только) целей есть специальный модуль в Апаче, который называется mod_rewrite. Он позволяет «переписывывать урлы», то есть, преобразовывать их «на лету» по правилам, которые вы ему опишите.
Это очень мощный модуль, и если вы в нем разберетесь, то сможете творить чудеса.
Плюсы: Очень мощный способ.
Минусы: Может не хватить мозгов. На хостинге может быть не установлен этот модуль.
Все, изложенное мной, является плодом более чем 3-летнего опыта в области оптимизации сайтов и практических наблюдений. Таким образом, мои рекомендации будут носить в большей степени субъективный практический характер, чем теоретический. Сразу предупреждаю, что все мои советы актуальны для владельцев серьезных тематических ресурсов, а не всяких дурацких развлекательных порталов, цель которых – привлечь абы кого, чтобы только заработать баннерные показы или накрутить счетчик.
Продвижение сайта - Заголовки
Итак, я открываю серию статей, посвященных продвижению интернет-сайта в сети. Все, изложенное мной, является плодом более чем 3-летнего опыта в области оптимизации сайтов и практических наблюдений. Таким образом, мои рекомендации будут носить в большей степени субъективный практический характер, чем теоретический. В моих статьях я не буду тратить время на всякие системы накрутки счетчиков, обмена посетителями и прочую подобную фигню. Продвижение в моем случае прежде всего означает оптимизацию страниц сайта под поисковые роботы + различные советы и тонкости из практики. Надеюсь, вам будет интересно и кому-нибудь мои советы даже помогут в увеличении целевой аудитории, посещающей ваш сайт.
Будем считать, что вы хорошо владеете программированием на HTML и знаете, для чего нужны различные тэги и куда их пихать, поэтому на технической стороне я не буду заострять внимание. Говоря о заголовке, я имею в виду содержание страницы от тэга ‹HEAD› до тэга ‹/HEAD›. Напомню, что структура стандартной страницы представляет из себя примерно следующее:
Как раз о верхней части страницы и пойдет речь в этой статье, т.е. подробно о тегах TITLE и META.
TITLE
Надеюсь, вы уже догадались, что TITLE – это титул страницы. Пользователь видит его в верхней части окна браузера. Тэг TITLE прежде всего имеет важное значение при оптимизации страницы под поисковые машины. Все без исключения поисковые роботы обрабатывают значение TITLE и в соответствии с его содержанием формируют перечень ключевых слов и фраз страницы. Таким образом, титул должен отражать реальное содержание страницы или сайта. Однако при заполнении этого параметра многие совершают следующие ошибки:
Начинают перечислять перечень ключевых слов. Современные поисковые роботы стали гораздо сообразительней, чем раньше и в большинстве случаев им удается распознать, что в титуле написана белиберда, а не четкое и внятное содержание страницы. Это может привести к тому, что поисковик проигнорирует титул при индексации;
Вбивают текст размером с первый том "Капитала" Карла Маркса. Дело в том, что поисковые роботы серьезно относятся к содержимому тэга TITLE, но обычно индексируют первые 25-50 символов. Таким образом, оставшаяся писанина только напрасно увеличивает объем страницы и время загрузки;
Перегружают титул спецсимволами (запятыми, кавычками, тире и пр. знаками). Спецсимволы в TITLE не индексируются поисковыми роботами, так что их использование лучше свести к минимуму, или вообще постараться обойтись без них;
Пишут содержание TITLE прописными (заглавными) буквами. Многие поисковики этого не любят. Так что лучше их не злить понапрасну и писать нормально. От того, что вы напишете титул прописными, заметней для поисковика вы не станете!
В общем, рекомендую перед заполнением тэга TITLE как следует подумать, о чем ваш сайт и выразить его тематику в 2-3 веских словах в виде словосочетания.
META
О тэге META у нас будет разговор серьезный. Прежде всего необходимо понять, что META-тэги являются важной составляющей в странице и их правильное использование может как поднять популярность страницы, так и оказать обратное воздействие.
META-тэги делятся на две группы: контролирующие отображение страницы браузером и служащие ценной информацией для поисковых машин. Первая группа тэгов вводится следующим образом:
‹META HTTP-EQUIV="параметр" CONTENT="значение"›
Я не буду заострять внимание на этом виде META-тэга, т.к. моя задача – рассказать, как сделать страницу доступной, а не как сделать, так, чтобы она правильно отображалась браузером. Но чтобы вы поняли, для чего нужны эти META-тэги, приведу несколько примеров их использования:
Указывает, в какой кодировке должна выводиться страница (в данном случае: windows-1251). Также возможны значения (в поле CHARSET): koi8-r, iso-8859-5, iso-8859-1 и т.д.
Указывает типы переменных, содержащихся на странице (в данном случае: текст и JavaScript™). Возможные значения: text, javascript, php и т.д.
‹META HTTP-EQUIV="pragma" CONTENT="no-cache"›
или
‹META HTTP-EQUIV="no-cache›
или
‹META HTTP-EQUIV="cache-control" CONTENT="no-cache"›
или
‹META HTTP-EQUIV="expires" CONTENT="wed, 2 mar 1996 00:00:05 GMT"›
Запрет на кэширование браузером страницы. Тэг актуален в том случае, если содержимое страницы часто меняется. В этом случае браузер будет при каждом обращении к странице заново ее кэшировать.
Сообщает браузеру язык, на котором написана страница (в данном случае: английский и русский). Возможно указать и один язык (например, только "ru") или несколько через запятую. Сразу скажу, что этот тэг актуален только для очень старых браузеров, а новые на него внимания не обращают, так что лучше его избегать.
Принудительно осуществляет переход на указанную страницу через определенное количество секунд (в данном случае: переход на страницу "http://yandex.ru/index.html" через 5 секунд).
Существует еще с десяток META HTTP-EQUIV тэгов, но, на мой взгляд, они бестолковые и не оказывают существенного влияния на отражение страницы. Или предназначены для устаревших версий браузеров, которые практически уже не используются. Советую не увлекаться такими тэгами и обратить внимание прежде всего на первый пример, выдающий кодировку документа – он является обязательным; остальные же используйте только по необходимости!
Второй тип META-тэгов вводится следующим образом:
‹META NAME="параметр" CONTENT="значение"›
Эти META-тэги никак не влияют на отображение страниц сайта, но играют важную роль в предоставлении информации поисковым роботам и указывают на алгоритм индексирования. В общем, служат чем-то вроде паспорта для страницы. Поскольку известно, что основная доля трафика генерируется поисковыми роботами, необходимо отнестись с полным сурьезом к заполнению значений этих тэгов. Ниже я привожу примеры значений с необходимыми комментариями:
‹META NAME="description" CONTENT="..."›
В поле CONTENT вы должны ввести краткое описание документа. Ни в коем случае не строчите трактат длинной в жизнь и не перечисляйте ключевые слова! Правильным будет написание небольшого предложения длинной до 200-250 символов, в котором повествуется, о чем ваш сайт (страница) и что на нем можно найти. Избегайте большого количества спецсимволов, слов из прописных букв и бессмыслицы (например, "Это чумовой сайт! Все сюда!"). Содержание параметра DESCRIPTION часто отражается в результатах поиска и вносится в базу данных поисковика. Так что чем точнее и лаконичней будет сформулировано описание сайта, тем лучше!
‹META NAME="keywords" CONTENT="..."›
В поле CONTENT вы должны внести через запятую (!) перечень ключевых слов и фраз, в соответствии с которым будет строиться запрос поисковым роботом. Только не надо вносить весь словарь Ожегова и/или Даля! Во-первых, поисковики обычно обрабатывают только первые n-цать символов в строке CONTENT (в среднем до 500). Во-вторых, ключевые слова и фразы должны отражать реальное содержимое страницы. В противном случае поисковый робот отсекает ненужное и часть содержимого KEYWORDS просто зазря засоряет страницу. Существует расхожее мнение, что сейчас поисковые роботы практически не уделяют внимания значению параметра KEYWORDS. Действительно, в процессе эволюции поисковики стали меньше обращать внимания на ключевые слова, потому что многие нехорошие люди занимались банальным поисковым спамом и вносили в KEYWORDS совсем не то, что было отражено на странице. Тем не менее, актуальность этого META-тэга еще до конца не утрачена и заполнять его все-таки рекомендуется.
Сообщает поисковому роботу частоту обновлений содержимого. В соответствии с этим страница может быть статичной (static), т.е. обновления происходят время от времени, редко или совсем не происходят; или динамичной (dynamic), которая обновляется часто (например, страница новостей). В поле CONTENT необходимо записать только одно из значений ("static" или "dynamic"), в соответствии с характером страницы. Некоторые "умники" пытаются обдурить поискового робота, объявляя статичную страницу динамичной, в надежде на то, что ее рейтинг повысится. Поисковик очень быстро вычисляет таких мошенников, отслеживая дату изменения файла страницы и характер изменений ее содержимого. В итоге можно отправиться в бан-лист, из которого путь будет не так прост. Чтобы этого не произошло, постарайтесь либо писать правду, либо вообще не употреблять этот параметр. Без него поисковик тоже в состоянии разобраться, какая эта страница и как часто ее переиндексировать.
‹META NAME="revisit-after" CONTENT="..."›
Тэг почти аналогичен предыдущему и указывает, через какой промежуток времени поисковик должен переиндексировать страницу. Опять-таки лучше не дразнить поискового робота и указывать реальное значение. Если у вас не лента новостей с ежедневным, еженедельным или прочим регулярным обновлением, то лучше этот параметр вообще не использовать. Если все-таки возникла такая необходимость, то значения поля CONTENT могут быть такими: day (пример: 1 day), days (пример: 7 days), week (пример: 1 week), weeks (пример: 2 weeks), year (пример: 1 year), years (пример: 5 years). Выражать промежуток времени можно различными значениями, но только одним из них. Например, 1 год можно записать как "1 year" или "365 days", или "52 weeks". Но недопустимо употребление сразу нескольких значений. Например, "1 year 2 weeks 3 days"!
‹META NAME="robots" CONTENT="..."›
Это очень важный тэг, который указывает поисковику, каким образом ему необходимо индексировать страницу. Возможные значения поля CONTENT:
index, follow – индексировать страницу и все ссылки на ней
index, nofollow – индексировать страницу, не индексировать ссылки
noindex, follow – не индексировать страницу, а только ссылки
noindex, nofollow – не индексировать страницу, не индексировать ссылки
all – равнозначен index, follow
none – равнозначен noindex, nofollow
Если вам все равно, как поисковый робот будет индексировать содержимое страницы, то лучше вообще этот параметр не использовать, т.к. в этом случае поисковик определит наиболее оптимальный и эффективный способ индексации. Если вдруг вам необходимо запретить на индексацию часть содержимого страницы, а другую оставить, то необходимо поместить запрещенный для поисковых роботов блок в тэг ‹NOINDEX›...‹/NOINDEX›. В этом случае META-тэг с параметром "robots" использовать не надо.
Существует еще целая куча META-тэгов подобного вида, всесторонне описывающая содержимое страницы, включая данные о ее создателе, генераторе, классификации и т.п. Отталкиваясь от практического опыта могу заметить, что ничего, кроме, засорения страницы и увеличения ее объема, они по сути не делают. Так что лучше ограничиться использованием вышеуказанных тэгов, которые являются основополагающими.
Итак, мы рассмотрели с вами основные требования к написанию заголовка страниц таким образом, чтобы их успешно и правильно индексировали поисковые роботы. Если вы все сделаете правильно, то уже через некоторое время (от 2 недель до месяца) вы заметите, что поисковые роботы стали лучше вас видеть и посетители стали лучше вас находить. Закрепляя вышесказанное, хочу привести пример, как может выглядеть идеальная для поисковика страница:
‹HTML›‹HEAD›‹TITLE›Справочник по META-тэгам‹/TITLE›
Я встречал много вопросов связанных с интеграцией обычных шаблонов под шаблоны 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 бедующей темы, а остальные части сайта прорабатываете сами.
В этой публикации мы затронем те директивы, которые не успели охватить в предыдущих частях. Эти директивы не поддаются определению на уровне директорий. Это означает то, что вы должны иметь доступ к файлу конфигурации веб сервера Apache (httpd.conf).
Обычно такой доступ имеют пользователи «root» или администратор сервера.
Если вы хотите вести логи всех операций, выполненных с помощью mod_rewrite, можно активировать это с помощью следующей записи:
Эту строку нужно вписать в «Раздел 2: Конфигурация основного сервера» в файле httpd.conf, а не в .htaccess!
Все манипуляции, произведенные mod_rewrite будут записываться в этот файл. Имя лог файла может быть любым. Вы можете указать абсолютный или относительный (относительно ServerRoot) путь к файлу.
Если вы хотите вести разные лог файлы для различных виртуальных хостов, то нужно ввести изменения в «Раздел 3: Виртуальные сервера», например так:
RewriteLogLevel может быть определен в пределах диапазона от 1 до 8. Обычно достаточно первого уровня. Более высокие уровни используются для деббагинга.
Другая директива, которая является очень удобной в целях клоакинга – это так называемая карта перезаписи. Это – файлы, содержащие пары ключ/значение, обычно в формате текстового файла:
Ключи, как вы видите, имена хостов или IP адреса. В этом простеньком примере значение всегда одно – «spider». Естественно, в реальном файле значения будут другие. Эта директива может быть записана в второй («Конфигурация основного сервера») или третий («Виртуальные сервера») раздел файла httpd.conf:
«Карта перезаписи» возымеет эффект на весь сервер.
Также, в файл .htaccess записывается:
Данные условия будут производить системную проверку: произведен ли запрос поисковиком. С этой целью производится поиск по файлу spiderspy.txt. Если ключ найден, будет возвращено значение «spider», а «условие» будет являться истинным.
Затем выполняется первый RewriteRule. Это означает то, что запрашиваемая «.htm» страница будет отдана поисковику. Переменная $1 равна части в круглых скобках «^(. *).htm$», то есть имя файла останется тем же самым.
Если же URL вызван обычным посетителем, то применяется второе «правило»: пользователь будет перенаправлен на страницу «index.html».
Поскольку «.htm» страницы будут читаться только «пауками», они могут быть оптимизированы соответственно для поисковых серверов. Вы можете также использовать файл в формате «dbm» вместо обычного текстового файла. Бинарный формат данных позволяет ускорить поиск, который является особенно важным, если вы работаете с очень большими списками поисковиков. Пример, данный выше, предлагает простые функциональные возможности клоакинга. Все обычные посетители будут всегда переадресовываться к странице «index.html» и не будет вестись никаких логов файлов вне логов mod_rewrite.
Можно заменить несколько строчек кода php (perl и т.д.) в ваших приложениях, используя всего одну-две строки mod_rewrite. Последний пример проиллюстрирует это более подробно.
Цель – показать посетителям «фото дня». Посетитель, кликнувший по ссылке http://yoursite.com/pic.html увидит лучшую фотографию или картинку дня, и так каждый день. Мы будем работать с серверными переменными: TIME_MON, TIME_DAY
Поместим в файл .htaccess одну единственную строку:
Запрашиваемый URL будет перезаписан, например: pic-08-28.html, pic-08-29.html, pic-08-30.html и так далее.
Теперь, все что вы должны сделать – это единожды загрузить файлы с соответсвующими именами и забыть о ежедневном обновлении ссылки. Переменные времени также могут использоваться для другой периодичности.
Это был последний пример в серии публикаций о замечательном модуле mod_rewrite. Естественно невозможно было затронуть все нюансы, директивы, переменные и т.д. в данной публикации, целью было другое – дать общее представление и понимание основ, и так сказать «ввести в курс дела».
В двух предыдущих частях мы познакомились с основами «правил перезаписи» 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!
Вы наверняка встречали в сети термин «mod_rewrite». Для наших читателей, которые не до конца знакомы с этим модулем веб сервера Apache, а также для тех, кто вообще первый раз об этом слышит – постараюсь рассказать в этой публикации (в нескольких частях) подробнее о данном модуле.
Модуль mod_rewrite является программным модулем веб сервера Apache (обратите внимание, что он не будет выполняться под другими веб серверами!). Его первичная функция - манипуляция действий с URL. Модуль очень универсален и разносторонен, поэтому я постараюсь показать здесь множество реальных примеров.
Mod_rewrite является замечательным модулем, который предоставляет «основанный на правилах механизм динамического изменения запрашиваемых URL-ов». Это действительно мощный инструмент, и поэтому, его знание принципиально важно, если вы хотите стать подлинным веб мастером или веб программистом. Не столько принципиально, будете ли вы использовать его в своей работе, сколько важно то, что вы знаете, что он может делать, и сможете поведать об этом своему боссу, когда появится желание сделать что-нибудь странное с веб сервером.
Однако нужно быть очень осторожным и даже дотошным при работе с этим модулем! Некоторые ошибки, которые Вы способны допустить, могут привести к логической петле, причиняя непрекращающуюся 100%-ую загрузку ценрального процессора (CPU).
Чтобы не казаться пространным в рассуждениях, приведу некоторые очень простые примеры.
Прежде, чем мы сможем приступить к работе, Вы должны будете проверить, установлен ли модуль на вашем веб сервере или нет.
Есть несколько способов проверить это:
1. Спросить вашего системного администратора - знает ли он (или она) о наличии этого модуля на веб сервере. Они действительно должны знать, но как показывает практика – попадаются и не очень сведующие сисадмины ...
2. Не напрягайте других: если Вы используете ваш веб сервер с сотнями других доменов, ваши действия могут разбудить некоторых спящих собак, поскольку использование mod_rewrite будет всегда влечь за собой некоторую увеличенную загрузку ценрального процессора.
3. Проверить ваш файл конфигурации Apache (httpd.conf), если Вы имеете к нему доступ. Один из возможных стандартных путей может быть: /etc/httpd/httpd.conf
Однако, ваш путь может очевидно отличаться от этого. Проверить работу вашего сервера с ниже приведенными примерами. Если сервер работает без ошибок – mod_rewrite действительно установлен на вашей системе. Если нет, Вы получите следующее сообщение при запросе любой web-страницы с вашего сервера: «Внутренняя ошибка сервера» Также, Вы увидите такую запись в файле «error.log»: «Invalid command 'RewriteEngine', perhaps mis-spelled or defined by a module not included in the server configuration».
Теперь давайте копнем поглубже и посмотрим первый практический примерчик.
Предположим, что Вы будете использовать mod_rewrite только для вашего собственного сайта, то есть не как обобщенную перекрестную установку сервера.
Для нашего примера потребуется использование файла .htaccess. Для работы этого метода, Вы должны загрузить файл под названием «.htaccess» (пожалуйста, обратите внимание на точку в начале имени файла!) в папку сервера, с которой Вы будете работать. Это можно сделать через telnet или ftp. (Предупреждение: .htaccess должен быть загружен в «режиме ASCII», то есть не в бинарном режиме!)
Если у Вас уже имеется файл «.htaccess», например со следующими записями:
то просто добавьте снизу наш образец кода к уже существующему (Важно: редактируйте ваш файл .htaccess в ASCII-редакторе типа Notepad).
Первые две записи запустят сам модуль:
Совет: запись «RewriteEngine off» отменит все последующие команды. Это - очень полезная особенность: вместо необходимости комментировать все последующие строки – все, что Вы должны сделать, это установить «off».
Если ваш системный администратор запрещает Вам использование «Options +FollowSymlinks», Вы не сможете ограничить использование mod_rewrite для отдельных каталогов, вместо этого изменения будут действовать на весь сервер.
Следующая необходимая запись - это:
«/» является корневым (основным) URL. Если у Вас какой-то другой URL, Вы можете указать это в данной директиве, однако «/» – обычно эквивалентно адресу «http://домен.ру».
А теперь, господа, перейдем к более интересным записям!
Предположим, что вы хотите защитить от несанкционированного доступа ваш файл .htaccess. На некоторых серверах Вы можете легко читать этот файл просто вводя URL следующего формата в поле адреса вашего браузера: http://www.domain.com/.htaccess – серьезное упущение защиты, так как содержание вашего .htaccess может показать важную информацию об установках и настройках вашего сайта человеку, знающему как эти знания применить против вас.
Чтобы блокировать этот доступ, запишем следующее:
Это правило переводится так:
Если кто-то пробует обращаться к файлу .htaccess, система должна произвести код ошибки «HTTP response of 403» или «403 Forbidden - You don't have permission to access /.htaccess on this server».
Конструкция ^.htaccess$ в этом регулярном выражении означает:
^ – якорь начала строки
$ – якорь конца строки
. – в регулярных выражениях точка «.» обозначает мета-символ и должна быть защищена обратным слэшем (backslash), если Вы все-таки хотите использовать именно фактическую точку.
Имя файла должно быть расположено точно между начальным и конечным якорем. Это будет гарантировать то, что только это определенное имя файла и никакое другое, сгенерирует код ошибки.
[F] – специальный «запрещающий» флажок (forbidden).
В этом примере, файл ".htaccess" теперь будет состоять из таких строк:
Если мы добавим наш код (в примерах) к существовавшему ранее файлу «.htaccess», то получим следующую конструкцию:
Это введение затрагивает лишь основы, требуемые для того, чтобы работать с модулем mod_rewrite. Во второй части этой обучающей серии статей постараюсь объяснить использование различных условий в конфигурировании модуля.
Ссылка по теме: URL Rewriting Engine
Автор статьи: Denveroid
Источник: sitemaker.ru
Просто мой первый скин :) Нарисовать логотип фантазии не хватило, так что рисуйте сами что хотите.
