Архивы блога

Если пересохранить пост за который уже голосовали пользователи, то в логах голоса останутся, в комментариях они тоже будут показаны при добавлении такой команды в шаблон — а  в общем рейтинге записей и под записью рейтинг сбрасывается до нуля, т.е. стирается вообще  и пишет «еще не оценили». После чего если голосовать заново то количество голосов считает заново. Заметил такое еще во времена бета-версий 2.7, но это продолжается и после выхода финальной версии WP ив новой версии плагина.

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

Вчера SlaFFik обратился за помощью — как он сказал у него

после обновления WPMU с 2.6.3 до 2.6.5 перестали показываться все картинки

Провозился он сначала сам долго, затем привлек меня в помощь. я тоже очень долго возился… Что только не проверял — все равно не отдавались картинки через редирект на сервере (путь идет как www.site.ru/files/2008/12/file.jpg а реально файл лежит в WPMU к примеру www.site.ru/wp-content/blogs.dir/1/files/2008/12/file.jpg) — ни в какую не открывало так, хотя на сервер картинки все закачивались и даже миниатюры создавались. При этом в логах писало ошибку о каком то превышении числа редиректов.

mod_rewrite: maximum number of internal redirects reached. Assuming configuration error. Use ‘RewriteOptions MaxRedirects’ to increase the limit if neccessary.

изменение этого параметра он писал что не помогло.

Ради прикола переименовал картинку — сделал ей левой расширение TXT — файл тут же начал нормально загружаться через браузер по прямой ссылке.
В конфиге и htaccess в корне сайта было все нормально. Решил попробовать у себя поставить вмпу2.6.5 — та же фигня. ставлю 2.6.3 — тоже не пашет. 2.6.1 — тоже не пашет. 1.5 — тоже не пашет. хотя раньше все работало. Сегодня поставил бету wpmu 2.7 — думал ну там то уж точно может заработает — фигушки! и тут дернуло меня выключить для тестового домена в конфиге nginx отдачу статики (там были как раз перечислены расширения). Перезапустил Nginx и вуаля — WPMU тут же заработал без проблем. Видно причина кроется как раз в том что идет схема nginx-apache-wpmu и при использовании еще и редиректа внутри домена на папку с загрузками что то блокируется. nginx отдавал ошибку 404 — типа не найдено ничего на сервере. Но это ладно — мой сервер и такое может быть — где то может что то не учел в настройке для совместимости с MU (я у себя его только тестирую а реально не использую для себя)
но у SlaFFik’а конфигурация софта совсем другая : Server: Apache/1.3.41 (Unix) mod_throttle/3.1.2 mod_psoft_traffic/0.2 mod_ssl/2.8.31 OpenSSL/0.9.8b
и nginx-ом там даже не пахнет. Но тем не менее даже при откате у него на старую версию движка проблема не пропадает. в чем причина тоже не ясно. если у меня просто выдает 404, то у него просто виснет секунд на 30 и потом прекращается запрос — видно по поведению браузера.
Есть у кого идеи по источнику проблемы?

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

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

посмотрите на два скриншота

так показан список страниц с стандартным шаблоном ссылок

так показан список страниц с любым другим шаблоном ссылок

при этом если во втором случае (с чпу) «быстро редактировать» страницы то они вообще пропадают из списка. и приватная страница не показывается в списке сверху (там видно что всего 26страниц а публичных только 25). и еще при работающем ЧПУ не работают вообще скрин опшнс в управлении страницами — т.е. не отключаются колонки: автор, дата и т.д.

долгая чистка таблицы опций во время поиска багов дала тоже свои положительные результаты — выкинул из нее 1мб мусора (с 1,2мб до 200кб примерно снизил) и отрубил все rss в доске объявлений чтобы снова не засорялось.

2 сразу после апдейта с 2.6.3 до 2.7 на двух сайтах заметил что файлы стали загружаться не в папку 2008/11 а в 0000/00. Проблема решилась сама после захода в «Разные настройки» и их сохранении.

3 в визуальном редакторе (при использовании плагина расширенного редактора) почему то не добавляется сразу подпись картинки (та что в рамке), а вставляется она под картинкой. если зайти в свойства картинки и изменить там подпись то вижу что поле пустое. после заполнения его все на месте

4 вчера кажется оставили мне комент где был три раза тег < CODE >. так вот в списке коментов в админке этот комент был «залочен», т.е. у него отсутствовали ссылки на редактирование, ответ и т.п.

ищем дальше… пишу багрепорты в wp-testers иногда, но что то не реагировали еще ни разу

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

Вот уже не одну неделю копаюсь с парой сайтов, оптимизирую их и правлю баги. Стоит на них вот такая тема, которая при всей своей достаточной навороченности имеет один гагантский глюк! Обнаружил его вчера когда проверил в очень полезном сервисе для каждого вебмастера сколько «весит» главная страница сайта. После проверки у меня мягко сказать «упала челюсть». Более 4,5мегабайт, хотя визуально на сайте вроде все картинки мелкие и не весят столько ни при каком раскладе. Баг зарылся в файле thumb.php в самой теме. Что делает этот файл — создает при первом вызове миниатюры указанных картинок (пути к картинкам прописывает автор при создании поста в отдельном произвольном поле). Далее он все честно складывает в папку своего кэша, но почему то вместо названий файлов с расширениями jpg, png и т.д. нормальных выдает абракадабру без расширений. И ладно бытолько это — в браузер посетителю выдавалась при этом ПОЛНАЯ КАРТИНКА, хотя на экране были показаны эскизы около 100*100пикселей. Это легко было проверить даже вручную вызвав адрес «мини-картинки» в браузере. Начал копаться что к чему и почему. В скрипте обнаружил адрес создателей скипта. Полез на сайт и скачал свежую версию.  Размер файла значительно отличался от того что был в «глючной теме». Скопировал его на сервер в папку темы под именем старого и очистил папку кэша. Загрузил страницу и «челюсть упала» во второй раз. Теперь миниатюры создавались с корректными названиями, нормальных размеров и самое главное отдавались в браузер тоже нормальных маленьких размеров. Прогнал через вышеуказанный сервис страницу повторно и получил результат — вес страницы уменьшился в 5 раз! Не говоря о том что на неповоротливый апач лишняя нагрузка в виде постоянной загрузки объемных картинок ни к чему. Да и посетителю это понравится куда больше.

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

Далее в программе
Продолжить чтение →

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

Активация винды накрылась медным тазом

Жила себе на одном компе Windows XP Home SP2 не тужила. Обновили ее до SP3. Добавили памяти 512мб в комп для проверки, склонировали диск 40гб на 80гб. Ничего особенного. Потом выдернули память и оставили только новый винт. И тут винда выкидывает что «много оборудования было изменено и давай переактивируемся». «Да без базара», подумал Кактус. Хотя и при больших заменах оборудования все обходилось без активации. Но не тут то было… Выскакивает уже до боли знакомое окно мастера активации и что мы видим: нет кода установки. вообще! После повторного внесения ключа продукта код установки также не отображался. Активация по инету тоже не работала, даже не пыталась вылезти в Сеть. Возиться с переустановкой винды начисто было некогда и пришлось возвращать 40гб винт на место до лучших времен…

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

Вот такой прикол заметил во время тестирования одного сайта, который обновлял вчера. Причем проблема была только если комментатор не залогинен. Пользователь оставался на странице SITEURL/wp-comments-post.php без редиректа на страницу где писал комментарий. Такая же проблема на днях обсуждалась на форуме, но по ссылке там ничего конкретно тоже не было ясно, кроме как посмотреть на работу mod_security на сервере, что я сделать не могу.
Полдня пролазил в гугле-яндексе и нашел кучу подобных проблем и кучу совершенно разных решений. И самое смешное на том же сервере если закачать дополнительную директорию с WordPress и там настроить голый сайт то проблемы нет. Попробовал завести голый сайт в корневой папке — там проблема есть. Маразм. Пробовал как рекомендуют менять WWW на NO-WWW адрес в админке, пробовал перемещать WP в папку и указывать урл сайт на корень, но проблема оставалась. И попробовал последний метод, который почему то сразу отбросил когда находил (там была проблема с каким то плагином и тоже говорилось «про почту»)- отключил в настройках админки отправку писем администратору при добавлении нового комментария и вуаля! комментарии сразу стали добавляться без проблем. В чем прикол?

PS глюк присутствовал там на всех версиях 2.5.1-2.6.2 (кстати вышла сегодня, выложу вечером). Старые версии не проверял. Хостинг MCHOST.RU  :cry:

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

На своем компьютере то у меня ДНС настроены уже давно левые, но я их периодически меняю туда-сюда чтобы проверить оживают ли вебстримовские. А вот на сервере у меня как были прописаны вебстримовские так и оставались (забыл возможно изменить). И вот всю неделю сайт мне просто откровенно трахал мозги выдавая страницы по 5-10секунд и постоянно зависая в админке.

Изменил ДНС на сервере, перегрузился. Стало немного полегче, но все равно было дискомфортно. Тогда вспомнил я что писал Максим про тормознутость 2.6рс1 и решил проверить и это. До начала глюков с ДНС я проблем не испытывал на версии 2.6 и ничего у себя не менял.

В новой версии 2.6.1 файл немного изменился (решение для 2.6 описано по ссылке выше в комментариях), поэтому пришлось вырезать из него немного больше. Кстати плагины блокировки уведомлений об обновлениях движка и плагинов не помогают в этом. тормоза с ними также остаются.

Что же нужно выкинуть из файла для заметного ускорения работы:

add_action( 'init', 'wp_version_check' );

и ниже

add_action( 'load-plugins.php', 'wp_update_plugins' );
add_action( 'admin_init', '_maybe_update_plugins' );
add_action( 'wp_update_plugins', 'wp_update_plugins' );

if ( !wp_next_scheduled('wp_update_plugins') )
wp_schedule_event(time(), 'twicedaily', 'wp_update_plugins');

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

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

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

Комментарии к записи Про ревизии WP 2.6 (то что было удалено) отключены