Първо, направих стандартните бекъпи на базите данни и на файловете на WP 2.9.2. Just in case.

После upgrade към WP 3.0. Всичко мина гладко, ако не броим:

1) Math Comment Spam Protection плъгинът (версия 2.2, леко модифицирана от мен, за да се сработва добре с WP Super Cache) директно спря да работи и така за един миг “събори” анти-спам защитата на всички блогове, които поддържам. До WP 2.9.2 този прост и изключително ефективен плъгин срещу спам работеше супер-стабилно и не създаваше никакви грижи (“2+1=?”). Но вече не. Предполагам, в ядрото на WordPress са настъпили някакви сериозни промени, които са направили плъгина неработещ…

Ще търся ново ефективно (но просто) решение за проблема със спам коментарите — за съжаление, WP Spam Free май също не работи с версия 3.0, а плъгини, които разчитат на CAPTCHA или на специални алгоритми за разпознаване на спам коментари, не признавам. Или са твърде досадни, или неефективни, или и от двете по малко…

AKISMET също не става, защото първо пуска спам коментарите до базата данни, а освен това и има false positives…

Уф.

2) Сега WordPress изисква още повече памет за PHP процесите. На 64-битов сървър с “чиста” инсталация на WP 2.9.2 и стандартна тема, без никакви инсталирани плъгини, WP има нужда от около 14.5 MB памет, само за да зареди заглавната страница от блога. За WordPress 3.0, числото нараства на поне 16.5-16.75 MB. Това е с цели 2 MB повече!

Ако добавите и няколко базисни плъгина (анти-спам, кеширане, статистики…), ще имате нужда от поне 24-25 MB памет за зареждането на само една (!) страница!

Какво означава това за обикновените потребители, които ползват shared hosting услуги? Вероятно е по-често да виждат SERVER ERROR 500 при опит за зареждане на страница от блога или от WP-Admin (администрацията на блога), тъй като много хостинг доставчици имат доста лимитирани параметри за PHP RAM. И не само това.

За сравнение само ще кажа, че за зареждането на една обикновена PHP страница, сървърът има нужда от по-малко от 256 kB памет. Сравнете 256 kB с 17-25 MB, и ще разберете, защо си мисля, че разработчиците на WP напоследък започват твърде много да да се стараят да добавят нови и нови функции, без изобщо да се опитват да оптимизират самото ядро на WP. Bloatware? Надявам се, не. (Това вече сме го виждали при Adobe — все повече и повече функции, а програмите стартират все по-бавно и по-бавно и имат нужда от все повече памет и CPU…)

Не разбирам от PHP, само от дизайн, иначе с удоволствие бих се включил с мой малък принос към развиването (и оптимизирането) на WordPress. Но в случая трябва да разчитам на някой друг — примерно, гурута като Ники Бачийски и Matt… :-)

Надявам се WP 3.0.x/3.1.x да се фокусира повече върху оптимизирането на ядрото, отколкото върху добавянето на нова функционалност. Иначе скоро WordPress няма да може да работи нормално върху повечето shared сървъри…

UPDATE-1 (2010/06/21): Пробвам да заместя защитата с Quiz 1.2. След малко “хакване” на кода на плъгина и на темата на блога, проработи, май. Сега ще тествам също така, дали ще спре спамботовете ефективно, или не.

UPDATE-2 (2010/06/21): Frank Bültge от WP-hackers листата бе така добър да погледне кода на математическия плъгин и сега тествам негова леко променена версия… :)

[...] I’m tired of the tedium and repetition. Using WordPress and a good theme framework means that a lot of a site’s infrastructure is already done for me, and done solidly too.

Like James Dalman said in his article:

• It takes a lot of energy and time to create something from nothing,
• freelancers are limited by time,
• and a business’ primary goal (freelance or otherwise) is to be profitable.

— дизайнерът Stéphane Bergeron за използването WP themes frameworks

Мисля, че той е прав. Лично аз обичам да контролирам почти изцяло HTML/CSS кода, който създавам, но ако трябва да напиша една тема за WordPress от A до Z, това вероятно би ми отнело поне два пъти повече време, отколкото да адаптирам готова, стабилна тема. Възможността да адаптирам готова тема за целите ми (или да адаптирам theme framework) почти не ме ограничава, но за сметка на това ми дава възможността да спестя доста време.

Скорошен такъв пример е новият дизайн на nixonixo.com — въпреки че с Никсо се спряхме на готова минималистична тема (Manifest), дизайнът на сайта се получи доста различен, и според мен постига целите си доста добре: layout’тът е разширен от 500 на 800 px; запазен е минимализмът, но има добавени доста нови неща; страницата с архивите е доста по-функционална; коментарната форма (и коментарите) изглеждат по-добре и са по-приятно използваеми; и, може би най-важното — дизайнът е оригинален, въпреки че само около половината код беше пренаписан (btw, тези дни се надявам да ми остане малко свободно време да разкажа повече за измислянето на новия вид на nixonixo.com).

Така че, лично аз одобрявам “надграждането” в някои случаи, в сравнение със създаването на дизайн/код изцяло от A до Z. Но, естествено, всичко зависи от конкретния случай — ако времето/усилията, необходими за промяната на един готов дизайн (готова WP тема) съгласно конкретните нужди, е по-голямо от написването на изцяло нов дизайн, то очевидно може да се окаже по-смислено измислянето и написването на съвсем оригинална WP тема! (Това всъщност каза и Джефри Зелдман неотдавна, в една своя публикация за някои добри WP теми…)

Започвам да осъзнавам, че WordPress и лекотата, с която сега можем да създаваме и променяме цели сайтове, е нещо, за което дори не съм предполагал преди 5 години, във времето на почти статичните сайтове и скъпите и/или тромави CMS системи…

Естествено, Матт е писал за това, като не е пропуснал да спомене и новото кодово име на 2.9: “Carmen” (на името на Carmen McRae).

Преди ден само четох една доста подробна статия за това, какви нови неща ще има в WP 2.9 — тази статия в TechnoSailor ви я препоръчвам и на вас.

Иначе, на мен най-много ми допаднаха две неща:

– Вече може да връщате от “кошчето” неща, които сте изтрили по погрешка (или нарочно)! Всичко изтрито ще се пази в “Trash”-а за поне един месец (като това време може свободно да го промените на една седмица, или пък три месеца).

– Вече ще може да се прави upgrade на всички плъгини с един клик!

Естествено, има и цял куп фикснати бъгове и разни други подобрения (пълен списък).

Аз, обаче, колкото и да съм ентусиазиран, може би ще изчакам до 2.9.1… нещо като първия ServicePack за 2.9.x ;-)

<meta name="generator" content="WordPress [version number]" />

Начинът беше много прост, беше необходимо само да се добави един ред код в functions.php файла в темата на блога. После ми хрумна, обаче, че е възможно да има и по-лесен начин — чрез плъгин. След малко ровене, намерих такъв!

Remove-Generator-Meta-Tag WordPress Plugin

Самият плъгин е изключително прост, просто го качвате в ‘wp-content/plugins/’ и го активирате от WP Admin интерфейса и готово — версията и “WordPress” мистериозно ще изчезнат от кода на страниците! ;-)

Може би има и други подобни плъгини, но това е най-простият, който успях да намеря — и при това върши добра работа! :-)

Това може да бъде полезно, ако вашият WP-базиран сайт е подложен на хакерска атака. Или ако искате да разберете, откъде идва основният поток от спам (IP адреси).

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

Оригиналният код не показваше timestamps на записваните събития. Аз добавих тази функционалност, като запазих кода почти непроменен. Ето я и update’натата версия:

$posty_ip = $_SERVER['REMOTE_ADDR'];
$the_file = $_SERVER['SCRIPT_NAME'];
$browser = $_SERVER['HTTP_USER_AGENT'];
$date_sub = date('Y-M-d @ H:i (O)');
if ( $posty_ip != "123.123.123.12" && $posty_ip != "123.123.123.23" ) {
  if ( !empty($_POST) ) {
    $fp = fopen( '/home/path-to-log/logfile.html', 'a' );
    foreach( $_POST as $key => $value ) {
	fwrite( $fp, $key.' = '.$value." <br />\n" );
	}
    fwrite( $fp, "file = ".$the_file." <br />\n" );
    fwrite( $fp, "ip = ".$posty_ip." <br />\n" );
    fwrite( $fp, "agent = ".$browser." <br />\n" );
    fwrite( $fp, "date = ".$date_sub." <br />\n" );
    fwrite( $fp, '================================================'." <br /><br />\n\n" );
    fclose( $fp );
  }
}

Реших също така да добавя и знаци за нов ред, тъй като за мен беше по-полезно да форматирам лог файла в базисен HTML формат.

Инструкциите къде (и как) да поставите това парченце код могат да бъдат намерени на оригиналното място. Все пак, добре е да повторя още веднъж: Бъдете внимателни, къде ще поставите самия лог файл на сървъра!

И още — препоръчвам (в случай, че администрирате блога си през http, не през https) да използвате плъгин, който криптира паролите (може да го свалите от wordpress.org). Това не е задължително, но винаги, когато е възможно, е добре да се пращат паролите криптирани, а този плъгин го позволява и без да ползвате https.

Enjoy! :-)

UPDATE (2009/05/01): Промених още малко скриптчето, сега може да записва и user agents:) Ако човек се поразрови, има доста възможности…

Тъй като (засега) не съм склонен да плащам по 25 долара на година за още една уеб услуга, албумчето със снимки може да се разглежда удобно онлайн, но не може да си свалите оригиналния размер на снимките. Все пак, за който иска 8 mpix оригинали, може да си ги свали от моя сървър [download link].

Сорри за неудобствата… Надявам се, flickr форматът ще ви е по-удобен! :-)

240 MB ZIP архив (съдържа 39 снимки и един кратък видеоклип). Enjoy! :-)

Ще се радвам, ако споделите и вашите снимки и/или впечатления, също. Благодаря! :-)

В момента сме на WP 2.7 Upgrade партито на Ники Б. и да ви кажа, бира и мезенца не липсват (благодарим, space.bg!) :)))

След като направих uprade до WP 2.6.5, после пълен backup на файловете и базите данни, се престраших и пуснах и upgrade до 2.7. На пръв поглед изглежда, че всичко е наред. Не виждам неработещи плъгини, WordPress си работи нормално. Интерфейсът е изцяло обновен (е, не съм изненадан, виждал съм screenshot-и;-) и по-скоро ми допада, отколкото обратното. Ако мога да се изразя така — WP 2.5 беше стъпка назад (спрямо 2.3.3), а 2.7 е стъпка напред (спрямо 2.5.x/2.6.x) — като интерфейс на админ панела, имам предвид.

Настроението е готино, наоколо мяркам немалко симпатични блогъри (някои от тях — без WordPress — Iffi, намигам ти;-) — Крокодила (ping), Силвина, Гонзо, Стефан, Лина, Светльо — ако съм пропуснал някой, оставете коментар, да се поправя ;-)

Сега отивам да си отворя още една бира, стига съм блогвал Live! :-D

UPDATE (@2:24 am): Снимките!!! :-)

Поради специфични причини, ми беше необходимо да изтрия от HEAD частта на един WordPress блог:


<meta name="generator" content="WordPress [версия номер]" />


Темата, в която правих промените, беше стандартната за WordPress — Default Kubrick Theme. WP версия — 2.6.2.

Рових, рових в кода на header.php — нищо не намерих! Преди във всяка WP тема, в header.php, обикновено присъстваше следният ред код:


<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" /><!-- leave this for stats -->


Сега не успях да го открия…

Пуснах и global search във всички файлове на темата, пак нищо не успях да открия. Накрая прибегнах към последното възможно решение — търсене…

И намерих! :-)

Накратко: ако искате да скриете от кода "<meta name="generator" content="WordPress ..." />, както и коя версия е конкретният WP блог, всичко, което трябва да направите, е (в случай, че не намирате кода в header.php), е:

1) Намерете и отворете файла functions.php в темата, която използвате в момента — например, ако ползвате Default Theme, то този файл ще се намира в wp-content/themes/default/funtions.php.
2) Добавете вътре във файла в следния код:
remove_action('wp_head', 'wp_generator');
3) Запишете functions.php и го качете обратно на сървъра.

Това е! Automagically, кодът, който показва, че използвате WordPress, както и конкретната негова версия, ще изчезне от HTML сорса! :-)

Може чрез FTP и браузър. Може чрез SSH и браузър — и може дори да се напише и малък скрипт, който да прави backup на файловете и след това да инсталира последната версия на WP. А може и през SVN и браузър.

Аз в момента, за различни WP блогове, ползвам основно двата последни начина — през SSH чрез скрипт, или чрез SVN:

Вариант 1: Пускам малък shell скрипт, който прави backup на WP файловете и директориите, след това сваля WP latest stable, разархивира, трие старите файлове, копира новите и след това остава само да пусна upgrade.php и съм готов. (Е, ползвам и плъгин за автоматично бекъпване на MySQL базата данни, че това през SSH не съм го пробвал).

Вариант 2: SVN — ако инсталирам блога през SVN:
svn co http://svn.automattic.com/wordpress/tags/2.X.X .
(http://svn.automattic.com/wordpress/tags/)

…после е лесно, при upgrade — бекъпвам базата данни чрез плъгин, след това:
svn sw http://svn.automattic.com/wordpress/tags/2.6.1/ .
…и накрая, отварям upgrade.php и сме готови.

Единствено се чудя — когато ползвам SVN, дали мога лесно да се върна към предишна версия, ако нещо се обърка? При условие, че съм направил и snapshot на MySQL базата данни, естествено. Не съм тествал, а пък иначе горните две команди съм ги преписал прилежно, без да съм сигурен, как точно става магията… :)

Иначе, SSH и SVN ти дават голяма свобода — вместо да чакаш половин час триене на файловете през FTP и после още толкова време за качването на новите, пък да не прекъсне връзката… вместо това, за секунди инсталация и upgrade… красота! :-)