Я не только пишу блог, но и постоянно читаю практически всю русскоязычную IT-блогосферу. Есть блоги, которые нравятся, есть и пара тех, что не нравится, но я заметил одну закономерность. Есть ряд признаков, небольших настроек, на первый взгляд неочевидных, которые делают блог УДОБНЫМ для чтения и комментирования. Я решил написать небольшую сводку — что сделать с блогом, чтобы не создавать читателям и потенциальным подписчикам проблем. Кажется, это получился гайд в основном по рекомендуемым плагинам WordPress. Итак…

Читать далее »

На iCamp 2008 мы не только пили пиво, но ещё и очень-очень много общались. Под воздействием эпохальных речей норвежских парней из Opera Software о скорой смерти проприетарных стандартов, в голове у представителей различных социальных сетей начали шевелиться мысли…

И начали мы думать, как нам объединить усилия таким образом, чтобы проекты ничего не потеряли, но при этом стали сильнее. Некоторые гнули в свою сторону, мол мы будем интеграторами всея рунета, некоторые махали руками в сторону Google, SocialGraph, FoaF, OpenID и прочих вещей, которые технологически интересны и полезны, но законченного решения, увы, не дают.

Потом мы ещё очень долго думали и к концу третьего дня iCamp мысль начала понемногу фокусироваться и люди с ней начали соглашаться.

Проблема: необходимость для пользователей многократно заполнять свои профайлы в сети.

Причина: невозможность или незаконность парсинга сайтов для получения данных о пользователе даже при его желании.

Решение: создание единого формата обмена пользовательскими данными между сайтами.

Мы решили создать такой формат, придумав кодовое имя OpenProfile. Да, есть аналоги, может быть даже речь идёт об изобретении велосипеда, но мне кажется, что есть шанс сделать действительно удобный, гибкий и полностью децентрализованный формат. В каком-то роде это получится продолжение идеи OpenID, но пересекаться с ним никак не будет, разве что дополнит его.

Поскольку речь идёт о передаче пользовательского логина и пароля в одну сторону и его личной информации в другую, необходимо шифрование канала. Это не большая проблема, так как достаточно обычно SSL-сертификата и взаимодействия между веб-серверами по https-протоколу.

В качестве носителя информации в данном случае идеален XML-формат. Кроме того, сужествуют наработки по обмену данными между базами данных с отличающейся структурой:

1. Спецификация и форматы обмена данными в разнородных информационных системах на базе XML-технологий.

2. Уже почти забытый формат обмена OIFML (уже нет).

Вот, в общем-то, и вся идеология на данный момент. На iCamp-е я заручился поддержкой в этом начинании у представителей нескольких молодых социальных сетей, а уже дома убедился, что и наша команда не против поучаствовать. Поэтому я быстро купил домен и на скорую руку поставил туда движок Wiki для обсуждения, к которому вас и приглашаю.

Работая над одной идеей, связанной с RSS, заметил, что больше половины всех FeedBurner-лент блогеров работают не совсем правильно. Дело в том, что при определённой настройке FeedBurner меняет в ленте все ссылки на редиректные, находящиеся на своём сервере. Таким образом, если на каком-то аггрегаторе выводятся ссылки на ваши последние статьи, то ведут они не на ваш сайт, а на FeedBurner, с которого уже перебрасываются к вам. С точки зрения пользователя это не заметно, а с точки зрения SEO — это маленькая катастрофа, так как вес в большинстве случаев не передаётся.

Сегодня вместе с Диким мы разобрались как решить эту проблему.

Решения два:

1. Если вы только создаёте RSS-трансяляцию в FeedBurner, то на втором этапе не ставьте галочку «Clickthroughs«.

2. Если лента уже существует, то зайдите в раздел «Analize» — «Site Stats» и снимите галочку с «Item link clicks».

Это всё. Теперь все ссылки на оригинал записи в ленте и в аггрегаторах будут вести прямо на ваш блог. Что от этого теряет статистика FeedBurner? Учёт кликов по заголовкам. Но его, в общем-то, никто и не смотрит.

«Облако тегов» или «Облако меток» (англ. tag cloud) — визуальное представление списка ярлыков. Частота упоминаний, поисков, ссылок в интернете с определенного сайта неких слов, терминов, имен, отображается в виде изображения этих слов в формате гиперссылок. Размер изображения тем больше, чем выше релевантность данного слова.

Теги для многих удобнее категорий, и, наверное, поэтому без них сейчас не обходится ни один проект в концепциях Web 2.0. Для многих CMS есть модули или плагины, выводящие облако тегов. WordPress поддерживает такую функцию начиная с версии 2.3.

Но мне захотелось вывести такую штуку на самописном движке сайта «Коллеги: 1000 IT-блогов«. Реализация оказалась проще, чем я думал.

• 1. Создал таблицу соответствий «Тег — Число».
• 2. Заполнил её (несложная функция, подсчитывающая число вхождений тега в таблице блогов).
• 3. Рассчитал максимальное значение и исходя из него — популярность каждого тега в процентах.
• 4. Разделил теги на группы по популярности и назначил им CSS-классы.
• 5. Подготовил соответствующие CSS-классы для отображения.
• 6. Вывел облако на страницу блоком.

TagCloud.phps - формирование облака тегов.

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

Жилинский Владимир.

Вдогонку к заметкам о морфологическом антимат-фильтре на PHP, функциях для экстренного конвертирования в UTF и обратно и функции для защиты от XSS-атак, публикую потрясающую по полезности находку.

Это полнейший must have для PHP-программистов — если даже и не включать это в готовый код, то для отладки — бесценно. Я уже не знаю, что бы я делал без функции is_utf8, например. Поэтому качаем архив, распаковываем его себе и пользуемся, изучив и сохранив описание.

Этот сборник продвинутых функций для работы с UTF-8 текстом создан коллективным разумом форума программистов и усилиями Рината Мухтарова. Скачать архив.

Далее — список доступных функций и их описания:

1. censure. Функция определяет наличие мата (нецензурных, матерных слов) в тексте. Возвращает false, если мат не обнаружен, иначе обнаруженное матерное слово. Алгоритм достаточно надежен и быстр, в т.ч. на больших объемах данных. Метод обнаружения мата основывается на корнях и предлогах русского языка, а не на словаре, поэтому скорость очень высока.

2. cp1251_to_utf8_recursive. Функция для перекодировки данных произвольной структуры из кодировки cp1251 в кодировку UTF8.

3. cp1259_to_utf8. Конвертирует текст из кодировки cp1259 и cp1251 в кодировку UTF-8.

4. html_template. HTML-ориентированный шаблонизатор с автоматическим квотированим значений меток-заменителей.

5. html_words_highlight. «Подсветка» найденных слов для результатов поисковых систем.

6. hyphen_words. Расстановка «мягких» переносов в словах.

7. is_utf8. Возвращает true усли переданная строка — правильный UTF-8, иначе false.

8. php2js. Конвертирует данные PHP из scalar, array и hash в данные JS в scalar/array/hash.

9. strip_tags_smart. Более продвинутый аналог strip_tags() для корректного вырезания тегов из html кода. Возможности:

— корректно обрабатываются вхождения типа «a < b > c».
— корректно обрабатывается «грязный» html, когда в значениях атрибутов тагов могут встречаться символы < >.
— корректно обрабатывается разбитый html.
— вырезаются комментарии, скрипты, стили, PHP, Perl, ASP код, MS Word теги.
— автоматически форматируется текст, если он содержит html код.
— защита от подделок типа: «<script>alert(‘hi’)script>».

10. textarea_rows. Вычисляет высоту области редактирования текста (<textarea>) по значению и ширине.

11. ucs2_to_utf8. Преобразует строку из кодировки UCS-2 в UTF-8, без использования iconv.

12. utf8_autoconvert_request_charset. Перекодирует значения элементов массивов $_GET, $_POST, $_COOKIE, $_REQUEST, $_FILES из кодировки cp1251 в UTF-8, если необходимо. Побочным положительным эффектом функции является защита от XSS атаки с непечатаемыми символами на уязвимые PHP функции.

13. utf8_check. Пытается определить, находится ли строка в кдировке Unicode.

14. utf8_convert_case. Конвертирует регистр букв в строке в кодировке UTF-8.

15. utf8_escape. Перекодирует строковые объекты так, чтобы они читались везде.

16. utf8_html_entity_decode. Конвертирует все HTML-entities в символы UTF-8.

17. utf8_html_entity_encode. Конвертирует спецсимволы UTF-8 в HTML-entities.

18. utf8_simple_search_sql. Создает условия для простого поискового SQL запроса, основанного на LIKE и REGEXP.

19. utf8_str_limit. Обрезает текст в кодировке UTF-8 до заданной длины, причём последнее слово показывается целиком, а не обрывается на середине.

20. utf8_strlen. Расширенная функция strlen() для работы со строками в utf-8.

21. utf8_substr. Расширенная функция substr() для работы со строками в utf-8.

22. utf8_ucfirst. Преобразует первый символ строки в кодировке UTF-8 в верхний регистр.

23. utf8_ucwords. Преобразует в верхний регистр первый символ каждого слова в строке в кодировке UTF-8, остальные символы каждого слова преобразуются в нижний регистр.

24. utf8_unescape. Функция декодирует строку в формате %uxxxx в строку формата UTF-8.

25. utf8_unescape_recursive. Рекурсивный вариант utf8_unescape().

26. utf8_unescape_request. Корректирует глобальные массивы $_GET, $_POST, $_COOKIE, $_REQUEST, декодируя значения в юникоде, закодированные через функцию javascript escape() ~ “%uxxxx”.

Жилинский Владимир.

Довольно интересная тема, особенно важная для интернет-магазинов, сайтов турагенств и прочих оператор-ориентированных сервисов. Стандартный подход в рунете такой: в шапке сайта указывается телефон, в подвале — е-мейл, в лучшем случае есть ICQ или форма обратной связи.

Такой подход явно не располагает посетителей к контакту: я не люблю звонить непонятно куда по телефону (да и зачем, я же в сети), ICQ — это что-то личное, да и для контакта требуется слишком длинная цепочка действий, а по почте мы все знаем, что не дождёмся ответа скорее всего никогда.

На западе решением этой проблемы было озадачено несколько компаний, разработавших всё, что можно найти в Google по запросу «Live Chat Software«, то есть программы для мгновенной связи оператора с посетителем сайта. По некоторым данным, такой механизм в хорошей реализации может увеличить конверсию и, соответственно, продажи более чем на 80% (!). Это вполне логично — задать вопрос специалисту проще, чем лазать по каталогу и легче, чем звонить, искать кого-то в ICQ или ждать ответа по e-mail.

Отсюда логически следует жизненный вопрос: как это реализовать, желательно самостоятельно и бесплатно?

Подход первый. Грамотный.
Будем писать сервис под себя. Самый удобный, открытый и подходящий для этой цели стандарт, на мой взгляд — Jabber . Берём class.jabber.php или немного его доработанный вариант PHP Jabber Client и пишем всё, что нам нужно. Для любителей Python: xmpppy .

Не нравится XMPP — можно рискнуть и заморочиться с ICQ, например на основе PHP-класса WebIcqPro или даже Java-библиотеки Joscar . Я думаю, что ICQ следует использовать только в том случае, когда нет возможности использовать Jabber, так как этот протокол не блещет стабильностью, надёжностью и предсказуемостью. Да и возможность несложного создания Jabber2ICQ гейта даёт Jabber`у дополнительное преимущество.

Подход второй. Быстрый. Бесплатный.
Использование бесплатного стороннего мессенджера, желательно не слишком навязчивого и более-менее удобного. Например:

1. Hab.la . Весьма удобный сервис, основанный на Jabber. Легко настраивается, не вызывает конфликтов, легко интегрируется в любую страницу, позволяет использовать любой jabber-клиент на стороне оператора. Подробнее про хаблу можно почитать у Дикого .

2. Google Talk chatback badge . Просто и со вкусом, если грамотно оформить, то вполне приемлемо. Но найден недостаток в реализации — сделано с использованием Flash (Google, ЗАЧЕМ?), что ограничивает в общении неанглоязчных пользователей не-windows. Я надеюсь, в Google исправят этот косяк.

Подход третий. Корпоративный.
Самим писать ничего не хочется, бесплатных сервисов мало, хочется чего-то серьёзного — придётся платить. Не буду рекламировать платные сервисы, скажу только, что идеального среди них я тоже не нашёл, так как каждый стремится к изобретению нового двухколёсного транспортного средства. Вот список более-менее дружественных корпоративному пользователю:

• Веб Мессенджер
• SiteHelper.NET
• GoTalk
• LiveContact

В общем, выбор есть, и я постарался сделать его чуть более очевидным. Пользуйтесь, это очень повышает уровень доверия пользователей к онлайн-сервису.

Спонсор статьи: продвижение сайтов от StarDesign. Без комментариев.

Жилинский Владимир.

Предлагаю небольшое исследование на тему безопасности веб-приложений и фильтрации вводимых данных. Скорее всего, я ещё вернусь к этой теме, но сейчас больше хочется не писать трехтомник, а сохранить и упорядочить собранное и проверенное. В частности, речь пойдёт о фильтрационной защите от XSS-атак и SQL-инъекций.

В PHP есть ряд специальных функций для работы со строками, применимых для этой цели. Вот они:

strip_tags() — вырезает теги HTML и PHP из строки.

htmlspecialchars() — конвертирует только специальные символы (‘&’, ‘»‘, »’, ‘<‘ и ‘>’) в HTML сущности (‘&amp;’, ‘&quot;’…). Используется для фильтрации вводимых пользователем данных для защиты от XSS-атак.

htmlentities() — конвертирует все символы в строке (кроме букв) в мнемоники HTML. Используется для защиты от XSS, являясь более гибким аналогом htmlspecialchars.

stripslashes() — удаляет заэкранированные символы (после преобразования в сущности предыдущими функциями их незачем экранировать). Обычно используется в связке с проверочной функцией get_magic_quotes_gpc(), показывающей текущую установку конфигурации magic_quotes_gpc.

Эта конфигурация влияет на то, как будут обрабатываться специальные символы, содержащиеся в данных, передаваемых пользователем (массивы $_GET, $_POST, $_COOKIE). При magic_quotes_gpc = 1 эти спецсимволы (одиночные и двойные кавычки, обратный слэш, байт NULL) автоматически экранируются. При magic_quotes_gpc = 0 все данные передаются в таком виде, в каком их ввел пользователь. В последнем случае в целях безопасности требуется обрабатывать передаваемые данные.

mysql_real_escape_string — мнемонизирует специальные символы в строке для использования в операторе SQL с учётом текущего набора символов в кодировке соединения. Иными словами, функция превращает любую строку в правильную и безопасную для MySQL-запроса. Используется для очистки всех данных, передающихся в MySQL-запрос для защиты от SQL-инъекций.

На основе этих данных, можно собрать функцию для однозначной очистки непроверенных данных. Эта функция получает две переменные — строку с введёнными символами и булево значение для определения — требуется ли приведение к MySQL-запросу. Возвращает функция очищенную строку. Конечно, это не панацея, но функцию легко изменить под собственные нужды.

InputClear.phps - фильтрация введённых пользователями данных.

Если кто-то обнаружит ошибки, или знает способ лучше — добро пожаловать в комментарии, мне очень интересно.

Жилинский Владимир.

Несколько дней назад я выкладывал скрипты для определения средствами PHP показателей Яндекс ТиЦ и Google PR для сайтов (это может быть полезно при создании рейтингов, каталогов и для SEO). В комментариях Виталий спрашивал — почему скорость определения ТиЦ такая низкая (до минуты). Причина была найдена вместе с альтернативным решением.

Дело в том, что я пытался определить ТиЦ, используя данные для Яндекс.Бара, которые отдаются медленно (недостаток серверных ресурсов, скорее всего). Решение — обращаться к каталогу Яндекса, который неизбежно показывает нужное значение (хотя, говорят, иногда обновляется с небольшим опозданием).

По скорости — получилось. Всё-таки, каталог — это сайт, а сайт Яндекса должен работать быстро. Исчезли задержки по 30-50 секунд, скрипт выполняется за 0.2 — 0.3 секунды.

Cy-2.phps - получение Яндекс ТиЦ в виде числа.

Проверить скорость и точность работы кода можно на том же тестовом скрипте.

PS: У меня всего 100 коллег? Не верю!

Жилинский Владимир.

Помните, в сентябре 2007-го я проводил Конкурс Конкурентов с выбором лучших IT-блогеров? С тех пор прошло уже порядком много времени, но проводить конкурс повторно я пока не хочу. А вот блогролла мне уже мало. Да и не конкуренты мы вовсе — я бы сказал, коллеги:

Скрипт ещё толком не отлажен, так что если что — пишите в комментарии. Ну и помогайте наполнять, конечно. Условия добавления блога в эту матрицу — IT-направленность и наличие постов за последние 30 дней.

Скрипт разработан на основе исходника Юрия Пименова (aka Danaki), блог которого заработает к понедельнику.

Жилинский Владимир.

Когда-то давно, около года назад, я уже пробовал поставить на блог кеширующий плагин, но тогда и WP был другой версии, из плагинов только каждый десятый работал. Но вот настал период, когда захотелось улучшить ситуацию со скоростью доступа к блогу — на VDS поселился посещаемый магазин и скорость стала пониже.

В плане скорости сложно выбрать однозначный способ замеров, так как это зависит от того места, октуда идёт запрос. Но эксперименты показали, что довольно адекватное значение даёт сервис HostTracker, запрашивающий страницу из 62-х точек в разных странах.

Я замерил начальную скорость. Результат - 3.8 сек.

После этого я установил плагин WP-Cache 2.1.12. Устанавливается он весьма просто:

• Скачать последнюю версию.
• Распаковать.
• Загрузить папку wp-cache в каталог /wp-content/plugins/ на сервер.
• Выключить в админке GZIP-сжатие (по умолчанию — выключено).
• В файл wp-config.php добавить строчку define(‘WP_CACHE’, true); (если файл закрыт от записи).
• Активировать плагин в панели управления и включить в настройках.

Я не стал ничего менять в настройках плагина, кроме времени кеширования (увеличил до 10800 секунд — это 3 часа).

После этого я сделал ещё один замер скорости. Результат - 0.8 сек.

Разница чувствуется даже без секундомера. Так что всем читателям — обратить внимание на увеличившуюся скорость загрузки блога, а всем блогерам — замерьте свою скорость и задумайтесь о кешировании. Помогает.

Жилинский Владимир.