Open Live Writer — Куда пропал мой контент из черновика, и что теперь делать ?

Редактор блогов Open Live Writer (OLW) является, на мой взгляд, наиболее комфортным инструментом для offline-редактирования записей блога WordPress на платформе Windows. Однако, этот редактор, как и любой другой программный продукт, имеет свои недостатки. В частности, имеется весьма досадный баг, замеченный мной ещё в Windows Live Writer (WLW), и в последствии унаследованный в OLW.

Бывает иногда так — создаёшь черновик, потихоньку наполняешь его содержимым, пишешь, пишешь, объем материала растёт и черновик приобретает некоторую ценность, обусловленную объёмом потраченного времени и умственных потуг. Но ведь всё хорошо, и беспокоится не о чем, ведь черновик мной периодически сохраняется во время правки (черновики OLW хранит в профиле пользователя в каталоге %USERPROFILE%\Documents\My Weblog Posts\Drafts\ в виде файлов с расширением wpost). И вот уже статья почти дописана, осталось внести косметически изменения…хотя нет, отложим это на потом, – закрываем черновик… А при следующем открытии черновика, с удивлением обнаруживаем, что часть контента из черновика попросту исчезла. То есть, некоторая часть черновика с совершенно определённого места попросту как-будто отрезана и выброшена. Иногда бывает так, что исчезает почти всё содержимое, но это, как говорится, как «повезёт».

Первый раз с такой ситуацией я столкнулся в WLW, но тогда объём исчезнувшего контента был несущественен, и я, не придав этому значения, просто заново переписал утерянное. Второй случай был тоже на WLW, но уже в других обстоятельствах и с другим черновиком. Тогда стало понятно, что это скорей закономерность, чем случайность, но разбираться с причиной как-то поленился в силу того, что опять же, потеря контента была незначительной. Третий раз ко мне это «счастье привалило» уже на OLW, и тут я уже «хлебнул сполна». Черновик, который несколько раз открывался и дополнялся большим объёмом контента, когда уже почти был готов, после очередного открытия радостно предстал передо мной в виде первого абзаца, написанного неделю назад… Отправив в тропосферу речь про «Кузькину мать», я понял, что нужно с этим безобразием разбираться.

Для начала, я покопался в старых теневых копиях диска (VSS), которые у нас периодически делаются на всех клиентских Windows-системах, и обнаружил, что интересующий меня черновик OLW (wpost-файл) сильно уменьшился в размере при прошлом сохранении, которое было произведено во время закрытия этого черновика. Взял последнюю полную копию файла, переименовал её и подсунул в ранее упомянутый каталог черновиков. Открыл восстановленный черновик в OLW, и снова вижу только первый абзац. Закрыл черновик без редактирования и сохранения …. размер файла опять сильно уменьшился, хотя повторю, никаких правок я не вносил. Возникло подозрение, что исчезнувший контент внутри wpost-файла на момент открытия всё же есть, но по какой-то причине не отображается в интерфейсе программы при открытии и напрочь теряется при его закрытии.

Изучение логов OLW в каталоге %USERPROFILE%\AppData\Local\OpenLiveWriter\ ситуацию никак не прояснило. Понятно, что остаётся только один путь – попытаться понять, что из себя представляет wpost-файл. Выяснилось, что wpost-файл это, своего рода, контейнер, подпадающий под определение Compound document. Затем выяснилось, что есть специализированное ПО, умеющее работать с такими файлами-контейнерами. В частности, в руки попалась платная программа Compound File eXplorer (CFX), которая в течение 30-дней после установки вполне пригодна для использования (искать альтернативное бесплатное ПО в момент «разбора полётов» времени просто не было).

При запуске CFX сразу предложит открыть интересующий нас файл. Перед открытием wpost-файл потребуется переименовать, если его имя содержит кириллицу, так как у CFX с этим делом проблемы. После открытия файла мы увидим, что внутри имеется некоторая структура вложенный элементов. Ориентируясь по размеру элементов в байтах (Element size) удалось обнаружить то, что основной текстовый контент черновика в HTML формате хранится в элементе Contents.

Воспользуемся встроенной в CFX функцией экспорта элемента в файл Save to file и сохраним контент во внешний файл, задав ему имя, например, Contents.txt. В итоге получится файл, который можно открыть в любимом текстовом редакторе с подсветкой синтаксиса HTML и попытаться проанализировать контент в том месте, после которого теряется содержимое. В моём случае было обнаружено, что в одном из фрагментов кода отсутствовал закрывающий тег </pre>. После правки контента во внешнем файле, его можно обновить внутри wpost-файла с помощью функции Import: 

На вопрос о замещении контента потока элемента Contents содержимым из внешнего файла Contents.txt отвечаем утвердительно

Затем на верхней панели кнопок станет активной кнопка сохранения. Жмём.

Отредактированный черновик закидываем в каталог черновиков OLW и открываем. Доступ к ранее исчезающему контенту должен быть восстановлен. Несмотря на то, что после такой правки черновик в OLW успешно откроется, я бы не рекомендовал дополнительно рисковать, а создать новый чистый черновик в OLW и скопировать туда контент из восстановленного черновика. А то, мало ли CFX что-то ещё может повредить в структуре черновика и об этом станет ясно уже только потом. В общем, описанным образом мне удалось вернуть свой материал.

Самое неприятное в описанном баге OLW то, что он проявляется плавающим образом, и воспроизвести вручную проблему, чтобы зарегистрировать как-то вменяемо баг в сообществе разработки, пока не получилось. Ибо, если, например, при вставке кода в редакторе попытаться убрать открывающий или закрывающий тэги <pre></pre>, то есть намеренно сломать HTML-разметку, то в результате просто искажается отображение текста, но сам текст при этом не теряется и никуда не исчезает. Последнее проявление бага было замечено в том месте, где во время редактирования часть контента была вставлена через буфер обмена, куда в свою очередь попала из другого форматированного содержимого (с веб-страницы). Возможно, исходное содержимое имело сломанную разметку.

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

Всего комментариев: 2 Комментировать

  1. Smearg /

    Оу! Спасибо! Буду иметь в виду.

  2. Алексей Максимов / Автор записи

    В быстром выявлении неправильного использования тэгов HTML может помочь онлайн-сервис http://www.freeformatter.com/html-validator.html, в котором можно проверять код из «Contents»

Добавить комментарий