Minor update for WordPress 2.7 compatibility.

I know I haven’t updated UseShots Editor since summer. I was pretty busy with my other project Unmask Parasites. But I still use UseShots Editor myself (here is a couple of my latest blog posts created with UseShots Editor: 1, 2.).

A few days ago, when WordPress 2.7 RC2 was released, I discovered that UseShots Editor produced the ” -2: Key [description] not found” error. My first thought was it was a bug introduced in RC2. I even found a suspect change in WP code and reported it in WP support forum.  However when forum members failed to reproduce the error, I double-checked the issue and discovered a bug in my own code.

In versions prior to WordPress 2.7 RC2, they ignored category descriptions in XMLRPC responses for the metaBlogger.getCategories call and always returned the category name in the “description” field. This way the “description” field was never empty. However in RC2, the started to pass actual category description (which may be blank and is usually blank for the “Uncategorized” category) in that field. For some reason in UseShots Editor, I didn’t check whether all fields in the responce are non-empty. It worked for previous versions of WordPress but no longer works for WordPress 2.7.

That’s why I decided to release  an emergency update to make UseShots Editor fully compatible with the latest version of WordPress, which you definitely should upgrade to.

You can download UseShots Editor v0.6.1.63 here.

Tags: update, WordPress 2.7 bug

WordPress 2.7 Released. With XMLRPC bug.

WordPress 2.7 has been released. It’s a major upgrade (especially in terms of GUI).

I’ve been using beta versions of 2.7 for quite some time for my other blog and I must admit I like it. However yesterday, with the Release Candidate 2, they added a bug to version 2.7 which was not fixed in this final release.

This bug prevents offline clients like Windows Live Writer and UseShots Editor to load a category list from a server if even one category doesn’t have a description. This is a nasty bug since many people don’t assign description to categories. And there is a default pre-installed “Uncategorized” category that doesn’t have a description. This means your offline blogging clients won’t work smoothly with WordPress 2.7.

I reported this bug in WordPress support forum. Until it is fixed, I don’t advise to upgrade to version 2.7 if you use XMLRPC-based clients.

Update: Thanks to responses in the forum I realized that the bug was in UseShots Editor, not in WordPress 2.7. Sorry for the false alert. You definitely should upgrade to WordPress 2.7 - you’ll like it.

I have fixed the bug and released an emergeny update of UseShots Editor.

Tags: WordPress 2.7 bug, xmlrpc

Googlebot теперь находит ссылки и в JavaScript’е.

Должно быть я что-то пропустил. Всегда думал, что Google не видит ссылки внутри JavaScript кода. А даже если и видит, то такие ссылки не имеют никакой ценности для SEO: при подсчёте PR они не учитываются и для индексации не используются, т.е. если на страницу можно попасть только в результате выполнения скрипта и на неё нет прямых ссылок, то такая страница не будет проиндексирована вообще. И что? Это информация уже устарела?

Вот моя история.
Есть у меня один новый сайт. Ему всего месяц, страниц мало и входящих ссылок пока почти нет. Поэтому достаточно легко проследить то, как он индексируется Гуглом. На сайте в тестовом режиме работает сервис, проверяющий веб страницы на предмет скрытых вредных включений (невидимые спаммерские ссылки, iframe’ы, скрипты, редиректы). Для работы сервиса активно используется AJAX.

Недавно, проверяя статистику посещений, увидел, что кто-то зашёл ко мне с Гугла по запросу types of hidden spam. Я решил посмотреть, на какой месте показывается мой сайт в результатах по этому запросу. Оказалось, что на первом. И это при общем количестве результатов превышающем 14 миллионов. Приятно, но немного неожиданно для очень нового сайта.

Ещё больше меня смутила «страница», на которую указывал результат: unmaskparasites.com/security-tools/find-hidden-links/site/?siteUrl=. Я использую этот URL (или вернее сказать, часть URL’а) внутри скрипта для динамического построения персонализированных ссылок для показа в отчетах. Ни одна из страниц на моём сайте (да и на других тоже) не ссылается на unmaskparasites.com/security-tools/find-hidden-links/site/?siteUrl=

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

Так почему же Гугл предпочёл неполный динамический URL, спрятанный внутри JavaScript’а, неимеющий никаких входящих ссылок, а не полноценную страницу со статическим URL’ом и прямыми входящими ссылками? Может эта страницу почему-то не была проиндексирована? Я ввёл запрос site:unmaskparasites.com. Сайт совсем небольшой, и все страницы, включая эту, оказались проиндексированы. Более того, этот запрос выявил страницы, которые вообще не должны были быть проиндексированы, так как использовались только внутри служебных AJAX запросов. (unmaskparasites.com/results/ и unmaskparasites.com/token/ на скриншоте. )

Какого черта! Откуда Гугл узнал про них?!

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

Доказательства

Ссылки в AJAX запросах.

http://unmaskparasites.com/results/ и http://unmaskparasites.com/token/ - это служебные URL’ы, использующиеся исключительно в AJAX (JavaScript)-запросах. Нигде больше эти URL’ы не используются. Вот так они используются в моих скриптах:

$.get(’/token/’, function(txt){ …

и

$.post(”/results/”, { …

Как видите, тут простым регулярным выражением не обойтись. Ссылки относительные, и нужно понимать, что делает код, чтоб отличить строки содержащие такие ссылки от прочих строк.

Ссылки в строках с HTML кодом.

URL http://unmaskparasites.com/security-tools/find-hidden-links/site/?siteUrl= также встречается только в скрипте. На этот раз внутри строки, в которой подготавливается HTML код для вставки в нужное место на странице:

...‘<a href=”/security-tools/find-hidden-links/site/?siteUrl=’ + escape($(”#id_siteUrl”).val() )+ ‘”>’ …

Если спайдер будет выполнять этот код, то получится следующая строчка: ‘<a href=”/security-tools/find-hidden-links/site/?siteUrl=”‘>’, так как он не заполняет форму, и значение поля id_siteURL будет пустым. Получаем URL идентичный тому, что был почему-то проиндексирован Гуглом. Опять же, переведённый из относительной формы в абсолютную.

У Googlebot’а JavaScript не такой, как в наших браузерах.

Складывается впечатление, что Googlebot выполняет только ту часть кода скрипта, которая нужна для обнаружения ссылок и игнорирует всё остальное.

Анализируя, кэшированную страницу http://unmaskparasites.com/results/, ясно видно, что она была получена после GET-запроса с пустыми параметрами. Однако, если выполнять мой код, то 1). с пустыми параметрами невозможно дойти до самого вызова, так как не будет пройдена валидация, 2). выполнялся бы POST-запрос.

Можно предположить, что Googlebot не оснащён полноценным движком JavaScript. Он всего лишь умеет разбирать код, находить ссылки и выполнять усечённый набор команд (например для склейки строк).

jQuery

Есть у меня ещё предположение, что подобное возможно только тогда, когда Гугл видит, что используется код, основанный на известных ему библиотеках. Я использую jQuery и загружаю её напрямую с Гугловских серверов:

http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js

Это единственная сторонняя библиотека, загружаемая моими страницами, и Гугл может быть уверен, что функции $post(…) и $get(…) загружают страницы через AJAX-запросы, а $(’#results’).html(…) вставляет HTML код в div с идентификатором «results».

Google Toolbar

Чтоб рассмотреть альтернативные версии попадания ссылок из JavaScript в результаты поиска, допустим, что Гугл узнал о них с помощью тулбара, установленного в моём браузере. Однако есть ряд факторов, указывающих на то, что тулбар тут не при чём:

1. Ссылки, используемые в AJAX-запросах никогда не попадают в адресную строку браузера, а значит нет причин запрашивать для них PageRank.
2. Тулбар запрашивает информацию лишь по тем ссылкам, что встречаются в реальной жизни. Значит, с помощью тулбара Гугл скорее бы проиндексировал ссылки типа: http://unmaskparasites.com/security-tools/find-hidden-links/site/ или http://unmaskparasites.com/security-tools/find-hidden-links/site/?siteUrl=example.com, но уж никак не http://unmaskparasites.com/security-tools/find-hidden-links/site/?siteUrl=
3. Другие «секретные» страницы, которые я загружал в браузере, остались непроиндексированными.
4. Вы когда нибудь видели, чтоб страница на одномесячном домене без единой входящей ссылки оказывалась на первом месте в результатах поиска (пусть даже и по непопулярному запросу), имея при этом более 14 миллионов конкурентов?

Немного официальной информации от Гугла.

Только что нашёл ряд косвенных подтверждений в официальном блоге Google Webmaster Central.

A spider’s view of Web 2.0

“Основная проблема с Ajax-сайтами в том, что хоть Googlebot и прекрасно разбирается в структуре HTML-ссылок, у него могут возникнуть сложности при индексации сайтов, использующих JavaScript для навигации. Хоть мы и работаем над тем, чтоб лучше понимать JavaScript, всё же лучший способ сделать сайт дружественным для поисковых роботов – это предоставить им HTML-ссылки на ваш контент.”

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

Improved Flash indexing

“Googlebot не выполняет некоторые команды JavaScript.”

О чём я и говорил. Googlebot выполняет JavaScript, но его поддержка довольно ограничена.

“Что касается ActionScript, мы способны находить ссылки, загружаемые с помощью ActionScript.”

Если они могут находить ссылки в ActionScript, то что мешает им делать подобное и с JavaScript?

Новая веха?

Flash, JavaScript, что дальше? Похоже скоро поисковые роботы смогут «видеть» веб страницы почти также как и мы, люди. Пока же проверьте скрипты на своих страницах. Возможно вы показываете Гуглу больше, чем ему следует видеть. Я уже добавил несколько новых Disallow правил в robots.txt.

Или это у меня паранойя?

Tags: AJAX, google, googlebot, JavaScript, links, SEO, Unmask Parasites

Готовимся к WordPress 2.6

Уже можно скачать WordPress 2.6 RC 1, и в любое время на этой неделе может быть объявлено об официальном выпуске WordPress 2.6.

Удалённая публикация в WordPress 2.6

По умолчанию, WordPress 2.6 будет устанавливаться с отключенной возможностью удалённых публикаций. Т.е. вы не сможете сразу же воспользаваться Windows Live Writer’ом или UseShots Editor’ом для публикации на только что установленные блоги.

Без паники! Удалённую публикацию легко вернуть.

Внимание: Если вы будете апгрейдить существующий блог до версии 2.6, то ничего делать не нужно - удалённая публикация при апгрейде остаётся нетронутой.

Settings / Writing

Залогиньтесь в WordPress. Кликните Settings, потом Writing.

Enable XML-RPC

На этой странице найдите секцию Remote Publishing (удалённая публикация) и включите опцию XML-RPC. (Для некоторых программ может ещё понадобиться опция “Atom Publishing Protocol”)

Нужно ли апгрейдить блог до версии 2.6?

Да. Лучше всего проапгрейдить свой блог сразу же после официального выпуска WordPress 2.6, не дожидаясь пока хакеры подберут ключи к вашему блогу на WP 2.5.1. Новая версия должна быть более защищённой. Если же вы используете ещё более древнюю версию WordPress’а, то вам однозначно нужно произвести апгрейд.

Предостережение

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

Поэтому перед апгрейдом убедитесь, что ваш блог не имеет признаков взлома. Для этого можно воспользоваться WordPress Exploit Scanner’ом (сканнер взлома), который находит признаки взлома в файлах и базе данных WordPress’а. Если вы не хотите ничего уcтанавливать, то проверьте веб страницы вашего блога на предмет невидимых вредных включений с помощью бесплатного сервиса Unmask Parasites.

Tags: remote publishing, Unmask Parasites, WordPress 2.6, WordPress Exploit Scanner

Выпущен UseShots Editor v0.6. Три шаблона статей.

Новая версия

Сегодня был выложен для скачивания новый релиз UseShots Editor’а - версия 0.6.

С этой версии вы получаете больший контроль над тем, как будут выглядеть статьи, созданные в UseShots Editor’е. (смотрите «Шаблоны Статей» ниже)

Скачать UseShots Editor 0.6

Smarter UseShots Camera

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

Тэги <code> и <pre>

Если вы размещаете в блоге куски кода, то вы оцените возможность использовать тэги code и pre.

code - компьютерный код.
pre - преформатированный текст. Этот тэг помогает сохранить выравнивание (начальные пробелы и переводы строки) в отрывках кода. Текст выводится моноширинным шрифтом.

Вот пример PHP кода из файла wp-atom.php(из исходников WordPress), помещённого между pre тэгами:

<?php
if (empty($wp)) {
	require_once('./wp-config.php');
	wp('feed=atom');
}
require (ABSPATH . WPINC . '/feed-atom.php');
?>

Чтоб получилось более наглядно, можно использовать стили.

Article Layouts

До версии 0.6 нельза было изменить шаблон, по которому UseShots Editor создавал статьи. Шаблон был хороший (картинки по центру, ниже аннотации), но если вам больше нравится, когда картинки расположены справа или слева, а текст как бы обтекает их, то чтоб достичь токого эффекта, вам приходилось редактировать уже опубликованную статью в редакторе самого WordPress’а.

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

Есть три шаблона статей: Самоучитель, Статья (картинки слева), Статья (картинки справа).

Layout: Tutorial

По-умолчанию используется шаблон Самоучитель.

Каждая картинка располагается на своей строке по центру. Каждый экран визуально отделён от других экранов прерывистой горизонтальной линией.

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

Layout: Article (left images)

Если вы пишите обзор (или просто статью со скриншотами) и предпочитаете более естественное расположение текста, то шаблоны Article (один из них) вам подойдут больше.

В шаблоне Article (left images) (Статья – картинки слева) небольшие картинки (меньше чем в половину ширины колонки) будут располагаться слева, а текст будет их как бы обтекать. Большие же картинки будут, как и в шаблоне Самоучитель, располагаться по центру. Экраны визуально не разделяются.

Layout: Article (right images)

В шаблоне Article (right images) (Статья – картинки справа) небольшие картинки (меньше чем в половину ширины колонки) будут располагаться справа, а текст будет их как бы обтекать. Большие же картинки будут, как и в шаблоне Самоучитель, располагаться по центру. Экраны визуально не разделяются.

Для этой статьи (как и многие другие на этом сайте, она создана в UseShots Editor’е) использовался шаблон Статья (картинки справа).

Отзывы

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

Программа ещё находится на стадии активной разработки, и вы можете повлиять на то, в каком направлении она будет развиваться дальше. Критикуйте, предлагайте новые фичи. Присылайте мне ссылки на ваши статьи созданные с помощью UseShots Editor’а – время от времени я будут публиковать эти ссылки здесь.

Любые отзывы приветствуются. Оставляйте комментарии здесь или воспользуйтесь контактной формой.

Tags: code, layout, update, UseShots Camera

Как продвигать свои инструкции и самоучители в интернете. Каталоги самоучителей. (Часть 2)

Read the rest of this entry »

Tags: review, tutorial directories

Free Downloads Center: “The future is UseShots Editor”

O. James Fagbire of Free Downloads Center blogs about UseShots Editor.

“One of the biggest areas of blogging in the modern world has to do with the idea of screenshots.” read more

Thanks James.

Tags: free downloads center

Как продвигать свои инструкции и самоучители в интернете. Каталоги самоучителей. (Часть 1)

Tutorials are the sort of online resources many people like. At the same time they are a great way to promote your web sites, products, services and skills.

In this post, I want to talk about how you can promote your online tutorials.

Read the rest of this entry »

Tags: tutorial directories

Выпущен UseShots Editor v0.5. Добавлена поддержка категорий WordPress

1.  Новая версия

Выпущена новая версия 0.5 UseShots Editor‘а, программы с помощью которой можно "на лету" создавать инструкции со скриншотами и публиковать их в своём блоге.

С добавлением поддержки категорий, в UseShots Editor’е стали доступны все основные опции, используемые в WordPress’е при публикации статей. Больше не нужно добавлять категории из контрольной панели блога статьям созданным в UseShots Editor’е, теперь это можно сделать в самой программе.

Новую версию можно скачать здесь.

2.  Что нового?

• Добавлена поддержка категорий WordPress.
• UseShots запоминает размер и позицию своего окна и восстанавливает их при последующих запусках.

Исправленные баги:

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

3.  Категории

Когда вы готовы опубликовать статью, отметьте подходящие категории в списке категорий (Categories)

4.  Добавление категорий

В первый раз список категорий будет пуст. Кликните load (загрузить), чтоб загрузить список с сервера. Также можно воспользоваться ссылкой add (добавить), чтоб добавить новые категории.

Tags: UseShots v0.5, WordPress Categories

Выпущен UseShots Editor v0.4.1. Оптимизация под поисковые системы и поддержка PNG

1. Выпущена новая версия

UseShots Editor - это программа, помогающая блоггерам использовать скриншоты в своих статьях. Все рутинные операции исключаются. Остается лишь сделать серии скриншотов (как при работе с обычным цифровым фотоаппаратом), добавить соответствующие описания и нажать кнопку Publish (опубликовать)

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

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

Скачать UseShots Editor можно здесь.

2. Что нового в версии 0.4.1?

• Имена файлов оптимизированы для поисковых систем
• Поддержка PNG
• Более пропорциональное масштабирование изображений
• Наглядная информация о размере скриншота и его масштабе.

3. Оптимизированные для поисковых систем имена файлов

Наконец-то я нашёл время и сделал то, что нужно было сделать с самого начала. Файлы изображений больше не будут иметь уродливые имена вроде 1C4D4616E76602684EA67F3BFB314C209401D40B.jpg. Теперь они будут оптимизированы для поисковых систем и, одновременно, для человека. Имена будут основаны на заголовках соответствующих экранов в UseShots Editor’е.

Например, если заголовок экрана “WordPress 2.5 post editor“, то имя файла соответствующего скриншота будет wordpress-post-editor.jpg (или .png, или .gif, в зависимости от формата изображения).

Если заголовок не указан, или в нём присутствуют нелатинские символы, то файл будет назван pictureN.jpg, где N это номер картинки в статье.

4. Поддержка PNG

UseShots Editor автоматически сохраняет скриншоты в формате, оптимизированном для Интернета (лучшее качество при минимальном размере файла). К уже поддерживаемым GIF и JPEG, в версии 0.4.1 добавился формат PNG. Это значит, что скришоты, сделанные в UseShots Editor’е будут занимать ещё меньше места на вашем веб сервере, а качество их как минимум не ухудшится, а в некоторых случаях и улучшится.

Файлы изображений в PNG формате можно также загружать в редактор
UseShots.

5. More prominent screen shot size and scaling information

В правом верхнем углу появился информационный блок, показывающий размеры и масштаб выбранного скриншота.
Формат: ширина x высота (масштаб%)

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

6. Что вы думаете?

UseShots Editor - бесплатная, небольшая и довольно полезная программа (во всяком случае для меня. Большинство статей в этом блоге было создано в UseShots Editor’e). Скачайте и попобуйте сами.

Что вы думаете о программе? Чего вам в ней не хватает, а что хочется изменить? Любые отзывы и комментарии приветствуются.

Tags: PNG, SEO, update, UseShots Editor 0.4.1