Быстрый поиск
Введите фрагмент названия статьи для поиска
"Я знаю AJAX, ЧПУ, CMS и много других страшных слов"
28.03.2009 | Категория: Web-мастеру и не только | Автор: ManHunter
Немного перефразированную шутку из названия я часто вспоминаю, когда посещаю многие сайты, популярные и не очень. Web-мастера, начитавшись умных слов и получив в свое распоряжение готовые CMS сайтов и фреймворки, облегчающие разработку, начинают их активно использовать. И в результате очень часто в жертву приносится такая важная составляющая сайтов, как юзабилити. Если единственное, для чего вам нужен сайт - это завешать его порнушными баннерами и поп-апами в три слоя, разместить стыренный контент исключительно на платных файлообменниках, чтобы любыми средствами срубить бабла, то валите отсюда подальше, мне с такими мразями говорить не о чем. Эта статья для немногочисленных web-мастеров, которые стремятся к тому, чтобы на их сайт посетителям хотелось вернуться, чтобы от результатов их труда все получали только удовольствие. Я никого не хочу ни в чем убеждать, но если кто-нибудь после прочтения задумается, значит моя цель достигнута. Мало знать современные технологии, надо уметь их грамотно применять. Вполне возможно, что какие-то вещи будут для вас очевидными, просто наболело :)В современном web-строительстве очень популярно использование так называемых ЧПУ - "человекопонятных УРЛ". Это красивые, интуитивно понятные ссылки, формируемые из названия раздела и статьи. Например:
http://www.site.ru/category/subcategory/article_nameПри обращении к такой ссылке она разбирается средствами сервера на отдельные параметры и дальше обрабатывается как обычная ссылка. Один из основных принципов формирования ЧПУ заключается в том, что при обрезании ссылки до последнего слеша, посетитель должен попадать на вышестоящий раздел сайта. Это хорошо и правильно, но до тех пор, пока в ссылке не начинает присутствовать дата:
http://www.site.ru/2009/01/25/article_nameПо логике вроде бы все правильно: дата добавления статьи, название статьи. При обрезании ссылки до дня получаем все статьи за день, до месяца - за месяц и т.д. Проблема в том, что такая система формирования ссылок хорошо подходит для новостных сайтов, но категорически не годится для основного контента порталов. Информация на новостных сайтах привязана ко дню, когда случилось это событие и после публикации на сайте вряд ли когда изменится. А в популярных портальных движках (названий не указываю, кому надо и так поймет) дата публикации обычно равна дате последнего редактирования статьи, и вот тут начинаются косяки. Реальный случай из жизни: на каком-нибудь сайте выложили какую-то нужную мне информацию. Я зашел на сайт, добавил ссылку в закладки браузера или послал ссылку товарищу в аську. На следующий день пользователь, разместивший статью, отредактировал ее. В результате дата изменилась, ссылка, соответственно, тоже, а сохраненная ранее ссылка становится недействительной. Приходится заново тратить время, искать нужную статью, что никак не добавляет положительного отношения к сайту. Аналогичная ситуация складывается, если идентификация в ЧПУ жестко завязана на полном названии статьи. Удобно? Нет.
Читать статью целиком »
Просмотров: 6219 | Комментариев: 9
Парсер REFERER'ов с поисковых систем
04.02.2009 | Категория: Web-мастеру и не только | Автор: ManHunter
Обработка заголовка HTTP referer является одной из важных задач при раскрутке сайта и сборе статистики. По нему можно определить, какие ресурсы ссылаются на ваш сайт. Но особую ценность представляют данные посещений с поисковых систем, так как эта информация позволяет наиболее четко определить, по каким ключевым словам ваш сайт может быть найден, а также проанализировать эффективность поисковой оптимизации вашего ресурса. Если вы пользуетесь сторонними счетчиками посещений, то эту информацию они обычно предоставляют сами. В некоторых случаях такие данные предоставляют серверные системы статистики типа Webalizer. Я принципиально не пользуюсь ни тем, ни другим, обрабатываю все данные самостоятельно. Для этого была написана функция обработки рефереров, которую я использую в своих проектах. Данные поискового запроса обычно передаются методом GET и содержатся в строке браузера, но основная проблема в том, что кодировка этих данных может быть разной даже в пределах одной и той же поисковой системы. Как выяснилось, не везде доступна штатная функция PHP is_unicode(), поэтому для подстраховки пришлось написать свою. Проверка выполняется согласно правилам формирования Юникода.Code (PHP) : Убрать нумерацию
- // Функция проверки является ли переменная строкой в Юникоде
- // Если штатная функция не определена, то применить нашу
- if (!function_exists('is_unicode')) {
- function is_unicode($str) {
- for ($i=0; $i<strlen($str); $i++) {
- // Если символ с кодом больше 191, то возможно это юникод
- if (ord($str[$i])>191) {
- // Следующий символ должен быть в интервале
- // 10000000b ... 10111111b (128...191)
- if (ord($str[($i+1)])<128 || ord($str[($i+1)])>191) {
- // Условие не выполнено, значит это не юникод
- return false;
- }
- else {
- // Пропускаем один байт, т.к. он является частью символа
- $i++;
- }
- }
- }
- // Проверка пройдена, это юникод
- return true;
- }
- }
Читать статью целиком »
Просмотров: 28761 | Комментариев: 27
Материалы, опубликованные на этом сайте, не рекомендуются к просмотру лицам в возрасте до 16 лет без присутствия взрослых.
Вам помог этот сайт?
Поблагодарили 35,952 раза
Поблагодарили 35,952 раза
Буду очень благодарен, если размеcтите мою кнопочку:
 |
Яндекс ИКС: 360 |
 |
 |