[CMS?] Vriendelijke urls / 404 redirect?

[BoomSmurf]

Ik was even aan het denken over CMS'n en vriendelijke urls voor de gebruikers. Niet zo zeer dat ze altijd een mooie url zien, maar dat ze bijvoorbeeld www.mijnsite.nl/blogs/henk/vakantiecanada in kunnen typen en dat ze dan goed uitkomen.

Maar goed, als je dus een CMS hebt, dan zal deze waarschijnlijk een logische boomstructuur voor navigatie hebben. Nu zie je vaak bij CMS'n, ik zal als voorbeeld even phpNuke nemen, dat er verschillende php files voor verschillende onderdelen aangeroepen worden. Bijvoorbeeld /module.php?name=blog&person=henk&article=vakantiecanada . Nu ben ik zelf dus aan het brainstormen over een CMS (zoals een wijze GoT'er ooit zei: iedereen moet ooit een eigen CMS gebouwd hebben) en voor de manier hoe ik het op wil zetten zal alles via /index.php lopen.

En nu komt de huuc huuc barbatruc, ik dacht als je nu een custom error document voor 404 neemt, en daar de request_uri afvangt (die overeenkomt met de interne navigatieboom) en die doorgeeft aan /index.php dan ben je er toch?

M'n water zegt me echter dat dit geen goede oplossing is. Waarom, kan ik zo niet zeggen. Ik heb het op die manier ook nog nooit gezien (wat natuurlijk niet betekend dat sommigen het niet zo hebben). Het eerste wat je vaak hoort als je het hier over hebt is mod_rewrite - maar daar zal niet iedereen toegang toe hebben. Dus de vraag is, is dit een acceptabele oplossing of not-done en zo niet waarom niet?

[ Voor 6% gewijzigd door BoomSmurf op 28-06-2005 13:59 ]

[Verwijderd]

DotNetNuke is een portal/CMS systeem die dat kan. Die werkt met 'friendly urls'. Je kunt zelf portals maken als fotos.website.nl of www.website.nl/fotos/.

Daarnaast is DotNetNuke een fantastisch product

[BoomSmurf]

Err... en dit heeft op welke manier betrekking op de OP ?

[ Voor 3% gewijzigd door BoomSmurf op 28-06-2005 14:08 ]

[SchizoDuckie]

Ik vind het zelf op zich wel een goeie oplossing, (gebruik het ook in een aantal sites)

het enige nadeel wat ik er aan zou kunnen zien is dat sommige stats scripts er niet mee om zouden kunnen gaan.

Let wel op trouwens dat je voor verschillende webservers verschillende 404 scripts moet koken. IIS werkt net weer iets anders dan apache

[NMe]

Sorry? Lijkt me geen goed plan. Je wil 404 misbruiken om je gebruikers alsnog naar de goeie pagina te linken? Er wordt intussen wel mooi een errorcode opgeworpen, en daarom is het gewoon een vieze oplossing. Wat is er mis met een gewone rewriterule m.b.v. mod_rewrite?

[BoomSmurf]

1) Als je niet je eigen server draait heb je niet altijd mod_rewrite beschikbaar
2) WIMP heeft volgens mij niet eens een mod_rewrite (kan het mis hebben hoor, ben geen IIS expert)
3) Waarom moeilijk doen als het makkelijk kan?

Ik bedoel maar, als die plek in de navigatieboom niet bestaat kan ie toch nog altijd zeggen dat die pagina niet bestaat? Nu wordt er inderdaad een error code verkracht maar buiten dat je een melding in je logs krijgt zie ik niet wat hier een probleem aan is.

[Verwijderd]

Je kunt toch ook gewoon aliasen in zo'n "boom" hangen...

[megamuch]

Drupal doet het via url alias in te geven voor elke pagina. (www.drupal.org) Een pagina is dus op te roepen via http://www.bla.com/node/1/2/3/4/etc/ en daar kan je http://www.bla.com/melp van maken dmv url alias.

Hoe het precies intern in php werkt bij drupal weet ik (nog) niet. Ben er zelf ff mee aan het spelen, maar volgens mij gebruikt drupal een andere manier dan 404 verkrachten.

[Verwijderd]

BoomSmurf schreef op dinsdag 28 juni 2005 @ 16:03:
1) Als je niet je eigen server draait heb je niet altijd mod_rewrite beschikbaar

3) Waarom moeilijk doen als het makkelijk kan?

1) Scoor een server waarbij je dat wel hebt. Ik ken maar weinig hosts die dit niet bieden eigenlijk.
3) Om wat -NMe- al zeide. Onder andere bots van zoekmachines kunnen door die 404 de verkeerde conclusie trekken, namelijk dat de pagina niet bestaat. Het is gewoon een slechte oplossing voor een probleem dat redelijk makkelijk op te lossen is met mod_rewrite en zoveel moeilijker is dat helemaal niet.

Neem bijvoorbeeld de reviews sectie van Tweakers. De links zien er allemaal zo uit: reviews: Dutch Power Cows. Die 123 kan je met 1 mod_rewrite regel eruit plukken en doorsturen naar een script dat op zijn beurt het artikel uit de db haalt. 1 regeltje!

[Superdeboer]

Je zou het ook kunnen doen door multiviews in Apache te gebruiken in combinatie met:

PHP:

list ($var1, $var2, $var3, $var4) = explode("/", substr($_SERVER['PATH_INFO'],1));

in je index.php.

Als jij weet welke variabele je op welke plaats kunt verwachten (bijvoorbeeld in geval www.server.tld/index/arti...rtikel-over-mooie-linkjes) dan kun je die in het script eruit zoeken. Alles loopt dan altijd via je index.php, dus die /index blijft daar altijd, op elke pagina. In het bovenstaande voorbeeld is 'articles' dan $var1 en 'dit-is-een-artikel-over-mooie-linkjes' is $var2. Daar kun je dan in de rest van je scripts mee doen wat je wilt.

Dus 'dit-is-een-artikel-over-mooie-linkjes' gooi je dan bijvoorbeeld in een query om dat betreffende artikel op te halen; ik noem maar wat.
React werkt op dezelfde manier als ik me niet vergis, en de Frontpage ook.

Er is echter één groot nadeel hieraan... en dat is dat Google nog wel eens een probleem hiermee wil hebben, doordat sommige versies van de Googlebot geen */* in de acceptheader meesturen. Dan gaat het fout, want dan zoekt Google naar een text/html mimetype, terwijl Apache terug gaat zoeken (vanwege multiviews) en uitkomt bij index.php. Apache komt dus heel lief application/x-httpd-php als mimetype tegen voor die file, en denkt dan: heej, dat kan ik niet afleveren, want die wordt niet geaccepteerd... dus retourneert een 406 aan de Googlebot. Vervolgens wordt geen van je pagina's echt geïndexeerd. Meer informatie over dit probleem vind je hier: http://www.gerd-riesselma...re-of-apaches-multiviews/

[Not Pingu]

Verwijderd schreef op dinsdag 28 juni 2005 @ 18:02:
[...]


1) Scoor een server waarbij je dat wel hebt. Ik ken maar weinig hosts die dit niet bieden eigenlijk.

Ik kan me goed voorstellen dat TS een fullproof oplossing wil hebben. BIjv. als je je CMS gaat gebruiken bij het opzetten van websites voor klanten. Dan krijg je te maken met een brede variatie aan hosts en vaak maken bedrijven van dusdanig goedkope (= crappy) hosts gebruik dat je problemen krijgt als je teveel eisen stelt.

Afhankelijk van in welk marktsegment je zit, is het dan ook geen optie om je klant te vertellen dat ie moet overstappen naar een andere host.

[Verwijderd]

Dat is begrijpelijk. Echter, je klant een systeem aanbieden dat bij elke request standaard een 404 uitbraakt voordat-ie een pagina geeft vind ik een stuk erger en naar mijn weten biedt zelfs de meest cheap-ass host controle over .htaccess tegenwoordig. Overigens heeft ook niet elke host custom 404 pagina's of zelfs PHP ondersteuning dus dat zou je dan eigenlijk ook niet kunnen gebruiken.

[Not Pingu]

Verwijderd schreef op dinsdag 28 juni 2005 @ 21:29:Overigens heeft ook niet elke host [..] PHP ondersteuning dus dat zou je dan eigenlijk ook niet kunnen gebruiken.

Maar dat is dan ook minder makkelijk te overkomen voor een CMS heb je hoe dan ook actieve hosting nodig.

En tsja, je zult maar tegen een hoster aanlopen die geen mod_rewrite biedt. In mijn ervaring weten klanten er vaak de meest vage cheape hostingbedrijven uit te pikken waarbij communicatie daarheen ook nog moeilijk is. Of ze hebben met andere bedrijven een gezamenlijke hosting waarover je geen invloed uit kunt oefenen.

Het voordeel van PHP is dan wel dat het op hoog niveau in Apache kan liggen rommelen. Ik werk zelf met ASP.NET en daar wordt niet elke request naar de webserver afgehandeld door je ASP.NET app. Daar moet je dus een verwijzing naar een ASP.NET bestand opnemen voordat je er vanuit je app iets mee kan doen.

[SchizoDuckie]

Even voor de volledigheid, iedereen blaat hier over .htaccess, multiviews en mod_rewrite

maar wat nou als je deze functionaliteit op een IIS server wil hebben zonder 404s?
Iemand opties?

[phYzar]

Verwijderd schreef op dinsdag 28 juni 2005 @ 18:02:
3) Om wat -NMe- al zeide. Onder andere bots van zoekmachines kunnen door die 404 de verkeerde conclusie trekken, namelijk dat de pagina niet bestaat. Het is gewoon een slechte oplossing voor een probleem dat redelijk makkelijk op te lossen is met mod_rewrite en zoveel moeilijker is dat helemaal niet.

Ik heb de methode wel eens gebruikt en het werkt perfect, met elke zoekmachine ook. Wat je daarvoor wel moet doen is natuurlijk een header 200 bijvoegen zodat de opvragende partij doorkrijgt dat alles goed is (als je dat niet doet krijg je dus een 404 en sommige browsers willen dan ook nog wel eens een eigen errorpagina geven ipv jouw pagina)

[Not Pingu]

SchizoDuckie schreef op woensdag 29 juni 2005 @ 15:16:
Even voor de volledigheid, iedereen blaat hier over .htaccess, multiviews en mod_rewrite

maar wat nou als je deze functionaliteit op een IIS server wil hebben zonder 404s?
Iemand opties?

IIS kent niet dit soort functies out of the box bij mijn weten. Je zou wel een 3rd party ISAPI filter kunnen installeren ofzo. Wel is het zo dat IIS niet net als Apache onderliggende processen functies geeft op webserver niveau. Je kunt niet elke URL laten afvangen door een PHP/ASP/ASP.NET applicatie zonder dat in de URL verwezen wordt naar een PHP/ASP/ASP.NET pagina, dan pas wordt de request door de bijbehorende runtime afgehandeld.

[guanpedro]

Voor IIS is inderdaad een ISAPI filter, ik dacht dat deze het wel kon:

http://www.isapirewrite.com/
http://www.qwerksoft.com/products/iisrewrite/

En voor in ASP.NET:
http://msdn.microsoft.com...spp/html/urlrewriting.asp

http://scottonwriting.net/sowblog/posts/943.aspx

Bijvoorbeeld Microsoft's Content Management Server draait zowat geheel op een ISAPI filter

Misschien dit? http://cheeso.members.winisp.net/dl/IonicIsapiRewriter.zip (Open source), uit de reame:

Ionic's Isapi Rewrite Filter (IIRF)

The mod_rewrite for Apache is widely used to rewrite URL
requests before they reach web application engines. IIS 5.0
(Windows 2000) 5.1 (Windows XP) and v6.0 (Windows 2003) lack a
built-in URL rewriting function.

There are several add-on tools that can add the URL re-writing
function to IIS. All are implemented as ISAPI Filters.
- ASP.NET provides some URL mapping capability
- the IIS v6.0 Resource Kit includes the UrlRemap tool.
- IISRewrite
- ISAPI_Rewrite -
includes a "lite" version available for free.
- Mod_Rewrite 2

All of them have drawbacks.
The ASP.NET support requires that all URLs map through ASP.NET;
even static files would have to be served by the ASP.NET
runtime. This can imply a large performance cost.

The IIS6 Resource Kit filter is provided by Microsoft, and is
supported. However, it does not allow specifying rules via
Regular expressions, and as a result it is not as flexible as
some would like.

The ISAPI_Rewrite module is commercially supported, and does
Regular Expressions, but is expensive. Likewise Mod_Rewrite and
IISRewrite. There is a "Lite" version of ISAPI_Rewrite, but it
does not do Regular Expressions. Doh!

IIRF adds one more option to the list. IIRF is an open-source
Rewrite filter, available in source or binary form at no
cost. It does Regular-Expression mapping based on the PCRE
library. The source is available so you can modify and tweak
the filter if you want to, or need to.

[ Voor 88% gewijzigd door guanpedro op 29-06-2005 17:25 ]

[BoomSmurf]

Heren, met dank

Ik ga het standaard met mod_rewrite (proberen te) doen maar maak toch de custom error document die een 200 teruggooit voor het geval dat.