Ага, про них я писал уже не раз, но постоянно сталкиваюсь с большими и большими извращениями. Некоторые “рецепты счастья” я уже публиковал, но и они не всегда спасают. За последние три  дня правил три очень запущенные базы. Несмотря на то что две из них были на одном хостинге и в пхпмайдмине выглядели закорючки одинаково – их состояние было различным и исправлял я глюки в них совершенно разными способами. Методом подстановок, скрещивания дампов разных версий, отката и наката разных версий движка, пересохранением всех записей через “быструю правку” для исправления ссылок и привязки к рубрикам (уже рука набита) и т.д. В итоге на каждую базу затратил в примерно по 2 часа, но результат радует. Одну базу еще немного поправить только надо (не все буквы И и ш еще пофиксены). Третья база также страдала этой “двухбуквенной болезнью”, но там текста было на порядок меньше.

Но в целом – за час или полдня, но все базы лечатся как я уже убедился за пару лет. И примерно в 70% случаев когда ко мне обращаются за обновлением движка различных  версий, у пользователей поврежденная база в той или иной степени, но они про это не догадываются т.к. выглядит все нормально вроде пока не решатся сами обновиться (либо хостер подсунет свинью в виде внепланового обновления софта).

2 комментария

(голосов: 3, средний: 5.00 из 5)

 Загрузка ...

Давно не смотрел в консоле убунтовой информацию типа

cat /proc/cpuinfo

и когда сегодня заглянул – ужаснулся. Оказывается я последний раз когда копался в биосе включил режим Cool’n'Quite для теста (посмотреть как изменится температура) и забыл про это совсем. В итоге частота процессора (Athlon 64 X2 4400+) упала с 2300мгц до 1000мгц (при большой нагрузке естественно она бы выросла, но такой нагрузки на сервере не было). И вот подцепил клаву к серверу, вырубил нафиг эту фичу и сразу время генерации страниц сократилось со средних 0.6сек до 0.2сек! А я то думал чего это сервер стал так медлителен. Грешил уже на новую версию php…

5 комментариев

(голосов: 2, средний: 5.00 из 5)

 Загрузка ...

Тут просматривал коменты к своему посту WP2.7.1 и увидел комент где спрашивали чо делать если коменты не хотят одобряться. Как то я забыл про это вообще а тут всплыл такой баг с WP2.7.1 на хостинге ру-центра (да и вообще тормозит там все просто ахтунг). В общем гуглил по инету и наткнулся на официальный форум WP где рекомендовали выключить отправку коментов на мыло. Коменты сразу начали одобряться (т.е. не просто делать видимость что “одобрено” и после перезагрузки страницы снова “ожидает”). Возможно это какие то особенности настройки конкретного блога. В том блоге, где встретил я ошибку были настройки: модерировать все коменты, отправка на мыло если комент надо одобрить, отправить при наличии коментов. вот последнюю галочку и убрал.

Вот собственно этот баг

Один комментарий

(голосов: 1, средний: 5.00 из 5)

 Загрузка ...

В продолжение моего недавнего поста про глюки с БД.

Через день после того исправления глюк на том самом втором сайте повторился. Было перепробовано все что только можно

Проблема возникала не со всеми картинками, а в основном с теми, где в базе каким то образом прописался полный путь в файловой системе (без разницы – старого и нового хостинга). Удаление путей хирургическим путем в базе приводило к тому что WP забывал что у картинки есть миниатюра.

и помогало только “удаление всех глючных картинок из базы” и повторная закачка. Меня этот вариант не устроил и я искал другие способы. Вспомнил что глюк произошел после обновления с версии 2.7 до 2.7.1 (но мне не сразу сообщили про этот сбой).

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

Открываем файл wp-includes/post.php и комментируем там этот блок (строки 2566-2569)

			elseif ( false !== strpos($file, 'wp-content/uploads') )
$url = $uploads['baseurl'] . substr( $file, strpos($file, 'wp-content/uploads') + 18 );
else
$url = $uploads['baseurl'] . "/$file"; //Its a newly uploaded file, therefor $file is relative to the basedir.

Если лень патчить файл ручками и у вас такая же проблема – просто скачайте этот файл (для версии 2.7.1) и замените ваш в папке wp-includes

Надеемся в версии 2.7.2 баг исправят…

Ни*уя баг не исправили и в 2.8.2 версии он также присутствует. Авторы совсем обленились. Вот пропатченный файл для версии 2.8.2

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

4 комментария

(голосов: 3, средний: 5.00 из 5)

 Загрузка ...

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

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

3 комментария

(голосов: 2, средний: 5.00 из 5)

 Загрузка ...

Первый пакет из пяти исправлений для WordPress 2.7 который рекомендуют использовать не дожидаясь версии 2.7.1

Скачать набор исправленных файлов все-в-одном (если у вас уже был установлен WordPress 2.7) и просто распаковать все содержимое сохраняя структуру папок поверх установленного WordPress.

В своем дистрибутиве файлы тоже обновил

Что исправлено:
1 при установке админу присвается уровень 0 вместо 10 (возникают проблемы с некоторыми плагинами). Если вы обновляли старую версию (до 2.7) то проблемы нет.
2 исправляется ошибка

Warning: curl_exec() has been disabled for security reasons in /home/nicetec/public_html/wp-includes/http.php on line 1022 Warning: curl_exec() has been disabled for security reasons in /home/nicetec/public_html/wp-includes/http.php on line 1027 Warning: Cannot modify header information – headers already sent by (output started at /home/nicetec/public_html/wp-includes/http.php:1022) in /home/nicetec/public_html/wp-includes/pluggable.php on line 850

помнится у кого то она была – писали в коментах
3 исправление для обновления плагинов
4 незакрытый тег STRONG в «редакторе темы»
5 исправление проблемы с постраничными комментариями (для тех кто использует встроенную в 2.7 разбивку коментов по страницам)

Эти исправления не затрагивают той проблемы, что описана в прошлом  посте. Поэтому если у вас та самая проблема, то скачайте полный патч этот официальный+тот неофициальный все-в-одном (в обновленный дистрибутив тот патч не включен)

Комментариев нет

(голосов: 1, средний: 5.00 из 5)

 Загрузка ...

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

Более подробно можно ознакомиться с проблемой по ссылке выше, там же можно взять diff файл для патчинга. Или скачать у меня уже исправленные файлы (с примененными теми самыми патчами). У меня ошибки такой не было ни разу за все время работы с версией 2.7, поэтому подтвердить или опровергнуть ошибку не могу. Использовать файлы на свой страх и риск (если у вас есть ошибка). Официального исправления пока еще не выходило.

это же исправление+набор официальных исправлений все-в-одном

Один комментарий

(голосов: 2, средний: 5.00 из 5)

 Загрузка ...

Если вы еще не хотите/не готовы полностью переработать вашу «тему» для поддержки новой функции комментариев WordPress 2.7, то сделайте хотя бы минимальное изменение:

Откройте ваш файл «темы» comments.php и найдите там строку типа такой:

<legend>Вы вошли как <a href="<?php echo get_option('siteurl'); ?>/wp-admin/profile.php"><?php echo $user_identity; ?></a>. <a href="<?php echo get_option('siteurl'); ?>/wp-login.php?action=logout" title="Выйти из текущего аккаунта">Выйти &raquo;</a></legend>

и замените в ней одну часть чтобы получилось так

<legend>Вы вошли как <a href="<?php echo get_option('siteurl'); ?>/wp-admin/profile.php"><?php echo $user_identity; ?></a>. <a href="<?php echo wp_logout_url(get_permalink()); ?>" title="Выйти из текущего аккаунта">Выйти &raquo;</a></legend>

Отличие на первый взгляд малое, но работает кардинально по разному (про новый тег писала недавно Соника (ссылку на пост ставил я на днях у себя)

<?php echo wp_logout_url(get_permalink()); ?>

меняет вашу ссылку «выхода» с примерно такой

http://www.вашсайт.ru/wp-login.php?action=logout

на примерно такую

http://www.вашсайт.ru/wp-login.php?action=logout&redirect_to=http%3A%2F%2Fwww.вашсайт.ru%2Fcategory%2nazvanieposta%2F&_wpnonce=f280f0b1cd

. Основное отличие в дополнительном параметре _wpnonce=f280f0b1cd без которого выход невозможен (кстати это тот самый параметр про кторый я писал что он появился в конфиге WP2.7), а остальное это просто говорит что после выхода редиректиться будет само на этот же пост.

Зачем все это нужно вообще? а чтобы не получить вот такую ошибку например при нажатии на эту самую ссылку «ВЫЙТИ» (и так будет показывать постоянно)

22 комментария

(голосов: 2, средний: 5.00 из 5)

 Загрузка ...