SEO блог и уеб програмиране » бъг

Бъг в IE8 и Google Chrome

Георги Стефанов — Sun, 10 Jan 2010 15:59:19 +0000

Вече двама души ми съобщиха, че под браузъри Google Chrome и Internet Explorer 8 блога ми не се изобразява правилно и двете колони вдясно се разместват.

Направих проверка и наистина с тези браузъри текста от средната колона навлизаше в дясната колона и изместваше цялото и съдържание извън колоната (виж картинката).

Като цяло кода на страницата си беше валиден XHTML и затова помислих, че става въпрос за промени по интерпретиране на CSS в тези нови браузъри. Прекледах какви са елементите на страницата. Двете колони вдясно са включени в две от колоните на HTML таблица. След доста време прекарано в преглеждане на CSS файла се сетих да проверя, кой е най-дългия от низовете в средната колона, който не съдържа интервали и се оказа че е „sites.google.com/site/zabolekarvsofia“ (посочен от червената стрелка на картинката). Тук ми хрумна, че е ако браузъра възприема този низ като една единствена дума е нормално да не го пренася на нов ред. Веднага направих проверка, като сложих един интервал след знака „/“ и така открих този елементарен, но труден за откриване:

Проблем:

Internet explorer 8 и Google Chrome неправилно интерпретират знака / като буква, в резултат на което дълги низове с URL адреси не се пренасят на нов ред и разместват текста по страницата.

Решение:

В моя случай трябваше да се погрижа или по някакъв начин да пренеса низа или да го скъся до 25 символа, за да се събере в колоната, като едновременно с това връзката към страницата, която е платила за SMS реклама да си остане непроменена. Намерих кода на плъгина за SMS реклама в директория /wp-content/plugins и промених тази част, която показва връзките.

Заместих реда:

echo "

\"{$http_link}\">{$row->link}

със следния код:

$link_text = $row->link;
$link_text = preg_replace('|/|','/ ',$link_text);
if(mb_strlen($link_text)>25) $link_text = mb_substr($link_text,0,25).'...';
echo "

\"{$http_link}\">{$link_text}

Това ще доведе до пренасяне на нов ред на връзките след знака / ако не се събере в колоната. Текста на връзката става на повече от един ред, като адреса на линка остава непроменен. За всеки случай добавих и съкращаване на връзките до 25 сивмола, защото освен знака / е възможно да има и други знаци интерпретирани като букви.

Пробвах дали има проблем с други знаци:
не се пренасят на нов ред _ , . @ & ? + = ; пренася се на нов ред - това важи за всички браузъри.
Знаците / \ се обработват различно в различните браузъри – IE8 и Chrome не ги пренасят, Firefox – да.
Интересно е че със знака ! е обратно – при IE8 низа се пренася, а при Firefox и Chrome не.

Това са особености на браузърите, с които трябва да се съобразяваш, когато поставяш дълъг низ на място с ограничена ширина.

Брой разглеждания на тази статия: 3522

Бъг в WordPress: визуалния редактор не работи

gan — Mon, 12 Oct 2009 17:11:23 +0000

Преди малко открих бъг в WordPress 2.8.4 (последната версия в момента).

Грешка

Докато за пореден път актуализирах любимата си статия Популяризиране на сайт с външни връзки, открих следния неприятен ефект – в админ панела при промяна на публикация визуалния редактор спира да зарежда текста и в долния десен ъгъл изчезна грапавото ъгълче за разтягане на полето с текста на публикацията. Така единствено в режим на HTML може да се промени статията.

Проучване

Разгледах внимателно цялата страница и забелязах, че страницата не се е заредила до края и не показва предишните версии на публикацията. В долния край на страницата има списък с предишни версии на публикацията, които се увеличават при всяка промяна на статията. Веднага след заглавието на списъка „Версии на публикацията“ страницата завършваше. Разгледах други публикации от блога, но там нямаше проблем. Това ме наведе на мисълта, че грешката се дължи на големия брой версии на публикацията и дългия текст. За съжаление в момента нямам време да прегледам кода на WordPress, но вероятно всички предишни версии се зареждат в паметта и при голям брой версии страницата се чупи.

Отворих cpanel на хостинга и от там влязох в phpMyAdmin. След кратко разглеждане на таблицата с публикациите wp_posts разбрах как да изведа броя на предишния брой публикации.От адреса на страницата за промяна на публикация се вижда, че номера на публикацията е 125. Адреса е: http://ganbox.com/blog/wp-admin/post.php?action=edit&post=125

Изпълнява се следната SQL заявка:

SELECT * FROM `wp_posts` WHERE `post_name` LIKE '125-%'

Където 125 е номера на публикацията и при мен изведе
Showing rows 0 – 29 (82 total, Query took 0.0041 sec)

Вижда се, че има 82 версии на публикацията, като се добави и това, че текста е дълъг бях сигурен, че това е проблема.

За всеки случай си направих резервно копие на таблицата wp_posts и след това реших да поизтрия малко стари версии.

Решение

Първо изпълних заявката

SELECT * FROM `wp_posts` WHERE `post_name` LIKE '125-%'
AND post_date < NOW() - INTERVAL 1 MONTH
ORDER BY post_date

Showing rows 0 – 29 (56 total, Query took 0.0173 sec)

Това ми показва, че има 56 версии по-стари от един месец.

Изтрих ги със заявката:

DELETE FROM `wp_posts` WHERE `post_name` LIKE '125-%'
AND post_date < NOW() - INTERVAL 1 MONTH

Всичко си заработи нормално при промяна на публикацията.

Явно този бъг се проявява много рядко и само, когато сумарния текст от всички версии на една публикация е прекалено голям. Ако и при теб „Визуалния редактор“ на WordPress спре да зарежда текста може да пробваш този хак.

Винаги прави резервни копия на базата данни преди да го използваш, ganbox.com не носи отговорност за проблеми възникнали от използването на този хак.

Брой разглеждания на тази статия: 3067
(след дата 20 декември 2009)

Подобни статии:

WordPress 2.9 на български Както сигурно вече си видял днес излезе новата версия на...