ugrás a tartalomhoz

keresőbarát urlek - htaccess vagy php?

therest · 2011. Feb. 25. (P), 23.20
Sziasztok!

Egy kis fejtágításra lenne szükségem urlekügyben. Próbálom az oldalamat fentebb csalogatni a googleben, és sok url a szokásos paraméterezett módon van megoldva (cikkek.php?cid=321), holott az adatbázisban ezeknek teljesen jól megfeleltethető rövid szöveges tartalmak találhatóak. Szeretnék az adatbázison alapuló keresőbarátabb urleket létrehozni. A kérdés tehát az, hogy hogyan lehet mysql adatokat bevonni a htaccesses átirányításokba. Be lehet? Ha nem ez a módja, akkor merre kéne elinduljak?

példa:
mysql táblában
id:133
title:"egy újabb cím"

Jelenleg az url valami ilyesmi: http://valami.hu/cikkek.php?cid=133
E helyett kéne valami ehhez hasonló: http://valami.hu/egy-ujabb-cim/
Kb mint egy wordpress blognál.

Mi a háttere az ilyen urleknek?
‹ Frame vagy Div újra... kombinálás!!! ›
 ■
1

Az adatbázisban minden

Joó Ádám · 2011. Feb. 25. (P), 23.28
Az adatbázisban minden tartalomhoz el kell tárold a kívánt szöveges azonosítót. Ezt követően az összes beérkező kérést irányítsd át egy állományba (pl. index.php), itt dolgozd fel, majd keresd ki a megfelelő tartalmat a szöveges azonosító alapján.

A .htaccess állományod valahogy így fog kinézni:
RewriteEngine on
RewriteRule ^.*$ index.php
Az index.php-ban ezek után a $_SERVER['REQUEST_URI'] változót kell vizsgáld.
2

ez eddig stimmt

therest · 2011. Feb. 26. (Szo), 00.11
Akkor request uriből kiszedem ami nekem kell, ez után visszakeresem a string alapján az adatbázisből az id-t (ez azért nem túl sebesség barát :S). És ez után? Gondolom ha megvan, akkor keresesét elvégző phpből újabb redirect jön, de hova? Hogyan marad meg az url felhasználó barátnak? Ezt használom rá? <link rel='canonical' href='keresobarat-url' /> (wordpress forássát elemezgetve gondolom).

(Ezekről a link metákról van valahol jó leírás? Feszítem a húrt: esetleg magyarul? :) )
3

Nincs redirect

Poetro · 2011. Feb. 26. (Szo), 00.13
Miután megtalálta az index.php a tartalmat adatbázisban, azt egyből ki is szolgálja.
4

nem világos még teljesen

therest · 2011. Feb. 26. (Szo), 01.14
Oké, akkor szolgálja ki az a script amire a htaccess átirányította. Legyen ez a cikkek almappában az index.php.
Az url ettől hogy marad meg ilyennek: http://valami.hu/cikkek/lekert-cikk-cime/ ?
5

Minden kérést ugyanaz az

Joó Ádám · 2011. Feb. 26. (Szo), 01.30
Minden kérést ugyanaz az index.php szolgál ki, nem almappákban lévők. A szerver átadja neki a kérést és az URL-t, te pedig az URL alapján eldöntöd, hogy milyen típusú tartalom (cikk, fórumtéma stb.) melyik példányát szolgálod ki, majd egyszerűen teszed a dolgod, ahogy szoktad. Természetesen nem kell az egész programodnak ebben az egy fájlban lennie: tetszés szerint felbonthatod, ahogy eddig, csak most nem közvetlenül hívják meg a különböző fájlokat, hanem te hívod meg őket az index.php-ban.
6

egy konkrét példa két sor kóddal?

therest · 2011. Feb. 26. (Szo), 17.06
Ezt nem nagyon értem: "Természetesen nem kell az egész programodnak ebben az egy fájlban lennie: tetszés szerint felbonthatod, ahogy eddig, csak most nem közvetlenül hívják meg a különböző fájlokat, hanem te hívod meg őket az index.php-ban."

Így gondoljátok?

$urlpart-ban az url azon része van, amely meghatározza a tartalmat.

if($urlpart=='cikkek') {
#include('articles.php');
showArticleList(); // függvény az articles.php-ből
// és a többi cikkekkel kapcsolatos teendő
} else if($urlpart=="blog"){
#include('blog.php');
showBlogPostsList(); // függvény a blog.php-ből
// és a többi bloggal kapcsolatos teendő
}
Remélem nem, és van valami jobb megközelítés, mert egy nagyobb oldalnál ez számomra elég átláthatatlan kódot jelentene.
Be kell valljam, sosem csináltam olyan oldalt, ahol mindent az index szolgál ki, és lövésem sincs miként kéne.

Írnátok pár sor kódot példának? Gyanítom abból azonnal megérteném.
7

Pontosan így, természetesen

Joó Ádám · 2011. Feb. 26. (Szo), 17.12
Pontosan így, természetesen az ilyesmit illik absztrahálni külön osztályba, függvénybe, épp azért, hogy átlátható legyen, és ne kelljen minden alkalmazásodnál megírni a feltételvizsgálatokat, hanem elegendő legyen mondjuk egy asszociatív tömbben megadni, hogy milyen URL mintához milyen kódot (állományt, osztályt, függvényt) hívjon meg.

Esetleg megnézheted a népszerű keretrendszerek, tartalomkezelők kódját, manapság már szinte mindegyik így csinálja.
8

lassuak is :)

therest · 2011. Feb. 26. (Szo), 17.55
Kicsit masszív megközelítés ez nekem, amiatt, hogy az index.php így borzasztó sok mindent kell kezeljen. Tanácsodat megfogadom, és megnézek azért pár CMS-t ennek kapcsán.

Utolsó kérdésem, ígérem: :D

Tegyük fel akkor hogy az index.php kezel le mindent. A beérkező kérésnél htaccess:

RewriteEngine on  
RewriteRule ^.*$ index.php
Ebben az esetben, az urlben hogyan lesz index.php helyett, az eredetileg kért url? Mert ha jól sejtem a fenti htaccessel, az url végül index.php lesz.
11

Még mindig nem érted, az

Joó Ádám · 2011. Feb. 26. (Szo), 18.15
Még mindig nem érted, az index.php csak a megfelelő állományt választja ki, azt végzi el, amit eddig az Apache, semmi többet. A munkát pont ugyanazok az önálló fájlok végzik el, amiket eddig a hagyományos URL-ek mellett írtál. Az URL pedig nem lesz index.php, mert itt egy belső átírásról és nem HTTP átirányításról van szó. De ezt magad is kipróbálhattad volna. Alant egy példakód.

library/router.php:
<?php

function route($routes, $url) {
    foreach ($routes in $path => $file) {
        if (preg_match($path, $url, $params = array())) {
            include $file;
        }
    }
}
.htaccess:
RewriteEngine on    
RewriteRule ^.*$ index.php
index.php:
<?php

require 'library/router.php';

$routes = array(
    '^/cikkek$'      => 'articles.php',
    '^/cikkek/(.+)$' => 'article.php',
    // ...
);

route($routes, $_SERVER['REQUEST_URI']);
article.php:
<?php

// Minden, amit eddig itt csináltál. A cikk azonosítója a $params[1] lesz
18

Na erre volt szükségem.

therest · 2011. Feb. 26. (Szo), 20.15
Na erre volt szükségem. Valahogy nekem eszembe sem jutott, hogy includeal így lefuttatható egy másik script. C++ hátérrel kezdtem phpzni, és a includeolt fileokra eddig úgy tekintettem, ahol osztályok vagy függvények vannak, fel sem merült bennem, hogy ez így működhet. :)

Köszi a válaszokat, nekiállok meglátom mire jutok!
20

Természetesen ez így nem szép

Joó Ádám · 2011. Feb. 27. (V), 01.03
Természetesen ez így nem szép megoldás! Egy szép megoldásban ugyanúgy használod az include-ot, mint C++-ban, és a hivatkozott állományban deklarált osztályt példányosítod, majd hívod meg a megfelelő függvényét. A fenti a lehető legegyszerűbb példa volt, nagyon sok munka ráfér még, mire valós környezetben használhatóvá válik.
9

Sokszor volt téma

vbence · 2011. Feb. 26. (Szo), 18.07
Amire én esküszöm:
http://example.com/c133-egy-ujabb-cim

c - cikk
133 - db id
ami utána van bármi lehet, figyelmen kívül van hagyva

Így szerepel a cím is benne emberbarát módon, és a DB-ben sem kell bajlódnod az azonsítóval (a cikk cím ugyebár lehet duplikált is).
10

Nem szerencsés

Poetro · 2011. Feb. 26. (Szo), 18.12
Ugyanis két különböző URL is eredményezheti ugyanazt az oldalt, és ezért tudtommal a keresőmotorok nem túl boldogok.
16

Egyértelmű URL-ek

vbence · 2011. Feb. 26. (Szo), 19.22
Nem eredményezheti, hacsak nem változik meg a cikk címe menet közben (akkor meg indokolt). Az URL-ek generálásakor mindig rendelkezésedre áll az adatbázis, szóval egyértelműek lesznek a címek, nem hasból töltöd ki az utolsó részt, hanem mindig következetesen a cím éktelenítésével.
21

És ha harmadik fél rájön, és

Joó Ádám · 2011. Feb. 27. (V), 01.07
És ha harmadik fél rájön, és egyszerűbbnek tartja csak http://example.com/c133 címen hivatkozni? Esetleg véletlenül elütik, elmarad egy része a címnek? Sosem derül ki, és máris több cím hivatkozik az adott tartalomra.
23

Harmadik fél

vbence · 2011. Feb. 27. (V), 02.30
Egyrészt megoldható egy check-kel a request URI-ra, hogy ha nem a kívánt címen nézik meg az oldalt az átirányítson (moved permanently) a "hivatalos" címre. Másrészt a töb címen elérhető tartalom negatív hatása is inkább csak városi legenda szintjén bizonyított. (Például sok oldal visz át session-jellegű információkat az URLben).

Akár itt a youtube URL-ek végén néha feltűnő feature=related rész, amit harmadik felek szivesen levágnak. Nem logikus, hogy ezt bármilyen jelnek tekintenék a tatalom minőségére. - Persze erre ellenérv lehet, hogy a querystring és a path nem egy súllyal esnek latba, de napjainkban, amikor a querystringet mindenféle path-oknek próbálják álcázni nem hiszem, hogy van lényeges eltérés a két rész feldolgozása között.
25

Persze, megoldható, csak az

Joó Ádám · 2011. Feb. 27. (V), 03.03
Persze, megoldható, csak az elején azt írtad, hogy a numerikus azonosító utáni részt eldobod, erre reagált Poetro. Az pedig szerintem valóban ellenérv, hogy az egyik az útvonal része, a másik pedig lekérdezés. És alapvetően nem a lekérdezést álcázod útvonalnak, hanem eddig használtuk olyasmire a lekérdezést, amire valójában az útvonal való.
12

Az én szépérzékem ettől

Joó Ádám · 2011. Feb. 26. (Szo), 18.20
Az én szépérzékem ettől sikítozik. Az azonosító dolga, hogy egyértelműen azonosítson egy erőforrást. Lévén a kettő közül egy is elég lenne, ezért ez redundáns. A legcsúnyább azonban az, ahogy egybefűzöd a tartalomtípust az azonosítóval: az URL-eknek is megvan a maga szemantikája, az pedig azt követeli meg, hogy a kettő közé egy perjel kerüljön. Arról nem is beszélve, hogy miért kell a „cikkek” öt karakterén nyerészkedni.
17

Persze hogy redunáns

vbence · 2011. Feb. 26. (Szo), 19.26
Nem lenne kötelező beleírni a cikk címét, csak így kereső és emberbarátabb. Az éktelenített cím nem egyértelmű azonosító.

A "cikkek" vagy inkább "cikk" nem tartalmaz a usernek értelmes információt, így nyugodt szívvel minimalizálható (és nem ez lesz az első lértelmes szó az URLben, ami ugye nem igazán keresőbarát).

A slash kontra kötőjel témában én sem vagyok biztos, régebben / válaszotta el a címet az azonosítótól, viszont így egy logikai szinttel hátrébb került a cikk címe. Amúgy gyakorlatiag nem tartom jelentősnek a különbséget.
22

Én ha nem akarok a szöveges

Joó Ádám · 2011. Feb. 27. (V), 01.23
Én ha nem akarok a szöveges azonosítóval bajlódni, akkor viselném a következményét, és lenne szám. Az ékezetmentes cím pedig egyértelmű, ha gondoskodsz róla, hogy az legyen. Egyébként sem érdemes automatizálni a cím konverzióját, mert a nemideálistól egészen az kész hülyeségekig sülhetnek ki belőle dolgok, így érdemes kézzel megadni.

A „cikkek” már hogyne tartalmazna információt, a felhasználó számára egyértelművé teszi, hogy milyen tartalomról van szó. Arról nem is beszélve, hogy a cikkeket nyilván ki fogod listázni valahol, a lista és az egyes cikkek közt alá-fölérendeltség van, így van egyértelmű, hogy a lista a /cikkek oldalra fog kerülni. A cikkek rész megléte a felhasználóval azt is tudatni fogja, hogy a listát ott találja. Az URL-ek szemantikáját pedig a kereső pont ugyanúgy ismeri, mint a felhasználó, tehát ő is ugyanígy hasznosítani tudja, azt pedig a városi legendák közé sorolnám, hogy ez rontana a helyezésen, épp azért, mert a kereső is tisztában van vele, hogyan épül fel egy cím.
13

Szerintem

Blintux · 2011. Feb. 26. (Szo), 18.49
Ez szerencsésebb szerintem ebben a formában:

http://example.com/cikk/egy-ujabb-cim
http://example.com/oldal/egy-ujabb-cim
http://example.com/kereses/van-e-ilyen

Én erre esküszöm:)
14

A keresésnél a keresett

Joó Ádám · 2011. Feb. 26. (Szo), 19.04
A keresésnél a keresett kifejezést paraméterként illik átadni, ugyanis kifejezetten erre találták ki. Nem kell átesni a ló túloldalára és félni a használatától, ha az, amit át akarunk adni nem egy koncepcionális erőforrás (keresőoldal), csak annak átadott információ (keresendő szöveg).
15

Ékezetes keresés?

vbence · 2011. Feb. 26. (Szo), 19.20
Mi van ha ékezetes szövegre keresel?
19

Százalékkódolás, mi lenne.

Joó Ádám · 2011. Feb. 27. (V), 00.59
Százalékkódolás, mi lenne.
24

Akkor ott állunk ahonnan

vbence · 2011. Feb. 27. (V), 02.32
Akkor ott állunk ahonnan indultunk, nem barátibb vagy olvashatóbb semmivel a querystringnél.
26

A lekérdezés a szintaktikája

Joó Ádám · 2011. Feb. 27. (V), 03.07
A lekérdezés a szintaktikája miatt nehezen olvasható, meg amúgy is hajlamosak a fejlesztők mindenféle érthetetlen dolgokat odaírni. De ha megnézed, feljebb azt írom, hogy ez pont query stringbe való, csak nem értettem, hol látod a nehézséget az ékezetekben, ha path-ról van szó.