[DISC] Wel of geen "vriendelijke" URL's in CMS?

[Reveller]

Als je kijkt naar verschillende CMS systemen, kun je een duidelijk onderscheid maken: CMS'en die "vriendelijke" (http://www.mijnsite.com/contact) en "onvriendelijke" (http://www.mijnsite.com?id=5) genereren.

Na veel lezen vond ik twee belangrijke argumenten om op de eerste manier te werk te gaan:
• deze urls worden goed geindexeerd door zoekmachines. URL's met een ? of & worden niet of minder goed geindexeerd;
• bezoekers kunnen nu ook een URL "raden", bijvoorbeeld http://www.microsoft.com/office.

Beide argumenten vind ik wat zwak:
• google staat vol met sites die zich van de meest onmogelijke querystyringen bedienen;
• ik heb veel mensen in mijn omgeving gevraagd of zij ooit een URL raden. De meesten wisten niet eens wat een URL inhield en hadden er nog nooit bij stil gestaan dat je dat ook zelf kon intikken. Maar zelf met die kennis interesseert het ze niet. "Ik klik wel of ik bookmark de pagina".

Ik wil graag weten wat jullie hiervan denken. Welke methode gebruiken jullie in je CMS? Ik ben er benieuwd naar omdat ik tot een paar weken geleden helemaal weg was van http://www.mijnsite.com/vriendelijke/urls/, maar kom hier steeds meer van terug omdat:

• het moeilijker is meerdere argumenten mee te geven aan de querystring, bijvoorbeeld hoeveel plaatjes per pagina de bezoeker wil zien, of de pagina in print-layout getoond moet worden, bij welke zoekresultaten we zijn gebleven. Je krijgt dan nog steeds verhalen als http://www.mijnsite.com/gastenboek/10/20!print ofzo.
• voor de gebruiker is het minder gebruiksvriendelijk. Als die een nieuwe pagina aanmaakt, moet deze (optioneel) een alias voor de pagina aanmaken. Dan kan het zijn dat er al een pagina met die alias bestaat, wat weer frustratie kan wekken.

Voor de duidelijkheid: mijn doelgroep zijn kleine MKB bedrijven die voor het eerst een (professionele) website opzetten en deze zelf willen kunnen bijhouden. In een grote organisatie met aparte IT-afdelingen, zijn mensen gespecialiseerd en is het tweede argument hierboven een non-opmerking. Het gaat er mij dus om of voor de doelgroep mooie urls nou echt nodig zijn, vooral gezien de nadelen die ermee samenhangen.

Er zijn veel bekende websites en grote bedrijven die onvriendelijke URLS gebruiken: http://www.nu.nl, http://www.leidenuniv.nl, http://www.minfin.nl, http://www.rotterdam.nl etc. Uiteraard zijn er evenzoveel voorbeelden te geven van vriendelijke (of: vriendelijkere) urls: http://www.telegraaf.nl, http://www.eur.nl, http://www.sun.com.

Het lijkt mij alleen dat als er echt een enorme vraag naar vriendelijke URLS zou zijn, grote organisaties als het ministerie van financien, de univeristeit leiden en de gemeente rotterdam wel een ander CMS hadden gekozen dan wat ze nu hebben? Ze hebben er in ieder geval het geld voor - en bovendien: de universiteit leiden gebruik (URL-onvriendelijk) QCMS, wat behoorlijk wat centjes kostte, maar de erasmus universiteit gebruik het gratis (URL vriendelijke) Silva CMS (op zope.org). Dus het kostenplaatje is geen argument. Is het dan gewoon een voorkeur?

Graag jullie ervaringen / meningen, want ik wil voor mijn eigen CMS een goede keuze maken.

[Not Pingu]

Er zijn een aantal mensen die graag van de 'hackbaarheid' van URL's gebruikmaken, bijv. op GoT is het handig om posts in de search te zien ipv topics door de toevoeging /messages.
Het is imho ook beter ivm. bookmarking enzo om pagina's naar een textuele referentie te laten verwijzen dan naar een get string.

In mijn nieuwe CMS kun je pagina's hierarchisch creeren waardoor je bijv. een url krijgt als www.kunstgalerie.nl/collectie/beelden/marmer/beeld1 etc. Voor de mensen die het niks kan schelen; baat het niet dan schaadt het niet. Voor de mensen die van de adresbalk gebruikmaken voor navigatie en herkenning van pagina's is het super handig.

[ Voor 38% gewijzigd door Not Pingu op 05-09-2004 15:07 ]

[mbravenboer]

Cool URIs don't change. 'Onvriendelijke URLs' zijn niet cool: ze hebben de neiging te veranderen. Ze leggen de implementatie op de server-side bloot.

[NMe]

Reveller schreef op 05 september 2004 @ 15:01:
• deze urls worden goed geindexeerd door zoekmachines. URL's met een ? of & worden niet of minder goed geindexeerd;

Oud argument, gaat niet meer op.
Beide argumenten vind ik wat zwak:

Reveller schreef op 05 september 2004 @ 15:01:
Ik wil graag weten wat jullie hiervan denken. Welke methode gebruiken jullie in je CMS? Ik ben er benieuwd naar omdat ik tot een paar weken geleden helemaal weg was van http://www.mijnsite.com/vriendelijke/urls/, maar kom hier steeds meer van terug omdat:

• het moeilijker is meerdere argumenten mee te geven aan de querystring, bijvoorbeeld hoeveel plaatjes per pagina de bezoeker wil zien, of de pagina in print-layout getoond moet worden, bij welke zoekresultaten we zijn gebleven. Je krijgt dan nog steeds verhalen als http://www.mijnsite.com/gastenboek/10/20!print ofzo.

Wat is daar het probleem aan? Het ziet nog steeds minder ingewikkeld uit dan al die vraagtekens en ampersands...

Reveller schreef op 05 september 2004 @ 15:01:
• voor de gebruiker is het minder gebruiksvriendelijk. Als die een nieuwe pagina aanmaakt, moet deze (optioneel) een alias voor de pagina aanmaken. Dan kan het zijn dat er al een pagina met die alias bestaat, wat weer frustratie kan wekken.

Dit volg ik niet? Je zegt net zelf dat een gebruiker liever klikt, en niet eens naar de URL kijkt. Wat maakt zo'n alias dan uit? En de meer ervaren gebruiker zal echt wel beter opletten.

Wat een goeie keuze is, is helemaal persoonlijk. Die vriendelijke URLs zijn trouwens altijd aliassen, die naast de standaard URLs werken. Ze zijn dus sowieso beide bruikbaar. Zelf geef ik de voorkeur aan de vriendelijkere URLs omdat ze meestal korter zijn, en makkelijker/duidelijker uitzien. Maar iemand die niet veel met computers of internet werkt, kijkt zoals je zelf al zegt niet naar de URL, en zal er weinig verschil van merken. Deze hele discussie is daarom helemaal niet zo belangrijk.

[ Voor 3% gewijzigd door NMe op 05-09-2004 15:18 ]

[Verwijderd]

Ik gebruik niet standaard SES urls, maar gebruik parameters. De urls worden prima geindexeerd.

Ik geef de gebruiker echter wel de mogelijkheid om een mapping aan te maken
/software = id
/support = id
etc.

Bij het aanmaken van een mapping wordt op klantniveau een bestand aangemaakt die een relocate naar het id uitvoert.

[Verwijderd]

Reveller schreef op 05 september 2004 @ 15:01:

• het moeilijker is meerdere argumenten mee te geven aan de querystring, bijvoorbeeld hoeveel plaatjes per pagina de bezoeker wil zien, of de pagina in print-layout getoond moet worden, bij welke zoekresultaten we zijn gebleven. Je krijgt dan nog steeds verhalen als http://www.mijnsite.com/gastenboek/10/20!print ofzo.

In principe hoef je het toch ook niet in de querystring mee te geven? Je zou het via een form naar een script kunnen sturen. Ik weet niet of dit ivm het gebruik van een CMS ook voor jou een mogelijkheid is, maar in elk geval zou dit een oplossing zijn.

Ik heb zelf ook erg lang zitten piekeren over vriendelijke URLs en ik heb besloten om ze op mijn nieuwe site wel te gebruiken. Deze beslissing hangt samen met de update van het Google alghoritme van een paar maanden geleden (genaamd Florida?) Er is sindsdien veel onderzoek gedaan naar de werking van het pr alghoritme en er wordt gesuggereerd dat directory-achtige sites op veel lof van Google kunnen rekenen.

Ik heb mijn URL's daarom als volgt:

www.blablablabla.nl/
www.blablablabla.nl/Microsoft_Office/
www.blablablabla.nl/Microsoft_Office/Frontpage.html
www.blablablabla.nl/Microsoft_Office/Excel.html
etc

Zo creëer je eigenlijk vertikale thema's in je site, zoals bij een directory, en dat schijnt erg goed te zijn. Daarnaast vind ik het gewoon fijn als URLs hackable zijn en bovendien een goede indicatie geven van waar je je bevindt in de site.

Je ziet waarschijnlijk wel dat ik niet uit ervaring zeg dat vriendelijke URLs het zo goed doen in zoekmachines. Ik heb een PHPBB forum met dynamsche URLs waarmee ik ook zeer goede zoekmachine posities behaal. Als je meer wil lezen hierover moet je eens naar dit artikel en ditartikel op webmasterworld fietsen. Je moet je wel registreren.

Als vriendelijke URLs betekent dat jouw klanten moeilijkere handelingen zouden moeten uitvoeren, dan zou ik dat argument zwaar meewegen. Ik begrijp niet zo goed wat de extra handelingen voor de eindgebruiker zouden zijn, maar dat lijkt me ondanks zoekmachines en hackability zeker een belangrijke overweging.

[Reveller]

NMe84 schreef op 05 september 2004 @ 15:11:
[...]
Deze hele discussie is daarom helemaal niet zo belangrijk.

Nou, deze discussie is in zoverre belangrijk dat het een heel andere aanpak vergt van hoe je je CMS in elkaar hackt. Vriendelijke URL's maken betekent:

• Ik moet in in de .htaccess de http://www.mijnsite.com/vriendelijke/url/pagina herschrijven naar http://www.mijnsite.com?q=vriendelijke/url/pagina
• Ik moet in de database gaan kijken of er een Alias "vriendelijke/url/pagina" bestaat en zo ja, naar welke pagina die moet verwijzen
• probleem: /hier/een/gastenboek/30 betekent: zoek Alias "hier/een/gastenboek" en laat alle berichten vanaf bericht_id 30 zien. Probleem: hoe weet ik of die 30 niet onderdeel is van de alias zelf?
• zonder vriendelijke URL's kunnen de gebruikers van het CMS gewoon een nieuwe pagina aanmaken, deze vullen en klaar. Automatisch wordt de pagina aan de navigatie toegevoegd etc. Met vriendelijke URL's zal de gebruiker ook nog een Alias moeten verzinnen, wat toch een extra belasting is voor mensen die in mijn ervaring niet eens weten wat een URL of adresbalk is (zonder neerbuigend te willen klinken)

Ik ken de artikelen van Lee, maar die zijn vooral vanuit ideologisch oogpunt geschreven - amazon is niet minder succesvol omdat ze geen vriendelijke url's gebruiken (waarom kan ik niet gewoon naar http://www.amazon.com/thrillers surfen?), en ook de universiteit leiden geeft geen studenten tekort omdat ze een http://www.leidenuniv.nl/...3?c=43&n=32&garb=54234523 URL-vorm gebruiken.

Als het net zo makkelijk zou zijn om vriendelijke URL's te maken als het is om "gewone" URL's te maken, is het argument "baadt het niet dan schaadt het niet" inderdaad een goede. Maar mijn stelling is dat het zowel op programmeer gebied als voor de gebruiker extra belasting met zich meebrengt. Aan de programmeurs kant is dat niet erg - we noemen dat een uitdaging. Maar ik ben benieuwd of er harde argumenten zijn die "het moeten submitten van het aantal plaatjes per pagina via een form ipv in de get" etc. vergoeilijken

[chris]

wat ik wel een groot nadeel vindt: niet alle hosters ondersteunen het. geen idee of dat bij jou een item is, maar bij mij (MKB) is het zeker wel belangrijk. Als je een CMS voor écht grote bedrijven wil dan is het niet iets om rekening mee te houden.

In plaats van http://www.mijnsite.com/home/producten/blaat/ kan je natuurlijk ook http://www.mijnsite.com/23/ doen, dit is al een stuk vriendelijker, en misschien vindt google het ook nog 's leuk.

offtopic:
het is niet "baadt het niet dan schaadt het niet" maar "baat het niet dan schaadt het niet"

[Verwijderd]

Maar hoe doe je het dan bij een variabel systeem,
waar zelf nog vele pagina's bij gemaakt kunnen worden?

Wat ikzelf nu gebruik is "mijnsite.nl/actie/{id}", waar het {id} de primairy sleutel van de 'pagina' is. Je zou er ook "mijnsite.nl/{unieke paginba identifier}" van kunnen maken, wat nog een extra sleutel opslaan betekend.
Maar de id's worden toch al aangemaakt....

[Mithrandir]

Reveller schreef op 05 september 2004 @ 15:50:
[...]


Nou, deze discussie is in zoverre belangrijk dat het een heel andere aanpak vergt van hoe je je CMS in elkaar hackt. Vriendelijke URL's maken betekent:

• Ik moet in in de .htaccess de http://www.mijnsite.com/vriendelijke/url/pagina herschrijven naar http://www.mijnsite.com?q=vriendelijke/url/pagina

dat hoeft niet met .htaccess. Mod_rewrite kan het krachtiger oplossen:
P&W FAQ - PHP

• Ik moet in de database gaan kijken of er een Alias "vriendelijke/url/pagina" bestaat en zo ja, naar welke pagina die moet verwijzen

Eh, hoeft niet. Implementatie-dingetje. Hoeft niet altijd waar te zijn dus.

• probleem: /hier/een/gastenboek/30 betekent: zoek Alias "hier/een/gastenboek" en laat alle berichten vanaf bericht_id 30 zien. Probleem: hoe weet ik of die 30 niet onderdeel is van de alias zelf?

Door goede rules te maken. Weer implementatie specifiek.

• zonder vriendelijke URL's kunnen de gebruikers van het CMS gewoon een nieuwe pagina aanmaken, deze vullen en klaar. Automatisch wordt de pagina aan de navigatie toegevoegd etc. Met vriendelijke URL's zal de gebruiker ook nog een Alias moeten verzinnen, wat toch een extra belasting is voor mensen die in mijn ervaring niet eens weten wat een URL of adresbalk is (zonder neerbuigend te willen klinken)

De gebruiker hoeft dat helemaal niet. Het kan gewoon de titel zijn. Vaak krijgen door gebruiker toegevoegde berichten overigens een nummer.

Ik ken de artikelen van Lee, maar die zijn vooral vanuit ideologisch oogpunt geschreven - amazon is niet minder succesvol omdat ze geen vriendelijke url's gebruiken (waarom kan ik niet gewoon naar http://www.amazon.com/thrillers surfen?), en ook de universiteit leiden geeft geen studenten tekort omdat ze een http://www.leidenuniv.nl/...3?c=43&n=32&garb=54234523 URL-vorm gebruiken.

Zijn ook zat sites die ze wel gebruiken. Het is iets dat handig KAN zijn, maar geen verplichte feature ofzo.

Als het net zo makkelijk zou zijn om vriendelijke URL's te maken als het is om "gewone" URL's te maken, is het argument "baadt het niet dan schaadt het niet" inderdaad een goede. Maar mijn stelling is dat het zowel op programmeer gebied als voor de gebruiker extra belasting met zich meebrengt. Aan de programmeurs kant is dat niet erg - we noemen dat een uitdaging. Maar ik ben benieuwd of er harde argumenten zijn die "het moeten submitten van het aantal plaatjes per pagina via een form ipv in de get" etc. vergoeilijken

Heb ik zelf geen problemen mee dus

[Verwijderd]

Mithrandir schreef op 05 september 2004 @ 19:21:

dat hoeft niet met .htaccess. Mod_rewrite kan het krachtiger oplossen:
P&W FAQ - PHP

En waar wil je die mod_rewrite rules laten? Juist.
Overigens bestaat er ook nog MultiViews, wat dan eigenlijk weer mijn voorkeur zou hebben.

De gebruiker hoeft dat helemaal niet. Het kan gewoon de titel zijn. Vaak krijgen door gebruiker toegevoegde berichten overigens een nummer.

En als de titel wordt gewijzigd? Cool url's don't change.

Als je dit echt netjes wilt doen, dan moet degene die met het CMS moet gaan werken begrijpen waar iets voor dient. Een "shortcut" of "interne aanduiding" is een principe dat je dus zult moeten uitleggen aan de eindgebruiker. En daar zit hem het hele verhaal, je zult de gebruiker wat instructie moeten geven. En daar is niets mis mee.

Ik wil nog even duidelijk maken, dat een keuze voor een url als /pad/naar/informatie niet meteen alles moet afdwingen. Houd je opties open. Als er variabele parameters bestaan, dan kun je die altijd nog meegeven met de bekende ?param=value&amp...
Kijk dus even naar de MultiViews mogelijkheden in Apache (aangenomen dat je dat gebruikt), dat is volgens mij niet veel programmeerwerk, met een grote speelruimte.

[ Voor 21% gewijzigd door Verwijderd op 05-09-2004 19:30 ]

[Skaah]

Ik heb het zo opgelost: http://www.granaet.nl/index.php/command/photo/id/449/

Zo heb je serverside niets (extra) nodig. Ik vind het zelf redelijk. Je hoeft bij het genereren van links ook geen rekening te houden met de aliassen.

[Soultaker]

Ik vind 'vriendelijke' URL's altijd wel erg praktisch. Ten eerste kun je er altijd makkelijk naar toe navigeren als je een beetje bekend bent met de site in kwestie. Ten tweede (en misschien belangrijker) kun je daardoor makkelijk herkennen waar een URL over gaat. (Als bijvoorbeeld een documenttitel in de URL zit in plaats van een database identifier). Dat is vooral handig als je een boel URL's van dezelfde site hebt en daar onderscheid in wil maken.

Overigens is het wel zaak om je "vriendelijke" URL's consistent door te voeren. Ook is het wijzigen van URL's extra vervelend voor de gebruiker. Ik heb nog maandenlang http://gathering.tweakers.net/listtopics/14 getypt om op dit forum te komen, voordat ik eindelijk de nieuwe URL's geleerd had.

Ik vind trouwens ook dat een URL een uniek document moet identificeren. Hoewel het niet echt verboden is om meerdere URL's naar hetzelfde document te hebben, vind ik het wel een beetje rommelig om allerlei zoektermen en voorkeuren (zoals het aantal berichten per pagina) in de URL te prutsen. Naar mijn mening is dat nu precies waar de query string voor bedoeld is.

[Reveller]

Soultaker schreef op 05 september 2004 @ 19:46:
Ik vind trouwens ook dat een URL een uniek document moet identificeren. Hoewel het niet echt verboden is om meerdere URL's naar hetzelfde document te hebben, vind ik het wel een beetje rommelig om allerlei zoektermen en voorkeuren (zoals het aantal berichten per pagina) in de URL te prutsen. Naar mijn mening is dat nu precies waar de query string voor bedoeld is.

Wat je hier zegt grijpt eigenlijk terug op de vraag: "wat zijn vriendelijke url's?". Voor mij zijn dat url's die
• te "hacken" (zelf te verzinnen) zijn
• geen andere tekens dan letters, cijfers en / hebben - met andere woorden: geen als zodanig aan de wijzen querystring.

Je hebt dus voor een CMS een aantal mogelijkheden. Stel dat de pagina met het id 58 de module "gastenboek" inlaadt, en afhankelijk van de msg variabele, 10 20 of 30 berichten per pagina laat zien:
• mijnsite.com/index.php?id=58&msg=20 -> normale querystring
• mijnsite.com/58/20 -> multiviews of mod_rewrite
• mijnsite.com/gastenboek/20 -> vriendelijke url (mijn idee, zie boven)
• mijnsite.com/gastenboek?msg=20 -> volgens mij wat jij bedoelt

58 is in ieder geval zeker een unieke identifier van de pagina die we zoeken. Als je de beheerder van de site de mogelijkheid geeft een alias (gastenboek) hiervoor aan te maken, staat dit vriendelijker maar is dit nu echt interessant voor een MKB site? Bovendien klopt de url niet meer als de alias veranderd wordt.

ik vind overigens gastenboek/20 of 58/20 vriendelijker staan dan gastenboek?msg=20, omdat je properties via een querystring wil doorgeven (of begrijp ik je nu verkeerd?).

Ik onderken zeker dat leesbare url's handig zijn, vooral bij een forum als GoT. Maar eerlijk: let je ook op andere niet-community sites op de url?

[tomato]

Soultaker schreef op 05 september 2004 @ 19:46:
Ik vind trouwens ook dat een URL een uniek document moet identificeren. Hoewel het niet echt verboden is om meerdere URL's naar hetzelfde document te hebben, vind ik het wel een beetje rommelig om allerlei zoektermen en voorkeuren (zoals het aantal berichten per pagina) in de URL te prutsen. Naar mijn mening is dat nu precies waar de query string voor bedoeld is.

Soultaker bedoelde waarschijnlijk: '...om allerlei zoektermen en voorkeuren (zoals het aantal berichten per pagina) in het pad te prutsen.'

(De URL is het geheel in dit geval.)

En dan ben ik het met hem eens. Stel je een overzicht van zoekresultaten voor. In veel gevallen wil je dit via een GET request toegankelijk maken, dus de truck om maar een POST request te gebruiken gaat niet op. Je wilt ook vriendelijke url's gebruiken, maar naar mijn mening is in dit geval het volgende geen vriendelijke url:

code:

http://site.com/zoeken/pentium+overklokken/2002-2003/sortbydate/onlyclosedtopics

Het wordt hier een zooitje als je een van de middelse argumenten weglaat, of hoe bepaal je in welke volgorde de argumenten moeten staan?
Dit voelt niet natuurlijk omdat deze argumenten helemaal geen boomstructuur opspannen en dat doen paden gewoonlijk wel.

Er is dan ook niets mis mee om het gewoon zo te doen:

code:

http://site.com/zoeken?keyword=pentium+overklokken&sort=sortbydate&dateinterval=2002-2003

Maar wanneer je het over identificerende delen in een URL hebt die wel logischerwijs in een boomstructuur op te nemen zijn moet je dat ook zeker doen:

code:

http://site.com/articles/overclocking/pentiums.html

(Ook over de .html kun je twisten, al is het natuurlijk lang niet zo erg als een .php.)

in plaats van

code:

http://site.com/page.php?id=64509823

[Verwijderd]

Ik gebruik zelf het Open-Source CMS Typo3 al weer voor een tijdje en daar zit ook een dergelijke functie in genaamd "Simulate Static Documents".

Met die functie genereerd hij i.p.v index.php?id=5 ---> contact__42_0.html o.i.d

IK zet deze functie altijd aan, werkt beter voor zoekmachines...

[We Are Borg]

Reveller schreef op 05 september 2004 @ 15:50:
[...]


Nou, deze discussie is in zoverre belangrijk dat het een heel andere aanpak vergt van hoe je je CMS in elkaar hackt. Vriendelijke URL's maken betekent:

• Ik moet in in de .htaccess de http://www.mijnsite.com/vriendelijke/url/pagina herschrijven naar http://www.mijnsite.com?q=vriendelijke/url/pagina

PHP:

<?php
$urlrewrite = explode('/' , $_SERVER['REQUEST_URI']); //array gemaakt
?>

Op deze manier werk ik met mijn CMSje. Ik moet er wel bij zeggen dat het een hobby/amateur projectje is dus misschien is het niet zo'n nette oplossing of zitten er nadelen aan die ik nog niet ben tegengekomen.

Url ziet er dan ook zo uit: www.mijnsite.nl/mainpage/1/3

Werkt prima en ziet er ok uit

[creative8500]

slug

[gorgi_19]

creative8500 schreef op 05 september 2004 @ 21:54:
slug

Leg uit graag?

[Reveller]

@tomato- een goed verhaal, en ik ben het met je eens. Maar ik mis je opstelling ten aanzien van bijvoorbeeld het volgende. Stel, je hebt een module 'persberichten' hebt gemaakt. Elk persbericht krijgt een nummer mee. Het persbericht kan in "normale" layout of in een print-template geladen worden. Laten we ervan uit gaan dat de bezoeker pesbericht 43 wil printen:

• de persberichten module is, via een alias, te vinden op http://site.com/over_ons/persberichten. In dit geval (default mode), retourneert de module een lijst met titels van alle persberichten in de database.
• op http://site.com/over_ons/persberichten/43 is persbericht 43 te vinden
• om te printen, dient de url http://site.com/over_ons/persberichten/43/print te worden gevolgd.

Dit is hoe ik het zou oplossen, maar als ik jullie goed begrijp behoort "43" tot de directory structuur, en dus is http://site.com/over_ons/persberichten/43 een goede url. Maar omdat "print" geen verband houdt met de directory structuur, mag dit: http://site.com/over_ons/persberichten/43/print niet? Hoe zou jij dan die url vormgeven? Ik moet toch via een GET uitlezen dat ik het print-template moet inladen, toch? Bedoel je dan iets als:

code:

http://site.com/over_ons/persberichten/43$print

waarbij duidelijk is dat "print" niet tot de directory logica wordt gerekend? Of zou je middels een POST duidelijk maken dat de gebruiker wil printen? Volgens mij gaat dat niet, want dan zou je alle <a href=""> tags (waarmee je alleen een GET request kan aanroepen) vervangen door <input type="button">s ofzo...

Ik hoop dat ik duidelijk ben?

En om dicht bij de discussie te blijven: http://site.com/articles/overclocking/pentiums.html is een fraaie url, maar in hoeverre is dat __opzich__ belangrijk voor een MKB site? Wat is je inschatting?

@We Are Borg - zo doe ik het nu ook:
• mbv mod_rewrite herschrijf ik elke url naar de vorm http://site.com/index.php?q=mooi/pad/naar/pagina
• en dan $args = explode("/", $_GET['q']);

Maar het grootste nadeel hiervan is dat je nooit zeker bent in welke volgorde je variabelen worden aangeboden. Ik moet er nu maar vanuit gaan dat $args[2] de variabele "berichten_per_pagina" representeert. Dat is allemaal wat minder veilig naar mijn gevoel dan dat je rechtstreeks http://site.com/index.php...a&berichten_per_pagina=20. Want hoe weet nu wwat hiermee bedoelt wordt: http://site.com/producten/groep/20/10 -> heeft de gebruiker een alias producten/groep/20 aangemaakt en moet ik 10 producten per pagina laten zien of heeft de gebruiker een alias producten/groep aangemaakt, en is die 20 het aantal producten per pagina? Dat moet je eerst allemaal gaan checken en dat kost weer queries / load / tijd etc. En daar ben ik dus wat bang voor...

[ Voor 24% gewijzigd door Reveller op 05-09-2004 22:07 ]

[David]

'Lelijke' URLs zijn gewoon een kwestie van gemak. Nette URLs zijn altijd beter, maar het kost meer moeite om die te implementeren.

Ik vind het het uurtje extra werk bijna altijd wel waard. Kijk naar sites als die van de Postbank: ik typ www.postbank.nl in en word doorgestuurd naar http://www.postbank.nl/in...,2809,1859_103763,00.html . De 'lenen'-pagina is te vinden op http://www.postbank.nl/in...,2817,1859_175186,00.html. Op de een of andere manier komt dit ontzettend slordig over. Een implementatie als deze laat gewoon weer de incompetentie van de webbuilders zien.

[Verwijderd]

Voor SES urls kun je onderstaande coldfusion conversie evt. gebruiken, dit gebruik ik als optie in mijn cms, maar het staat standaard uit.

PHP:

01:function SES()
02:{
03:  var UrlVars=ReReplaceNoCase(trim(cgi.Path_Info), '.+\.cfm/? *', '');
04:  var loopcount=ListLen(urlvars, '/');
05:  var potential="";
06:  if (cgi.script_name EQ cgi.path_info)
07:    return 0;
08:  for(i=1;i LTE loopcount; i=i+1)
09:  {
10:    potential=trim(listgetat(UrlVars, i, '/'));
11:    if (REFindNoCase('^[a-z][a-z0-9_]*:.*', potential))
12:      SetVariable('Url.'&listfirst(potential, ':'), listlast(potential,
':'));
13:  }
14:  return 1;
15:}

[bRight]

Verwijderd schreef op 05 september 2004 @ 19:27:
En waar wil je die mod_rewrite rules laten? Juist.
Overigens bestaat er ook nog MultiViews, wat dan eigenlijk weer mijn voorkeur zou hebben.

offtopic:
rewrite rules kunnen toch ook in de virtualhost?

[tomato]

Reveller schreef op 05 september 2004 @ 21:59:Maar omdat "print" geen verband houdt met de directory structuur, mag dit: http://site.com/over_ons/persberichten/43/print niet? Hoe zou jij dan die url vormgeven?

Het probleem hier is dat je dezelfde data vraagt in verschillende vormen. In dit geval zou ik sowieso gewoon voor een aparte printstylesheet kiezen (en dan heb je uberhaupt geen extra url nodig), maar er zijn meer van dit soort situaties. Sommige documenten zijn bijvoorbeeld in HTML en PDF beschikbaar. Of HTML en XHTML.
Of enigzins hetzelfde verhaal geldt voor verschillende taalversies en ingewikkeld wordt het wanneer beiden spelen.

Je kunt hier op heel veel manieren mee omgaan. Vaak zie je dingen als 'pentiums.html.en' en 'pentiums.html.de', waarbij een van de twee geserveerd wordt wanneer er om 'pentiums.html' gevraagd wordt. Je zou dit ook wel in een boomstructuur kunnen verwerken; je hebt een knoop 'pentiums' met daaronder knopen 'engels' en 'nederlands'. Een van de twee kun je dan de directory index maken. Dat komt op hetzelfde neer.

Het wordt nog interessanter als je op de server zelf aan content negotiation gaat doen. Stel je hebt een Nederlandse, een Duitse en een Engelse versie van een document. Pietje vraagt het document op ('pentiums.html') en in zijn request headers staat dat hij Nederlands prefereert. Je kunt hem dan automatisch 'pentiums.html.nl' serveren.
Ingewikkeld wordt het wanneer Pietje een spelfout op die pagina ziet en de link doorstuurt naar zijn vriendje in Duitsland. Deze bekijkt de pagina, krijgt automatisch de Duitse versie voorgeschoteld en kan de spelfout natuurlijk niet vinden. Is dit nou nog handig of is het niet wenselijk?


Wat denk je overigens van het volgende? Deze twee URL's zou je beide kunnen gebruiken voor een overzichtspagina van ervaringen van overklokkers van Pentiums:

code:

http://site.com/comments/overclocking/pentiums.html

code:

http://site.com/overclocking/pentiums/comments.html

De structuur van je website kun je vaak op veel verschillende manieren in elkaar zetten. Persoonlijk vind ik in dit voorbeeld de tweede mogelijkheid 'natuurlijker'. Maar zeker wanneer de paden geen absoluut pad in het filesystem van de server representeren ga je dit vaak af laten hangen van implementatie-technische argumenten. Waarvan ik denk dat je ze zo licht mogelijk moet laten wegen.

Sowieso is het belangrijk je in je URL opbouw absoluut niet te laten leiden door je implementatie. Na 1 of 2 jaar komt er een ander bedrijf het onderhoud van de website overnemen, dat alle PHP scripts vervangt door een .NET implementatie. Het zou wel zo aardig zijn als alle links op je website, vanaf andere websites (en zoekmachines) en in de bookmarks van mogelijke klanten nog gewoon werken

[man-o-script]

Zelf gebruik ik, sinds ongeveer een jaar, ook altijd vriendelijke URL's.
Ben in samenwerking met een site bezig geweest een hoge ranking te krijgen in Google en dat is mede daardoor gelukt. (voor het woord 'afvallen' op 1 gekomen )

Google geeft zelf ook als punt dat hij sites met onvriendelijke urls (index.php?p=3&i4) ziet als dynamische sites waardoor hij om de server niet te overbelasten niet iedere keer alle pagina's zal spideren.
Dit heeft dus wel degelijk een belangrijke invloed op je pagerank e.d. en het 'erven' daarvan van andere pagina's. Zeker ook omdat je keywords kunt laten terugkomen in je URL die gezien worden als een directory of bestandsnaam.

Meer info, zie: http://www.google.com/webmasters/2.html

Your pages are dynamically generated. We are able to index dynamically generated pages. However, because our web crawler can easily overwhelm and crash sites serving dynamic content, we limit the amount of dynamic pages we index.

Niet altijd is het even duidelijk, op een andere site bijvoorbeeld:
http://www.breedbandwinkel.nl/details/25/57/9
Maar nog steeds vind ik dit netter staan als bijvoorbeeld details.php?id1=25&id2=27&id3=9

Deze site is later ook omgebouwd naar een 'vriendelijke url' site, waarmee meteen alle nieuwsartikelen e.d. werden geindexeerd, vandaar nu de 1.730 pagina's in Google.

[Orphix]

DiMension schreef op 05 september 2004 @ 22:09:
Ik vind het het uurtje extra werk bijna altijd wel waard. Kijk naar sites als die van de Postbank: ik typ www.postbank.nl in en word doorgestuurd naar http://www.postbank.nl/in...,2809,1859_103763,00.html . De 'lenen'-pagina is te vinden op http://www.postbank.nl/in...,2817,1859_175186,00.html. Op de een of andere manier komt dit ontzettend slordig over. Een implementatie als deze laat gewoon weer de incompetentie van de webbuilders zien.

Toch kan je je afvragen of de postbank wel wil dat mensen direct linken naar content op de pagina. De vele voorbeelden die hier worden genoemd zijn tweakers.net achtige sites. Het is vrij gemakkelijk om hier een archief bij te houden; dit is immers een lijst van alle newsposts.

Maar neem nu een gemiddelde bank. Geen verzekeringspakket, lening, rentepercentage, of beleggingspakket zal lang hetzelfde blijven. Dit verandert jaarlijks, zoniet maandelijks. Het is denk ik ook niet eens wenselijk dat mensen rechtstreeks de brochure over het IT-beleggingsfonds van 2001 kunnen inzien.

In een geval zoals de postbank zullen ze dus al heel algemeen hun urls moeten gaan benoemen: postbank.nl/verzekeringen, postbank.nl/fondsen, etc. Hoeveel meerwaarde heeft dit dan nog t.o.v. de gedachte dat mensen via de portal (beginpagina) hun informatie moeten opzoeken?

Oftewel, ik denk dat de structuur ook moet passen bij de site. Het abstractieniveau van je urls moet passen bij de content die je aan kan blijven bieden op langere termijn. Als het abstractieniveau hoog is, zal je niet op langere termijn 'vriendelijke' urls aan kunnen bieden voor veel van je content en is de meerwaarde van die vriendelijke urls ook gering.

[Reveller]

man-o-script schreef op 05 september 2004 @ 23:58:
Niet altijd is het even duidelijk, op een andere site bijvoorbeeld:
http://www.breedbandwinkel.nl/details/25/57/9
Maar nog steeds vind ik dit netter staan als bijvoorbeeld details.php?id1=25&id2=27&id3=9

Maar een deel van mijn pleidooi is dus dat die vriendelijke URL moeilijker te valideren is dan die niet-vriendelijke URL. Stel dat iemand (reden doet er niet toe)

code:

http://www.breedbandwinkel.nl/details/25/57/9

omtovert in

http://www.breedbandwinkel.nl/details/25/9

Dan is het voor jou op de server maar de vraag wat die variabelen representeren: is het laatste ID van de URL afgehaald, dan betekent dat:

code:

id1 = 25
id2 = 9

Maar het kan ook zijn dat id2 ertussenuit is gehaald. Of verschoven. De volgende zijn ook mogelijkheden:

code:

id2 = 25
id3 = 9

id1 = 25
id3 = 9

Wat ik maar wil zeggen, is dat als er iets vout zou gaan met je URL genereren, of als de gebruikers om wat voor reden dan ook aan je url prutst, je meer kans hebt op een goede afhandeling. Stel nu weer dat de 57 ertussenuit valt:

code:

details.php?id1=25&id2=57&id3=9 wordt dus
details.php?id1=25&id2=&id3=9

Dan weet ik nu vrij zeker dat 25, id1 is en 9 id 3 is en dat er iets fout is met id2. Ik kan dan beter een foutafhandeling implementeren dat bij de nette url, of is dit te ver doorgedacht?

[Verwijderd]

Misschien een leuke aansluitende discussie:

stel je kunt aan knopen in je 'url-boom' verschillende applicaties hangen, zoals (ik noem maar ff wat voorbeeldjes):

- een article op basis van page-id (reusable views dus zegmaar)
- een folder-applicatie die een opsomming
- een login pagina (een script dat via 1 unieke url bereikbaar is)
- shopping cart
- productcategory view

Hoe ga je dan om met title/label-generation. Uiteraard is dit simpel op de betreffende pagina zelf (voor de pagetitle). Maar voor links/menus is dit toch iets complexer. En je wilt toch zeker niet overal waar je naar een bepaalde pagina linkt de naam van de pagina veranderen als deze wijzigt (moet wel centraal blijven).

In principe zou je je url-node een title kunnen geven...
Een andere mogelijkheid is om elke pagina een 'article' te maken waaraan een title hangt, en dat je daarin met bepaalde tags scripts kunt embedden. Een geinig voordeel is dat je dan weer via je article editor teksten boven en onder een reusable script kunt zetten.

Ik hoor graag hoe jullie hier over denken alhoewel ik nu begin te twijfelen of dit niet een nieuw topic had moeten worden

[Not Pingu]

Wat vaak gebruikt wordt is dat een pagina zelf slechts identificerend is, en dat de inhoud van deze pagina daar los van wordt gedefinieerd.
Je hebt dus 2 tabellen:

tblPaginas
--------------
Id
Titel
Reference


tblPaginaOnderdelen
-----------------------------
Id
PaginaId
Type (= artikel/fotoboek/nieuwsoverzicht/etc.)
Inhoud (= welk artikel/fotoboek/nieuwsbericht/etc.)

Zo heeft 1 pagina meerdere onderdelen maar kun je door de referentie van de pagina deze altijd zoeken. Die referentie (of een extra veld MenuTitel) gebruik je ook voor weergave in menu's. Je geeft de ID's van de inhoud dus per pagina op, die hoef je niet meer in de URL op te nemen.

[Verwijderd]

Ik snap niet zo goed waarom er zo ontzettend moeilijk over wordt gedaan.

Maak pagina aan
Genereer een mapping of laat de gebruiker zelf kiezen
Maak evt. een directory structuur, met een listener erin
Sla mapping op

.. erm.. klaar?

[DaCoTa]

Reveller schreef op 05 september 2004 @ 15:01:
Na veel lezen vond ik twee belangrijke argumenten om op de eerste manier te werk te gaan:
• deze urls worden goed geindexeerd door zoekmachines. URL's met een ? of & worden niet of minder goed geindexeerd;

Misschien is beter geïndexeerd een betere manier om dit uit te drukken. Als google keywords in de url tegenkomt, indexeerd hij de pagina's beter en sneller. Dit uit praktijkervaring van een CMS bij de internetafdeling van een groot nederlands dagblad. De hoeveelheid geïndexeerde pagina's bij google steeg in een paar maanden met een veelvoud nadat we vriendelijke url's ingevoerd hadden. Dit is op meerdere subsites doorgevoerd en we zagen daar eenzelfde soort stijging.

[ Voor 3% gewijzigd door DaCoTa op 06-09-2004 14:47 ]

[man-o-script]

Reveller schreef op 06 september 2004 @ 10:14:
[...]


Maar een deel van mijn pleidooi is dus dat die vriendelijke URL moeilijker te valideren is dan die niet-vriendelijke URL. Stel dat iemand (reden doet er niet toe)

code:

http://www.breedbandwinkel.nl/details/25/57/9

omtovert in

http://www.breedbandwinkel.nl/details/25/9

Dan is het voor jou op de server maar de vraag wat die variabelen representeren: is het laatste ID van de URL afgehaald, dan betekent dat:

code:

id1 = 25
id2 = 9

Maar het kan ook zijn dat id2 ertussenuit is gehaald. Of verschoven. De volgende zijn ook mogelijkheden:

code:

id2 = 25
id3 = 9

id1 = 25
id3 = 9

Wat ik maar wil zeggen, is dat als er iets vout zou gaan met je URL genereren, of als de gebruikers om wat voor reden dan ook aan je url prutst, je meer kans hebt op een goede afhandeling. Stel nu weer dat de 57 ertussenuit valt:

code:

details.php?id1=25&id2=57&id3=9 wordt dus
details.php?id1=25&id2=&id3=9

Dan weet ik nu vrij zeker dat 25, id1 is en 9 id 3 is en dat er iets fout is met id2. Ik kan dan beter een foutafhandeling implementeren dat bij de nette url, of is dit te ver doorgedacht?

Daar heb je wel gelijk in, het is maar net hoever je het wilt doorvoeren natuurlijk.
In dit geval (http://www.breedbandwinkel.nl/details/25/57/9) is het in principe duidelijk.
De getallen achter de url zijn de id's van de abonnementen, indien je hier er 1 weghaald, zie je die ook niet meer. Wissel je ze van volgorde dan worden ze in die gekozen volgorde weergegeven.
Dit gaat natuurlijk niet voor alle sites op, maar in dit geval komt het toevallig goed uit.

Ik zorg er ook altijd wel voor dat variabelen weggelaten kunnen worden zonder dat je dan vreemde errors voor je krijgt.
Als ik dat allemaal afweeg tegen de goede indexering door o.a. Google, dan maak ik er maar al te graag gebruik van

Denk dat zeker ook je doelgroep (MKB) het steeds belangrijker gaat vinden om goed gevonden te kunnen worden via de zoekmachines.
En het is zeker mogelijk zonder al te veel ingrepen.

Als je toch een CMS aan het bouwen bent, kun je het (zeker ook voor het hergebruik) maar beter meteen goed doen!

[Verwijderd]

Als je echt SES urls gaat gebruiken, dwz op de dynamische manier dan zul je toch aan zijn gewezen op een standaard startpunt parameter in je url om parameters van directory te onderscheiden. Bijv. "go".

[Verwijderd]

Ik maak zelf gebruik van "vriendelijke" url's, en daarvoor heb ik de volgende redenen.
• Betere indexering met bv Google
• Netter voor de gebruiker
• Dynamisch te scripten

Ik wil vooral ingaan op het dynamische scripten van de URL's, hiervoor maak ik gebruik van mod_rewrite. Ik heb een website, daarin heb ik 3 programmas (nieuws, reviews, faq) draaien vanuit 1 script (f_ran.php). De opbouw van alle programma's dien ik wel in mijn htaccess OF httpd.conf te zetten, maar dan vind ik het wel mooi werken.
Ik heb afgesproken met mezelf de volgende standaard te hanteren voor mijn ran (zo benoem ik dat script).

code:

www.site.nl/news/1/4/deletepage/y 
        => www.site.nl/f_ran.php?id=1&page=4&do=deletepage&sure=yestype=news

www.site.nl/news/1/4/deletepage 
        => www.site.nl/f_ran.php?id=1&page=4&do=deletepage&type=news

www.site.nl/news/1/4/edit 
        => www.site.nl/f_ran.php?id=1&page=4&do=edit&type=news

www.site.nl/news/1/4 
        => www.site.nl/f_ran.php?id=1&page=4&type=news

Opzich heb je hierdoor wel de gehele werking van de site in èèn file (htaccess/httpd.conf), daardoor kan ik veel sneller zien welke request waar naartoe zou gaan. Ik heb nou wel een htaccess file van 4kb, omdat ik alle mogelijke url type's (verschillende scripts) moet rewriten, maar dat werkt perfect.
Voor mijn RAN systeem heb ik 8 regels ModRewrite per soort (nieuws, reviews, faq), maar het werkt zeker goed.

Ook als je er voor zou kiezen om bij een website geen ModRewrite te gebruiken dan kan je dat doen. Je verwijderd je htaccess file en herschrijft even je templates.

Echt grote query's als bijvoorbeeld een search die zal ik dmv een querystring GETten, maar waardes die klein zijn (zoals ik hier boven gebruik) dat moet kunnen.

[man-o-script]

Je kan ook altijd nog MultiViews gebruiken en alles in een Array dumpen, opzich een minder nette oplossing vind ik, maar in sommige situaties ook erg handig.

[Verwijderd]

man-o-script schreef op 06 september 2004 @ 20:28:
Je kan ook altijd nog MultiViews gebruiken en alles in een Array dumpen, opzich een minder nette oplossing vind ik, maar in sommige situaties ook erg handig.

Je moet dan wel rekening houden als je op een Windows computer van Multiviews gebruik wilt maken, dat PHP als apache module moet draaien en niet als CGI.
Bij een standaard installatie staat php op cgi en kan je het onder een standaard php install op Windows niet draaien. Dit is de reden dat ik mod_rewrite prefereer BOVEN multiviews

[ Voor 4% gewijzigd door Verwijderd op 06-09-2004 20:35 ]

[man-o-script]

Hmm ik gebruik altijd XAMPP onder windows om op te testen, lekker makkelijk en met wat kleine configuratie aanpassingen draait het allemaal perfect:
http://www.apachefriends.org/en/xampp-windows.html (waarin multiviews dus wel werken)

[djluc]

http://www.breedbandwinkel.nl/details/25/57/9

Ik vind vriendelijke URL in dit geval sowieso al niet relevant: de id's van de abbos zijn niet voor de klant relevant, het is daarom gewoon onzin om deze "vriendelijk" weer te geven want de klant kan er toch niets mee. Dan nog liever iets als: http://www.breedbandwinke...ADSLLite/tiscaliADSLsmart enzovoorts. Dan staan de keywords tenminste in de url.

Overigens wordt een dergelijke pagina toch al zeer moeilijk gevonden door google omdat de pagina url op basis van userinput wordt samengesteld.

[Reveller]

djluc schreef op 07 september 2004 @ 14:45:
[...]
Ik vind vriendelijke URL in dit geval sowieso al niet relevant: de id's van de abbos zijn niet voor de klant relevant, het is daarom gewoon onzin om deze "vriendelijk" weer te geven want de klant kan er toch niets mee. Dan nog liever iets als: http://www.breedbandwinke...ADSLLite/tiscaliADSLsmart enzovoorts. Dan staan de keywords tenminste in de url.

Maar los van het feit of het relevant is of niet, is het toch altijd mooier / beter om

code:

http://www.breedbandwinkel.nl/21/43/56

te hebben in paats van

code:

http://www.breedbandwinkel.nl/?id1=21&id2=43&id3=56

Het zou onzin zijn om delen van je site wel en andere delen niet met (relatief) vriendelijke URL's te bouwen denk ik.

Ik zit eigenlijk nog te wachten op iemand die de absolute voordelen van niet-vriendelijke URL's kan geven boven vriendelijke URL's - met andere woorden: wat zijn de voordelen van

code:

http://www.breedbandwinkel.nl/?id1=21&id2=43&id3=56

boven

code:

http://www.breedbandwinkel.nl/21/43/56

Dat is ook een reden waarom ik deze discussie gestart ben. Ik neig ernaar om nette / vriendelijke URL's (http://www.breedbandwinkel.nl/21/43/56) in mijn CMS te bouwen, maar overzie wellicht de voordelen van http://www.breedbandwinkel.nl/?id1=21&id2=43&id3=56. Argumenten, iemand?

Overigens heb ik nog een probleem waar ik niet uitkom. Ik heb de volgende tabel genaamd "nodes" (alleen relevante delen):

code:

+-----+----------------------+--------+
| nid | alias                | module |
+-----+----------------------+--------+
| 17  | contact              | 2      |
+-----+----------------------+--------+
| 18  | contact/gastenboek   | 1      |
+-----+----------------------+--------+
| 22  | nieuws/persberichten | 5      |
+-----+----------------------+--------+

Het idee is als volgt:
• als een gebruiker een nieuwe pagina ("node" --> nid) aanmaakt, en hier een module aan toekent (2 = artikel, 1 = gastenboek, 5 = persberichten), kan de pagina, bijvoorbeeld nid 22, benaderd worden via de link: http://site.com/22.
• optioneel kan de gebruiker zelf een alias aanmaken voor een pagina. Deze gebruiker heeft ervoor gekozen dat de persberichten-pagina ook via http://site.com/nieuws/persberichten te benaderen is.
• Hoe werkt dit? Met mod_rewrite zet ik http://site.com/nieuws/persberichten om in http://site.com/index.php?q=nieuws/persberichten, ik zoek in de database naar een match en zie dat ik nid = 22 moet laten zien

Nu mijn mijn probleem. De persberichten module gebruikt een integer input. Als er geen id gegeven wordt, laat de module de titels van alle persberichten zien. Wordt er wel een id gegeven, wordt het betreffende bericht uit de database getrokken en getoond. Dat gaat nu als volgt:
• http://site.com/nieuws/persberichten$22 wordt omgezet in http://site.com/index.php?q=nieuws/persberichten$22.
• Ik explode op $, doe met $url[0] wat ik hierboven deed. $url[1] (waarde: 22) werk als input voor de module.

wat ik graag zou willen is dat ik hetzelfde kan bereiken met de url http://site.com/nieuws/persberichten/20. Het probleem is dat ik nu geen onderscheid heb tussen wat alias is en wat als input voor de module geldt. Met andere woorden: is "nieuws/berichten/20" in zijn geheel een alias? Of is "nieuws" de alias en zijn "berichten" en "20" allebei input? Probleem is dat ik niet weet wat de gebruiker als alias opgeeft. Als ik weet dat elk derde element (hier: 20) input is, is er geen probleem. Maar dit loopt alweer stuk als de gebruiker als alias over_ons/nieuws/persberichten invult. Ik krijg dan over_ons/nieuws/persberichten/20. Nu is het vierde element de input. Omdat ik niet (zoals nu) een ondersheidend teken ("$") aanbreng tussen alias en input variabelen, is het bijna niet te bepalen wat wat is, zonder er een berg queries tegenaan te gooien. Heeft iemand ideeen hoe ik dit zou kunnen oplossen?

[Not Pingu]

@Reveller:

2 mogelijkheden: of je bepaalt dat een stuk URL dat naar bepaalde data verwijst (bijv. een persbericht-ID) altijd een leesteken oid voor zich heeft, een _ ofzo.

Je kunt ook bepalen dat het laatste stuk uit de URL een data-ID is mits dit volledig numeriek is. Daarbij bepaal je dat een alias nooit met een getal kan beginnen, en je bent klaar.

[man-o-script]

djluc schreef op 07 september 2004 @ 14:45:
[...]
Ik vind vriendelijke URL in dit geval sowieso al niet relevant: de id's van de abbos zijn niet voor de klant relevant, het is daarom gewoon onzin om deze "vriendelijk" weer te geven want de klant kan er toch niets mee. Dan nog liever iets als: http://www.breedbandwinke...ADSLLite/tiscaliADSLsmart enzovoorts. Dan staan de keywords tenminste in de url.

Overigens wordt een dergelijke pagina toch al zeer moeilijk gevonden door google omdat de pagina url op basis van userinput wordt samengesteld.

Als je een sitemap maakt met alle mogelijkheden ben je hier ook al vanaf, die zal hij allemaal indexeren.
Op dit moment staan ook alle losse abonnementen in Google, bovendien nog aardig wat combinaties.