Kto z was nie kojarzy phpBB? Myślę, że większość postawiła na nim swoje pierwsze forum. Skrypt swego czasu bardzo popularny, co w pewnym okresie było już dziwne, ze względu na jakość jego kodu. No właśnie… własne dziwaczne szablony budowane na czymś podobnym do komentarzy HTML, pluginy, które wymagają modyfikacji plików źródłowych skryptu i ogólnie niezbyt dużo nowatorskich rozwiązań. To właśnie sprawiło, że skrypt ten stopniowo był wypierany przez darmowe rozwiązania takie jak MyBB, SMF czy płatne IPB albo vBulletin.

Sam też się tym skryptem nie interesowałem, od dawna nie miałem potrzeby postawienia żadnego forum dyskusyjnego. Dziś rano trafiłem jednak przypadkiem na podsumowanie zmian nadchodzących w phpBB 3.1. Trzeba przyznać im jedno - widać, że mają plan i stopniowo dążą do jego realizacji.

Jeżeli byłeś użytkownikiem phpBB interesującym się jego rozwojem, to pewnie nie raz słyszałeś o mitycznym phpBB 4. Nie potrafię policzyć ile lat temu pojawiły się pierwsze pogłoski na ten temat - myślę, że około siedmiu. Tymczasem twórcy, wydaje się, że słusznie, odrzucili koncepcję przepisania całego silnika na raz, wybierając stopniowe zmiany. Zaczęli jednak naprawdę solidnie, zdecydowanym krokiem wchodząc w drugą dekadę XXI wieku. Oto krótkie podsumowanie tego, co przynoszą nam dotychczas wydane wersje phpBB 3.1 - do trzeciej bety.

Nowe możliwości

• Rozszerzenia - bum, z grubej rury wchodzi system rozszerzeń niewymagających modyfikacji plików źródłowych. Niemalże obowiązkowa zmiana, choć przyznam się, że nie spodziewałem się takiej zmiany z wersji 3.0 na 3.1
• AJAX - nie da się ukryć, brak przeładowania w paru miejscach jest bardzo przydatny
• Powiadomienia - prawdopodobnie to Facebook wpłynął na to, że ten sposób komunikacji z użytkownikiem stał się tak popularny. Trzeba przyznać, że jest to bardzo wygodna metoda. Niektóre fora, np. forumweb same implementowały mechanizm powiadomień. Miło, że znalazło się to w standardzie
• Gravatar - nie ma co się rozpisywać. Też praktycznie standard, też wielu ludzi to modyfikowało i też dobrze, że jest wbudowane
• Responsive Design - zarówno wbudowany motyw phpBB Silver2 i szablon panelu administracyjnego są responsywne

Zmiany pod maską

• Przestrzenie nazw i autoloading - słusznie pachnie to erą PSR i composera - phpBB zostało członkiem PHP-FIG
• Dependency Injection - konsekwenetne zastosowanie tego wzorca, o którym piszą autorzy, z pewnością uporządkowało trochę kod źródłowy
• Routing - myślę, że spokojnie możemy spodziewać się nice URLs w standardzie (aktualizacja: w standardzie się nie znajdą, ale ich zaimplementowanie powinno być łatwe z poziomu rozszerzenia - takie jest stanowisko autorów)
• Composer - podstawa przy korzystaniu z komponentów. Jakich? Już w następnym punkcie.
• Twig - mogę tylko odetchnąć z ulgą. Miałem wątpliwą przyjemność "bawić" się z ich poprzednim wynalazkiem
• Przyciski tekstowe - mała zmiana, ale postanowiłem o niej napisać, bo bardzo denerwowała mnie niegdyś konieczność podmiany obrazków w celu spolszczenia "New topic" itd. Teraz jest to oczywiście tekst odpowiednio ostylowany w CSS

To naprawdę tylko przegląd najważniejszych opcji. Dodano wiele innych rzeczy takich jak chowanie tematów zamiast ich usuwania, logowanie poprzez oAuth np. Facebook, Google), czy liczne poprawki dla CSS szablonów.

Muszę przyznać, że jestem pod wrażeniem tego jaki krok wykonała ekipa z phpBB. Niewykluczone, że ich produkt z powrotem odbije kawałek rynku, który kiedyś zajmował. Jak myślicie?

Witajcie,

pierwszy kwietnia już za nami, czas na kilka sprostowań. Przepraszam kilku rozczarowanych, uspokajam zaniepokojonych (Comandeer ;)). Wczorajszy wpis był wyłącznie żartem (czy dobrym, to już nie mi oceniać). Z PHP się nie rozstaję… wręcz przeciwnie. Od pewnego czasu zastanawiałem się nad dołączeniem do jakiegoś projektu Open Source, nawet dla zabicia czasu (jasne, przecież mam go tak dużo ^^). Nie powiem, że z PHP łączy mnie jakaś szczególna więź emocjonalna, ale jako, że z tego wytworu środowiska Open Source korzystam najczęściej, wybór padł właśnie na niego.

Uspokajam od razu wszystkich przerażonych. Nie, nie zostałem developerem parsera PHP, tak więc gorzej niż jest teraz raczej nie będzie, a już na pewno nie z mojej winy. Nie znam C, natomiast lubię sobie czasem pogrzebać przy stronach internetowych. Postanowiłem w jakiś sposób to wykorzystać - no i się udało :) Po pokazaniu, że co nieco potrafię (raportowanie bugów i przede wszystkim wysyłanie pull requestów na githubie) oraz złożeniu odpowiedniego wniosku zostałem developerem PHP.net. W zakresie WWW rzecz jasna.

To, co niedawno pisałem o PHP, odnosi się po części także do ich infrastruktury sieciowej. Wiele elementów nie było modernizowanych od dawna i bardziej przypominają zeszłe stulecie niż rok 2014. Stosunkowo duże pole do popisu, nawet dla osób z tak niewielkimi umiejętnościami jak moje. Teraz kilka konkretów, co udało mi się zrobić od 16 marca, kiedy to zaakceptowano mój wniosek.

• Swoje wysiłki skupiłem przede wszystkim na modernizacji strony doc.php.net, czyli zestawu narzędzi dla twórców i tłumaczy manuala PHP. Ciężko wymienić wszystkie rzeczy, które zmieniłem. Jako, że strona, poza nielicznymi poprawkami, nie była aktualizowana od 10 lat, zacząłem od uprzątnięcia tego, co nie jest i nie będzie już używane. Myślę, że łącznie wyszło gdzieś z 10.000 linii kodu na minus. Nie zawsze więcej znaczy lepiej ;) Pierwotny interfejs poza tym, że nie przystawał do dzisiejszych standardów, był niesamowicie przerośnięty. Podczas zmieniania strony, mimo, że przejechałem ją wzdłuż i wszerz, nadal potrafiłem się zgubić. Opracowałem koncepcję tego, jak chciałbym, żeby strona wyglądała docelowo, dostałem wolną rękę od innych developerów i ruszyłem z pracami. Nie chce mi się opisywać całości, więc pozwolicie, że całość zilustruję screenem z przed i po modernizacji.
• Wiele małych poprawek do wielu z podserwisów PHP: qa.php.net, news.php.net czy bugs.php.net
• Zamknąłem kilkanaście bug reportów dotyczących WWW i dokumentaji
• Zaangażowałem się troszeczkę w polskie tłumaczenie manuala. Zaktualizowałem i przetłumaczyłem kilkadziesiąt plików, choć generalnie temat jest już martwy
• Przyłożyłem rękę do standardyzacji kilku rzeczy pomiędzy różnymi tłumaczeniami dokumentacji

Lista może nie jest zbyt imponująca, ale nie chodzi o to, aby przebudować wszystko co tylko się da. Jak widać, wciąż jest wiele rzeczy, które można na PHP.net poprawić i pomoc im się przydaje. Sam też czerpię z tego jakąś satysfakcję i naukę. Wrzucam tę informację na bloga w ramach sprostowania wczorajszego wpisu i pokazania, że jeszcze nie umarłem. Prawdopodobnie nie jest to zbyt porywająca lektura, no ale o czymś pisać trzeba ;)

Pozdrawiam.

Dzisiejszy artykuł chciałbym poświęcić rozwojowi PHP - jako projektu samego w sobie. Będzie trochę historii, ale postaram się skupić głównie na tym co się zmienia i zmienia się na lepsze. Zapraszam do czytania.

PHP to język z dosyć długą historią - pierwsza wersja powstała w roku 1994. Często jednak rozumie się to jako wadę, a nie powiedzmy źródło doświadczenia wśród jego deweloperów. Różnorakie nieprzemyślane rozwiązania wymyślone i nagromadzone jeszcze w zeszłym stuleciu potrafią być bagażem po dziś dzień.

O PHP krąży nieprzypadkowo obiegowa opinia, że jest to język prawie tak ciężko reformowalny jak kościół katolicki w średniowieczu. Ma to oczywiście uzasadnienie: deweloperzy boją się wszelkich zmian zrywających kompatybilność wsteczną, bo jej zapewnienie buduje zaufanie ludzi tworzących w danej technologii. Nikt przecież nie chciałby przepisywać swoich aplikacji co dwa miesiące, prawda? W PHP doszło to jednak do bardzo wysokiego poziomu - latami starano się o wiele potrzebnych zmian, poprawek i rozliczeń z przeszłością. Prace nad ostatnią wersją major, czyli PHP5 zostały rozpoczęte jeszcze w 2002 roku. Stabilna wersja ukazała się na początku 2003. Znacząco poprawione zostały między innymi wszystkie rzeczy związane z programowaniem zorientowanym obiektowo. Można powiedzieć, że PHP wykonało susa do przodu i dogoniło ówczesną epokę pod wieloma względami.

Niewiele później, w okolicach wydania PHP 5.1, czyli w roku 2005 środowisko PHP zaczęło snuć plany na kolejną dużą wersję - hucznie zapowiadano rychłe nadejście PHP6, które miało poprawić rzeczy nie ruszane praktycznie od początku istnienia projektu - ujednolicić API, wprowadzić pełne wsparcie dla UTF-8 i poprawić wiele nieeleganckich i przestarzałych rozwiązań. Początkowy zapał jednak w miarę szybko osłabł, a tempo rozwoju dodatkowo osłabiły podzielone opinie wśród programistów samego języka - wielu z nich uważało, że planowane zmiany są zbyt radykalne oraz, że wymagają zbyt dużego nakładu czasowego. PHP6 szybko stało się martwym projektem, którego w zasadzie nikt na oczy nie widział, a jego rozwój został oficjalnie zawieszony w roku 2010.

Czas płynął, inne technologie dynamicznie się rozwijały, powstawały coraz bardziej nowoczesne rozwiązania. Dlatego ekipa PHP również postanowiła się pozbierać i wprowadzić część z rozwiązań planowanych na 6.x we wcześniejszych wersjach. Tak pojawiło się PHP 5.1 wprowadzające PDO, PHP 5.2 (listopad 2006) dodające wbudowane wsparcie dla formatów takich jak ZIP czy JSON oraz poprawiające zarządzanie pamięcią.

Kolejną wersją z piątej gałęzi, która ze względu na wprowadzone zmiany mocno zapadła w pamięci wielu programistów, była oznaczona numerkiem 5.3. Została ostatecznie wydana 30 czerwca 2009 roku i wprowadzała takie nowości jak przestrzenie nazw, domknięcia (clousures), mysqlnd (natywny driver MySQL) oraz poprawiająca obsługę modelu obiektowego.

Po tym kolejnym podgonieniu konkurencji, rozwój PHP ponownie jakby zamarł. Część środowiska nadal liczyła na szybkie ukończenie wersji 6 (której rozwój nie został wtedy jeszcze oficjalnie zdementowany), ale dla wielu stało się widoczne, że przez kilka kolejnych lat nie udało się wprowadzić praktycznie żadnych istotnych ulepszeń. Konkurencja gnała do przodu, a deweloperzy PHP grzęźli w wewnętrznych konfliktach.

Przełom nastąpił około roku 2012, czyli stosunkowo niedawno. Wtedy, po prawie 3 latach przerwy pojawiło się PHP 5.4 Można uczciwie powiedzieć, że próbowano znaleźć złoty środek między kompatybilnością z poprzednimi wydaniami i rozliczeniem się z błędami przeszłości.

• usunięto często (i słusznie) krytykowane magic quotes, register globals oraz safe mode
• usunięto składnię break/continue $var
• usunięto między innymi funkcje import_request_variables(), session_is_registered(), session_register() i session_unregister()
• wersje sqlite starsze niż 3 zostały wyrzucone do PECL
• domyślnie wyłączono obsługę <? jednocześnie na stałe umożliwiając użycie składni <?=zmienna?> niezależnie od konfiguracji
• wprowadzono uproszczoną składnię dla tablic ($array = [1, 2, 3])
• umożliwiono array dereferencing (echo explode(' ', 'raz dwa')[1])
• analogicznie pozwolono na zapis typu echo (new foo)->bar())
• dodano wsparcie dla $this w domknięciach (clousures)
• dodano traitsy
• dodano wbudowany serwer developerski
• duże poprawki wydajności

Ilość i "ciężar" wprowadzonych zmian, który jak na PHP był naprawdę duży odbił się szerokim echem. Był to głównie odbiór pozytywny, zazwyczaj ludzie cieszyli się, że pewne złe rozwiązania zostaną w końcu wyeliminowane siłowo. Przyspieszenie rozwoju nie było tak chwilowe jak poprzednio i już 20 czerwca 2013 pojawiło się wydanie 5.5. Tym razem zdecydowano się na następujące ulepszenia i kolejne rozliczenia z ciężarem dawnych wersji.

• usunięto powodujące zagrożenie funkcje php_logo_guid(), php_egg_logo_guid(), php_real_logo_guid(), zend_logo_guid()
• zdeprecjonowano wszystkie funkcje mysql_*
• zdeprecjonowano flagę /e dla preg_replace()
• zdeprecjonowano pewne funkcje z modułów mcrypt i intl
• dodano generatory
• dodano obsługę bloku finally
• dodano nowe API dla hashowania
• dodano wsparcie dla list() w foreach
• dodano obsługę wyrażeń skalarnych w empty()

Lista zmian nie jest kompletna, tak jak dla PHP 5.4 skupiłem się na tym co najistotniejsze z punktu widzenia tego artykułu. Rozwój nadchodzącej wersji 5.6 obserwuję już na bieżąco i piszę już z własnych obserwacji takich miejsc jak GitHub oraz lista malingowa deweloperów PHP. Planowane/ukończone są obecnie następujące zmiany:

• trzykrotne zmniejszenie zużycia pamięci dla danych POST
• wbudowany debugger phpdbg
• obsługa wyrażeń skalarnych dla const (podobnie jak wcześniej dla empty())
• variadic functions i argument unpacking dzięki operatorowi ...
• operator potęgowania (**)
• obsługa uploadu plików większych niż 2GB
• obsługa przestrzeni nazw dla funkcji
• poprawki dla SSL i mcrypt
• ustawienie domyślnego kodowania w php.ini dla funkcji takich jak htmlspecialchars()

Poza samymi zmianami w języku widać też zmianę podejścia w środowisku twórców. Podam na dzisiejszym przykładzie: kilka dni temu jeden z deweloperów zaproponował zmiany w rozszerzeniu mcrypt, które miały by bardziej rygorystycznie pilnować podawania soli dla haseł (jej brak miałby skutkować warningiem, a nie przemilczaniem błędu i obejściem jak jest obecnie). Mimo początkowego hałasu podniesionego o przerwanie kompatybilności wstecznej, zmiana została dziś dodana do gałęzi 5.6, mimo, że niedługo nadchodzi już wersja beta. To jedno wydarzenie pokazuje dosyć istotny postęp - niektóre zmiany, głównie związane z bezpieczeństwem, nawet takie które zepsują kilka skryptów, przechodzą po prostu łatwiej.

Ostatnio coraz więcej dyskusji toczy się także na temat zmian jakie chciano by zawrzeć w PHP6. Ponownie rozważana jest kwestia pełnego wsparcia dla UTF8 (kto musiał korzystać z funkcji mb_* wie o co chodzi), uporządkowanie API (ujednolicenie nazewnictwa funkcji i tak dalej) i porządkach w Zend Engine. Proponowane szkice zmian można znaleźć między innymi tutaj i tutaj. Jednocześnie głównym kierunkiem rozwoju pozostaje dotychczas wersja 5.7.

Co sądzicie o zmianach ostatnich lat, które zachodzą w PHP? Jest nadzieja? ;) A może cały rumor jaki się podniósł i używanie haseł takich jak "renesans PHP" jest Waszym zdaniem na wyrost?

Zapraszam do dyskusji :)

Taki już chyba mój los, że przy każdej okazji, gdy kombinuję coś ze stroną, muszę zmienić format odnośników. Tak było też ostatnio. Obiecałem sobie, że to będzie ostatnia zmiana na długi, długi czas, ale mimo wszystko trzeba było sobie jakoś poradzić z przekierowaniem wszystkich starych adresów w odpowiednie miejsca. Tak jak w wypadku poprzedniej walki z przekierowaniami skorzystałem z wtyczki Redirection. Wynikało to głównie z faktu, że miałem gotowy skrypt, który na podstawie starej bazy generował mi wszystkie potrzebne przekierowania. Podczas testów wszystko wypadło pomyślnie, jednak dziś rano, przy dodawaniu kolejnych brakujących adresów, wtyczka zaczęła się bugować. W związku z tym musiałem na szybko poszukać lepszego rozwiązania i zaimplementować je zamiast starego,

Z pomocą przyszła mi wtyczka Simple 301 Redirects. Chwilę po zainstalowaniu i odpaleniu odpowiedniej zakładki w panelu admina, wiedziałem, że to jest to. Autor reprezentował to samo podejście do tworzenia oprogramowania co ja - wtyczka była naprawdę simple! Wystarczy porównać interface obu rozwiązań.

Różnicę widać gołym okiem. Autor drugiej wtyczki nie kombinował z własnymi stylami, przez co niezależnie od wersji WP wtyczka nie odstaje wyglądem od reszty skryptu. Analogicznie sytuacja wygląda w kwestii kodu źródłowego. Kilkadziesiąt plików, wymyślanie koła na nowo kontra rozwiązanie zawarte w jednym pliku PHP. Poza tym wtyczka Simple 301 Redirects jest bardzo aktywnie rozwijana, ostatni rozwiązany temat na forum supportu pochodził z wczoraj.

Nie trudno się domyślić, że drugą stroną medalu jest ilość oferowanych możliwości. Druga wtyczka nie oferuje między innymi śledzenia błędów 404 czy obsługi wyrażeń regularnych dla przekierowań (poza *). W moim wypadku jednak spokojnie wystarcza prostsze rozwiązanie.

Wszystkim, którzy podobnie jak ja szukają naprawdę nieskomplikowanej wtyczki do zapewnienia przekierowań na nowe adresy, mogę polecić opisywane oprogramowanie.

Witajcie, ostrzegam od razu, że wpis zawiera spoilery.

Dziś przeglądając repozytorium git dla strony PHP.net natknąłem się na interesujący commit z dosyć oczywistym opisem easter eggs. Polecam sobie zajrzeć i sprawdzić, chyba, że ktoś nie lubi sobie psuć niespodzianek ;)

Jakby dla kogoś nie było jasne, to wystarczy po wejściu na stronę na klawiaturze wpisać (nie trzeba celować w żadne pole, strona cała przechwytuje naciśnięcia klawiszy) podane napisy, oczywiście wyrazy takie jak space czy enter zastępując naciśnięciami odpowiednich klawiszy.

Myślę, że numer całkiem udany, po I hate PHP widać, że chłopaki mają dystans do siebie.

Robiłem dziś mały przegląd frameworków dla potrzeb własnych. Którymś z kolei, na który spojrzałem była Kohana. Odkładałem ją w zasadzie na koniec badania, bo nie obiła mi się o uszy żadna większa aktualizacja, odkąd zgłębiałem ją po raz ostatni.

Dla pewności wszedłem jednak na stronę, a po przejściu na listę wydań frameworka zobaczyłem taką oto notkę. Zwróćcie uwagę na koniec wsparcia:

Tak więc mamy w świecie PHP framework, w dodatku naprawdę znaczący (choć widać, że z oczywistych względów zainteresowanie słabnie), którego stabilna wersja nie jest wspierana :D Parafrazując klasyka: Wow, such support.

Skoro znalazłeś się tutaj, to prawdopodobnie dobrze wiesz czym jest liczba PI i do czego może przydać Ci się jej (przybliżona oczywiście) wartość. Dlatego pominę ten aspekt i skupię się od razu na obsłudze PI w PHP.

W PHP istnieją dwa równoznaczne sposoby pobrania liczby PI:

• Funkcja pi() - nie przyjmuje żadnych argumentów, a dane zwraca w postaci float
• Stała M_PI

Jak już wspomniałem oba sposoby są równoznaczne - otrzymamy ten sam wynik. Długość rozwinięcia jest zależna od dyrektywy precision w php.ini. Domyślną wartością jest 14, co oznacza, że dokładnie tyle miejsc po przecinku będzie miała liczba PI wyświetlona którymś z podanych wyżej sposobów. Dyrektywa precision wpływa oczywiście na długość rozwinięcia wszystkich liczb zmiennoprzecinkowych (float), a nie tylko na PI. Jej maksymalna wartość zależy od środowiska, w tym między innymi od architektury procesora.

W PHP mamy także kilka innych predefiniowanych stałych zawierających liczbę PI poddaną różnym prostym operacjom. Podsumuję wszystkie dostępne możliwości listingiem kodu:

<?php
// domyślna wartość precision = 14

echo pi(); // 3.1415926535898
echo M_PI; // 3.1415926535898
// wyniki są identyczne

// Dodatkowe stałe (dodane w PHP4)
M_PI_2 = 1.57079632679489661923 // PI/2
M_PI_4 = 0.78539816339744830962 // PI/4
M_1_PI = 0.31830988618379067154 // 1/PI
M_2_PI = 0.63661977236758134308 // 2/PI
M_SQRTPI = 1.77245385090551602729 // Pierwiastek kwadratowy z PI
M_2_SQRTPI = 1.12837916709551257390 // 2/pierwiastek kwadratowy z PI (2/sqrt(pi))

Nie muszę chyba tłumaczyć, że wszystko bazuje na przybliżeniach :)

Ten komunikat znany jest pewnie wszystkim, którzy w Kohanie stworzyli choć jedną aplikację. Mimo iż jego naprawa jest trywialna, może napsuć krwi początkującym, którzy po pomyślnej "instalacji" frameworka spodziewali się ujrzeć napis "Hello World" a nie błąd na powitanie.

Aby naprawić ten problem należy otworzyć plik kohana/application/bootstrap.php gdzie przez kohana rozumie się folder, w którym wypakowano frameworka. Na końcu pliku doklejamy następującą linię:

Cookie::$salt = 'twojawartosc';

I po sprawie, po odświeżeniu powinien zostać wykonany domyślny kontroler. Z oczywistych względów bezpieczeństwa zalecam, aby w miejsce twojawartosc naprawdę wpisać coś własnego :P

Przez moment szukałem w głowie odpowiedniego przymiotnika, którym chciałbym opisać bohatera dzisiejszego krótkiego wpisu. Myślę, że wygodny będzie całkiem dobrym określeniem choć Markdown jest zarówno wydajny jak i intuicyjny.

Czym w ogóle jest Markdown? Jest to język znaczników, służący do formatowania tekstu, wymyślony przez Johna Grubera i Aarona Schwartza w roku 2004. Jak już wcześniej wspomniałem, od innych dostępnych rozwiązań takich jak BBCode czy czysty kod HTML odróżniają go między innymi szybkość użycia i intuicyjność. Składnia Markdown zaprojektowana jest w taki sposób, że nawet patrząc na jeszcze nieprzetworzony kod widzimy przeznaczenie każdego znacznika. Już podaję przykład:

Nagłówek pierwszego stopnia
===========================

Podrozdział
-----------

Poszczególne akapity są od siebie oddzielone pustą linią, tak więc
w obrębie jednego paragrafu swobodnie możemy korzystać z
klawisza enter.

Równie intuicyjne jest też wyróżnianie tekstu: czy to poprzez *emfazę*,
czy **pogrubienie**.

Lista nienumerowana

- kurczaki
- ziemniaki
- psychotropy

Oraz lista ponumerowana:

1 kurczaki
2 ziemniaki
3 psychotropy

Taki kod Markdown zostanie sparsowany (parsery dostępne są dla większości języków) do następującego kodu HTML:

<h1>Nagłówek pierwszego stopnia</h1>

<h2>Podrozdział</h2>

<p>Poszczególne akapity są od siebie oddzielone pustą linią, tak więc
w obrębie jednego paragrafu swobodnie możemy korzystać z
klawisza enter.</p>

<p>Równie intuicyjne jest też wyróżnianie tekstu: czy to poprzez <em>emfazę</em>.
czy <strong>pogrubienie</strong>.</p>

<p>Lista nienumerowana</p>
<ul>
<li>kurczaki</li>
<li>ziemniaki</li>
<li>psychotropy</li>
</u>

<p>Oraz lista ponumerowana:</p>
<ol>
<li>kurczaki</li>
<li>ziemniaki</li>
<li>psychotropy</li>
</ol>

Jest to oczywiście pokaz tylko części możliwości Markdown. Chodziło m raczej o zademonstrowanie samej koncepcji i przejrzystości składni. Jak widać, dzięki użytej budowie, artykuły można spokojnie pisać w dowolnym edytorze tekstowym i nadal pozostaje to czytelne.

Poza to, co pokazano wyżej, składnia Markdown oferuje jeszcze między innymi: odnośniki, obrazki, przełamania linii wewnątrz akapitów, umieszczanie bloków kodu, czy cytaty. Istnieje też alternatywna składnia dla kilku z pokazanych już zastosowań - w standardzie dostarczono m.in. dwa sposoby oznaczania nagłówków, emfaz i pogrubień, które można stosować wymiennie w obrębie jednego dokumentu. Nic nie stoi też na przeszkodzie aby np. umieścić element listy składający się z kilku akapitów -nie chciałem po prostu opisywać tutaj całej składni, bo to już dobrze zrobił sam autor.

Ponadto, dla PHP (oryginalny preprocesor został napisany w Perlu) istnieje parser Markdown w wersji Extra, który oferuje nam takie rzeczy jak listy definicji, przypisy, tabele, czy poprawiony sposób umieszczania kodów źródłowych w tekście. Tutaj należy wspomnieć o jednym założeniu poczynionym na samym początku przez Grubera - Markdown nie ma stać się składnią alternatywną dla HTML. Ma być jedynie wygodną warstwą abstrakcji, która faktycznie ułatwi nam najczęściej stosowane formatowania tekstu.

Jako potwierdzenie powyższych zalet wystarczy zobaczyć jak wiele języków obecnie dostarcza biblioteki do obsługi tej składni i jak wiele oprogramowania pozwala z niej korzystać, czy to jako natywny sposób formatowania, czy jako rozmaite modyfikacje. Znajdziemy więc między innymi rozszerzenie do Thunderbirda, które pozwala nam pisać maile w ten sposób, a potem konwertuje je do HTML-a, a także wtyczkę do Wordpressa (przyznaję, że sam chętnie przerzuciłbym się właśnie na Markdowna, gdyby nie duża ilość treści do przekonwertowania).

Markdown jest też jednym ze sposobów formatowania treści dostarczanym natywnie przez takie usługi jak Github, BitBucket, Jekyll, a także rozmaite systemy CMS.

Tak więc Markdown kryje pod swoją nazwą dwie rzeczy: standard opisu informacji, czyli zaprezentowany i opisany wyżej język znaczników, a także pierwotny parser napisany przez Grubera w Perlu. Niezależnie od czy tworzycie jakąś nową aplikację w języku, który ma bibliotekę do parsowania Markdowna albo pracujecie z programem, który umożliwia jego użycie , jeżeli przewidujecie dużą ilość pracy z prostym tekstem, polecam spróbować tego rozwiązania - praca po chwili staje się naprawdę przyjemna i szybka.

Na sam koniec dwa konkretne linki dla osób, które zainteresował temat: oryginalna strona projetu gdzie w pełni opisano dostępną w standardzie składnię oraz stronę klasy Markdown.php.

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.