Устранение «необъяснимого глюка базы данных» с аттачами WordPress

Второй раз уже столкнулся с такой проблемой: часть картинок (аттачи к записям) отображалась нормально, а часть не показывалась вообще, хотя файлы были на диске и права нормальные были установлены. Причем в первом случае проблема возникла после восстановления дампа базы на новом хостинге, а во втором просто после некоторого времени само «сломалось». Про первый случай я уже забыл и не мог понять что же случилось. изучение дампа ни к чему не приводило. Вид записей в таблице wp_postmeta у проблемных и нормальных позиций был в принципе одинаковый.

Выглядело это так: путь к картинке был не стандартный вида http://SITE/images/bla-bla.jpg, а  http://SITE/images//home/userXXX/public_html/images/bla-bla.jpg Причем в базе как раз такие «пути к папкам на сервере» и прописаны (можете посмотрет ьи в свои дампы).

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

В чем дело?

Это конечно очень смешно, но в кодировке (поврежденной).

Как решается?

Элементарно просто!

Делаем дамп таблицы wp_postmeta (в случае стандартного префикса wp_)

Открываем дамп в правильном текстовом редакторе (как ни странно только проверенный годами UnicEdit решал эту проблему, все другие редакторы, которые подходили для правки шаблонов тут не годились. Дамп «кривой» к примеру весил  540471байт, сохраненный в Notepad++ столько же, в PHP expert editor 540453байт, а в UnicEdit — 542757). Причем везде идет речь про формат UTF8 без BOM. Визуально если открыть файлы то содержимое ничем не отличается.

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

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

Открываем страницу сайта где у нас «были глюки».

Смотрим что все стало в порядке.

Связанные записи

3 комментария на запись “Устранение «необъяснимого глюка базы данных» с аттачами WordPress”

  1. adw0rd 28 февраля 2009 в 14:12

    Спасибо за UnicEdit, буду пользоваться!

  2. Ю.Б. 28 февраля 2009 в 15:25

    Посмотрел базу. Очень интересно. В базах WP 2.7 записи вида "2009/02/090218-metro-alekseevskaya.jpg", т.е. относительные пути (смотрел на двух сайтах: один локальный, другой на хостинге). У более ранних — пути "от печки".

  3. jobgomel 1 марта 2009 в 16:24

    Никогда с таким не сталкивался. Лучше учиться на ошибках других :). Спасибо за инфу!