Ето ме с нов-новеничък WordPress 2.2 “Getz”, който инсталирах на 21 май, няколко дни след официалното му излизане. Има доста подобрения (няма да влизам в детайли, а и може просто да проверите списъка с bugfixes за WP 2.2) – но има и бъгове, които са нови само за WP 2.1.x (и 2.2.x).
В този пост искам да разкажа само за две неща – един “+” и един “-“.
Първо, две думи за главния плюс на v. 2.2 (според мен):
Проблемът с кирилицата (а и всякакви други езици) и MySQL най-после е разрешен по един доста гладък начин! Вече няма нужда от “хакове”, за да работят нещата добре!
Преди:
При upgrade на WordPress се налагаше всеки път ръчно да се редактира файлът wp-db.php (намиращ се в wp-includes), и след следния код:
$this->dbh = @mysql_connect($dbhost, $dbuser, $dbpassword);
се вмъкваше:
mysql_query("SET NAMES 'utf8' COLLATE 'utf8_unicode_ci'");
Това разрешаваше проблема с кирилицата при ползване на UTF-8 encoding, и оправяше комуникацията между PHP скриптовете на WP и MySQL базата данни.
Забележка: Тази стъпка не е необходима винаги, когато се инсталира WordPress – всичко зависи от настройките на MySQL на сървъра.
Сега:
Същите настройки (SET NAMES, COLLATION) са вече част от wp-config.php файла. Красота! :-)
Има безброй support requests във форума на WordPress How-To & Troublshooting, посветени на проблема с UTF-8/MySQL/SET NAMES/collation… Затова изнасянето на тези настройки в wp-config.php е стъпка в правилната посока.
Аз за първи път се сблъсках с проблема, когато направих тестова WordPress инсталация на този сайт (беше през декември миналата година). В началото тествах на няколко пъти, преди да стигна до финалния вариант на блога. Всичко изглеждаше ОК, до момента, в който погледнах в MySQL базата данни. Беше пълна с маймуни, вместо с кирилица!
Странното беше, че на самия блог всичко си се четеше ОК!
Мистерията беше разрешена след дълго ровене из support форумите на WordPress. Оказа се, че има такова нещо като default encoding, който се използва при комуникирането на MySQL базите данни с PHP скриптовете. В моя случай, default encoding’ът се оказа… Latin-1 (Swedish)! И само защото родината на MySQL е Швеция! Cool! Да, ама на мен сайтът ми е с UTF-8, и нещата се объркваха от този latin-1!
Workaround-ът се оказа относително прост. Отваря се wp-db.php файлът в wordpress/wp-includes, и се добавя SET NAMES, COLLATION и това overwrite’ва latin-1. Единственият проблем беше, че при всеки upgrade се налагаше ръчното редактиране на файла.
Затова посрещам с радост WP 2.2, където SET NAMES & COLLATION са вече (опционално) част от wp-config.php. Няма нужда повече от “хакване” (ръчно редактиране) на wp-db.php, за да е ОК кирилицата (и всякакви други странни знаци;-) в моя WordPress blog.
***
А сега и две думи за главния минус на v. 2.2 (пак според мен):
Първата версия, инсталирана на Optimiced, беше WordPress 2.0.5. Тъй като използвам две инсталации на WordPress (за моите двуезични нужди) бях решил, че за мен най-удобно е да качвам всички файлове (снимки, картинки и т.н.) в wp-uploads в главната директория на optimiced. Което означава едно ниво по-нагоре от едната и от другата инсталация на WordPress блога.
Дотук добре.
За целта отивам в:
OPTIONS -> MISCELLANIOUS -> Uploading -> Store uploads in this folder: ../wp-uploads
В случая, “../” означава едно ниво по-нагоре от wordpress (както е прието), и после посочвам директория wp-uploads.
Във версия 2.05 тази настройка правилно се разпознаваше от WordPress и всички файлове отиваха в https://www.optimiced.com/wp-uploads/ при качването им директно от интерфейса на самия блог при писането на нов пост.
След като направих първия си сериозен upgrade (мисля, че беше към версия 2.1.1), изведнъж тази настройка спря да работи. “../” просто започне да се добавя към URL адресите! Примерно, https://www.optimiced.com/bg/../wp-uploads/ вместо https://www.optimiced.com/wp-uploads/!
Нещо беше променено в core файловете на WordPress.
Опитах след това всевъзможни други варианти – от root да задам настройката за uploads, с абсолютен адрес (http://…), относителен, какво ли не. Не ставаше и не ставаше.
Надеждата ми беше, че като излезе 2.2, този бъг ще се оправи.
Е, не. Все още нещата са така — не може да се зададе директория за качване на файлове, намираща се едно ниво по-високо от тази, в която е инсталиран блогът. Затова качвам файловете през FTP (Filezilla не е лош ftp клиент) и после само копирам линковете. Малко е по-бавно, но за момента не съм открил друг начин.
Пуснах и trac ticket, сега чакам да видя, какво ще стане… Дано му обърне някой внимание:)
(BTW, ако някой знае, в кой файл на WordPress се объркват нещата с дефинирането на upload директория, ще се радвам да остави коментар по-долу, може би поне временно ще мога да patch’на нещата, докато чакам развитие по track ticket’a:)))
***
Бях подготвил draft на този текст преди седмици… От работа и непрекъсната заетост той потъна в “дългото чекмедже” (както аз го наричам), та сега реших да го изровя и с една-две дребни корекции да го пусна да види бял свят. Може да се окаже полезен за някой:)