Często zachodzi potrzeba sprawdzenia tego, jak wygląda czas generowania naszej strony lub ile generuje ona zapytań do bazy danych. Pomijając tutaj użycie profilerów (choćby ze względu na brak dostępności na większości hostingów) pokażę jak uzyskać takie informacje w skrypcie Wordpress.

Pobieranie ilości zapytań
Aby uzyskać ilość zapytań wykonanych do bazy przez Wordpressa należy skorzystać z funkcji get_num_queries() - zwraca ona liczbę tylko liczbę wykonanych zapytań. Przykład użycia pokażę na końcu wpisu.

Pobieranie listy zapytań
Pobranie samej treści wykonanych zapytań jest już lekko trudniejsze. Należy zacząć od zdefiniowania jednej stałej w pliku wp-config.php. Gdzieś w nim (można to zrobić np. po stałej WP_DEBUG) należy umieścić następujący zapis.

define('SAVEQUERIES', true);

W tym momencie Wordpress zacznie logować informacje na temat wszystkich wykonanych przez siebie zapytań. Aby je wyświetlić możemy użyć kodu oferowanego przez oficjalną dokumentację WP:

<?php
if (current_user_can('administrator')){
  global $wpdb;
  echo "<pre>";
  print_r($wpdb->queries);
  echo "</pre>";
}
?>

Zasada działania jest prosta: jeżeli dany użytkownik ma uprawnienia administratora, to pokaże się dump tablicy wielowymiarowej zawierającej informację o zapytaniu. Na każde zapytanie składają się trzy klucze. Pierwszy określa treść zapytania, drugi: czas jego wykonania, a trzeci mówi o tym jak po kolei wyglądała droga do wykonania tego zapytania (dołączane pliki i wywoływane funkcji).

Jeżeli jednak, tak jak ja, nie potrzebujecie aż tak szczegółowych informacji o każdym zapytaniu, możecie użyć takiego kodu:

<?php
global $wpdb;
foreach ($wpdb->queries as $query) 
  echo $query[0]."\n";
?>

Ten kod pokazuje jedynie treść wykonanych zapytań. Uwaga: ja używam tego kodu do wsadzenia tej informacji w HTML-owy komentarz. Jeżeli chcecie wyświetlić to na stronie, to pamiętajcie o zamianie nowej linii na br. Oczywiście można dodać sprawdzanie uprawień użytkownika, aby takie informacje udostępnić tylko dla administratorów (to wskazane posunięcie!).

Pobieranie czasu generowania strony
Do pobrania czasu generowania strony opartej na WP służy funkcja timer_stop(). Przyjmuje ona dwa parametry, pierwszy określa czy wartość ma być wyświetlona (1), czy zwrócona (0; ustawienie domyślne). Drugi określa zaś precyzję, czyli ilość cyfr po przecinku w czasie generowania (domyślnie 3). Przykład użycia za chwilkę.

Sprawdzanie ilości użytej pamięci
Tutaj skorzystamy już z wbudowanej w PHP funkcji memory_get_usage(). Zwraca ona wynik w bajtach, tak więc dla lepszej czytelności zatroszczymy się o przeliczenie na megabajty.

<?php echo number_format(memory_get_usage()/1024/1024, 2); ?>

Drugi parametr funkcji number_format() także określa liczbę miejsc po przecinku.

Kompletny przykład
Oto przykładowa implementacja powyżej pokazanych rozwiązań.

<!--
Zapytania: <?php echo get_num_queries();
global $wpdb;
foreach ($wpdb->queries as $query) 
  echo $query[0]."\n";  ?>
Czas generowania: <?php timer_stop(1, 2); ?>s
Użyta pamięć: <?php  echo number_format(memory_get_usage()/1024/1024, 2); ?>MB
-->

I to by było na tyle. Mam nadzieję, że przedstawione rozwiązanie do czegoś się Wam przydało. Pamiętajcie też, że po skończonym debugu lepiej jest usunąć stałą SAVEQUERIES z konfiguracji lub przestawić ją na false, gdyż włączenie opcji logowania zapytań zwiększa zużycie zasobów.

Każdy, kto korzystał z WordPressa i ma w zwyczaju patrzeć jak jego strona wygląda "pod maską", z pewnością zauważył, że tytułowy CMS nie generuje najlepszego jakościowo kodu. Wynika to głównie z jego rozszerzalności i uniwersalności, ale nie oznacza to, że w prosty sposób nie możemy pozbyć się części nadmiarowego kodu HTML i CSS.

Usuwanie odwołania do RSD (Really Simple Discovery)
Mowa o następującym kodzie w nagłówku strony:

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://example.com/xmlrpc.php?rsd" />

Jest on używany przez klienty protokołu XML-RPC, np. Windows Live Writer. Jeżeli nie używasz go lub wspomniane nazwy po prostu nic Ci nie mówią, prawdopodobnie możesz bez obaw usunąć ten kod ze swojej sekcji head.

Jak to zrobić? To bardzo proste, dzięki wbudowanemu w WordPressa systemowi akcji, który pozwala także na ich usuwanie. Najlepszym sposobem będzie dodanie następującego kodu na koniec pliku functions.php w katalogu Twojego szablonu (wp-content/themes/Twoj_Theme/functions.php). Jeżeli plik o tej nazwie nie istnieje we wspomnianej lokalizacji, należy go utworzyć i wstawić poniższy kod w jego treść:

<?php
remove_action('wp_head', 'rsd_link');

Usuwanie odwołania do WLW (Windows Live Writer)
Odpowiada za niego następujący kod HTML w nagłówku bloga:

<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://example.com/wp-includes/wlwmanifest.xml" />

Jego przeznaczenie jest takie jak powyższego, co widać dokładnie po nazwie :) Jeśli chcesz go usunąć, to analogicznie do functions.php w katalogu Twojego szablonu (więcej wyżej) dodaj kod:

remove_action('wp_head', 'wlwmanifest_link');

Usuwanie wersji WordPressa (meta generator) Mówię oczywiście o tym:

<meta name="generator" content="WordPress X.X.X" />

Ten kod jest najprawdopodobniej zbędny. Skorzystać z niego będą prawdopodobnie tylko roboty przeszukujące sieć pod kątem starych wersji WordPressa, które będą podatne na ataki. Nic nie stoi więc na przeszkodzie, aby i jego usunąć. Na koniec wspomnianego pliku functions.php dodajemy kod:

remove_action('wp_head', 'wp_generator');

Linki relacyjne i nawigacyjne do wpisów
Wiele blogów generuje kod na kształt poniższego:

<link rel='index' title='Strona główna' href='http://example.com' />
<link rel='start' title='Pierwszy wpis' href='http://example.com/pierwszy-wpis/' />
<link rel='prev' title='Post poprzedni' href='http://example.com/post-poprzedni/' />
<link rel='next' title='Post następny' href='http://example.com/post-nastepny/' />

Na początku warto zaznaczyć, że ten kod może być często przydatny, korzystają z niego niektóre przeglądarki, aby ułatwić nawigację pomiędzy kolejnymi artykułami na stronie (np. Opera). Jeśli jednak uważasz, że takie rozwiązanie jest Ci niepotrzebne, możesz je usunąć dodając do functions.php:

remove_action('wp_head', 'start_post_rel_link'); // Odniesienie do pierwszego wpisu
remove_action('wp_head', 'index_rel_link'); // Odniesienie do strony głównej
remove_action('wp_head', 'adjacent_posts_rel_link'); // Odniesienia do postów sąsiednich (poprzedni, następny)

Cały plik functions.php
Czyli opcja dla leniwych

<?php
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
remove_action('wp_head', 'wp_generator');
remove_action('wp_head', 'start_post_rel_link');
remove_action('wp_head', 'index_rel_link');
remove_action('wp_head', 'adjacent_posts_rel_link');

Wyjaśnienie na koniec
Możesz też sobie zadać pytanie: dlaczego nie usunąć podanych fragmentów wprost z kodu WordPressa zamiast używać funkcji remove_action()? Odpowiedź jest bardzo prosta: przedstawione wyżej rozwiązanie nie narusza w żaden sposób rdzenia skryptu, w związku z czym zmiany nie zostaną utracone np. przy aktualizacji. Umożliwia też ono łatwe cofnięcie zmian - wystarczy usunąć odpowiednie wywołanie funkcji remove_action()

Mam nadzieję, że przedstawiona krótka porada przyda się Wam. Zawsze to zaoszczędzone kilka bajtów transferu :)

Witajcie,

jak może część z Was pamięta, przy ostatniej migracji zmieniłem lekko format linków prowadzących do wpisów. Uważałem, że pozbycie się ID notek z adresów będzie dobrym posunięciem, bo wtedy linki staną się zwyczajnie prostsze. Założenie dobre, a wyszło… jak zwykle ;)

Można mi się dziwić czemu nie zadbałem o przekierowania ze starych adresów na nowe - po prostu sądziłem, że Google znacznie szybciej zreindeksuje strony. Tak czy siak problem narastał, zainstalowałem wtyczkę 404 redirected by Weberz. Za jej pomocą ustawiłem kilkadziesiąt ręcznych przekierowań 301 na nowe adresy, sama wtyczka utworzyła ich ponad 800. Mimo wszystko Centrum dla Webmasterów od Google nadal informowało o rosnącej liczbie błędów 404 na mojej stronie. Czymś co najbardziej mnie martwiło, jest to, że liczba błędów 404 wykazywanych przez Google z każdym dniem rośnie (aktualnie koło 480).

W pewnym momencie nowe przekierowania dodawane w wyżej wspomnianej wtyczce po prostu przestały mi działać. Dlatego poszukałem innych rozwiązań - dodatkowo doinstalowałem  (starej nie usuwałem, ze względu na te ponad 800 już ustawionych redirectów)  wtyczkę Redirection.

W końcu stwierdziłem, że ręczne dodawanie kolejnych przekierowań mija się z celem i postanowiłem zautomatyzować proces. Napisałem na tą okoliczność mały skrypcik, który przedstawiam poniżej.

<?php
$mysqli = new mysqli('serwer', 'user', 'haselko', 'baza');

$result = $mysqli -> query("SELECT ID, post_name FROM wp_posts WHERE post_status = 'publish' AND post_type = 'post'");

$i = 1;
while ($row = $result -> fetch_array()) {
	$mysqli -> query("INSERT INTO wp_redirection_items SET url = '/".$row['ID']."/".$row['post_name']."/', action_data = '/".$row['post_name']."/', regex = 0, position = $i, group_id = 1, status = 'enabled', action_type = 'url', action_code = 301, match_type = 'url';");
	$mysqli -> query("INSERT INTO wp_redirection_items SET url = '/".$row['ID']."/".$row['post_name']."', action_data = '/".$row['post_name']."/', regex = 0, position = $i, group_id = 1, status = 'enabled', action_type = 'url', action_code = 301, match_type = 'url';");
	$mysqli -> query("INSERT INTO wp_redirection_items SET url = '/".$row['ID']."/', action_data = '/".$row['post_name']."/', regex = 0, position = $i, group_id = 1, status = 'enabled', action_type = 'url', action_code = 301, match_type = 'url';");
	$mysqli -> query("INSERT INTO wp_redirection_items SET url = '/".$row['ID']."', action_data = '/".$row['post_name']."/', regex = 0, position = $i, group_id = 1, status = 'enabled', action_type = 'url', action_code = 301, match_type = 'url';");
	++$i;
}

Skrypt dodaje rekordy do tabeli wyżej wspomnianego pluginu - we wszystkich formatach, w jakich mogą być spotykane w na moim blogu lub indeksach Google. W ten sposób z automatu dodałem 456 przekierowań (liczba wpisów * 4 możliwe warianty).

Mam nadzieję, że to rozwiąże problem i liczba stron z błędami 404 zacznie spadać. W najbliższym czasie podzielę się wynikami.

Na bloga powrócił skrypt WordPress Cleaner. Część z Was może go jeszcze pamiętać ze starej wersji bloga. Po ostatnich zmianach postanowiłem go nie wrzucać, do momentu napisania lepszej wersji. I oto jest!

Skrypt służy do usuwania rewizji wpisów z bazy danych WordPressa. Rewizje to kopie zapisywane automatycznie przez edytor wpisów, są tworzone co jakiś czas, głównie po to, aby nie utracić wpisu po nieoczekiwanym zamknięciu strony edycji (np. poprzez brak zasilania i wyłączenie komputera lub po prostu przypadkowe wyłączenie przeglądarki).

W nowszej wersji uprościłem skrypt (wydaje mi się, że tak bardzo jak to możliwe) i poprawiłem kilka rzeczy.

Więcej informacji tutaj.

Jedną ze zmian dokonanych przy ostatniej migracji, którą z pewnością moi stali czytelnicy (kilku takich jest :P) zauważyli od razu, jest zmiana szablonu na na moim blogu. Nadal jest to Mystique, jednak wersja, z której korzystałem tak długo pochodziła sprzed ponad dwóch lat (pobierałem ją dziesiątego maja 2010, w momencie zakładania bloga). Teraz, po tak długim czasie zdecydowałem się jednak na pobranie najnowszej wersji. Nie było to łatwe, bo w mojej poprzedniej wersji wprowadziłem ogromną ilość modyfikacji.

Przy tej okazji udało mi się jednak przełamać i zachęcony nowym wyglądem (i częściowo nowymi możliwościami) postanowiłem dokonać aktualizacji i ponownie poprawić co nieco w szablonie. Największą robotą było przetłumaczenie całego szablonu na polski (jeśli gdzieś znaleźliście błędy w tłumaczeniu to proszę serdecznie o kontakt).

Poza tym (tak samo jak w poprzedniej wersji szablonu z której korzystałem) starałem się lekko poprawić wynikowy kod HTML. Niestety, Wordpress zbudowany jest w ten sposób, że pewne fragmenty kodu narzuca odgórnie, więc żeby je zmodyfikować musiałbym albo napisać własne wersje masy funkcji z Wordpressa albo modyfikować jego rdzeń, wykraczając z modyfikacjami poza pliki szablonu, co oznaczało by odcięcie się od aktualizacji oprogramowania, bo przy każdej z nich Wordpress nadpisywałby moje zmiany.

Jedną z wprowadzonych zmian jest przeniesienie favicon.ico z katalogu theme'u do głównego katalogu strony (root). Dlaczego? Część przeglądarek wczytując stronę za każdym razem robi dodatkowego requesta pod /favicon.ico w poszukiwaniu favicony. Dopiero gdy jej tam nie znajdzie, to podąża do lokalizacji podanej w znaczniku meta. Efekt jest prosty, mając favicon.ico w innej lokalizacji od części przeglądarek dostawałem o jedne request więcej przy każdym wywołaniu strony. Drobna poprawka, ale skoro coś może być lepsze tak małym nakładem czasu, do dlaczego tego nie zmienić?

Zrobiłem też trochę porządków w sekcji head dokumentu. Usunąłem linki do RSD, WLW, wersję Wordpressa (meta generator) i jeszcze kilka zbędnych rzeczy. Tutaj na szczęście Wordpress pozwala na modyfikację za pomocą systemu akcji (add_action(), remove_action()).

Chciałem też zmniejszyć ilość dołączanych plików CSS i JS, połączyć je w kilka więszych (bo strona generuje spore ilości requestów), ale żeby to osiągnąć musiałbym przerobić używane przez siebie pluginy oraz szablon, a nie mam ochoty tracić pracy przy każdej aktualizacji wtyczki lub co gorsza rezygnować z aktualizacji.

Tym razem zmian ściśle pod maską szablonu nie było wiele, w zasadzie tylko powyższe drobnostki i dopisanie jednego własnego widgetu.

Mam nadzieję, że szablon Wam się podoba, jeśli macie jakieś uwagi, komentujcie :)

No cóż, nadszedł czas na kolejny taki wpis. Była już przeprowadzka z boo.pl na 1&1. Skorzystałem wtedy z oferowanego przez nich darmowego pakietu na dwa lata (jak się okazało pakiet faktycznie był darmowy, niepotrzebna była tak duża ilość krzyku…) Jednak mimo tego, że na jakość 1and1 naprawdę nie mogę narzekać, to ceny były jak dla mnie trochę za wysokie. Właśnie z tego powodu postanowiłem dokonać migracji strony na serwery linuxpl.com. Domena została przetransferowana do hekko.pl

Przebieg migracji
Standardowo, pobrałem wszystkie pliki i całą zawartość bazy danych z poprzedniego hostingu. Potem skorzystałem z okazji i zrobiłem w nich naprawdę duże porządki, ale o tym niżej ;) Jeśli chodzi o samą właściwą migrację, to wszystko poszło aż zaskakująco dobrze. Po wgraniu plików na nowy serwer zostało mi tylko pozmieniać pliki konfiguracyjne i zmienić dwie opcje w bazie danych Wordpressa - blog działał bez zarzutu :)

Porządki, porządki i jeszcze raz porządki…
Od poprzedniej akcji czyszczenia serwera minął już prawie rok. Jestem zdumiony jak dużo śmieci udało mi się nagromadzić od tamtego czasu, mimo tego, że nie zostawiałem każdego wrzuconego na serwer pliku…

Z najciekawszych rzeczy trzeba wspomnieć, że w momencie kiedy przenosiłem się z boo.pl na 1&1, to działała jeszcze moja stara strona domowa - napisana bez użycia żadnego CMS-a, po prostu zlepek mojego PHP i HTML z kilkoma darmowymi skryptami i pomocą kolegów :) Niedługo po przenosinach do 1&1 postanowiłem skończyć działalność tamtej strony i zastąpić ją blogiem. Jak się okazało, w swojej genialności zostawiłem wszystkie pliki tej strony. Jedyny, którego brakowało na FTP to index.php, podmieniłem go na tego z Wordpressa. Tak czy siak - jeden konkretny śmieć wyleciał z serwera. W Google do dziś bez problemu można znaleźć linki do tamtych podstron mimo, że nie były aktualizowane i używane od prawie dwóch lat.

Krótkie podsumowanie innych rzeczy jakie wyleciały z FTP: jedna z nieskończonych gier mojego projektu i związane z nią forum (skrypt Simple Machines Forum), inne prywatne forum (MyBB), ale przede wszystkim niezliczona ilość wszelakich śmieci - łącznie z FTP ubyło ponad 80MB plików, pozostało poniżej 50MB. Jeśli chodzi o ilości, to z ponad 5.200 plików zrobiło się około 1600.

Porządki w bazie danych
Przed migracją w bazie danych znajdowało się 169 tabel, a jej eksport z phpMyAdmina do formatu SQL zajmował 3,6MB. Po dokładnej analizie i podjęciu kilku decyzji ilość tabel w bazie zmniejszyła się do 13… Rozmiar eksportu natomiast wynosi około 2MB (mniejsza różnica w rozmiarze niż w ilości tabel wynika oczywiście z tego, że większość bazy zajmują tabele związane z tym blogiem). Porządki w bazie danych mogę uznać za bardzo udane, zostawiłem tylko to co niezbędne :)

Zmiana szablonu
Zmianą, która z pewnością będzie zauważana na pierwszy rzut oka jest zmiana szablonu na na moim blogu. Nadal jest to Mystique, jednak wersja, z której korzystałem tak długo pochodziła sprzed ponad dwóch lat (pobierałem ją dziesiątego maja 2010, w momencie zakładania bloga). Teraz, po tak długim czasie zdecydowałem się jednak na pobranie najnowszej wersji. Nie było to łatwe, bo w mojej poprzedniej wersji wprowadziłem ogromną ilość modyfikacji. Jako, że zmiana szablonu pociąga za sobą szereg mniejszych zmian, zapraszam do osobnego wpisu opisującego tę kwestię.

Zmiany na blogu czas zacząć
Migracja na inny hosting była idealną okazją do "podłubania" przy blogu i ogólnie całej stronie. Najpierw na spokojnie zajmowałem się stroną na subdomenie otrzymanej od linuxpl, dopiero po zakończeniu prac podpiąłem stronę pod domenę sobak.pl

Jedną z wielu zmian wykonanych na blogu jest wykonanie aktualizacji zarówno samego Wordpressa jak i używanych wtyczek. Być może zastanawiacie się: co takiego strasznego jest w aktualizacji WP?  No cóż, w teorii nic, a w praktyce miałem już kilka niespodzianek.

Kolejnym posunięciem było usunięcie wszelkiej integracji bloga z Twitterem. Samo konto w serwisie także skasowałem. Nie miałem ochoty na zajmowanie się nim (co doskonale widać było po ilości popełnionych na nim notek - ostatnia była z grudnia 2011 roku… Spójrzmy na to pozytywnie - zawsze to jeden request mniej :)

Być może pamiętacie domenę cms.sobak.pl przeznaczoną na rzeczy związane z IronCMS-em. Ona także zniknęła, linki prowadzące do downloadu skryptu zostały zaktualizowane.

Na blogu został także zmieniony sposób linkowania do wpisów -  z URL-i zniknęły ID. Ponadto w wyniku ogólnych porządków, wiele dotychczasowych adresów mogło się zmienić lub przestać istnieć. Starałem się posprzątać po tym wszystkim, jednak nie mogę być pewien że niczego nie przeoczyłem, dlatego jeśli jakiś link nie działa, będę wdzięczny za zgłoszenie.

Kolejną zmianą wprowadzoną na blogu jest możliwość subskrypcji komentarzy do dowolnego wpisu poprzez email (i RSS).

Przeniesienie projektów na bloga
No cóż, zdaję sobie sprawę, że część z Was pamięta pewnie jeszcze jak hucznie zapowiadałem nowe DevCenter. Okazało się że funkcjonowało troszkę ponad rok. Po tym czasie postanowiłem powrócić do koncepcji trzymania projektów przez Wordpressa. Dlaczego? Otóż uważam że zarządzanie jak największą ilością elementów z jednego miejsca jest po prostu wygodniejsze. Do tego dochodzą takie drobne umilacze jak np. wtyczka Akismet do Wordpressa, która bardzo skutecznie chroni przed spamem. Dopiero przy powiadomieniach mailowych dotyczących każdego komentarza w DevCenter zdałem sobie sprawę jak wiele spamu zalewa moją stronę (liczniki Akismeta nie pokazują tego tak dobitnie).

W najbliższym czasie zawartość zakładki projekty zostanie zaktualizowana o nowe pozycje jak i uaktualnienia istniejących skryptów, poinformuję o tym osobnym wpisem.

Aktualizacja części treści na blogu
Małych aktualizacji doczekały się podstrony Informacje i Kontakt. Na pierwszej dodałem trochę więcej informacji o samym sobie, a także krótko opisałem wszystkie poprzednie wersje mojej strony. Odnośnie kontaktu - muszę przyznać, że od długiego czasu, na wskutek błędnego działania przekierowywania maili na 1&1, na moją skrzynkę nie trafiały żadne emaile wysłane na adres podany do kontaktu. Niestety to prawda, przepraszam za utrudnienia i informuję, że teraz wszystko działa poprawnie, a kontakt jest teraz obsługiwany przez wygodny formularz.

Subkiektywne porównanie hostingów
Przy okazji nowego hostingu nie mogło zabraknąć kilku opinii o obu z nich. Zacznijmy od 1&1. Świadczyli naprawdę dobrą jakość usług. Miły, szybko reagujący support (także telefoniczny), to trzeba im przyznać. Możliwości w darmowym pakiecie na 2 lata też były ładne :) Między innymi takie rzeczy jak 1GB pojemności (z darmową możliwością rozszerzenia do 10GB - nie skorzystałem), nielimitowany transfer, 1000 subdomen, możliwość uruchamiania skryptów Perl i Python, umieszczania własnych plików php.ini - naprawdę przyjemnie.

Jeśli chodzi o LinuxPL, to jakby nie patrzeć, jestem tutaj dopiero trzeci dzień. Możliwości uzyskania wsparcia wydają się naprawdę szerokie: email, numery GG do 13 administratorów (plus pokazywanie ich statusu), pomoc telefoniczna, helpdesk, forum. Na temat tego jak support wygląda w praktyce słyszałem najróżniejsze opinie: od tego że reagują bardzo szybko, do tego, że olewają klienta. Mam nadzieję, że potrzebę przekonania się o tym będę miał jak najpóźniej.

Na nowym hostingu pozytywnie zaskoczyły mnie udostępnione panele. Dosyć wygodny Direct Admin, ich własny Panel Klienta i nowy phpMyAdmin. Akurat jeśli chodzi o panele, to mogę się z czystym sumieniem przyczepić do 1and1. Nie spotkałem jeszcze skryptu z którego korzystają - bardzo możliwe, że to jakieś autorskie rozwiązanie. Totalnie przepakowany JavaScriptem i to do zadań do których nie widziałem potrzeby jego użycia. Ilość JS potrafiła spowodować naprawdę niezłe przycięcie się starszych wersji Opery (fakt, że ta nigdy najlepiej sobie nie radziła z JavaScriptem ;)). Było też kilka denerwujących szczegółów jak np. to że z listy baz danych/kont ftp nie mogłem skopiować żadnych danych (nazwy użytkownika itd), musiałem wejść w edycję poszczególnych elementów, aby móc użyć ctrl+c.

Znacznie wygodniejsze są też nazwy użytkowników FTP, MySQL i baz danych. W 1&1 były to losowo (kolejno?) przydzielane ciągi cyfr w stylu u54543545 czy db34543534. Na LinuxPL bazy i użytkowników tworzy się na zasadzie nazwakonta_nazwabazy/nazwausera czyli w moim przypadku sobak_nazwabazy.

Jednym z parametrów, który był lepszy w promocji na 1&1 był transfer. Tam był nielimitowany, tutaj 20GB/m-c plus 3zł za każdy przekroczony gigabajt. Jednak w moim przypadku będzie on starczał jeszcze na długo, przez dwa lata na 1&1 nie miałem miesiąca, w którym wykorzystałbym więcej niż 2GB transferu.

Kolejna rzecz za którą muszę pochwalić LinuxPL to ilość dostępnych wersji PHP: od 4.4,9 do 5.4.4. Chciałem przeskoczyć na najnowszą wersję, jednak okazało się, że Wordpress nie działa na niej poprawnie (nie widzi z jakiegoś powodu pliku konfigracyjnego), tak więc poprzestałem na wersji 5.3.x

Kończymy I to już chyba będzie na tyle. Wynikiem ponad 1300 słów uzyskujemy najdłuższy do tej pory wpis na moim blogu :) Mam nadzieję, że choć część z Was przeczytała go do końca bez zaśnięcia. Starałem się aby podczas opisywanych zmian poprawić wszelkie zauważone błędy jak i unikać nowych, jednak ze względu na ilość rzeczy jaką zmieniałem, błędy mogą wystąpić. Będę bardzo wdzięczny za ich zgłaszanie w komentarzach do tego wpisu lub poprzez kontakt.

Dziękuję za uwagę.

Wpis opisuje akcję dosłownie sprzed chwili. Napisał do mnie m4tx z prośbą o napisanie zapytania SQL, które pobierało by komentarze z Wordpressa, każdemu użytkownikowi przypisując ilość napisanych przez niego komentarzy. Jestem zdziwiony, gdyż udało mi się to zrobić za pierwszym razem (potem musiałem jedynie dodać DISTINCT-a, o którym zapomniałem).

Jak pewnie wie, każdy kto programuje, w tej dziedzinie mało co wychodzi za pierwszym razem :D Tak czy siak postanowiłem podzielić się swoim dziełem:

SELECT DISTINCT comment_author AS author, (SELECT COUNT(comment_ID) FROM wp_comments WHERE comment_author = author) AS amount FROM wp_comments WHERE comment_approved = 1 ORDER BY amount DESC

Takie oto zagnieżdżone zapytanie doskonale rozwiązuje nasz problem :) Poniżej demonstruję wynik działania zapytania na danych z mojego bloga (to nie jest pełny wynik rzecz jasna :) nie ma sensu wkładać do screena całych danych)

Witam, dziś bez zbędnego gadania, będzie bardzo krótko.

Przedstawiam to proste zapytanie SQL, które pobierze tytuły wpisów i ilość słów w nich zawartych oraz posortuje po ich ilości.

SELECT
  post_title, 
  (LENGTH(post_content) - LENGTH(REPLACE(post_content, ' ', ''))) AS words
FROM 
  wp_posts
WHERE
  post_status = 'publish' AND post_type = 'post'
ORDER BY
  words DESC

Tak, to tyle. Na koniec screen z fragmentem wyniku działania na przykładzie mojego bloga:

Amen, dobranoc państwu :)

Przyznam się, że odkąd na innym blogu na którym pisuję (polecam swoją drogą ;)) dokonałem aktualizacji WP do wersji 3.2 (co zawsze robiłem, gdy tylko wychodziła polska wersja), byłem dość mocno rozczarowany. Przeszkadzał mi nowy wygląd panelu administracyjnego. Jeszcze bardziej zminimalizowany, jeszcze jaśniejszy i ogólnie jakiś taki dziwny (jak dla mnie, rzecz jasna).

Dlatego też wyjątkowo odkładałem aktualizację WP na sobak.pl. Odkładałem aż do dzisiaj

Czytaj dalej →

Około dwudziestego grudnia 2010 postanowiłem zacząć wcielać w życie pomysł, który przechodził mi przez myśl co jakiś czas. Miałem zamiar w końcu odrestaurować stronę sobak.pl. Był to czas, gdy blog stał się rozwiązaniem tymczasowym, w zamian za starą wersję mojej strony (kilka skryptów na krzyż). Postanowiłem napisać taki zalążek CMS-a do jej zarządzania.

Dosłownie dzień później stwierdziłem jednak, że mój przyszły skrypt można by uczynić jeszcze bardziej uniwersalnym i stworzyć niego "takiego pełnoprawnego CMS-a". I zacząłem pisać… szło mi to dość opornie. Dla przyspieszenia prac postanowiłem, że skorzystam z ogólnodostępnego szablonu (za co niektórzy chętnie by mnie zabili), aby jak najszybciej móc skupić się na pisaniu "kodu właściwego".

Pierwsza zmiana nastąpiła siódmego lutego 2011. Wtedy to do udziału w projekcie udało mi się namówić m4tx'a. W tym momencie zmieniłem też nazwę skryptu z samozwańczego SobakCMS na IronCMS (wiem, pachnie ironią…). Jeśli by kogoś interesowało pochodzenie nazwy (w co wątpię ;)), to po w poszukiwaniu nazwy przeglądałem iTunes'a i leciałem właśnie po dłuugiej liście utworów Iron Maiden.

Podczas tego już ponad czteromiesięcznego procesu tworzenia naklepałem tyle kodu i tyle razy go poprawiałem, że wydałem sobie cztery wewnętrzne, niepublikowane wersje dla utrzymania porządku. 25.03 postanowiłem zakończyć tworzenie ówczesnej wersji 0.4 i cały kod uzyskany do tej pory… napisać od nowa.

W ten sposób miałem okazję przyjrzeć się jak bardzo partyzanckie i nieoptymalne rozwiązania tam stosowałem (przykład jednego z nich już przedstawiałem). Poprawiłem naprawdę dużo kodu i w dniu dzisiejszym mogę powiedzieć z radością, że prace zmierzają ku końcowi. Premiera zapowiadanego skryptu powinna się odbyć najpóźniej za tydzień (oby nie było tak jak z Fx4). Uprzedzam tylko uczciwie: proszę nie spodziewać się fajerwerków. Nie jestem zawodowym programistą PHP i jest to mój pierwszy CMS. Nie znaczy to z drugiej strony, że będzie tam masa register_globals, magic quotes ect. Starałem się korzystać z nowoczesnych rozwiązań.

I teraz druga część dzisiejszego wpisu. Przeprowadziłem właśnie (kolejne już) porządki na stronie. Podjęte działania:

• skasowanie starej wersji bloga - niektórzy może pamiętają, że kiedyś blog mój znajdował się pod adresem sobak.pl/blog. Instalacja Wordpressa leżała tam aż do dziś
• odinstalowałem wtyczki All in one SEO Pack i Syntax Highlighter Evoled, z którymi miałem małe problemy. Pytanie na marginesie: zna ktoś z Was dobrą wtyczkę do podświetlania kodu w WP
• odinstalowałem wtyczkę Google Analytics for WordPress zastępując ją zwykłym wklejeniem kodu do szablonu. Naprawdę niepotrzebny mi skrypt PHP na 3000 linii do wygenerowania ośmiu linii JavaScriptu.
• kilka mniejszych optymalizacji
• wycofałem wsparcie dla IE6. Przy udziale tej przeglądarki w Polsce na poziomie 2% uznałem, że mogę z czystym sumieniem usunąć hacki na tą przeglądarkę

Ogłoszenia parafialne zakończone. O tym, czy Mojżesz uratował się z potopu dowiecie się w następnym odcinku ;)