Kompleksowe tworzenie stron internetowych, webdesign, aplikacje CMS

Przyjazne linki, czyli mod_rewrite w praktyce. Część 1

Artykuł został umieszczony w PHP Solutions Magazine, numer 06/2006.
Od 2006 roku wiele rzeczy zawartych w artykule mogło się zmienić.

Autor: Michał Gacki
Co powinieneś wiedzieć...: Potrzebna będzie średniozaawansowana wiedza na temat konfiguracji i korzystania z serwera Apache.
Co obiecujemy... Pokażemy, jak stosując Mod_Rewrite m.in. osiągnąć przejrzyste linki i zabezpieczyć dostęp do plików. Przybliżymy również podstawy wyrażeń regularnych.

Wszyscy lubimy przejrzyste i proste adresy stron WWW. Niestety, logika aplikacji PHP bywa dość skomplikowana – parę argumentów przekazywanych w URL-u wystarcza, aby skutecznie utrudnić życie użytkowników naszej witryny i obniżyć jej atrakcyjność dla wyszukiwarek. Problem ten rozwiążemy używając modułu Mod_Rewrite: dzięki niemu możemy zamienić nawet największą plątaninę linków i parametrów na czytelne i przyjazne adresy WWW.

Mod_Rewrite to moduł Apache'a, który jest domyślnie zainstalowany na serwerze (choć nie zawsze włączony w konfiguracji). Jego funkcją jest przepisywanie (ang. rewriting) URL-i, czyli możliwość prezentowania plików i katalogów umieszczonych na witrynie przy użyciu innych nazw i ścieżek niż w rzeczywistości. Pozwala nam to m.in. na dynamiczne przepisywanie linków, przekazywanie do skryptów PHP dodatkowych zmiennych, które nie zostały podane w zewnętrznym URL-u (metodą GET) ani przekazane metodą POST czy blokowanie zewnętrznych linków (zwanych też HotLinkami) do wybranych treści. Działanie Mod_Rewrite opiera się na stosowaniu reguł opisujących sposób przepisywania URL-i, które umieszczamy domyślnie w pliku .htaccess.

Czy możemy korzystać z Mod_Rewrite?

Niestety, obecnie większość serwerów hostingowych nie wspiera modułu Mod_Rewrite (stan na rok 2006, obecnie w 2014 mod_rewrite jest dostępny praktycznie wszędzie - przyp. autor). Ponieważ jednak coraz więcej użytkowników oczekuje możliwości korzystania z niego, jest on powoli wprowadzany jako standard. Na początek musimy się dowiedzieć, czy nasz serwer udostępnia ten moduł – możemy zapytać o to jego administratora albo sprawdzić to na własną rękę. Aby wykonać to drugie, przeprowadzimy prosty test: utworzymy plik test.php, w którym umieścimy następujący kod, po czym wykonamy go na serwerze:

<?php
phpinfo(INFO_MODULES);
?>

W tym skrypcie wywołujemy funkcję php_info(), która podaje parametry dotyczące środowiska PHP. Użycie parametru INFO_MODULES oznacza, że wyświetlone mają zostać wyłącznie informacje o zainstalowanych modułach (zob. Rysunek 1).

Jeżeli na liście widnieje nazwa mod_ rewrite, którą zaznaczyliśmy na Rysunku 1, to mamy pewność, że Mod_Rewrite jest zainstalowany na naszym serwerze. Może się jednak zdarzyć, że funkcja nie zwróci informacji o modułach (zależy to od konfiguracji serwera) – aby sprawdzić obecność Mod_ Rewrite, użyjemy wtedy skryptu przedstawionego na Listingu 1, który również umieścimy na serwerze pod nazwą test.php. Następnie utworzymy plik .htaccess, którego zawartość pokazujemy na Listingu 2. Działanie tego tandemu jest proste: w pliku .htaccess definiujemy przykładową regułę Mod_ Rewrite, która przepisuje wszystkie odwołania do pliku test.php jako test.php?tester=1, przez co do skryptu test.php przekazywana jest zmienna tester ($tester) z przypisaną wartością 1, co jest następnie sprawdzane. Jeśli nasz skrypt zwróci informację o braku Mod_Rewrite, możemy napisać do administratora z prośbą o jego instalację (czy choćby uruchomienie lokalne).

Pamiętajmy jeszcze o jednym: sprawdzając obecność zmiennej $tester przy użyciu isset($tester) zakładamy, że w ustawieniach parsera PHP włączone są register_globals. Tymczasem, na wielu serwerach są one wyłączane ze względów bezpieczeństwa. Lepiej jest więc użyć konstrukcji isset($_GET['tester']) w PHP5 lub isset($HTTP_GET_VARS['tester']) w PHP4. Kolejna uwaga dotyczy tworzenia pliku .htaccess w edytorze działającym pod systemem Windows w celu późniejszego przegrania go na serwer (np. za pomocą FTP). Pod tym systemem nie możemy utworzyć pliku, którego nazwa zaczyna się od kropki, co musimy obejść. W tym celu utworzymy plik o nazwie np. test.htaccess i dopiero na serwerze zmienimy jego nazwę na .htaccess. Gdy wgramy na serwer plik .htaccess z komendami Mod_Rewrite, a sam moduł nie będzie działał, wpisując adres jakiegokolwiek pliku istniejącego w tym samym katalogu, co .htaccess, ujrzymy informację o błędzie 404 (nie znaleziono pliku).Inne funkcje katalogu nie będą działać lub zobaczymy błąd 500 (Internal Server Error). Ten drugi zobaczymy zwłaszcza wtedy, gdy serwer zinterpretuje RewriteRule jako błąd składni .htaccess.

Listing 1. Sprawdzamy, czy Mod_Rewrite został zainstalowany na serwerze
<?php
if (isset($sprawdzacz)) {
?> Mod_Rewrite jest zainstalowany na tym serwerze <?
}
else {
?> Mod_Rewrite nie jest zainstalowany na tym serwerze lub jest błędnie
skonfigurowany <?
}
?>


Listing 2. Plik .htaccess, którego używamy wraz z test.php, aby sprawdzić obecność Mod_Rewrite
Options +FollowSymLinks
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(test.php)$ test.php?tester=1 [QSA]
RewriteRule ^$ test.php?tester=1 [QSA]
</IfModule>


Listing 3. Sprawdzamy, jaką wartość ma zmienna $menu
<?
$menu2 = false;
if (isset($menu) && $menu == true) {
?> <br /><b>Zmienna $menu istnieje, choć nie została podana w URL-u</b> <?
$menu2 = true;
}
?>
<br />
<? if ($menu2 == true) { ?>
Dzięki poprzedniej zmiennej wartość zmiennej $menu2 została zmieniona na
true, dlatego ten tekst jest widoczny.
<?
}
?>

Jeżeli nie korzystamy z serwera hostingowego, tylko mamy własny, a przepisywanie linków nie działa, to musimy zmodyfikować główny plik konfiguracyjny Apache'a noszący nazwę httpd.conf. W tym celu otworzymy go w dowolnym edytorze tekstu, odszukamy linie LoadModule rewrite_module modules/mod_rewrite.so, ClearModuleList oraz AddModule mod_ rewrite.c i usuniemy znaki komentarza (#), od których się rozpoczynają. Należy też poszukać w tym pliku dyrektywy AccessFileName, która określa domyślną nazwę pliku mogącego przechowywać ustawienia w katalogach. Standardowo jest nią .htaccess, jeśli jednak jest inaczej, to wpisujemy .htaccess. Teraz wystarczy zrestartować Apache'a i ponownie przeprowadzić testy: przepisywanie powinno działać.

Mod_Rewrite: zaczynamy

Jeżeli jesteśmy szczęśliwymi posiadaczami modułu Mod_Rewrite, możemy teraz przejść do bardziej zaawansowanych przykładów jego użycia. Poprzednio sprawdzaliśmy, czy zmienna przekazana do skryptu przy użyciu Mod_Rewrite istnieje: teraz sprawdzimy również jej wartość (true lub false). W tym celu stworzymy plik index. php, którego kod przedstawiamy na Listingu 3. Pamiętajmy o register_globals! Potrzebny nam też będzie plik .htaccess o następującej zawartości:

RewriteEngine On
RewriteRule ^index\.php$
index.php?menu=true [L]

Działanie tego zestawu index.php-.htaccess jest następujące: po wpisaniu nazwy index.php w przeglądarce WWW (albo przejściu do katalogu, w którym on się znajduje, jeżeli serwer automatycznie rozpoznaje indeksy), Mod_Rewrite przepisze index.php na index.php?menu=true, co spowoduje przesłanie zmiennej $menu do parsera PHP. Jeżeli się to uda, ujrzymy tekst informujący nas, że zmienna $menu istnieje. Wartość zmiennej $menu2 zostanie też zmieniona na true (zauważmy, że na początku skryptu jest ona ustawiona na false, aby nie można jej było zmienić metodą GET) i zobaczymy resztę tekstu. Ta część jest prosta, przejdźmy więc do omówienia pliku .htaccess. Po pierwsze, aby móc tworzyć reguły Mod_Rewrite, musimy najpierw umieścić instrukcję RewriteEngine On, która – jak sama nazwa wskazuje – włącza przepisywanie. Następnie, korzystając z polecenia RewriteRule definiujemy poszczególne zasady. Jego składnia jest następująca:

RewriteRule ^adres_źródłowy$ adres
przepisany [FLAGI]

Pierwszy adres, czyli adres źródłowy, który zawsze rozpoczynamy znakiem ^, a kończymy znakiem dolara ($), to oryginalna ścieżka pliku, którą chcemy przepisać jako adres_przepisany. Pamiętajmy, że jeśli w którymkolwiek adresie używamy znaków specjalnych: dolara ($), kropki (.), daszka (^), gwiazdki (*), plusa (+), pytajnika (?), backslasha (\) czy nawiasów klamrowych, okrągłych lub kwadratowych, to musimy je poprzedzać znakiem backslasha (\). Wynika to stąd, że obie ścieżki są rozpoznawane przy użyciu wyrażeń regularnych (ang. regular expressions), w których te znaki pełnią określone funkcje; poprzedzanie tych znaków backslashem nazywamy natomiast ich eskejpowaniem lub uwalnianiem (ang. character escaping), które powoduje, że każdy znak specjalny znajdujący się bezpośrednio po tym backslashu jest rozpoznawany jako zwykły znak.

Kolejna sprawa to tzw. flagi, które umieszczamy na końcu reguł. Nie użyliśmy ich w dotychczasowych przykładach, ponieważ przydają się one wtedy, gdy korzystamy z większej ilości reguł. Najczęściej używane flagi to:

  • NC – dzięki tej fladze reguła zadziała bez względu na wielkość liter, jakimi został napisany URL. Gdybyśmy w opisanym przykładzie dodali flagę NC, moglibyśmy wpisać adres w dowolny sposób, np. INDEX.PHP, inDeX.pHp, IndeX.php, itd.,
  • OR – oznacza to samo, co słowo or w języku angielskim, czyli lub. Dodając tę flagę do reguły możemy być pewni, że jeżeli ta ostatnia nie zostanie wykonana, serwer spróbuje użyć reguły znajdującej się o linijkę niżej, Ÿ
  • L – skrót od angielskiego słowa last (ostatni). Wstawienie tej flagi powoduje zatrzymanie sprawdzania kolejnych reguł w .htaccess, jeżeli reguła ją zawierająca jest poprawna i zostanie użyta. Ÿ
  • R - skrót od redirect (po ang. przekierowanie). Dodanie tej flagi powoduje przekierowanie adresu na adres przepisany. Gdybyśmy wstawili tę flagę w naszym drugim przykładzie, w pasku adresowym przeglądarki dopisany zostałby ciąg ?menu=true, co w tej sytuacji nie byłoby pożądane. Stosując flagę R możemy też wskazać typ przekierowania, np. słynne przekierowanie 301 (Redirect 301) zapiszemy jako R=301.

Możemy dodać kilka flag jednocześnie – wystarczy je wymienić po przecinku między nawiasami kwadratowymi na końcu reguły. Przykład: [L,NC,OR]. W naszym przypadku ścieżka index.php zostanie przepisana na index. php?menu=true. Rozwiązanie przekazywania zmiennych jest przydatne, gdy chcemy bez modyfikacji plików PHP przesłać dodatkowe wartości. Przykładowo, jeśli chcemy dodać promocję w naszym sklepie internetowym, który korzysta z plików (a nie z bazy danych), nie musimy modyfikować za każdym razem tych ostatnich - wystarczy raz umieścić odpowiedni warunek w skrypcie PHP i wgrać plik .htaccess na serwer. Po zakończeniu promocji wystarczy usunąć .htaccess albo zmienić jego nazwę, np. na promocja. htaccess. Przy takich rozwiązaniach należy jednak pamiętać, że jeżeli ktoś wie, od jakiej zmiennej zależy warunek, może ją dopisać do adresu URL i tym sposobem obejrzeć ukrytą część strony! Aby sprecyzować zakres działania naszego pliku .htaccess, możemy pod linijką zawierającą komendę RewriteEngine On wstawić polecenie RewriteBase, które określa relatywną ścieżkę do aktualnego katalogu. Jej składnia jest następująca:

RewriteBase ścieżka

Jeśli chcemy, aby nasze reguły miały zasięg globalny, nie musimy wstawiać RewriteBase do pliku .htaccess.

Migracja domen przy użyciu Mod_Rewrite

Często się zdarza, że zmieniamy domenę naszego serwisu i chcemy zachować starą. Przykładowo, możemy przenosić ją z darmowej na płatną (np. .com), natomiast likwidacja starej domeny oznaczałaby dla nas utratę tysięcy linków do nas zamieszczonych na innych witrynach oraz pozycji w wyszukiwarkach, które zindeksowały wiele spośród naszych podstron ze starym adresem i związane z nimi słowa kluczowe. Na pierwszy rzut oka, rozwiązanie tego problemu migracji wydaje się proste – wystarczy podpiąć dwie domeny pod to samo konto. Wiążą się z tym jednak kolejne trudności, np. wyszukiwarka Google widzi takie domeny jako tzw. double content, czyli dwie witryny z identyczną treścią. Tu również pomoże nam Mod_Rewrite: w katalogu głównym starej domeny umieścimy plik .htaccess o następującej zawartości:

RewriteEngine On
RewriteCond %{HTTP_HOST} staradomena.com
RewriteRule ^(.*)$
http://www.nowadomena.com/$1 [R=301,L]

Jak widać, w kodzie pojawia się nowe polecenie RewriteCond. Określa ono zakres wykonywania dalszych reguł. W tym przypadku ustala warunek, że reguły będą interpretowane tylko wtedy, gdy wejście nastąpi z adresu staradomena.com. Składnia komendy RewriteCond jest następująca:

RewriteCond %{WARUNEK} adres

Jedyna zdefiniowana przez nas tym razem reguła przepisuje wszystkie stare adresy na http://www.nowadomena.pl/[adres]. Do rozpoznawania wszystkich znaków służy wyrażenie regularne (.*) – kropka symbolizuje dowolny znak, a * – dowolną ilość znaków.

Użyte przez nas przekierowanie przy użyciu RewriteRule i RewriteCond jest znacznie lepsze od tradycyjnego Redirect301 / http://www.nowadomena.com, ponieważ to drugie przekierowuje użytkownika od razu na nową domenę niezależnie od tego, czy wpisał adres starej, czy nowej. Co więcej, to stosując przytoczoną instrukcję Redirect301 (którą też umieszczamy w pliku .htaccess) można łatwo zapętlić serwer. Umieszczenie instrukcji Redirect301 przekierowującej ze starego adresu na serwerze, pod który podpięte są dwie domeny (staradomena.com i nowadomena. com), grozi tym, że serwer będzie nas przekierowywał w nieskończoność, gdyż nie będzie wiedział, która domena jest stara, a która nowa – obie będą czytały ten sam plik .htaccess. Dzięki zastosowaniu przedstawionego zestawu składającego się z przekierowania warunkowego RewriteCond i reguły RewriteRule tego unikniemy: serwer nie będzie miał problemu z ustaleniem, która domena jest nowa, a która stara, gdyż przekierowanie podziała tylko, jeżeli wejdziemy ze starej.

Skuteczna blokada HotLinków

Chyba każdy, kto zamieszcza jakiekolwiek pliki do pobrania na stronie WWW, wie, co znaczy termin HotLink: oznacza on podpinanie się pod wybrane pliki (np. MP3 czy PNG) z innego serwisu. W praktyce wygląda to tak, że webmaster kupuje serwer, na którym umieszcza pliki, które z kolei są przeznaczone do pobrania z jego strony, a osoba prowadząca inny serwis po prostu podpina te same linki u siebie na stronie, czego następstwem jest wzrost transferu na koncie webmastera, który wykupił serwer. Powoduje to zwiększenie obciążenia łączy prowadzących do tego serwera; co więcej, niektóre firmy hostingowe ustalają górne limity miesięczne transferu z konta, po przekroczeniu których strona jest zawieszana.

Aby się bronić przed tym zjawiskiem, należy zastosować blokadę HotLinków. Dotychczas opracowano i wdrożono wiele tego rodzaju blokad działających na poziomie PHP. Jednymi z najskuteczniejszych były te, które sprawdzały serwer polecający (tzn. serwer, z którego nastąpiło kliknięcie na link) i porównywały jego adres z adresem witryny, której właściciel umieścił swoje pliki oraz używały przepisywania linków w celu ukrycia plików do pobrania, zarazem uruchamiając skrypt. Niestety, blokady te miały jedną wadę – jeżeli ktoś znał prawdziwe ścieżki do plików, skrypt się nie uruchamiał i plik można było spokojnie pobrać.

Tu również z pomocą przychodzi Mod_Rewrite, pozwalając na udoskonalenie opisanej metody. Wystarczy stworzyć plik .htaccess, który następnie umieszczamy w katalogu przeznaczonym do zabezpieczenia:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://
(.+\.)?strona\.com [NC]
RewriteRule ^.*\.(zip|exe|rar|gz|
tar.gz|tar)$ http://www.strona.com/
HotLink.html [L]

Dzięki poznanej wcześniej komendzie RewriteCond i wyrażeniom regularnym możemy w prosty sposób ustalić warunek wykonywania reguł dla serwerów polecających: następne reguły (które przekierowują wszystkie HotLinki na stronę informującą, że jest to zabronione) będą wykonywane tylko wtedy, jeżeli sprawdzany przez HTTP_ REFERER adres serwera polecającego nie jest naszym adresem. Problem mogący się pojawiać przy użyciu przedrostka www rozwiązuje zastosowanie wyrażenia regularnego (.+\.)?, dzięki któremu nieważne jest, czy w adresie użyto tego prefiksu, czy nie. Zauważmy, że przed naszym adresem (strona.com) umieściliśmy znak wykrzyknika: w języku wyrażeń regularnych oznacza on przeczenie.

Umieszczona w następnej linijce reguła sprawdza po rozszerzeniu pliku, czy wolno do niego linkować. Jeżeli rozszerzenie to (opisane wyrażeniem regularnym .*\., czyli dowolny_znak.znaki_po_kropce; zwróćmy uwagę na eskejpowanie znaku kropki) należy do grupy zabronionych (u nas zip, exe, rar, gz, tar.gz i tar), to link do pliku nie zadziała: użytkownik, który na niego kliknie, zostanie przekierowany na stronę HotLink.html.

Opisane rozwiązanie jest bardzo przydatne, ale ma jedną wadę: gdy wpiszemy adres pliku w przeglądarce (otrzymany np. w mailu czy komunikatorze), blokada HotLink zadziała i nie będziemy mogli pobrać pliku. A przecież ideą blokowania HotLinków nie jest utrudnianie życia zwykłym użytkownikom, tylko właścicielom serwisów obciążających nasze łącza! Aby zaradzić temu problemowi, możemy przerobić kod na następujący:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://
(.+\.)?strona\.com [NC]
RewriteRule^ .*\.(zip|exe|rar|gz|tar.gz
|tar)$
http://www.strona.com/index.php?page=down
load&file=$1 [L]

Spowoduje on przekierowanie użytkownika pod adres: index.php?page=download& file=nazwa_pliku pod którym zamieszczamy skrypt PHP służący do ściągania plików (nie podajemy go w artykule, gdyż może być to dowolny skrypt tego rodzaju dostępny w Internecie albo napisany przez nas). Użytkownik zobaczy komunikat zawierający link do pliku i będzie musiał go pobrać z naszej strony, więc blokada HotLinków mu w tym nie przeszkodzi. Oczywiście użyty w tym przykładzie adres jest testowy i należy go przystosować do własnego serwisu. Opisaną blokadę Hot- Linków można oczywiście wykorzystać także w przypadku plików graficznych, z czego korzystają zazwyczaj firmy udostępniające darmowy hosting.

Wyrażenia regularne

W regułach RewriteRule stosowaliśmy wyrażenia regularne (ang. regular expressions). Mówiąc najprościej, są to wzorce w postaci łańcuchów symboli, których używamy w celu zaawansowanego wyszukiwania wybranych fraz w tekście (w przypadku RewriteRule przeszukiwane są nazwy plików i katalogów). Wyrażenia te odnajdują tekst pasujący do wzorca. Ze względu na elastyczność, wyrażenia regularne stanowią wręcz standard wśród metod przeszukiwania tekstu. Warto wiedzieć, że dzielą się na składnię uniksową i perlową (znaną jako PCRE czyli Perl Compatible Regular Expressions i stosowaną nie tylko w Perlu, ale także w PHP, Ruby i wielu innych językach, które korzystają z utworzonej w C biblioteki PCRE). Bez znajomości choćby podstaw wyrażeń regularnych ciężko mówić o korzystaniu z Mod_Rewrite. Oto kilka znaczników używanych w wyrażeniach regularnych, które ułatwią nam dalszą pracę z tym modułem:

    Ÿ
  • kropka (.) – dowolny znak,
  • Ÿ
  • tekst1|tekst2 – alternatywa: tekst1 lub tekst2,
  • Ÿ
  • daszek (^) – rozpoczyna daną strefę znaków,
  • Ÿ
  • dolar ($) – kończy daną strefę znaków,
  • Ÿ
  • pytajnik (?) – zero lub jeden znak poprzedzający wyrażenie,
  • Ÿ
  • gwiazdka (*) – zero lub więcej znaków poprzedzających wyrażenie,
  • Ÿ
  • plus (+) – jeden lub więcej znaków poprzedzających wyrażenie,
  • Ÿ
  • (tekst _ w _ nawiasach) – grupuje tekst tekst _ w _ nawiasach.

Aby podstawić w adresie docelowym znalezione nazwy, które pasują do wyrażenia użytego w regule wobec adresu źródłowego, używamy oznaczającego rezultat wyszukiwania dolara ($), bezpośrednio po którym stawiamy numer wyrażenia (licząc od pierwszego pozwalającego na wstawienie tekstu), czyli np. $1, $2 i $3. Numery rezultatów szukania są przyporządkowane kolejnym wyrażeniom (zawartym w nawiasach), np. wyrażeniu ^([^-]+)/([^-]+)/([^-]+)$ zostaną przypisane $1, $2 i $3.

Przepisywanie adresów URL (tzw. przyjazne linki)

Mod_Rewrite pozwala także przepisywać linki. Niejedna osoba zdziwiła się pewnie widząc na dynamicznej stronie WWW adresy typu gallery-photo-1.html, które tak naprawdę maskują właściwe URL-e (np. index.php?module=gallery&function=photo&id=351). Jak wiadomo, w dzisiejszych czasach dla sukcesu strony bardzo ważna jest pozycja w wyszukiwarkach typu Google. Link zaczynający się od index. php z ustawieniem wielu zmiennych nie jest przyjazny ani dla użytkownika, ani dla wyszukiwarki, ponieważ zawiera znaki, których te ostatnie nie lubią, a mianowicie pytajnik i ampersand (&). Powoduje to, że strony zawierające takie adresy URL nie są w ogóle indeksowane lub są indeksowane bardzo powoli. Co więcej, systemy CMS (ang. Content Management Systems, czyli systemy zarządzania treścią) często korzystają z przekazywania identyfikatora sesji w adresach URL (przesyłania tego ID przez cookies wyszukiwarki i przeglądarki często w ogóle nie akceptują), przez co adres może wyglądać niezbyt zachęcająco, np.:

index.php?module=gallery&function=photo&id=35&PHPSESSID=accfcc299077b36817dc534c90588253

Dzięki Mod_Rewrite możemy uczynić adres naszej strony bardziej atrakcyjnym dla wyszukiwarek (i tych użytkowników, którzy lubią zapisywać bądź zapamiętywać URL-e) oraz usunąć doklejanie identyfikatora sesji do linków. To powinno być priorytetem nie tylko dla webdesignerów, ale dla wszystkich osób tworzących strony internetowe. Przyjazne adresy to teraz jakby nie było podstawa.

Zacznijmy od tego, że nie ma gotowego kodu, który będzie działał na wszystkich stronach; posłużymy się więc praktycznym przykładem testowym, który trzeba będzie przystosować do każdej strony. Załóżmy zatem, że chcemy zmienić zwykłe linki index.php?module=wartość1&function=wartość2& id=wartość3 na przepisane adresy w stylu katalogowym (wartość1/wartość2/ wartość3). Przykładowo, mając galerię zdjęć chcemy, żeby wpisując adres typu http: //www.mojadomena.com/gallery/photo/21, użytkownik był kierowany na stronę http: //www.mojadomena.pl/index.php?module= gallery&function=photo&id=21 nawet o tym nie wiedząc (w przeglądarce będzie cały czas widniał przyjazny URL). Nie chcemy i nie będziemy przy tym tworzyć katalogów o nazwach gallery, photo czy 21. Mod_Rewrite pozwala zarówno na udawanie nazw plików, jak i katalogów – stwórzmy plik .htaccess o następującej zawartości:

RewriteEngine On
RewriteRule ^([^-]+)/([^-]+)/([^-]+)$ index.php?module=$1&function=$2&id=$3 [L,NC,NS]

W powyższej regule użyliśmy trzech flag, oznaczających m.in. to, że wielkość liter w adresach nie będzie miała znaczenia (flaga NC), a przepisywanie nie zakończy się na tej jednej regule (flaga L), ponieważ jest to dopiero początek naszego większego pliku .htaccess. Tak więc, poprawny będzie zarówno adres http://www.mojadomena.pl/gallery/photo/21, jak np. http://www.mojadomena.pl/galLeRy/ phOtO/21. Natomiast wyrażenie regularne ([^-]+) pozwala na wstawienie dowolnego słowa.

Wszystko działa, ale czy na pewno? Zapraszam do drugiej części mojego artykułu.

Autor: Michał Gacki

Przeczytaj też: Przyjazne linki, czyli mod_rewrite w praktyce. Część 2

Zaufali nam:

i wielu więcej

Nowości »

Postanowiliśmy umieścić poradniki dotyczące tworzenia stron WWW, które opublikowaliśmy kilka lat temu na łamach magazynu PHP Solutions. Są to artykuły prasowe, które od dziś będzie można przeczytać online i zastosować w praktyce. Jeśli jesteś początkującym programistą lub chcesz zacząć swoją przygodę z programowaniem, zapraszamy do lektury. więcej nowości >