Боремся со спамом в комментариях

В последнее время многие блогеры жалуются на возросший спам в комментариях. Хотя не только на блогах, но и на некоторых форумах также появляется порно-спам. Каждый выбирает свою тактику в борьбе с этим злом: кто-то совсем отключает возможность комментировать заметки, кто-то обвешивается плагинами, кто-то устанавливает премодерацию. У каждого метода есть свои плюсы и минусы. Сегодня наткнулся на довольно интересную заметку: «Защита от спама в комментариях с помощью Apache».

У меня на блоге стоит WordPress'овский плагин Spam Karma, который меня в данный момент времени всем устраивает. Хотя да, случаются и у него промашки. Иной раз пропустит одна-два спам комментария или же нормальный комментарий определяет как спам. Но это бывает достаточно редко. Так что решение переложить фильтрацию на плечи Apache довольно интересное, надо будет попробовать.

Плагин wp-cache 2

Вот уже второй день бьюсь с плагином wp-cache 2. На домашнем серверке под управлением (ОС: Windows) Apache 1.3.x/PHP-4.4.1 он встал, но заработать не захотел. Ну тут всё ясно, сам автор пишет, что данный плагин под виндой работать не будет. Хорошо. Слил файл на сервер. Активировал плагин, нужные линки и каталоги создались, запустил плагин. Фиг там, не кеширует всё. Всё уже излазил, все комменты у автора прочитал, но так решение этой проблемы не нашёл.

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

Update: К вечеруночи после бокала пива emoticon разобрался с этим глюкомдромом. Вся фишка неработоспособности плагина (в моём случае) была в том, что я добавил строку define ('WP_CACHE', true); в самый конец файла wp-config.php перед ?>. Как только эту строку перенёс выше, запихнул под define ('WPLANG', 'ru_RU');, всё сразу заработало. Непонятно. emoticon Теперь посмотрим как будет работать блог с установленным кешированием.

SSI — что это такое и с чем его едят

SSI — Server Side Include (вставки на стороне сервера). Для полноты процитирую кусочек из статьи (ссылки ниже) размещённой на сайте @ NBSP // Журнал для вебмастеров:

SSI — это директивы, вставляемые прямо в HTML-код и служащие для передачи указаний Wев-серверу. Встречая такие директивы, которые, кстати, называются SSI-вставками, Web-сервер интерпретирует их и выполняет соответствующие действия. Какие, спросите Вы? А вот, например: вставка HTML-фрагмента из другого файла, динамическое формирование страничек в зависимости от некоторых переменных (например, типа броузера) и другие не менее приятные вещи.

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

После стремительного роста популярности PHP про SSI вебмастера стали как-то забывать. А зря, ведь с помощью SSI можно делать не только банальные вставки “шапки” и “подвала” страницы. Можно делать очень много (не так много как страница написанная на PHP) вещей, которые позволят сократить трудозатраты на … пусть тоже создание многоуровнего меню, например.

Лично у меня была пара работ, которые сделаны полностью на SSI. Делая эти работы я прочитал много материалов: документацию, советы, примеры, и от проделанной работы я получил не только материальное и моральное удовлетворение, но и получил новые знания.

Также хочу обратить внимание, что реализация SSI в Apache отличается от реализации SSI в IIS. В IIS’е она “кастрированная” (другого слова, к сожалению, не подберёшь).

А теперь обещанные ссылки (извините, за столько долгую и, может быть, никому не нужную лирику):

PHP4 и PHP5 на одном Apache

Сегодня прочитал две статьи по установке двух версий PHP — 4-ой и 5-ой — на один Apache. Статью "номер" раз можно прочитать тут (написана в 2004 году) и статью "номер два" можно прочитать тут (написана в мае 2005 года). Лично мне понравился способ описанный в первой статье, хотя ни один ни другой не пробовал. 🙂 Лично у меня пока нет такой необходимости иметь две разные версии PHP, хотя может быть кому-то такая комбинация и необходима и эти статьи будут полезны.