Mariusz Tarnaski "MariuszT"

Temat narzędzi wspomagających budowanie stron www po stronie klienta gościł już na moim blogu. Chociażby w październiku pisałem o Bootstrap od Twittera. Do tej pory nie znałem jednak HTML5 Boilerplate.

Jak zaczynacie budować nową stronę? Ja mam przygotowany gotowy wzór. Plik z podstawowym szkieletem strony, wpisanymi meta tagami, które uznaję za potrzebne oraz niewielką strukturę katalogów i kilka plików np. do resetu styli CSS czy do obsługi przezroczystych PNG (kiedyś, teraz już nie ). Pewnie każdy z Was ma coś podobnego. Jeżeli nie gotową paczkę to chociaż swój ulubiony model, który kopiujecie z jednego projektu do drugiego.

To jest oczywiście sensowny sposób, po co za każdym razem robić coś od nowa, powtarzać tą samą pracę. Można jednak pójść o krok dalej i zamiast korzystać z własnego rozwiązania, użyć np. HTML5 Boilerplate, który został opracowany i przetestowany przez wiele tęgich głów i na pewno spisze się lepiej niż samodzielnie przygotowany wzór dokumentu.

Najważniejsze cechy HTML5 Boilerplate:

• HTML5 to przyszłość
• Ale nie zapominamy nawet o takich starociach jak IE6
• Kod dostosowany do urządzeń mobilnych
• Użyto normalize.css zamiast resetu stylów
• Użyto respond.js dla CSS3 Media Queries
• Rekomenduje i współpracuje z Google Chrome Frame dla starszych wersji IE
• Użyto modernizr do detekcji możliwości przegladarki
• Wsparcie cachowania CSS i JS
• Poprawia bezpieczeństwo PHP np. wyłącza register_globals lub usuwa nagłówek HTTP-X-Powered-By informujący o wersji PHP
• Udostępniono ustawienia dla serwerów Apache, ngnix itp. dodające obsługę popularnych typów MIME, włączających kompresję gzip itd.
• i wiele, wiele więcej

To naprawdę tylko drobna lista wszystkich właściwości. W HTML5 Boilerplate jest mnóstwo drobnych udogodnień o których sami na pewno nie pamiętalibyśmy. Koniecznie przeczytaj dokumentację, przejrzyj pliki. Znajdziesz tam również wiele linków do materiałów dodatkowych takich jak integracje biblioteki z CakePHP, Zend Framework, WordPress czy Django. Fani WordPressa znajdą dodatkowo listę gotowych skórek opartych o HTML5 Boilerplate.

Do tego wszystkiego mamy prosty skrypt do zbudowania własnej biblioteki tylko z tymi elementami, które potrzebujemy i w takiej postaci jaka nam odpowiada. A jeżeli to nie wystarcza to skorzystaj z Initializr gdzie masz szereg dodatkowych opcji.

HTML5 Boilerplate robi ogromne wrażenie. Włożono w niego mnóstwo pracy, ilość wiedzy jaka była do tego potrzebna jest imponująca. Samemu nie jesteśmy w stanie zrobić tego lepiej. Żałuję, że nie wiedziałem o HTML5 Boilerplate wcześniej, użyłbym go do ostatniego projektu, przetestował w praktyce. Ale mój następny projekt będzie już korzystał z możliwości tej biblioteki.

CSS Media Types w CSS2 pozwala na proste zdefiniowanie który plik stylów CSS ma zostać zastosowany na konkretnym urządzeniu. Można mieć osobne style dla przeglądarki, osobne do druku a jeszcze inne na przykład dla urządzeń do czytania braillem. Przydatne, ale można lepiej.

W CSS3 rozbudowano ten mechanizm, powstało CSS3 Media Queries. Możemy definiować osobne style na podstawie takich czynników jak wymiary ekranu czy jego orientacja.

Tak wygląda to na przykładzie:

Powyższy kod oznacza, że style z pliku style.css zostaną zastosowane tylko dla urządzenia z ekranem o minimalnych rozmiarach 1024x500px.

Istnieją alternatywne zapisy. Wewnątrz dokumentu CSS:

Jako @import:

Możliwości jest wiele, zachęcam do przejrzenia tego dokumentu.

Wsparcie przeglądarek

Oczywiście, jak zawsze, pojawia się pytanie jak jest z obsługą tej technologii w różnych przeglądarkach. I oczywiście, jak zawsze, odpowiedź brzmi, że wszędzie jest dobrze oprócz Internet Explorer Dopiero w IE 9 wprowadzono obsługę Media Queries.

Z tego powodu powstała biblioteka js Respond. Niewielki pliczek, który magicznie powoduje, że nasze reguły (tylko min-width i max-width dla wszystkich typów mediów) zaczynają działać w starszych wersjach IE. Jak sam autor twierdzi, "biblioteka jest napisana w taki sposób, że prawdopodobnie powinna łatać inne przeglądarki, które nie obsługują Media Queries".

Wcześniej, aby wszystko działało jak należy, trzeba było dodawać komentarz przy naszych regułach. Teraz biblioteka stosuje wyrażenia regularne dzięki czemu automatycznie rozpoznaje nasze reguły. Musimy tylko dołączyć respond.js do naszego dokumentu, nic więcej.

Alternatywą jest css3-mediaqueries-js. Bardziej rozbudowany skrypt (na tą chwilę 15,6KB), który podobno działa ze wszystkimi regułami Media Queries. Co oczywiste, działa wolniej od respond.js, zwłaszcza przy rozbudowanych regułach. Nie działa z importowanymi arkuszami (@import), nie parsuje również atrybutów media dla tagów <link> i <style>.

Czy używać CSS3 Media Queries? Zdecydowanie tak! Reguły te dają wspaniałe możliwości i są obsługiwane przez większość przeglądarek, zarówno na desktopach jak i na urządzeniach mobilnych. Dla IE też są rozwiązania a użytkownicy z wyłączoną obsługą JS są sami sobie winni

Pisałem już o stylach resetujących domyślny CSS przeglądarki. I to nie raz. Czy to jednak jedyny sposób aby wszystkie przeglądarki wyświetlały Twoją stronę jednakowo?

Całkowity reset styli CSS do standardowych wartości jest często krytykowany za niewłaściwe podejście. Zdaniem niektórych, lepiej byłoby zmieniać tylko to co powinno być zmienione. Stworzyć reguły naprawiające tylko te ustawienia i tylko w tych przeglądarkach gdzie faktycznie jest coś nie tak. Ta idea przyświeca twórcom normalize.css.

Takie podejście jest trudniejsze do zrealizowania ale zdaniem niektórych, wydajniejsze i bardziej poprawne.

Podstawowe zalety normalizacji:

• Współpraca z przeglądarkami na urządzeniach mobilnych
• Reguły dostosowane do HTML5
• Mniej styli, mniejsza objętość
• Podczas debugowania nie mamy takiego bałaganu (kto pracował z Firebugiem i zwykłym resetem ten wie o czym mowa)
• Brak idiotycznych reguł opisujących, że koło jest naprawdę okrągłe
• Można się czegoś nauczyć, wiele pomocnych komentarzy przy stylach

Sami musimy zdecydować co nam lepiej odpowiada. Z pewnością normalizacja jest teraz bardziej trendy od resetu

Certyfikaty to dobra rzecz, potwierdzają Twoją wiedzę. Jestem skłonny zaryzykować twierdzenie, że dla każdego normalnego pracodawcy jeden konkretny certyfikat może być więcej wart niż studia, nawet w oczekiwanym kierunku.

Problemem natomiast jest wybranie, który certyfikat chcemy zdobyć. Strona w3schools.com osiągnęła mistrzostwo w pozycjonowaniu przez co pojawia się na czołowych pozycjach W Google dla wielu zapytań o HTML, CSS a nawet PHP i MySQL. Nazwa nie pozostawia złudzeń, że to wszystko musi mieć coś wspólnego z konsorcjum W3C.

W3Schools oferuje na swojej stronie możliwość zdania płatnych, certyfikowanych egzaminów. Jest w czym wybierać. Na tą chwilę (grudzień 2011) mamy testy z HTML, CSS, JavaScript, jQuery, XML, ASP i PHP. Każdy za 95 dolarów (kiedyś było taniej ).

Na pierwszy rzut oka, wygląda atrakcyjnie. Wczytajmy się jednak w szczegóły.

• Po pierwsze, egzamin zdajemy online. Każdy rozgarnięty w tej chwili sobie myśli "Ej! To co z wiarygodnością?". Wiarygodność ma zapewnić ktoś od Ciebie Ktoś kto w teorii ma nad Tobą stać i patrzeć czy rozwiązujesz test samodzielnie a potem podpisać się pod certyfikatem. Od Ciebie zależy czy to będzie Twój kumpel z podwórka czy np. Twój szef ze znanej i szanowanej firmy IT. Oczywiście Twój Anioł Stróż mógłby Ci wystawić zwykłą rekomendację i miałaby taką samą moc no ale wtedy W3Schools by nie zarobiło
• Test to 70 pytań wielokrotnego wyboru lub pytań TAK/NIE, limit czasu to 70 minut. Ja mam alergię na takie testy ale zdaję sobie sprawę, że to najprostsza i najszybsza forma egzaminu i może być nawet skuteczna o ile pytania są sensowne. W tym przypadku jednak nie są. Pytania są banalne. Tzn. nie wiem jakie są bo oczywiście nie przystąpiłem do żadnego testu ale są testy przykładowe i ich poziom woła o pomstę do nieba.
• Jeżeli nie zdasz (minimum 75% poprawnych odpowiedzi) lub chciałbyś poprawić swój wynik to masz jeszcze jedną próbę. Jak rozumiem, w cenie.
• W3Schools nie ma żadnego związku z konsorcjum W3C. Żadnego!

To wszystko powoduje, że nikt o zdrowych zmysłach nie weźmie pod uwagę tych certyfikatów. Więcej! Może uznać Cię za cwaniaka, który przyszedł go oszukać lub głupka, który dał się na tą farsę nabrać.

Do w3schools.com jest wiele więcej zarzutów. Społeczność webmasterska wyłapała wiele nieścisłości i błędów we wskazówkach tam umieszczonych. W swej złości stworzyli stronę w3fools.com gdzie bezwzględnie wytykają wszystkie grzechy autorów kursów.

Przy okazji, jakie certyfikaty warto zrobić?

Ja znam jeden dobry, certyfikat od Zend. W świecie PHP (w tej chwili certyfikat jest z PHP w wersji 5.3) nie ma cenniejszego certyfikatu. Osoby mocno związane z Zend Framework mogą też pomyśleć o certyfikacie z tego frameworka. Być może inne firmy egzaminują również z innych frameworków, CMS'ów itd.

Na pewno warto zastanowić się nad certyfikatami z bezpieczeństwa lub z baz danych. Szczegółów jednak nie podam bo ich nie znam Szukajcie przede wszystkim takich egzaminów, które mają błogosławieństwo od firm autorów oprogramowania.

Zdecydowanie nie warto podpierać się jakimikolwiek kursami i egzaminami z HTML i CSS. Wystarczy zrobić swoje portfolio i niech jego źródło mówi za nas. Miałbym również duże wątpliwości czy warto inwestować w coś co potwierdzi naszą znajomość Flasha i AS3. Natomiast jeżeli ktoś pracuje bardzo dużo z JavaScript to pewnie jakiś certyfikat byłby bardzo mile widziany (ale już nie z jQuery, to za proste!). Tylko czy coś takiego istnieje?

Domeny z narodowymi znakami są już dłuższy czas dostępne ale nie przyjęły się za bardzo, przynajmniej nie w Polsce. Nie usprawiedliwia to jednak programistów, którzy o nich zapominają. Może to nam wygenerować poważne problemy.

Kilka dni temu musiałem poprawić pewien mały skrypcik. Administrator może podać adres, który potem jest używany w przekierowaniu PHP. Zwykłe, banalne header():

I nagle zaskoczenie. Ten kod w Firefox i Safari (z Chrome i Operą było wszystko OK, IE nie testowałem) nie działa gdy zmienna $address to adres domeny z polskimi znakami diakrytyzowanymi!

Oczywiście pierwsza (i słuszna) myśl to przekodowanie takiej domeny do pierwotnej postaci. Jak powszechnie wiadomo, za tymi ładnymi narodowymi literkami kryją się okropne, niezrozumiałe krzaczki. Domena gżegżółka.pl tak naprawdę wygląda tak: xn--gegka-2ta76cmoc.pl. Do konwersji służy algorytm o nazwie Punycode.

Jeżeli masz PHP w wersji co najmniej 5.3 to rozwiązanie jest banalne. Masz dostępne dwie funkcje służące do konwersji z UTF8 do ASCII i z ASCII do UTF8.

Poniżej PHP 5.3 musisz posiłkować się zewnętrznymi bibliotekami. Najpopularniejsza z nich ma swoją stronę domową tutaj natomiast tutaj jest źródło do ściągnięcia.

Konwersja z UTF8 do ASCII:

Otrzymamy:
http://www.xn--gegka-2ta76cmoc.pl

Konwersja z ASCII do UTF8:

Otrzymamy:
http://www.gżegżółka.pl

Jeżeli spróbujemy poddać konwersji normalną domenę, nie IDN, to nic się nie stanie więc funkcje/metody są bezpieczne i można ich używać na wszystkich domenach, bez dodatkowego rozróżniania. Pamiętaj tylko aby mieć adres w UTF8.

Niektórzy twierdzą, że e-maile w ogóle nie powinny występować w postaci HTML. E-mail to ma być prosta, tekstowa wiadomość, od wszystkiego innego są strony www. Trudno odmówić temu rozumowaniu logiki. Zwłaszcza, gdy dostajemy kolejną reklamę przeładowaną grafiką. Mnie osobiście podobają się jednak ładne, dobrze zorganizowane e-maile, bez bajerów i innych wodotrysków. To cieszy oko i ułatwia korzystanie. Chciałbym budować maile używając HTML'a i CSS'a. Ale...

Najważniejszych przeglądarek internetowych mamy kilka, każda w kilku wersjach. Potrafi to przyprawić o ból głowy. Na szczęście już całkiem nieźle radzą sobie z obsługą standardów. Natomiast klientów pocztowych są dziesiątki a może nawet setki! Po pierwsze, trzeba je podzielić na klienty desktopowe i webowe. Tych pierwszych jest mniej ale i tak wiele. Tych drugich jest zatrzęsienie i nie ma tu żadnych reguł, każdy dostawca poczty często robi wszystko po swojemu.

Efekt jest opłakany. Zbudować dzisiaj atrakcyjny e-mail w HTML/CSS, który byłby prawidłowo wyświetlany we wszystkich popularnych klientach jest co najmniej ogromnym wyzwaniem. Prym wśród najpopularniejszych wiedzie... Gmail! Rozumiem, że to w trosce o swoich użytkowników ale ich klient wycina ze źródła prawie wszystko.

No ale dość tych gorzkich żali Czas na jakieś wskazówki. Oto co należy robić a czego bezwzględnie unikać przy budowaniu kolejnego newslettera:

• Używaj UTF-8.
• Cofnij się o 8 lat w rozwoju i do zbudowania głównej struktury użyj tylko tabelek.
• Cofnij się o 10 lat w rozwoju i nie wstydź się tagów typu <center />.
• Możesz używać styli CSS tylko w postaci inline czyli przypisanych bezpośrednio do tagów w atrybucie style="". Nic innego nie zadziała.
• Gdzie tylko możesz, używaj starych atrybutów zamiast CSS np. width="". A najlepiej oba.
• Zapomnij o pozycjonowaniu absolutnym. Najlepiej zapomnij o jakimkolwiek pozycjonowaniu.
• Zapomnij o tłach obrazkowych. Gdziekolwiek i bez względu na użytą metodę. Tekstu nad obrazek po prostu nie wstawisz, koniec kropka. Zostaje Ci tło jako kolor.
• Lepiej zrobić wszystko na konkretne wymiary i podawać je gdzie się da. Procenty lub pomijanie podawania niektórych wymiarów może się skończyć rozjechaniem całego szablonu.
• Marginesy zewnętrzne i wewnętrzne? Niestety, nie możesz.
• Nawet width i height mogą nie zadziałać na innych elementach niż tabelki i ich komórki.
• W sekcję <head /> możesz wpisać tag odpowiedzialny za kodowanie znaków. I to też tylko dla świętego spokoju. Nic więcej nie umieszczaj bo i tak wytną.
• Nie dodawaj niczego bezpośrednio do tagu <body /> bo i tak zostanie to usunięte.
• Jeżeli chcesz dać np. kolor tła dla całej wiadomości to użyj jakiegoś kontenera (np. <div />) i daj mu szerokość 100%. Wysokość zawsze dostosuje się do zawartości, inaczej się nie da.
• Dla swojego dobra powielaj gdzie się da ustawienia dla czcionki itp. bo nigdy nie wiadomo dla którego elementu nasz klient pocztowy postanowi zresetować te wartości do tych domyślnych.
• JavaScript? Najprostsza droga do katalogu "Spam" (I moim zdaniem dobrze, obsługa JS to byłaby już jednak przesada).

To lista najtwardszych zasad, którymi musisz się kierować ale ograniczeń jest oczywiście dużo więcej. Każdy znający HTML/CSS łatwo odpowie sobie, które jeszcze rzeczy nie zadziałają skoro nawet tak podstawowe metody wymienione wyżej sprawiają ogromne problemy.

Na szczęście są strony, które kontrolują sytuację i sprawdzają za nas co wolno a czego trzeba się wystrzegać.
Pierwsza z polecanych przeze mnie witryn to www.campaignmonitor.com/css/. W ładny i przystępny sposób prezentuje ograniczenia klientów pocztowych. Na górze, w prawej ramce, mamy linki do obszerniejszego raportu, obejmującego 24 klienty (stan na grudzień 2011).
Druga strona to www.email-standards.org. Prezentuje dokładne recenzje wielu popularnych klientów. Niestety nie w tak przystępnej formie jak powyższa strona ale też przydatne.

Radzę wziąć sobie te zasady do serca i pilnować grafika jeżeli takowego masz w zespole bo i bez jego finezyjnych wygibasów w Photoshopie, możesz spędzić kilka godzin nad przygotowaniem jego wizji w formie wiadomości e-mail. Znam z doświadczenia

Obsługa standardów w przeglądarkach nadal nie jest na takim poziomie jakiego byśmy oczekiwali. Przezornie nie wykorzystujemy wielu możliwości CSS3 bo "znowu rozwali się w IE i będę miał przez to tylko problemy". Jest jednak grupa efektów, które działają we wszystkich (lub prawie wszystkich) przeglądarkach i jedyny problem z ich zastosowaniem jest taki, że w różnych programach interpretowane są różne reguły.

Pomocną dłoń wyciąga do nas autor css3please.com. Na tej stronie znajdziemy kilka interesujących efektów CSS3 w wersjach na różne przeglądarki. Wszystko jest ładnie opisane, ciągle aktualizowane a obsługę ułatwiają nam skrypty JS. Warto przejrzeć reguły umieszczone na stronie, zapamiętać i wracać regularnie. Polecam!

Skuszony wieloma rekomendacjami i niskimi cenami, postanowiłem skorzystać z oferty hostingowej linuxpl.com. Podstawowym plusem jest także możliwość zmiany wersji PHP na 5.3. Ta wersja pojawiła się dwa i pół roku temu a do tej pory nie jest dostępna na większości hostingów :/

Na linuxpl.com dostajemy również dostęp do SSH, co bywa dla mnie czasami zbawienne. W ustawieniach zmieniłem wersję PHP na 5.3 i z poziomu SSH chciałbym uruchamiać skrypty także pod tą wersją. Niestety, bez względu na ustawienia w panelu, komenda "php skrypt.php" pod SSH zawsze chce korzystać z PHP w wersji domyślnej dla linuxpl.com czyli PHP 5.2. Dokonałem tego odkrycia podczas gorączkowych przygotowań do uruchomienia lastdeal.pl więc postanowiłem nie czekać na support i rozwikłać zagadkę sam.

Nie da się na linuxpl.com sprawić aby zwykłe "php skrypt.php" działało w wersji innej niż PHP 5.2. Można jednak podać ścieżkę do innej wersji PHP. Jest to kłopotliwe bo trzeba wpisać za każdym razem długie ścieżki ale przynajmniej w ogóle się da. Swoją drogą niektóre (większość?) skrypty mają "na sztywno" wpisane samo "php coś tam" i trzeba będzie niestety je zedytować przed uruchomieniem.

Nie przedłużając, oto gotowa recepta.

Po zalogowaniu na SSH musisz zejść "niżej" w strukturze katalogów, wyjść ze swojego konta. Najlepiej "cd /". Binarka PHP w wersji 5.3 znajduje się tutaj: "./usr/local/php5.3/bin/php". Zamiast wpisywać "php skrypt.php" musisz wpisywać "./usr/local/php5.3/bin/php ./home/twoje_konto/domains/twoja_domena/public_html/skrypt.php".

Próbowałem zrobić symboliczny link aby chociaż trochę skrócić ścieżki ale niestety, nie powiodło się. Tam gdzie mam uprawnienia do tworzenia linków, tam nie zadziała ta binarka PHP. Trzeba zejść niżej, wyjść z własnego konta. A tam znowu nie mam już uprawnień...

Gdy była chwila spokoju, napisałem zapytanie do supportu. Potwierdzili to co sam znalazłem, dodając jedną wskazówkę:

jezeli chce pan uzyc swojego php.ini to komenda

/usr/local/php5.3/bin/php -c /usr/local/directadmin/data/users/lastdeal/php/lastdeal.pl/php.ini skrypt.php

Mam nadzieję, że ten wpis zaoszczędzi komuś trochę czasu i nerwów

Jak już wspominałem w innym artykule (przeczytaj komentarze, warto!), przeglądarki, ze względów bezpieczeństwa, ograniczają nasze możliwości komunikowania się między stronami w różnych domenach. Możemy natomiast dowolnie pracować i komunikować się w obrębie tej samej domeny. Jak rozszerzyć nasze możliwości?

Istnieje pewna metoda i nazywa się window.postMessage. Opracowano po prostu bezpieczną metodę komunikowania się cross-domain.

Sposób ten nie jest obsługiwany przez starsze przeglądarki (np. IE 7) dlatego powstał ciekawy plugin jQuery, który w razie czego, potrafi komunikować się w alternatywny sposób, poprzez document.location.hash. Jest także alternatywa w postaci czystego JS.

PS
Wiem, że to nie jest żadna nowość ale ostatnio mocniej zainteresowałem się tym tematem i pomyślałem, że warto o tym wspomnieć. W naszym języku ciężko natrafić nawet na wzmiankę o takich rzeczach.

Jakiś czas temu (kilka lat temu?) ktoś w komentarzu poprosił mnie o wytłumaczenie jak zniwelować dodatkowe obciążenie jakie generuje użycie przyjaznych adresów URL. Zacząłem o tym pisać a potem, z jakiegoś powodu, przerwałem i do tej pory nie znalazło się trochę czasu aby skończyć... Wiele artykułów mi w ten sposób przepadło. Tym razem dokończę dzieła A raczej napiszę od nowa bo wcześniej niepotrzebnie się rozpisałem...

Główne założenia: musisz napisać wydajną aplikację z przyjaznymi adresami URL w których nie przekazujesz żadnych identyfikatorów.

Przyjazne adresy to dzisiaj już konieczność. Ale wymagania wciąż rosną i teraz adresy muszą być jeszcze bardziej przyjazne niż kiedyś Nie tak dawno każdemu wystarczały adresy w postaci example.com/artykuly/1,jakis-adres/ czyli z przekazanym identyfikatorem zasobu. Te jednak okazały się zbyt brzydkie. Dzisiaj już nie chcemy identyfikatorów, chcemy czystych adresów czyli example.com/artykuly/jakis-adres/.

Oczywiście z punktu widzenia trudności zakodowania takiego rozwiązania, różnica jest niewielka. Jedno małe zapytanie do bazy danych gdzie wyszukamy identyfikator/dane artykułu na podstawie jego adresu. Czas wykonania się kodu też jakoś specjalnie się nie wydłuży. W czasach rozbudowanych frameworków z ich prostymi w użyciu routerami mało kto w ogóle sobie takimi rzeczami zawraca głowę. Być może jednak potrzebujesz ekstremalnej wydajności lub jesteś jej zwykłym fanatykiem (tak jak ja swego czasu ). Jest sposób na zlikwidowanie dodatkowego obciążenia.

Kluczem do sukcesu jest fakt, że przekierowanie w .htaccess, którego używasz (zakładam, że używasz bo inaczej nie uzyskałbyś nawet adresu example.com/artykuly/1,jakis-adres/ a co najwyżej jakieś example.com/artykuly.php/1,jakis-adres/) aby mieć przyjazne URL'e, działa tylko wtedy jeżeli nie istnieje fizycznie na dysku katalog/plik odpowiadający wpisanemu adresowi. Innymi słowy, jeżeli w publicznym katalogu głównym naszej aplikacji istnieje katalog artykuly a w nim katalog jakis-adres to żadne przekierowanie z .htaccess nie zadziała tylko Apache zacznie szukać w tym katalogu jakiegoś pliku index do wyświetlenia/uruchomienia.

Od tej wiedzy do sukcesu już krótki odcinek. Wystarczy podczas tworzenia artykułu (ale nie zapomnij potem o edycji i usuwaniu) tworzyć katalogi, które będą odpowiednikami adresów na stronie. W każdym z takich katalogów wystarczy umieścić plik index.php. Jego zawartość może wyglądać tak:

Oczywiście kod jest zupełnie przykładowy, chodzi o samą logikę. W wygenerowanym pliku mamy informację o identyfikatorze. Dzięki temu nie trzeba robić dodatkowego zapytania do bazy danych. Następnie startujemy naszą aplikację i przekazujemy dalej informację o identyfikatorze.

A więc mamy katalog /artykuly/jakis-adres/ w którym znajduje się plik index.php z powyższą zawartością. Działa. Osobiście przenoszę jeszcze wszystkie wygenerowane katalogi do jakiegoś wspólnego miejsca np. katalogu /cache. To wprowadza mi pewien porządek na dysku serwera, zwłaszcza gdy elementów korzystających z tego mechanizmu jest więcej (miałbym wtedy katalogi artykuly, galeria, imprezy itd. co wprowadza niepotrzebny bałagan). Robię to za pomocą .htaccess. Przykład:

I w ten oto prosty sposób mamy trochę więcej katalogów i plików na dysku ale:
- zyskaliśmy piękne adresy URL
- cały mechanizm nie generuje zbędnego obciążenia
- sposób nie jest zbyt kłopotliwy bo cały cache siedzi sobie w jednym katalogu i nikomu nie przeszkadza
- nasza strona jest o jeden krok bliżej do osiągnięcia sytuacji gdy artykuły są dostępne nawet podczas awarii bazy danych

Podsumowując: gdy ktoś wpisze adres example.com/artykuly/jakis-adres/ to zadziała przekierowanie na katalog /cache/artykuly/jakis-adres/ gdzie wygenerowany plik index.php posiada informację o identyfikatorze tego katalogu, uruchomi naszą aplikację i przekaże jej ID.

Można jeszcze dopisać mechanizm, który zablokuje bezpośredni dostęp do plików cache na serwerze (aby nie działały adresy example.com/cache/artykuly/jakis-adres/). I na tym koniec

PS
Pamiętaj aby pilnować przy adresach bez identyfikatorów aby adresy się nie powtarzały.