Умный сайт: что мы там последнее читали?.. Закладки на сайте.

Пришла в голову оригинальная идея. Даже не одна, две пришли. Нигде такого еще не видел. Не буду тянуть кота за и так уже растянутые постоянным упоминанием <подставить слово>, перейду к сути.

1. Читая чужой блог, мы листаем посты, ходим по страницам, по категориям, жмем на теги. Иногда мы проделываем довольно длинный пусть по сайту. И, например, страшно нам блог понравился. На следующий день мы открываем этот же блог и хотим продолжить чтение, но… не помним где мы остановились. Судорожно ищем место, не находим. Читать уже знакомые заголовки, когда ищешь что-то новенькое раздражает неимоверно. Листать страницы по 5 постов на каждой раздражает еще больше (ну почему нельзя было сделать по 20 постов хотя бы?!).

А почему бы автору блога не сделать следующее?

Например, где-то вверху есть галочка «Запомнить, что я читал последним». При нажатии на нее пользователь может покинуть сайт, а при повторном открытии браузера (хоть через год) он попадет на ту самую страницу, которую читал последней.

Девид Блейн, остановись, демон! Как это?! А очень просто. Когда пользователь жмет галочку, то на сайте врубается простой механизм: при переходе на очередную страницу пользователю записывается Cookie с URL или URI этой страницы. Когда пользователь заходит на сайт с другого сайта или из «чистого» браузера, мы проверяем реферер и если пользователь пришел не с нашего сайта, то делаем редирект на последний записанный URL. Конечно значение галочки «Запомнить, что я читал последним» тоже нужно записать в Cookie.

Или даже так: URL сохраняется в Cookie в любом случае, но если галочка не установлена, то редиректа не происходит (для того, чтобы всегда точно знать, что пользователь прочитал последним).

2. Еще более глобальная система закладок. Причем индивидуальная для каждого пользователя и, понятное дело, доступная без регистрации (я вообще регистрации ненавижу).

Скажем, в боковой колонке есть блок под названием «Вот это я читал», а в постах под заголовком есть ссылка «Запомнить этот пост». Когда пользователь жмет на «запомнить», то в блоке появляется ссылка на этот пост. Ну и, скажем, запомнить можно сколько угодно постов.

Реализация тоже простая. Для этого тоже достаточно одной только Cookie. Правда записывать туда придется уже не URI, а ID поста из базы данных, т.к. мы должны иметь возможность отобразить заголовок поста в блоке. В Cookie же можно просто записывать ID через запятую, а при неободимости разбивать строку через «разделитель «запятая»" функцией explode и считывать все, что нам нужно из БД.

Да, почему я не назвал это «Закладками» и «Добавить в закладки». Потому, что, очевидно, пользователи будут путать это с закладками браузера, а нужно сделать так, чтобы даже никаких ассоциаций в эту сторону не появлялось.

Эпилог. Вторая идея – это продолжение первой. И, к сожалению, на мой взгляд она немного сомнительна. Ее можно использовать, например, в инернет-магазинах в качестве функции а-ля «сравнить товары» или «отобрать понравившиеся». Но… Сами понимаете. А вот первая, я считаю, вполне себе идеища и достойна реализации. Она помогает и пользователю и повышает крутость ресурса в глазах пользователя («- Толян, смотри, какая там прикольная фишка!»). Главное, дать пользователю выбор, сохранять или не сохранять страницу последнего посещения.

Комментариев (9)

Универсальная партнерская ссылка с любой страницы сайта

Откладывая в сторону сиськи и возвращаясь к моему предпоследнему посту, хочется написать еще один, раз уж пошла такая пьянка.

Как работают партнерские программы мы все знаем: ставим свои ссылочки, по ним приходят покупатели, оплачивают товарчеги и мы получаем денежги на свой счетег. Ссылки обычно имеют вид site.ru/?p=10, где 10 – это наш ID.

Как правило можно поставить партнерскую ссылку на любой товар, например site.ru/tovari/rozoviy_slon.htm?p=10 или на другую страницу.

А как программируются такие ссылки? Обычно предполагается, что ссылка будет передаваться через GET-запрос и находить мы ее будем в глобальном $_GET-массиве.

Но я предлагаю решение круче, которое позволит нам не зависеть от передачи параметра через GET-запросы и ставить партнерскую ссылку на любую страницу сайта. Интересно как?

В самом мега-главном файле сайта index.php в самом верху (после инициализации движка, точно так же как и в случае с tkd), пишем следующее:

preg_match («/(.*?)?p=([0-9]+)/si», $_SERVER["REQUEST_URI"], $m);
if (!empty ($m[2])) $pid = $m[2];

if (!empty ($pid)){
setcookie («partner», $pid, time()+3600*24*7, «/»);
}
Как видно из кода, мы опять использовали REQUEST_URI. Напомню, что он содержит URL данной страницы (там где сейчас юзер) без http и домена сайта. Например такой: /hello.htm. С помощью регулярных выражений мы вырезаем из URI выражение вида ?p=x, и определяем этот x (переменная $pid). Причем тут автоматически идет и защита от злых дядек – если после ?p= идут не цифры, то ничего мы не получим.

Дальше, понятное дело, на Ваше усмотрение. У меня ставится кука с ID партнера, который привел пользователя на сайт.

И, таким макаром, мы можем добавить ?p= вообще в любую ссылку, движку теперь просто все равно куда мы ее добавляем – вырезается все с помощью регулярок.

Кстати, раскрываю секрет фирмы. $pid не имеет никакого отношения к пидарасам мужчинам нетрадиционной сексуальной ориентации. Расшифровывается в данном случае как partner id. В линуксе, например, pid означает как правило process id и так далее.

Комментариев (3)

title / description / keywords – универсальная система для сайта

В последнем моем проекте было разработано довольно много разнообразных модулей (таких как опросы, новости, партнерские программы, разнообразная статистика, партнерские материалы, товары разных типов, да и просто страницы меню).

Возник вопрос о том, что для каждой страницы надо как-то задавать title, description и keywords (для SEO). Нужно было быстро реализовать это решение.

Обычно в таких случаях разработчики добавляют новые поля в базу данных для всех этих модулей, меняют скрипты (запросы в базы данных) и вообще перерабатывают пол-движка. Понятно, подводный камень в этом случае в том, что очень легко что-то пропустить, забыть подправить какой-то запрос и получить в релизе ошибки. А если, например, эти таблицы используют какие-то другие скрипты, то они могут внешне работать без ошибок, но фактически коверкать все данные (например, подсчитывать совершенно неверную статистику).

За 0.0141 секунды раздумий я придумал следующую систему, которая позволяет не перерабатывать весь движок.

Понятно, что каждая страница сайта имеет свой URL. URI – это тот же URL, только без домена. Его можно получить из переменной $_SERVER["REQUEST_URI"]. Понятно, что для каждой страницы URI свой собственный (иначе это уже одна и та же страница).

И возникает очень простая система. Создаем таблицу в БД с полями «title, key, descr, uri». В том месте, где должны выводиться title, description и keywords пишем что-то вроде:

<?php
$uri = $_SERVER["REQUEST_URI"];
if ($uri == «/index.php») $uri = «/»;
$q = mysql_query («SELECT * FROM table WHERE uri=’$uri’;»);
if (mysql_num_rows ($q) > 0){
$str = mysql_fetch_array ($q);
$t = $str['title']; $k = $str['key']; $d = $str['descr'];
}
?>
<meta name=»keywords» content=»<?php echo $k; ?>» />
<meta name=»description» content=»<?php echo $d; ?>» />
<title><?php echo $t; ?></title>

Понятно, что в таблицу записывается заголовок, описание и ключевики для того адреса, для которого мы хотим задать их. И работать это будет для всех страниц, которые обрабатывает движок (то есть в данном случае – для всего сайта вообще). А администратор получает возможность задавать заголовки, ключи и описание даже для тех страниц, которые в ТЗ не предусмотрены, плюс в следующих модулях не нужно будет реализовывать «внутреннюю» поддержку title, keywords и description.

Конечно, не забудьте о безопасности! Проверяйте это выражение перед передачей его в базу. Обычно оно проверяется очень просто – нельзя использовать никакие символы, кроме слеша, точки, букв и цифр.

Комментариев (6)

Китайская защита сайта от вирусов

Не секрет, что иногда сайты заражают вирусом.

Чем-чем? Вирусом. Он находится в iframe, и таким образом не виден посетителю. Но при этом посетитель успешно этот фрейм открывает и вирус хватает.

Как-как? Обычно внизу файла index.php располагается код, что-то вроде <iframe…>. При этом владелец сайта однозначно может сказать, что «ээ, дарагой, такова ранэшэ нэбэло, ээ!»

Как избавиться? Удалить этот код, сменить пароли на FTP (т.к. часто именно их и воруют).

В чем подвох? Подвох в том, что владелец сайта может «до последнего» не видеть вирус. Особенно, если вирус какой-нибудь новый. И даже Касперский не поможет.

В чем заключается моя «защита» и почему она «китайская»? Дело в том, что это скорее не защита, а оповестительная система, отключающая сайта, если вирус там поселился.

Как работает? Очень просто. Из учебника php следует, что закрывающий тег в конце файла можно опустить. То есть код:

<?php

echo «hello»;

тоже считается валидным и нормально работает.

Так вот, берем какой-нибудь WP, стираем в index.php нафиг закрывающий тег PHP (а именно вот этот: ?>). Все!

Чего ж будет-то? Если злоевек зальет Вам на сайт свой злоефрейм, то возникнет ошибка при исполнении этого файла php и сайт не откроется. Чем это важно? Важно тем, что владелец сайта, посещая свой сайт, сразу поймет, что на сайте поселился вирус, а посетители сайта не заразятся вирусом, т.к. сайт отключился.

Комментариев (15)

Возможность убрать рекламу, юзер-френдли

Реклама: начало кризиса, дешевый хостинг, автосалоны г одессы

Конечно, надоевшие баннеры уже всем… надоели. Но я нигде не видел такого решения проблемы: по умолчанию баннеры показываются (когда пользователь заходит на сайт), но у каждого есть в углу крестик. Нажав на этот крести, пользователь скрывает баннер (место просто становится пустым).

Логика: если пользователь увидел баннер и не кликнул по нему – он его уже не заинтересует, а будет только раздражать. «Прозрения» (когда 2 часа читаешь сайт, а потом вдруг понимаешь, что баннер-то мега-интересный) – редкое явление, почти не встречается.

Плюсы: супер-мега-дружелюбный интерфейс. Всенародное признание и любовь пользователей. Повышенное внимание к баннерам (как ни странно, но пока пользователь тянется к кретику, он смотрит на баннер дольше, чем если бы просто зашел на сайт).

Минусы: не подходит для оплаты по показам (а-ля «5$ за 1000 показов»), может быть неадекватно воспринято рекламодателями («мы тратим деньги на то, что пользователь не видит!»).

Как реализовать?

Очень просто. Оборачиваем баннер (предполагается, что это флеш или изображение) в div, в углу рисуем крестик ссылокой. При клике на ссылку срабатывает JavaScript, который записывает куки пользователю (да-да, а что, не знали, что это можно?). В куки содержится, например, имя скрытого баннера. При загрузке страниц PHP-скрипт (или что там у Вас на сервере) проверяет, есть ли куки с именем баннера и если уже есть, не отображает его.

Еще нужно предусмотреть возможность вернуть все «как было». Например вместо баннера показывать ссылку «показать баннер».

Комментариев (12)