О глючных «темах», избыточной нагрузке и глюках неизвестного происхождения на блогах
Вот уже не одну неделю копаюсь с парой сайтов, оптимизирую их и правлю баги. Стоит на них , которая при всей своей достаточной навороченности имеет один гагантский глюк! Обнаружил его вчера когда проверил в сколько «весит» главная страница сайта. После проверки у меня мягко сказать «упала челюсть». Более 4,5мегабайт, хотя визуально на сайте вроде все картинки мелкие и не весят столько ни при каком раскладе. Баг зарылся в файле thumb.php в самой теме. Что делает этот файл — создает при первом вызове миниатюры указанных картинок (пути к картинкам прописывает автор при создании поста в отдельном произвольном поле). Далее он все честно складывает в папку своего кэша, но почему то вместо названий файлов с расширениями jpg, png и т.д. нормальных выдает абракадабру без расширений. И ладно бытолько это — в браузер посетителю выдавалась при этом ПОЛНАЯ КАРТИНКА, хотя на экране были показаны эскизы около 100*100пикселей. Это легко было проверить даже вручную вызвав адрес «мини-картинки» в браузере. Начал копаться что к чему и почему. В скрипте обнаружил . Полез на сайт и . Размер файла значительно отличался от того что был в «глючной теме». Скопировал его на сервер в папку темы под именем старого и очистил папку кэша. Загрузил страницу и «челюсть упала» во второй раз. Теперь миниатюры создавались с корректными названиями, нормальных размеров и самое главное отдавались в браузер тоже нормальных маленьких размеров. Прогнал через вышеуказанный сервис страницу повторно и получил результат — вес страницы уменьшился в 5 раз! Не говоря о том что на неповоротливый апач лишняя нагрузка в виде постоянной загрузки объемных картинок ни к чему. Да и посетителю это понравится куда больше.
Кроме того я заметил что данный скрипт используется и в некоторых дорогих коммерческих темах, правда не смотрел есть ли там такой же баг — ночью было уже некогда проверять. Сегодня постараюсь выкроить время и потестировать.
Далее в программе Уважаемые авторы сайтов!
- Загружайте картинки нормального разрешения (не нужно загружать более 1000*1000px)
- Не нужно вставлять в записи полноразмерные картинки и править их размер через теги оформления (по крайней мере не надо уменьшать картинку 1000*1000 до 400*400). Всему есть разумный предел
- При выкладывании изображений в Сеть их как минимум нужно пересохранять с нормальным сжатием JPG 75-80%. Разницы от 98-100% почти никто не увидит, а размер файлов уменьшится в 2-3 раза. На вышеуказанных сайтах я еще обработаю позже картинки все. Сейчас они весят по 400*2000кб вместо нормальных 100-150 (проверил несколько пересохранил локально)
- Не нужно вставлять PNG картинки с фотографиями. Этот формат лучше всего используется для показа скриншотов, рисованной графики и т.п. Пересохранив один из файлов шапки я уменьшил картинку примерно с 350 до 50кб (просто сохранив в JPG с качеством 80%) без видимых изменений.
А теперь про оригинальные глюки, которые я уже видел на нескольких сайтах где вроде бы им и происходить неоткуда.
Вернемся к первому затронутому вопросу о скрипте. В новой версии все хорошо, но используется проверка адреса запроса. т.е. если открыть картинку так: http://site.ru/wp-content/themes/theme1/thumb.php?http://site.ru/image.jpg?тут_параметры то все будет ок, но если вы пропишите в записе путь с www к картинке то получите фигу (пустое место на странице. миниатюра не создастся т.к. скрипт не найдет путь) Методом наименьшего сопротивления принял решение исправить все пути за раз (а их нашлось около 150) , для чего был сделан дамп базы и в ней все исправлено. После загрузки обнаружил что вылетает ошибка на всех страницах, включая админку. Но баг тут не в кривой кодировке базы. Баг оказался с одним из плагинов. Плагин выводил в сайдбаре произвольную картинку в виджете и ее описание. Так вот почему то при импорте запись о виджетах повредилась и пока не отключал плагин лезли глюки. Выкосив в таблице опций информацию об активных виджетах получил нормальную страницу без глюков. И что интересно пока ошибка была виджет хоть и был включен (по инфе в базе), но не было его в активных виджетах в «управлении виджетами». Активировал виджет повторно и заполнил данные — глюк пропал. Аналогичный баг я виделна другом сайте, с другой темой и там был глюк именно в теме. Что то было кривое в functions.php и пока не выкосили оттуда код, то выскакивала везде ошибка о разных глюках где то в недрах движка и знаменитая «cannot modify header…» (хотя вся тема была сохранена корректна).
Надеюсь пригодится кому нибудь информация :-)
Связанные записи
18 комментариев на запись “О глючных «темах», избыточной нагрузке и глюках неизвестного происхождения на блогах”
30 сентября 2008 в 16:46
Сервис который ты привёл по ссылке действительно архиполезный. Я им сам пользуюсь. Там если отметить пункт «Save test», то сохраняется история проверок.
30 сентября 2008 в 18:19
Кактус, пост классный. Да, вот, ссылки на злополучную тему ведут на …
Короче просто большая просьба — выложи отфиксенную тобой тему и мы ее скачаем, чтобы не вникать в подробности :-)
30 сентября 2008 в 18:54
как избавится от бага я написал — просто заменить указанный файл
30 сентября 2008 в 21:51
а скачать не могу-то.
сцылки ведут в.. или я чето не понимаю ((
30 сентября 2008 в 21:55
@GoldMan: не понимаю я ваших «…». вы на ссылки нажимали? почему у всех все открывается а у вас нет ? может пора сменить провайдера/браузер/и тд ?
30 сентября 2008 в 22:04
вот например, при попытке скачать «скачал свежую версию» выдает мне это
* ..
* .htaccess
* README.txt
* format
* timthumb.php
Все это по адресу
Все так и должно быть?
30 сентября 2008 в 22:13
@GoldMan: вообще то ДА! Это список файлов, а timthumb.php — это искомый файл. уж что-что про это догадаться можно поди
30 сентября 2008 в 22:20
бльоооо
:-(
Прости.
23 октября 2008 в 19:32
Спасибо за сайт, теперь вижу в каком направлении копать :)
25 октября 2008 в 4:50
A YSlow, простите, ничего не сказал?
25 октября 2008 в 5:56
кстати:
Вот результаты для одной страницы:
Это из "сервиса"
Total objects: 39 (158.8 KB)
External objects: 8 (2.7 KB)
(X)HTML: 1 (46.6KB)
CSS: 4 (26.5KB)
Scripts: 4 (33.4KB)
Images: 30 (52.3KB)
Redirected: 2
А это из "YSlow"
41.8K 1 HTML/Text
34.1K 4 JavaScript Files
27.1K 4 Stylesheet Files
42.2K 14 CSS Images
2.9K 8 Images
148.3K Total size
31 HTTP requests
Наблюдается определенное сходство, не смотря на разные методики оценки. ;)
12 апреля 2009 в 14:33
Добрый день, Уважаемый Кактус!
Перерыл блог, но так и не смог найти ответ на волнующий меня вопрос…
Дело в том, что на одном из 6-ти живых сайтов на Вордпрессе, которые я поддерживаю, после смены хостинга вылез непонятный глюк. При попытке обновления плагина в автоматическом режиме вылетает окошко с таким примерно текстом:
__________
Информация для подключения
Чтобы выполнить запрошенное действие, требуется ввести информацию для подключения.
Имя сервера
Имя пользователя
Пароль
Ключи аутентификации
Публичный ключ:
Личный ключ:
Введите путь к директории на сервере, где расположены ключи. Если требуется пароль, введите его в поле выше.
Тип подключения
Тип подключения FTP
FTPS (SSL)
_____________
Что делать с этим "добром" — ума не приложу… :(
29 июля 2009 в 15:51
Офигеть!!!
респект за помощь
давно искал решение этой проблемы
23 августа 2009 в 22:48
Здравствуйте! на моем сайте похоже такая же проблемма. показывает миниатюры но грузит всю картинку польностью, и еще параллельно грузит все картинки на блоге (хотя заходиш на главную)…
В моей теме этого файла нет >>>thumb.php
пожалуйста помогите!!! что делать?
если есть время тут можно увидеть проблемму
27 сентября 2009 в 3:38
А чем Firebug не устроил?
13 ноября 2009 в 0:07
Обратите внимание на то, что по каким-то причинам указанный файл thumb.php (тот самый, свежескачанный) может вместо JPG создавать PNG. В этом случае имеет смысл перейти на страницу создателей скипта, указанную в посте, а там найти раздел «Issues». Тема называется «20kb JPG file converts to a 200kb PNG file — increase in file size «. В ней прикреплён изменённый файл timthumb.php (13.1 KB).
У меня сработало.
30 января 2010 в 18:57
Всем привет!
При использовании timthumb.php столкнулся с проблемой нагрузки на сервер: ведь миниатюры режутся каждый раз снова для нового пользователя, это легко проследить понаблюдав за папкой Cache. Кеширование страниц не помагает. Есть ли решение этого вопроса?
5 декабря 2010 в 10:46
Ответ мой поздноват для Андрея, но если кто-то, как и я попадёт на эту страницу введя в поиск «Чтобы выполнить запрошенное действие, требуется ввести информацию для подключения к веб-серверу», то ему будет полезно. В эти поля требуется ввести данные для подключения по FTP к вашему хостингу, соответственно смотрите письма, полученные при регистрации у хостера, и вводите данные о имени сервера (например, что-то вроде сайт.88.hosting-agava.ru) и логин/пароль для доступа к вашей файловой системе