|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Menu
Distributions (131)
bootable [55]
commercial [7] no-commercial [42] unclassified [20] [7]
Software (10844)
|
php rewriteNěkdy se stane, že nemáme k dispozici na našem hostingu tzv. rewrite, nebo si jeho pravidla nemůžeme sami zpravovat (např. u lighttpd serveru). V jiných pokročilých webových programovacích jazycích je ale obvyklé, použít tabulku adres a handlerů na funkce, které takovou adresu (požadavek) obslouží.
404 - stránka (ne)nalezenaK tomu aby to všechno fungovalo, potřebujeme provozovat vlastní chybovou stránku pro obsluhu chyby 404 - tedy nenalezeno. To lze nastavit na serveru Apache i pomocí .htaccess souboru. Pokud máme tuto možnost zakázanou, je třeba kontaktovat administrátora serveru, a požádat ho o příslušné nastavení. Chybová stránka je pak volána pokaždé, když server nenalezne soubor odpovídající http požadavku. Před samotným hledáním samozřejmě server provádí řadu úkonů, mezi něž patří i provedení rewrite pravidel. V případě že budeme veškeré řízení aplikace provádět přes tuto stránku, je třeba si uvědomit, že server automaticky vrací klientovi a loguje stav vyvolání stránky jako chybu 404, a je tedy takto vedena i ve statistikách generovaných právě z logu serveru. Aby k tomuto nedocházelo, je třeba server přesvědčit, v případě že požadavek je v pořádku) aby do logu a i klientovi vracel relevantní kód. Přesvědčit klienta je celkem snadné, je důležité co nejdříve zavolat příkaz header('HTTP/1.1 200 Ok'). V případě serveru Apache ovšem toto neovlivní kód který je logován, Teoreticky lze toto napravit funkcí http_send_status, toto ale nemám ověřené, navíc nejde o standardní funkci php, ale o funkci z PECL rozšíření.
dispatch tableA nyní co by měl dělat kód uložený v chybové stránce. Takový kód musí sám rozeznat http požadavek, resp. zadané url, a na základě vyhodnocení tohoto požadavku spustit příslušný kód. Toto v podstatě dělá i webový server, ten pokud ovšem nedokáže obsloužit takový požadavek, vrátí uživateli chybovou stránku, resp. pustí kód, který jí má vygenerovat. Naše chybová stránka, která duplikuje takové chování po svém pak může vypadat nějak takto:
Tento kód nejprve pomocí regulárního výrazu získá konec zadané adresy, která vyvolá chybu 404. Následuje jednoduchý switch, který pro konkrétní požadavek spustí konkrétní kód. Výchozí default větev vrátí chybovou stránku s chybovým stavem 404, tedy opravdu nenalezeno :) Tento kód slouží pro ukázku a je tedy velmi jednoduchý. Regulární výraz použitý pro získání požadavku se dá rozhodně pořádně vylepšit a ani hlavička s návratovým kódem není použita všude kde by měla, a už rozhodně ne pořádně. Kód by mohl být vylepšen o celou řadu dalších programátorských technik, rozhodně by to mohlo být volání funkcí místo spouštění kódu. Kolem celého mechanismu by měla být vytvořena řada nějakých podpůrných funkcí právě ke správnému a jednotnému ošetření hlaviček, výstupu atd. php rewritePomocí fíglu s odchycením chyby serveru 404 lze vytvořit v php i "opravdový" mod_rewrite, budeme mu říkat php_rewrite ;) Kód by měl v podstatě získat adresu požadavku, a na základě nějakých pravidel přesměrovat na správný požadavek, který již bude obsloužen (tak jak to dělá webový server). Jedno z kouzel mod_rewrite ale je, že se v prohlížeči návštěvníka stránky adresa nezmění, i toho lze malým trikem dosáhnout, musíme ale opravdu vědět, co vlastně děláme. Následující kód přidává php_rewrite do CMS Morias, tedy již do hotového projektu.
Co to vlastně dělá? Funkce rwrule dostane dva parametry, regulární výraz, který je použit na url a cíl regulárního výrazu, tedy stránku, která se má opravdu načíst. V kódu je trochu zmatek, aktuální verze ve skutečnosti nepošle prohlížeči požadavek na přesměrování, ale z nového url získaného rewrite pravidlem pomocí regulárního výrazu naplní super-globální proměnou _GET a přímo načte php soubor, který tento požadavek dál zpracuje, jako by to byl normální http požadavek. Díky tomu, že nedojde k přesměrování, ale k podsunutí _GET hodnot jinému php scriptu, uživatel bude mít ve svém prohlížeči původní adresu, a php_rewrite tak začne fungovat tak jak je mod_rewrite často používán. ZávěremOba příklady jsem zkoušel na serveru lighttpd, který právě trpí nedostatkem, kdy si uživatel sám nemůže upravovat rewrite pravidla, pokud nemá přístup přímo ke konfiguraci serveru. Otázka jak moc je, nebo není vhodné, takto rewrite řešit nechám na laskavém čtenáři, či diskutujícím. Kdo se ale do této magie pustí, měl by pamatovat na záludnosti regulárních výrazů, ty bude třeba určitě pořádně vyladit, aby obsloužily správně všechny adresy.
Related article
PHP (1) - Historie a budoucnost PHP (2) - Jak to funguje PHP (3) - Instalace PHP (4) - Základy syntaxe PHP (5) - Příkaz Echo; formátování kódu PHP (6) - Typy proměnných PHP (7) - Pole PHP (8) - Výrazy, konstanty, inkrementace PHP (9) - Přetypování proměnných PHP (10) - Logické výrazy a operátory PHP (11) - Operátory porovnání; priorita operátorů PHP (12) - Podmínky PHP (13) - Příkazy cyklu PHP (14) - Cyklus for PHP (15) - Funkce PHP (16) - Vyrobme si kalendář PHP (17) - Dokončujeme kalendář PHP (18) - Funkce pro práci s poli PHP (19) - Objekty PHP (20) - Objekty podruhé PHP (21) - Vkládání souborů PHP (22) - Regulární výrazy PHP (23) - Neztraťte se ve funkcích PHP (24) - Pracujeme s formuláři PHP (25) - Formuláře - nikomu nevěřte PHP (26) - Formuláře na sto způsobů PHP (27) - Příklady na formuláře PHP (28) - Chybovati je lidské PHP (29) - Soubory a adresáře PHP (30) - Počitadlo pomocí souborů PHP (31) - Upload a download souborů PHP (32) - Příklad na BLOG PHP (33) - HTTP hlavičky PHP (34) - Úvod do databází PHP (35) - Uložení dat v databázi PHP (36) - Připojujeme se k MySQL PHP (37) - Tvorba tabulek v MySQL PHP (38) - Dolujeme data z MySQL PHP (39) - Zobrazujeme a stránkujeme data PHP (40) - PHP a vkládání záznamů do databází PHP (41) - Měníme data v databázích PHP (42) - Odstraňujeme databázová data PHP (43) - MySQL rychleji a rychleji PHP (44) - MySQL ještě rychleji PHP (45) - Jsou data v databázi v bezpečí? PHP (46) - Importujeme data do databáze PHP (47) - Exportujeme data PHP (48) - Práce s binárními daty (BLOB) PHP (49) - Kam kráčíš, MySQL? PHP (50) - Ověřování uživatelů PHP (51) - Přenos dat mezi stránkami PHP (52) - Cookies PHP (53) - Sessions PHP (54) - Dodržování webových standardů PHP (55) - Odesílání e-mailů PHP (56) - Tisk a PDF PHP (57) - XML PHP (58) - XML lépe a radostněji PHP (59) - zapisujeme XML PHP (60) - Rozsáhlejší projekty 1. PHP (61) - Rozsáhlejší projekty 2. PHP (62) - Rozsáhlejší projekty 3. PHP (63) - Rozsáhlejší projekty 4. PHP (64) - Ladění kódu PHP (65) - Ladění kódu 2. PHP (66) - PHP debugger PHP (67) - Zdroje informací o PHP PHP (68) - Stavíme portál PHP (69) - Stavíme portál 2. PHP (70) - Registrace uživatelů na portálu PHP (71) - Přihlašování uživatelů na portál PHP (72) - Hrátky s uživateli PHP (73) - Frontend a backend PHP (74) - Administrátorské rozhraní portálu PHP (75) - Pokračujeme na portále PHP (76) - Zobrazujeme data na portále PHP (77) - Portál, databáze a relace PHP (78) - Informační obsah portálu PHP (79) - Triky s formuláři a ergonomie webu PHP (80) - Administrace diskografie hudebního portálu PHP (81) - Uživatel versus programátor PHP (82) - zabezpečení vstupů formulářů PHP (83) - Ukládání textů písní na hudebním portále PHP (84) - Ještě k registraci PHP (85) - ukládání souborů do databáze na portálu PHP (86) - zobrazení dat a stahování soborů pro registrované PHP (87) - finišujeme portál PHP (88) - provoz ve Windows PHP (89) - cesta do hlubin php.ini PHP (90) - Poťouchlé konfigurační volby PHP (91) - php.ini potřetí a naposledy PHP (92) - funkce pro interakci s operačním systémem PHP (93) - příkazový řádek PHP (94) - GUI PHP (95) - GUI podruhé PHP (96) - (ne)bezpečné PHP PHP (97) - bezpečnost ještě jednou PHP (98) - PHP 5. PHP (99) - Budoucnost PHP PHP (100) - Závěr PHP (101) - Apríl: Příklady z praxe Byte order mark a PHP Previous Show category (serial) Next
|
Szukanie oprogramowania
|
|||||||||||||||||||||||||||||||||||||||||||||||||
©Pavel Kysilka - 2003-2024 | maillinuxsoft.cz | Design: www.megadesign.cz |