[Plugins] Обзор плагинов — выпуск 1

На работе редкостная скукота, не смотря на то, что понедельник. Да и вообще я уже наметил увольняться, а то сидеть и тухнуть в бесперспективном месте — не для меня.

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

Yank Widget (v.1.0)

Версии WordPress: с 2.5 по 2.6

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

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


TinyMCE Entities Patch (v.1.0)

Версии WordPress: все версии ветки 2.5.x

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

Если вы пишете посты в визуальном редакторе и вам требуется отобразить код html-спец.символов (например, &gt; — > ,&lt; — <, &quot; — "), то начинается целая борьба с редактором, так как он автоматически преобразует коды в сами символы.

Собственно плагин позволяет:

1. Вводить коды html-спец. символов (т.н. html-entities) в виз.редакторе, без боязни их преобразования после сохранения.

2. Сохранять "дополнительные" пробелы между словами/предложениями, а не преобразовывать их в единичный пробел.

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

Важно! Если вы поставили себе WordPress 2.6, то там, в визуальном редакторе уже исправлена эта ошибка, поэтому не устанавливайте и/или отключите этот плагин. (Ещё один повод перейти на новую версию :D)


Context Ad Wrapper (v.0.2)

Версии WordPress: все выше 2.2.0

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

На данный момент плагин работает со следующими конторами:

  1. Google Adsense
  2. Amazon.com Context Links
  3. Kontera ContextLink
  4. MediaText

Жаль, что нет РСЯ и Бегуна, но я вообще не уверен, что там можно указывать контентные блоки, для более качественной отдачи объявлений.


EasyBan (v.1.2.3.1)

Версии WordPress: с 2.5 по 2.5.1

Позволяет забанить посетителя временно или навсегда по следующим параметрам: IP (отдельно или диапазон адресов), домену или реф.ссылке. 

image

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

До следующих выпусков. Удачи.

Быстрее-легче-стабильнее или “немного” о Wp-Super-Cache.

Почему-то, как мне показалось, довольно тихо прошло появление очередного «всесильного всемогущего сокращающего время загрузки и нагрузку на сервер» плагина WP-Super-Cache, а ведь за бугром о нём только ленивый не писал и даже успели отDiggать страницу плагина почти тысячу раз. Поэтому, думаю, стоит всё же приглядеться и пощупать это чудо программерской мысли.

Итак, что же может этот плагин, для чего/кого он предназначен и чем лучше аналогичных стандартных и не очень средств кэширования?


Введение
Большинству пользователей WordPress’а известен прекрасный плагин WP-Cache 2. Он кэширует страницы блога и отдаёт их по запросу без обращения к базе данных. Несмотря на это, всё же приходится подгружать определенный php-код, чтобы обслуживать уже кэшированные страницы, чтобы там не говорили на странице о wp-cache (прародитель wp-cache2)

WP Super Cache действует по другому принципу. После установки, создаются html файлы, и они отдаются браузеру без единого вызова php. Насколько быстро ваш сервер отдаёт картинки? Почти так же быстро он будет выдавать и кэшированные страницы. Если вашему сайту ежедневно приходится справляться с массированным потоком посетителей или периодически испытывать Дигг-эффект, то этот плагин для вас.

Как оно работает то?
Как обычно действуют люди, подготавливая свой сайт к массовому паломничеству с дигга? Они в ручную сохраняют копию страницы, которая теоретически будет генерить основной траффик, и помещают её в папку соответствующую пермалинку. Этот метод помогает серверу выдерживать большие нагрузки и не «умирать», но эффективность его напрямую зависит от возможности предсказывать потоки пользовательского интереса к страницам. Сам по себе WP-Cache хоть и полезен, но в определенных ситуациях не совсем адекватен, тогда как WP Super Cache как раз и был создан, чтобы воссоздавать этот процесс автоматически.

Когда к странице обращается незалогиненый посетитель или он не оставляет комментариев, то сервер отдаёт ему статическую html-страницу из подпапки supercache, которая создаётся в cache папке WordPress. Если вы зайдёте в эту папку (например по фтп), то обнаружите точную копию своей пермалинк структуры в виде папок и отдельные html-файлы в каждой из них. Чтобы убедиться, что страница создана плагином, достаточно просмотреть её исходный код и вы обнаружите там следующую строку в самом конце <!— super cache —> или <!— super cache gz —> для сжатого варианта.

Залогиненым же пользователям или тем, кто оставит комментарий, будет показана кэшированная страница, созданная средствами стандартного WP Cache, где в конце будет значится <!— Cached page served by WP-Cache —>.

Фишки/Отличия от WP-Cache

  • Собственная система hook’ов, для более тонкой настройки кэширования (важно только разработчикам).
  • Прекрасно работает и с WordPress MU в VHOST и не-VHOST конфигурациях. Файлы каждого блога кэшируются независимо друг от друга.
  • Стандартные файлы WP-Cache разбиты на 2 части. Мета-файлы теперь располагаются в отдельной папке, что увеличивает скорость обращения к ним и определения необходимости обновления кэша.
  • Встроена заплатка для WP-Cache при работе с защищенными постами.
  • Автоматически отключает gzip-сжатие в WordPress вместо того, чтобы «умереть».
  • Улучшена работа с Akismet и иными плагинами борьбы со спамом — кэш будет обновлен, только если комментарий 100% не спам.
  • Кнопка «lock down» (защёлкнуть) — подготавливает сайт к мощному наплыву посетителей. После включения «защёлкивает» статичные кэш файлы и не удаляет их после добавления нового комментария.
  • Автоматическое внесение изменений в .htaccess (Не забудьте сохранить свой .htaccess перед установкой плагина).
  • Не кэшируются запросы с GET-параметрами.
  • Улучшенная проверка совместимости wp-cache-config.php и advanced-cache.php, если вы пользовались старой версией.
  • Улучшена поддержка Microsoft Windows.
  • Правильно работает с кэшированными страницами в ОС Red Hat/Cent или других, содержащих запись для gzip в /etc/mime.types.
  • Функция «Не кэшировать следующие адреса» теперь может использовать регулярные выражения.

Минусы

  • Если вы залогинен или оставили комментарий, вы никогда не увидите super-cache страницу. Вам всегда будет выдаваться старый-добрый WP-Cache. Это не так уж и плохо, так как большинство ваших посетителей никогда не оставляют комментарии.
  • Для работы со статическими страницами используется Mod Rewrite Апача, поэтому необходимо, чтобы он был активирован на сервере.
  • Особо динамичные части вашего сайта не будут обновляться так быстро, как хотелось бы. Например, виджет — последнии комментарии.
  • Некоторые хостинги испытывают проблемы при работе со сжатыми html-файлами, т.ч. может потребоваться дополнительная настройка.
  • Не рассчитывайте, что дешевый хостинг выдержит большой всплеск трафика, даже если страницы будут кэшированы.
  • Помните, что динамический контент, вроде того, который размещается в сайдбаре, будет обновлен только когда будет обновлена кэшированная страница. Время до обновления можно настроить, но кэшированные файлы будут удалены лишь в том случае, если у вас будет смесь из статических и динамических запросов.
  • Некоторые плагины, такие как SK2, Bad Behaviour и другие, работа которых зависит от «свежести» данных, могут работать не совсем корректно, во всяком случае, до тех пор, пока эти плагины не будут специально оптимизированны для очищения кэша в нужный момент.

(с) Автор Плагина


Это всё конечно интересно и красиво на словах, но работает ли оно в действительности? Сам я не мастер нагрузочного тестирования, поэтому приведу выкладки других людей.

Во-первых, автор плагина ставит в пример себя — после анонса Wp-Super-Cache на дигге, посещения скакнули до 4700 пользователей, что прямо скажем не мало. И вот какие графики получились — первый нагрузка на процессор, второй — посещения.
wp super cache plugin cpu graph
wp super cache plugin visits graph
Отчётливо виден момент активации кэширование (падение нагрузки на процессор), а так же приятно наблюдать, что рост посещений никак не сказывается на процессоре.

Во-вторых, некий Роберт провёл замеры производительности для 1000 запросов. Тестировал по локальной сети, на сервере (P4 — 3Ghz, 2GB RAM) поставил чистый ВордПресс и с другой машины делал запросы.

Результаты:
а) стандартный WordPress без кэша:
— время на тест — 161 сек;
— запросов в секунду — 6.21/сек
— время на 1 запрос — 161 мсек
— скорость передачи — 31.07 Kbytes/сек

б) WordPress + Super Cache:
— время на тест — 5.718750 сек;
— запросов в секунду — 174.86/сек
— время на 1 запрос — 5.719 мсек
— скорость передачи — 898.62 Kbytes/сек

в) WordPress + Super Cache + eAccelerator:
— время на тест — 2.531250 сек;
— запросов в секунду — 395.06/сек
— время на 1 запрос — 2.531 мсек
— скорость передачи — 2030.22 Kbytes/сек

Думаю, комментарии излишни.

Включил сейчас плагин на этом блоге, на пару минут для теста активировал gzip-сжатие и проверил, как реагируют браузеры. С Оперой и ФФ всё ок, а ИЕ6 как обычно отличился — предложил сохранить локально .html.gz страничку) Чтобы не пугать людей, сжатие отключил, но вообще нужно будет разобраться почему ИЕ так отреагировал.

Плагин в установке достаточно прост, особенно если следовать рекомендациям в readme :-), а вот настройка для тех, кто не видел до этого Wp-Cache2, возможно покажется непонятной. С другой стороны Wp-Super-Cache довольно специфическая вещь и не факт, что окажется востребованным.

Хотелось бы узнать — нужно ли отдельным постом расписывать установку и настройку?


Кстати, курсовая и 2 из 4 экзамены сданы на отл., что ещё немного приближает ко второму красному диплому :p
Заинтересовался я тут eAccelerator, интересно, удастся ли мне поставить его на виртуальную площадку у МастерХоста. Если да, то напишу как и что я делал.
Удачного дня и побольше Дигг-эффектов.