На днях я столкнулся с довольно неприятной ситуацией. Скрипт, который прекрасно работал на локальном сервере начал выдавать ошибки на сервере хостера.

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

В данном случае дело было во включенных Magic Quotes (волшебных кавычках, хорошее название, появляются как по волшебству там, где не надо ).

Вообще-то, использование Magic Quotes не рекомендуемая практика.

В соответствующем разделе PHP manual ясно об этом сказано.

Warning

This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.

Предупреждение

Эта возможность считается устаревшей начиная с PHP 5.3.0 и будет удалена начиная с PHP 6.0.0. Рассчитывать на эту возможность крайне не рекомендуется.

Кратко поясню смысл этой функции. Она перехватывает данные, которые получает скрипт (массивы $_POST, $_GET и т.д.) и экранирует в них специальные символы.

Была разработана для защиты от хакерских атак вроде SQL Injection.

Но на практике от нее больше проблем, чем пользы.

Во-первых, 100% защиты она не обеспечивает. Т.е. вам все равно нужно самостоятельно проверять полученные данные (их тип, диапазон допустимых значений и т.п.). К тому же экранирование символов выполняется автоматически практически всеми библиотеками для работы с БД.

Во-вторых, часто нужны не экранированные данные.

Например, в моем случае ситуация была такой.

1) Клиент (браузер) передавал строку в формате json.
2) PHP при включенной Magic Quotes экранировал спец. символы.
3) функция json_decode возвращала NULL.

Почему хостеры включают Magic Quotes – вопрос отдельный. Может быть, хотят немного подстраховаться от начинающих разработчиков Или есть какие-то другие причины. Но в любом случае, вы можете легко ее отключить.

Посмотреть текущие настройки можно с помощью phpinfo(). (если Magic Quotes включена, в разделе Configure Command будет строка --enable-magic-quotes).

Для отключения создаем в папке со скриптами файл .htaccess с одной строчкой.

php_flag magic_quotes_gpc Off

Отключает Magic quotes для входящих данных из массивов GET/POST/Cookie.

Или добавляем эту же строчку в существующий .htaccess.

Примечание. Естественно, Magic Quotes можно отключить и в php.ini, но на shared хостинге у вас к нему доступа нет.

Подробнее об отключении Magic quotes можно почитать в PHP Manual.

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

До встречи!

Уделяете ли вы внимание организации своей работы?
Много ли у вас "мелких" дел, о которых вы регулярно забываете?

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

Хуже всего, когда нужно сделать много «мелких» дел, которые не занимают много времени, но обязательно должны быть выполнены вовремя… и держать в голове их все просто невозможно.

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

Я решил не оставаться в стороне и сделал собственный вариант такого ToDo списка, естественно, с некоторыми дополнительными возможностями.

Кстати, скрипт называется SimpleTasks.

Главная особенность – возможность указывать состояние выполнения задач. При этом используется специальная система обозначений.

Систему обозначений придумал не я. Но, к сожалению, не могу найти первоисточник (UPD. Огромное спасибо Smarty за ссылку на оригинал). Предназначена она для использования с бумажным блокнотом и довольно удобная. Во всяком случае, читать такой список задач становится намного легче. Взгляд сразу отбрасывает выполненные задачи.

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

В общем, я написал небольшое web приложение, использующее эту систему обозначений.

Если есть желание, можете поиграться с ним (логин admin@todo.loc, пароль password).

Или скачать архив и установить на своем сервере (инструкция в архиве).

Принцип работы.

Создание новой записи.
Кликаем по ссылке "Новая запись" (справа в верхней части страницы) и в открывшемся окне вводим данные записи.
При клике по полю "Дата" будет открыт календарь. Т.е. ввести дату в неправильном формате довольно проблематично.

Редактирование.
Клик или двойной клик на соответствующем поле позволяет изменить его. Открываетеся либо диалог, либо inline редактор.

Удаление.
Кликните по картинке с изображением крестика в соответствующей строке и подтвердите удаление.

Фильтры.
Позволяют выбрать задачи с определенным состоянием в указанном диапазоне дат.

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

Состояние работ.
На данный момент это только бета версия.
Еще не доделана локализация. Доступен только один вариант – русский.
Возможно, отсутствуют некоторые сообщения об ошибках.

Скорее всего, некоторые функции будут дорабатываться.

И я очень хочу услышать ваше мнение!

Прежде всего, меня интересуют такие вопросы.

1) Есть ли смысл делать подобное приложение многопользовательским? Т.е. технически это совсем не сложно, вопрос в том будет ли кто-то в рамках небольшой организации использовать такое приложение для хранения заметок сотрудников?

2) Какие еще функии вы бы добавили?

3) Может кто-то видел хороший тьюториал о локализации JS приложений? (Сейчас я ориентируюсь на то, как сделана локализация в jQuery UI).

P.S. На этих выходных я уезжаю догуливать остатки отпуска, поэтому прошу прощения, если не сразу отвечу на ваши комментарии. Я обязательно их прочитаю… даже спаммерские

Сегодня я продолжу рассказ о создании и использовании графиков на web ресурсах.

В предыдущих статьях речь шла об использовании для этих целей flash библиотек (Графики своими руками – Open Flash Chart 2) и внешних сервисов (Графики от Google и PHP библиотеки для работы с ними).

В принципе, на этом можно было бы остановиться, но судя по реакции в комментариях, я пропустил ещё один очень интересный вариант создания графиков. Речь, конечно, об использовании JavaScript.

Рассмотрим достоинства и недостатки этого варианта.

Достоинства.

1) Минимальные затраты на трафик. Передать нужно только саму библиотеку (обычно размер не превышает 100 кБ (без сжатия)) и данные для построения графика.

2) Минимальная нагрузка на сервер. Отрисовка графика выполняется браузером. Сервер должен только отправить массив с точками, по которым будет построен график.

3) Простота использования. Достигается за счет готовых библиотек.

Недостатки.

1) Возможны проблемы совместимости с некоторыми браузерами. С этими проблемами знакомы все web мастера. Но, должен отметить, что разработчики библиотек неплохо с ними справляются.

2) Дополнительная нагрузка на компьютер пользователя. Достаточно спорный момент. Вряд ли обычный пользователь заметит время, за которое будет создан один простой график. Но если графиков десятки и для их создания используются тысячи точек, то время создания такой страницы может существенно возрасти. В общем, тут многое зависит от вас.

Теперь перейдем к практической части.

На сегодняшний день JavaScript библиотек для создания графиков довольно много. Но принципы их использования практически одинаковые, поэтому пример приведу я только для одной.

Библиотека называется Flot.

Для начала определимся с задачей.

Допустим, у нас есть PHP скрипт, который получает данные, которые нужно показать на графике. И HTML страница на которой мы должны разместить график.

Начнем с разметки страницы.

Как видите, это обычная страница, внутри которой находится блок div, предназначенный для размещения нашего графика (строки 18-19). В CSS стилях этого блока нужно обязательно указать его размеры (width, height).

Кроме того, в конце страницы мы подключили файлы библиотеки (строки 25-27).

Т.к. библиотека Flot (jquery.flot.js) является плагином к jQuery, то первой мы подключаем её. Третий файл (excanvas.js) нужен для поддержки IE6.

В строке 30 мы подключаем JavaScript файл (main.js), который будет получать данные от сервера и рисовать график.

Рассмотрим его подробнее.

Как видите, тут все предельно просто.

1) Получаем данные (с помощью Ajax запроса).

2) Для передачи данных я выбрал JSON формат, т.к. он позволяют максимально упростить скрипты.

3) Строим график с помощью функции plot. В её первом параметре передаём id блока, в котором будет размещен график. Во втором – данные, полученные от серверного скрипта. В третьем – настройки графика (я указал только минимальное и максимальное значение по вертикальной оси).

Теперь переходим к сервреной части.

Этот скрипт просто создает массив с данными графика, преобразует в JSON формат и отправляет браузеру.

Обратите внимание на запись данных в массив. Массив $graph содержит 2 вложенных массива, каждый из которых в свою очередь содержит все данные, необходимые для создания одной линии на графике. Прежде всего, это координаты точек (элемент data), цвет линии (color), подпись (label).

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

Live Demo

Посмотреть, как выглядит этот график можно здесь.

Скачать

Кроме того, если есть желание поэкспериментировать вы можете скачать архив с примером.

В заключение приведу небольшой список JavaScript библиотек для создания графиков.

JS charts
jqplot
PlotKit
JavaScript Graph Builder
Raphaël
jQuery Sparklines

Небольшое дополнение.

В несжатом варианте используемые здесь JavaScript библиотеки довольно объемные. Поэтому я упаковал их архиватором 7-zip и добавил в папку с этим примером .htaccess с таким содержимым.

Теперь посетителю будет отправляться заархивированный вариант библиотеки.

Подробнее почитать о принципе работы .htaccess можно в статье Увеличиваем скорость загрузки web страниц.

Как всегда, буду рад услышать ваше мнение в комментариях

Сегодня я продолжаю рассказывать о разработке собственной системы отслеживания ошибок. В прошлой статье только вкратце была описана общая идея и возможности, а также показан предварительный эскиз приложения.

Но прежде чем переходить к основной теме, хочу поблагодарить всех комментаторов и особенно AmdY, Big_Shark и Алексея Качаева за советы!

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

В прошлый раз с инструментами мы определились (используем PHP, фреймворк CodeIgniter, MySQL и jQuery).

Сейчас нам нужно их установить и настроить.

Я предполагаю, что web сервер, PHP и MySQL у вас уже настроены, поэтому нам нужно только скачать CodeIgniter и jQuery. После этого распаковываем архивы в какую-нибудь папку на сервере. В результате должна получиться примерно следующая структура папок.

index.php
.htaccess
system/
js/
	jquery-1.3.2.min.js
css/

Файл index.php и папка system – из дистрибутива CodeIgniter.

.htaccess – самый обычный. Сразу приведу его содержимое.

<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteBase /

	RewriteCond %{REQUEST_URI} ^system.*
	RewriteRule ^(.*)$ /index.php?/$1 [L]

	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteCond $1 !^(index\.php|images|robots\.txt|css|js)
	RewriteRule ^(.*)$ index.php?/$1 [L]
</IfModule>

<IfModule !mod_rewrite.c>
	ErrorDocument 404 /index.php
</IfModule>

Основное его назначение – автоматически подставлять index.php в ссылки. Т.е. ссылка вида

bugtracker.local/bugtracker/page/2

будет преобразована в

bugtracker.local/index.php/bugtracker/page/2

При этом преобразование происходит, только если указанного в URL файла на самом деле не существует. Т.е. если запрос будет к js или css файлу, то index.php подставляться не будет.

Кстати, если вы хотите, чтобы приложение находилось в какой-нибудь папке (например, mysite.domen/bugtracker/), то нужно будет изменить параметр RewriteBase.

На настройке CodeIgniter подробно останавливаться не буду. Просто перечислю файлы, в которые нужно внести изменения.

Все конфигурационные файлы находятся в папке system/application/.

autoload.php – загружаем библиотеку для работы с базой данных и URL хелпер

config.php – здесь указываем адрес приложения, например,

и добавляем ещё один параметр

Как несложно догадаться его значение определяет количество записей о багах на странице.

routes.php – тут нужно указать только название контроллера, который будет использоваться по-умолчанию. Я решил его называть bugtracker.

database.php – здесь заполняем массив с параметрами подключения к базе данных.

Примечание. Подробнее о настройке фреймворка можно почитать в статье «PHP framework CodeIgniter. Установка и настройка.»

Теперь переходим к созданию базы данных.

Нам потребуются три таблицы:

1) bugs – используется для хранения информации о найденных багах и комментариях к ним.

Поля:
id – первичный ключ;
title – заголовок;
uname – имя пользователя, который оставил сообщение;
categoryid – id категрии к которой относится баг (должно совпадать с соответствующим полем в таблице categories);
description – описание бага;
status – здесь будет храниться информация о состоянии бага (по-умолчанию, «не исправлено»);
replyto – это поле устанавливает связь между багами и комментариями к ним (подробнее на этом мы остановимся чуть позже).

2) categories – список категорий.

Поля:
id – первичный ключ;
link – ссылка на категорию (латинскими буквами);
name – названии категории.

3) users – информация о пользователях. В данном случае этими пользователями будут только администраторы баг трекера. Оставлять сообщения и комментарии сможет кто угодно без авторизации.

id – первичный ключ;
name – имя пользователя;
pass – пароль.

Теперь посмотрите на запросы, которые создают эти таблицы.

Самый интересный момент здесь касается таблицы bugs, а точнее её поля replyto. Оно даёт возможность отличить комментарий к багу от самого бага. Если значение в нём не равно NULL, то это комментарий, если равно – баг. При этом число, записанное в поле replyto, указывает, к какому багу относится данный комментарий.

Например, в таблице есть четыре следующий записи:

Это означает, что мы имеем два бага (записи 1 и 4) и два комментария (записи 2 и 3), которые относятся к первому багу.

Кстати, значение поля categoryid для всех комментариев равно NULL.

Тут возникает проблема. Что будет с комментариями, если мы удалим баг к которому они относятся? Можно, конечно, решить эту проблему так:

1) найти все комментарии, которые относятся к данному багу;
2) удалить их;
3) удалить сам баг.

Но будет лучше, если движок MySQL автоматически удалит все связанные комментарии при удалении бага.

Для этого мы объявляем поле replyto внешним ключом (т.е. связываем его с полем id) и указываем опцию ON DELETE CASCADE (каскадное удаление) (строки 13-15). Теперь при удалении записи у которой поле id = 3 движок БД будет искать в этой же таблице все записи у которых replyto = 3 и удалять их.

И, кроме того, это поле (replyto) мы будем использовать при выводе сообщений о багах на страницах нашего баг трекера.

Но об этом в следующий раз.

До встречи!

Интересно почитать:
Слушать радио онлайн

Думаю, ни для кого не секрет, что разработчики браузеров стараются сделать серфинг в интернете максимально безопасным. Цель, конечно, прекрасная, но достигается она обычно за счет введения различного рода ограничений, которые усложняют жизнь не только мошенникам.

Приведу небольшой пример. Недавно я рассказывал об использовании Яндекс.Карт и сервиса IPLoc.

Для получения данных от IPLoc пришлось использовать PHP, хотя, как совершенно справедливо заметил Big_Shark, было бы гораздо удобнее отправить этот запрос с помощью JavaScript. Но кросс-доменный JavaScript запрещен политиками безопасности браузеров.

Тем не менее, мне стало интересно, можно ли обойти это ограничения без использования серверных скриптов (PHP). И решение, конечно, нашлось Правда, оно имеет свои недостатки, но об этом чуть ниже.

Примечание. По каким-то причинам сервис IPLoc на момент написания этой статьи недоступен. Но есть альтернативные варианты – например, WIPmania.com (), который имеет очень похожий API.

Для начала рассмотрим, как происходит обработка запроса и формирование страницы с использованием PHP.

Как видите, серверный скрипт должен отправить запрос сервису WIPmania, получить от него ответ, сформировать страницу и вернуть её браузеру.

Гораздо интереснее было бы отправить AJAX запрос сервису WIPmania и показать его ответ на странице. При этом необходимость в использовании PHP отпала бы.

Но, как я уже говорил, AJAX запрос может быть отправлен только тому серверу, с которого был загружен скрипт. Т.к. изменить поведение браузера мы не можем, то нужно, чтобы наш сервер перенаправил запрос на нужный ресурс (в данном примере WIPmania).

Если в качестве web сервера используется Apache, то для решения этой задачи можно использовать mod_proxy.

Из названия можно догадаться, что этот модуль позволяет использовать Apache в качестве прокси сервера.

Сразу хочу обратить ваше внимание на возможную угрозу безопасности. Нужно максимально ограничить возможность использования прокси. Например, в данном случае, можно разрешить доступ через него только к одному сайту – WIPmania.

На следующей диаграмме показан порядок обработки запросов в этом случае.

Как видите, в этом случае ajax запрос отправляется браузером web серверу, который получает необходимые данные от WIPmania.

Теперь посмотрим как это реализовать.

1) Включаем mod_proxy. Для этого в конфиге apache (httpd.conf) удаляем комментарии перед строками.

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

2) Сразу же запрещаем использовать apache в качестве обычного прокси сервера (forward proxy).

ProxyRequests Off

Вообще-то эта опция включена по-умолчанию, но перестраховка не повредит.

3) Указываем куда нужно отправить запрос. Допустим, нам нужно, чтобы в ответ на все запросы вида http://simplecoding.org/wipmania... сервер возвращал соответствующий ответ от сервиса WIPmania.

Создаем в корне сайта файл .htaccess со следующим содержимым.

Наибольший интерес здесь представляет 4-ая строка. Во всех запросах, в которых после адреса блога идет слово wipmania, мы первую часть заменяем на http://api.wipmania.com/. Оставшуюся часть запроса оставляем без изменений (нужно для передачи параметров).

Сформированный запрос отправляется через прокси (флаг [P]) серверу api.wipmania.com.

Таким образом мы можем получить данные от любого внешнего сервера. Для браузера эти запросы ничем не отличаются от обычных. Ведь на стороне клиента фактически невозможно установить каким образом web сервер сформировал ответ: прочитал обычный файл, выполнил PHP скрипт или получил данные с другого ресурса.

Так что этот метод будет 100% работать не зависимо от версии браузера и его настроек безопасности (вариант с запретом доступа в интернет вообще я не рассматриваю).

Теперь о недостатках.

Главный минус – нужен доступ к конфигу апача. Т.е. shared хостинг отпадает.

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

И, конечно, скорость загрузки данных будет зависеть от скорости сервиса с которым вы работаете. Например, тот же IPLoc сейчас просто недоступен (надеюсь, это временно).

Но есть и положительный момент.

Если вы можете реализовать весь функционал с помощью сторонних сервисов и JavaScript, то вам не нужна поддержка PHP (или другого языка).

Как видите, обойти запрет на XSS совсем не сложно Если у вас возникли вопросы, пишите, постараюсь ответить.

Небольшое объявление.

HighLoad-проекту требуется Senior PHP Developer

На проект fotostrana.ru требуется сильный PHP-разработчик:

* Опыт веб-разработки от трех лет;
* Профессиональное владение web-технологиями: PHP 5.0 + MySQL 5.0 + JS + AJAX и инструментами;
* Опыт работы с высоконагрузочными (highload) проектами;
* Участие в создании посещаемых проектов;
* Умение работать самостоятельно, быстро и на результат;
* Владение Zend Framework.

Работа в г.Санкт-Петербург. Подробнее на http://job.fotostrana.ru

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

Дело в том, что недавно я просматривал собственные посты и заметил, что в одном из них задача решается далеко не лучшим образом. Речь шла о блокировке доступа к блогу на движке WordPress.

Решение, которое я тогда предложил, работоспособное и им вполне можно пользоваться. Но только какое-то оно сложное

Нужно было использовать несколько файлов .htaccess для разных папок блога. Доступ для администратора получался немного ограниченным, например, статические ссылки не работали.

И, самое главное. Как абсолютно верно заметил Олег Лобач в комментариях к тому посту, если сайт закрыт на обслуживание, то необходимо отправлять заголовок с 503 кодом (Service Unavailable).

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

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

Нужно будет выполнить всего два шага.

1) Создать страницу, которую будем показывать посетителям во время обслуживания сайта.

2) Добавить пару строк в файл .htaccess, который находится в корне блога.

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

Идея заключается в ограничении доступа на основании IP адреса. Т.е. при попытке доступа к сайту web сервер (apache) проверит ваш IP и если он не совпадет с заданным, то все запросы будут перенаправлены на специальную страницу.

Итак, приступим.

Шаг 1. Создаем страницу с сообщением о том, что сайт временно закрыт.

Назовем её maintain.php и разместим в корне сайта.

Обсуждать тут особенно нечего. Саму страницу, конечно, лучше оформить в соответствии с общим дизайном сайта.

Но сейчас важнее заголовки (строки 2 и 3). Для их отправки используется стандартная функция PHP – header. В её первом параметре указываем заголовок.

Первый заголовок отправляет 503 HTTP код, а второй (Retry-After) – время, через которое рекомендуется обновить страницу. В данном примере я установил 1 час (3600 сек), но вы можете выбрать любой интервал времени по своему усмотрению.

Шаг 2. Определяем собственный IP.

Тут ситуация следующая. Если у вас статический IP адрес, то вы его знаете и определять ничего не надо

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

Поэтому заходим на эту страницу и переписываем свой текущий IP-шник.

Шаг 3. Делаем резервную копию файла .htaccess.

Например, с названием .htaccess_main.

Шаг 4. Добавляем проверку IP.

В качестве примера, рассмотрим .htaccess, который часто используется в блогах на WordPress.

Примечание. Правила в этом файле подходят для любого движка, в котором запросы обрабатываются скриптом index.php. Например, для сайтов, использующих фреймворк CodeIgniter такой .htaccess тоже вполне подойдет.

Добавляем две дерективы после RewriteBase /

Т.е. в результате получится.

Естественно, вместо 127.0.0.1 нужно указать свой реальный IP адрес.

Принцип работы предельно простой. В директиве RewriteCond (строка 5) мы сравниваем IP адрес посетителя с указанным. И если они не совпадают – отправляем посетителя на maintain.php (строка 6). Буква L в квадратных скобках указывает, что если это правило выполнилось, то обработку запроса нужно прекратить. Т.е. все последующие строки будут проигнорированы.

Если же вы сами заходите на сайт (IP-шники совпадают), то директива RewriteRule (в строке 6) пропускается и web сервер обрабатывает запрос как обычно.

Шаг 5. Восстанавливаем доступ к сайту.

Для этого просто восстанавливаем старый .htaccess файл из резервной копии.

Небольшое дополнение.

Если в процессе работы у вас изменится IP адрес, то вам нужно повторить шаг 2, создать .htaccess с новым IP и скопировать его в корень сайта по FTP.

Вот и все!

Все вопросы и замечания оставляйте в комментариях. Буду рад ответить или обсудить

До встречи!

Интересно почитать

Штукатурка кирпича по пеноблокам – достаточно сложная операция… но только не для профессионалов!
Узнать все объявления белоруссии вы сможете с помощью нашего сайта.

Представьте ситуацию. Вы ведете новостной блог, публикуете несколько постов в день, постепенно становитесь популярным . Количество комментариев постоянно растет, только спама появляется все больше…

Бороться с этим явлением можно разными способами от установки CAPTCHA до использования специальных служб вроде Akismet. Но вы находитесь в менее выгодном положении, чем большинство блоггеров. Постов очень много и естественно вы не сможете легко вспомнить, о чем шла речь полгода назад.

К тому же все чаще появляется спам, добавленный людьми. CAPTCHA от него не защищает вообще, Akismet тоже часто ошибается. Да что там Akismet, иногда, читая такой комментарий, сам сомневаешься спам это или нет. Приходится смотреть о чем был пост, а это требует времени.

Но, как правило, новости широко обсуждаются только в момент их появления, а потом о них забывают. Точнее они становятся историей .

Именно для таких постов можно применить самый надежный метод защиты от спама – закрыть комментарии.

Сделать это можно вручную через админ-панель WordPress, но есть способ проще.

Достаточно установить плагин Close Old Posts. Он будет автоматически закрывать комментирование для старых постов.

По-умолчанию, это происходит через 14 дней с момента публикации поста. Естественно эту настройку можно изменить.

Для этого нужно открыть единственный файл плагина close-old-posts.php и изменить переменную:

В остальном установка ничем не отличается от большинства других плагинов.

1) Распаковываете архив в папку wp-content/plugins.

2) Активируете.

После этого форма комментирования исчезнет во всех постах старше 14 дней.

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

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

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

До встречи!

Интересно почитать

InTravels- on-line журнал о путешествиях и туризме

О 404 ошибке знает, наверное, каждый web мастер, а о том, что ее нужно использовать с максимальной выгодой для себя – каждый оптимизатор .

Ситуация следующая. Эта ошибка возникает, если посетитель обращается к несуществующей странице вашего сайта. Как и почему это произошло – вопрос другой. Может быть, вы сами удалили статью, а может, изменили ссылку на нее, сейчас это не важно.

Вам нужно любой ценой оставить посетителя на сайте .

Самое главное – не показывать посетителю стандартную страницу, которую возвращает web сервер. Она создает впечатление, что сайт не работает вообще.

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

ErrorDocument 404 /index.php

Вариант не идеальный, но, по крайней мере, посетитель будет знать, что сайт работает, увидит навигационную панель, ссылки на какие-нибудь статьи. Если речь идет о блоге, то не помешает раздел «Самое читаемое».

Второй вариант – создать специальную страницу, красиво ее оформить, и разместить на ней форму поиска и/или ссылки на самые популярные статьи.

Кстати, очень неплохой и распространенный вариант. Например, многие темы для WordPress имеют такие страницы ошибок.

Только тут есть одна проблема. В начале таких страниц обычно пишут текст вроде «Извините, но страница, которую вы искали, отсутствует. Попробуйте воспользоваться формой поиска…». Т.е. посетитель видит сообщение об ошибке, написанное большими буквами, и уходит.

В общем, этот текст лучше убрать. Пусть посетитель смотрит на список ваших лучших материалов.

Третий вариант – попытаться предоставить посетителю ту информацию, которую он ищет. Для этого можно воспользоваться сервисом Google AJAX Search API. Он позволяет встроить в вашу страницу результаты поиска Google. Естественно, можно показывать результаты поиска только по вашему сайту.

Для того, чтобы реализовать этот вариант вам нужно зарегистрироваться в сервисах Google и получить Google Search API Key.

Вместе с ключом вы получите html код демонстрационной страницы. Впрочем, владельцам блогов на движке WordPress эта страница не нужна, т.к. существует плагин, который сделает все за вас .

Плагин называется AskApache Google 404.

Установить и настроить его не сложно. Вам нужно только ввести ключ и немного изменить тему. Добавить строку

в файл 404.php.

Теперь самый главный вопрос: «Посетитель зашел на несуществующую страницу. Что искать?».

Плагин поступает очень просто. Он берет название страницы и подставляет его в строку поиска. Например, если посетитель обратится к странице sitename/wordpress-404-plugin, то на странице появятся результаты поиска для слов «wordpress», «404», «plugin».

Это очень удобно, если вы переименовали страницу и изменили ссылку на нее. Вероятность того, что переименованная страница окажется в выдаче очень высокая. Кроме того, в выдаче окажутся и другие статьи на эту же тему.

Правда для русскоязычных блогов ситуация немного сложнее, т.к. ссылки обычно записываются транслитом. Но, по моим наблюдениям, Google обычно нормально его распознает и предлагает повторить поиск для слова на русском языке.

Если этот плагин вас заинтересовал, заходите на его официальный сайт. Там вы найдете "живую" демонстрацию, скриншоты и ссылки на видеоролики с подробными инструкциями.

Как видите, возможностей море. Главное правильно их использовать.

До встречи!

Недавно я наткнулся на одну очень интересную тему для WordPress – WP-Coda. Выглядит просто шикарно! Но дело не в этом.

Эта тема использует довольно много эффектов, реализованных с помощью JavaScript.

Мне стало интересно, во сколько эта красота обходится посетителям, и оказалось, что не так уж и дорого. Всего один js-файл размером 45кБ.

Дело в том, что автор упаковал семь исходных файлов в один и после этого сжал его упаковщиком вроде Packer JavaScript en PHP.

Но первый же эксперимент показал, что это не предел. Если упаковать этот файл в gzip архив, то его размер уменьшается до 21кБ. А большинство современных браузеров прекрасно работают с такими архивами.

При этом нет необходимости что-либо переделывать в самой теме.

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

После этого в файл .htaccess добавляем правила:

<IfModule mod_rewrite.c>
	RewriteEngine On
	AddEncoding gzip .gz
	RewriteCond %{HTTP:Accept-encoding} gzip
	RewriteCond %{HTTP_USER_AGENT} !Safari
	RewriteCond %{REQUEST_FILENAME}.gz -f
	RewriteRule ^(.*)$ $1.gz [QSA,L]
</IfModule>

Работают эти правила так.
1) включаем RewriteEngine;
2) указываем, что файлы с расширением .gz имеют MIME тип gzip;
3) начинаем проверки:
3.1) если браузер принимает gzip;
3.2) если это не Safari (у него вроде есть проблемы с gzip);
3.3) если существует файл с таким же именем, как и у запрошенного, но с расширением .gz;
4) если все проверки прошли успешно, то добавляем к имени файла расширение .gz и отправляем этот файл браузеру.

Таким образом, если браузер не работает с gzip, то он получит исходный файл, если поддерживает – получит архив.

Посетитель разницы не заметит. Разве что немного увеличится время загрузки страницы.

В качестве примера, взгляните на скриншоты Firebug, сделанные для блога с темой WP-Coda.

Исходный вариант:

После сжатия и установки правил в .htaccess:

Кстати, заметьте, имя файла в обоих случаях одно и тоже. Изменяется только его размер. Т.е. браузер в обоих случаях считает, что получил файл, указанный в теге script (global.js), а сервер отправляет в первом случае global.js, а во втором – global.js.gz.

На мой взгляд, такой подход имеет только один недостаток. Во время разработки очень не удобно работать с одним большим js файлом, тем более сжатым

Вручную упаковывать файлы тоже не интересно, поэтому нужно автоматизировать процесс.

Для этих целей я написал небольшой php скрипт.

Принцип работы следующий. Вы указываете папку с js файлами (JS_DIR) и имя файла в который будут упакованы все скрипты (JS_OUTPUT_FILE).

Скрипт читает содержимое всех файлов с расширением js из папки и сжимает его.

Примечание. Для сжатия используется PHP версия библиотеки JSMin. Она просто удаляет пробелы и комментарии из исходных файлов.

После этого сжатые скрипты записываются в файл, указанный в JS_OUTPUT_FILE. Именно этот файл нужно подключать к вашим страницам.

Следующим этапом php скрипт создает архив (с помощью функции gzencode), который получает имя JS_OUTPUT_FILE.gz.

Для тестирования я взял библиотеку jQuery и написал js-файл с небольшой функцией, которая создавала пару эффектов.

Т.е. в исходном варианте было 2 файла:
jquery-1.2.3.js – 96кБ
script.js – 1кБ

Сжатый вариант:
global.js – 53,1кБ

Архивный вариант:
global.js.gz – 16кБ

Как видите, разница довольно ощутимая.

Если есть желание поэкспериментировать, качайте архив с скриптом и библиотекой JSMin.

До встречи!

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

Прежде всего, это
DirectoryIndex

Она определяет, какой файл будет отправлен посетителю, если он не указал его имя явно. В параметрах этой директивы перечисляются имена файлов. Например:

DirectoryIndex index.php index.html index.htm

Приоритет имеет тот файл, который идет первым в списке. Т.е. если папка содержит index.php и index.html, то посетителю будет отправлен index.php.

Теперь небольшой пример. Допустим, сайт имеет такую структуру.

/
index.html
page1.html
page2.html
css/
    styles.css

По адресу http://sitename/ вы увидите страницу index.html.
Но если зайти в папку css (http://sitename/css), то картинка будет примерно такая

Список файлов на сервере

Т.е. сервер покажет вам список файлов в этой папке. Не думаю, что кому-то понравится такое поведение сервера.

Исправить ситуацию можно с помощью директивы:

Options -Indexes

Примечание: символ «-» перед словом Indexes означает, что индексирование содержимого папок запрещено.

Теперь если вы попытаетесь зайти в папку css, то увидите сообщение:

Forbidden
You don't have permission to access /css/ on this server. (у вас нет прав для доступа к /css/ на этом сервере).

При этом доступ к файлу styles.css (http://sitename/css/styles.css) сохраняется.

Если вы не можете конфигурировать Apache (например, сайт находится на shared хостинге), то создайте в корне сайта файл .htaccess с этой директивой.

В этом случае индексирование будет запрещено не только для корневой папки, но и для всех вложенных папок (если, конечно, они не содержат своих файлов .htaccess).

Правда, этот метод может не работать. Дело в том, что обработка файлов .htaccess может быть запрещена директивой AllowOverride none (в файле httpd.conf).

В этом случае вам нужен либо доступ к httpd.conf, либо придется в каждой папке размещать файлы index.html с каким-нибудь текстом (что-то вроде Access forbidden). Кстати, разработчики фреймворка CodeIgniter именно так и поступают (в каждой вложенной в system папке находится index.html).

Примечание. Для того чтобы вступили в силу изменения в httpd.conf нужно перезапустить сервер. Изменения в .htaccess начнут работать сразу после сохранения файла.

Спонсор статьи:
Записки webмастера. Читать всем!