Архив категории: ‘Плагины’

Небольшой хак для All in One SEO Pack

Monday, 20 Oct 08 в 1:00

wordpress плагинВ одной из прошлых статей я уже писал о том, как увеличить трафик для блога с помощью wordpress плагина All in One SEO Pack. Если говорить вкратце, то основная его заслуга - возможность добавления в каждом посте (или странице) заголовка (title), описания (description) и ключевых слов (keywords). Потратив несколько минут на подборку ключевых слов и заполнение данных полей вы вправе ожидать на небольшое количество трафика с поисковых систем - конечно, речь идет не о топовых запросах, но низкочастотные вполне могут сработать. Подробнее об этом читайте по ссылке выше, а сейчас я бы хотел рассказать немного о другом.

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

Теоретически понятно, зачем создатели плагина All in One SEO Pack сделали подобную функциональность - дабы пользователю не пришлось заполнять каждый раз поле keywords, а оно формировалось автоматически, но ведь должна быть возможность отключить эту опцию. Кстати, здесь возникает еще один нюанс. У меня в блоге установлен также плагин Simple Tags, который выполняет множество функций, связанных с тегами - позволяет создать облако тегов, выводит похожие по тематике посты после каждой статьи и т.п. В качестве одной из функций указано «Automatically include in header», которая также отвечает за включение тегов в МЕТА keywords. Но при этом в админке есть примечание - если в блоге установлен и настроен плагин All in One SEO Pack, то эта опция автоматически отключается!

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

В общем нашел в плагине All in One SEO Pack участок кода, который отвечает за все это “безобразие”. Итак, если вы хотите чтобы в ключевых словах для поста выводились только заданные вами значения, находим в файле плагина all_in_one_seo_pack.php строки:

// WP 2.3 tags
if (function_exists('get_the_tags')) {
 $tags = get_the_tags($post->ID);
 if ($tags && is_array($tags)) {
  foreach ($tags as $tag) {
   $keywords[] = $this->internationalize($tag->name);
  }
 }
}

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

Подсветка программного кода в постах (для Wordpress)

Friday, 25 Jul 08 в 1:19

Вставка кода в текст блогаДостаточно часто возникает желание вставить в посте часть кода из какого-то языка программирования. Как оказалось, сделать это в Wordpress быстро и просто не получается, приходится немного потрудиться. Что я только не пробовал дабы вставки HTML, Javascript или хотя бы PHP выводились в блоге корректно - использовал и <code>, и <pre>, но, к сожалению, результаты были не утешительные. Возможно, конечно, кое где я ошибся сам, но, тем не менее, проблема вставки и разных исходных кодов была для меня актуальной достаточно долго. Недавно я заставил себя сесть и разобраться с ней раз и навсегда. Забегая наперед, скажу, что частично это мне удалось.

Проблема размещения в блоге исходного кода не самая серьезная, но иногда дает о себе знать. Особенно это касается различных постов, где вы описываете операции, относящиеся к программированию. Без примеров в таких случаях не обойтись, а движок Wordpress, как назло, вносит в код свои «правки». Текстовый редактор неоднозначно воспринимает символы одинарной и двойной кавычек, преобразуя их текстовые аналоги:

Wordpress иногда коверкает исходный код

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

Кстати, по старинке я вставлял код с помощью Macromedia Dreamweaver (теперь уже Adobe® Dreamweaver® CS3) , который позволял с легкостью получить из обычной записи тот же исходный код, но полностью в HTML (скобки < > заменялись на специальный символы). Увы, от проблемы с кавычками это не спасало. Поэтому пришлось искать альтернативные методы. В принципе, можно было бы сохранять исходники в текстовые файлы, после чего в статье на них ссылаться, но это, пожалуй, применимо лишь для больших объемов кода. Во всех остальных случаях - создавало бы лишние проблемы для посетителей.

Плагины wordpress для подсветки кода

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

Raw HTML (скачать плагин)

Самый простой плагин. Позволяет вставлять HTML код в посты. Оборачивание текста в тэги <!–start_raw–>…<!–end_raw–> или [RАW]…[/RАW] предотвращает его преобразование. Во время вставки кода настоятельно рекомендуется выйти из визуального редактора в режим HTML. Поддерживает версию системы до 2.5.1.

CodeColorer (скачать плагин)

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

Вставка кода в wordpress с помощью плагина CodeColorer

CodeColorer обладает также рядом дополнительных интересных свойств, например, нумерацией строк, настройкой подсветки синтаксиса, подсветкой кода в комментариях и т.п. Модуль имеет достаточно широкий спектр настроек и большой список поддерживаемых языков. Единственное, что заставляет задуматься, это требования к версии wordpress - 2.1. Поэтому гарантии безотказной работы в более старших версиях нет. Подробнее о плагине на русском языке можете почитать в этом обзоре.

SyntaxHighlighter Plus (скачать плагин)

Плагин такой же серьезный, как предыдущий, хотя выглядит поживее - поддерживается версия wordpress 2.5.х. Если говорить о возможностях, то они идентичны CodeColorer - подсветка, нумерация строк и т.д. Возможно, имеются какие-то отличия на более глубоком уровне, но в глаза бросается лишь другое визуальное оформление:

Подсветка кода с помощью плагина SyntaxHighlighter Plus

Если присмотреться, то можно над кодом заметить дополнительные ссылки/функции view plain (просмотр кода в отдельном окне) copy to clipboard (копировать в буфер обмена) и print (печать). В блоге плагина есть небольшое описание, правда на английском. Хотя, в принципе, информации на официальном сайте wordpress вполне достаточно.

WP-Syntax (скачать плагин)

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

<pre lang=”LANGUAGE” line=”1″> … исходный код … </pre>

Где LANGUAGE - задает язык программирования, а необязательный параметр line указывает с какого числа начинать нумерацию строк в коде. Получаем:

Выделение кода в wordpress в помощью плагина WP-Syntax

Вообще из всех четырех плагинов я не попробовал лишь CodeColorer, по остальным свое впечатление сложилось. Raw HTML слишком прост и не очень нагляден, SyntaxHighlighter Plus наоборот слегка «громоздкий», поэтому я выбрал золотую середину - WP-Syntax. Не исключено, конечно, что в дальнейшем установлю более продвинутый модуль, например, чтобы в комментариях код также подсвечивался. Только для начала нужно «прикрутить» в форму комментирования кнопки для форматирования или хотя бы добавить описание допустимых тэгов. В общем, работать еще есть над чем, а пока главное чтобы читатели могли видеть и использовать корректный код.

Кстати, при активном использовании Raw HTML и WP-Syntax заметил небольшую особенность. Как уже говорил выше, редактирование кода требуется производить при выключенном визуальном редакторе в режиме HTML, иначе при сохранении могут возникнуть глюки в виде исчезновения отдельных частей исходного кода. Все это оставило не очень приятный осадок после работы с плагинами, тем не менее, насколько я понимаю, от этого никак не избавиться. Поэтому будьте предельно внимательны!

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

P.S. Дмитрий Ветров предлагает обсудить вопрос должен ли блог быть авторским?

Кстати, если вы хотите раскрутить свой блог или проект, можете воспользоваться рекламными услугами в этом блоге - приобретаем спонсорство в месяц (около 15-ти публикаций) за $50 или постовые по $5 за ссылку. Также свободен баннер 125х125 под блоком контактов - всего $30.

Спасибо спонсорам:

Определение безопасности блога - плагин WP Security Scan

Sunday, 22 Jun 08 в 0:14

Определение безопасности блога - плагин WP Security ScanСегодня хочу поговорить о безопасности блогов на WordPress и плагине, который делает ее более прочной. Это - WP Security Scan. Главной задачей модуля есть сканирование установленной версии системы и проверка ее на возможные прорехи в безопасности. После скана, плагин предлагает выполнить корректировку для уменьшения рисков взлома вашего сайта.

Чтобы установить модуль просто скопируйте его установочные файлы (целиком всю директорию wp-security-scan) туда, где располагаются остальные ваши плагины - wp-content/plugins/. После этого заходите в меню Plugins и активируете его - появится новый раздел Security.

Wordpress, раздел Security

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

Своевременное обновление. Запомните, установка последней версии системы - первый и самый основной ключ к обеспечению безопасной работы всего сайта. Разработчики постоянно трудятся над устранением багов и дыр, поэтому каждый новый релиз содержит исправления львиной доли прорех в защите. Последняя доступная на данный момент версия системы - Wordpress 2.5.1. Обновитесь, кто еще не успел! Стыд мне и позор, но я принадлежу именно к таким людям, о чем свидетельствует предупреждение WP Security Scan.

Таблицы в базе данных. Все таблицы в базе данных имеют префикс wp_ - wp_comments, wp_posts и т.д. Дабы обезопасить себя от SQL инъекций лучше его сменить. Чем меньше злоумышленник знает о настройках вашей системы - тем сложнее ему будет навредить. Для данного дела в разделе Security имеется специальная закладка - Database.

Внимание! Перед сменой префикса очень рекомендуется сделать бэкап (резервную копию) базы. Для успешного завершение процесса требуется чтобы файл настроек wp-config.php имел права на запись, а пользователь БД - возможность выполнять команду ALTER.
Если все эти условия у вас выполняются, то в форме на странице указываем префикс, на который мы хотим заменить стандартный, и нажимаем кнопку Start Renaming.

Безопасность базы данных

Теперь, зайдя в phpmyadmin, вы обнаружите новые названия таблиц. Кстати, разработчики плагина говорят, что бывали случаи, когда WP Security Scan на срабатывал, поэтому в документации (на англ.) описаны действия для ручного изменения префикса.

Отображение версии системы. Опять же, меньше информации - лучше защита. Если злоумышленник узнает версию системы, то сможет понять какие прорехи у вас есть. Зачем давать каждому понять, что вы еще не обновились. Версию системы убрать очень просто - в файле шаблона header.php (где содержится информация из блока HEAD) убираем META тэг generator или указываем в нем, например, номер последней версии.

Другие. К сожалению, не совсем понял на что влияют указанные элементы защиты «WordPress DB Errors turned off.» и «WP ID META tag removed form WordPress core» - у меня они сразу были «в норме». Первый параметр WordPress DB Errors по идее можно поискать в настройках системы (Options), а второй в исходном коде.

Имя пользователя. По умолчанию имя пользователя устанавливается в Admin. Если рассуждать логически, то это просто громадный «подарок» для злоумышленника - ему не придется тратить время на подбор логина, останется разузнать только пароль. Для изменения пароля потребуется какой-то инструмент для работы с MySQL на вашем сервере, скорее всего это будет phpmyadmin. Итак, заходите в базу данных, открываете таблицу wp_users (или подобную ей, если вы уже сменили префикс), находите запись admin в поле (колонке) user_login. Изменяете его значение и сохраняете новое.

Защита директории wp-admin. С помощью .htaccess файла можно запретить вход в админку всем неизвестным ip адресам, чтобы заходить могли только вы со своего домашнего и (или) рабочего компьютера. Считаю, это действительно очень хороший способ себя обезопасить, дабы ни у кого и в мыслях не было угадывать пароли. Чтобы реализовать данный метод создаете файл .htaccess, где пишете следующий текст:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName “Access Control”
AuthType Basic
order deny,allow
deny from all
allow from 91.250.120.20

В принципе, можно работать и без первых 4-х строк, но в некоторых примерах видел именно такую комбинацию. Что конкретно означают эти команды не разбирался, но информацию о них в Интернете я встречал. Строка deny from all запрещает любой доступ к директории wp-admin, а следующая как бы задает исключение для вашего ip адреса. Кстати, если у вас динамический айпишник, то запись в примере выглядела бы так:

allow from 91.250.120. (в конце строки должна быть точка, что символизирует «пустой» последний параметр).

После создания файла не забудьте записать его на фтп в директорию wp-admin!

Кроме того, в плагине WP Security Scan есть еще 2 опции: сканер и механизм проверки прочности паролей. Находятся они в соответствующих пунктах меню раздела Security. Если по второму пункту все понятно, то скажу немного слов о сканере. Он проверяет права пользователя, установленные на разные директории вашего сайта, и сравнивает их с требуемыми значениями. Когда все ок, то получится такая приятная картинка:

Безопасность в Wordpress - права на файлы и директории

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

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

P.S. Открыл для себя еще одну систему продажи ссылок на сайтах - Setlinks. С сапой тягаться, конечно, пока рано, по попробовать поработать с ней будет интересно. Пользователей, кстати, там 23 тыс.

При поддержке: