.htaccess verwijzing naar 404.php
Hi,
Naar aanleiding van een eerder aangemaakt topic heb ik op mijn website een 404 pagina aangemaakt.
Ik heb dat op de volgende manier gedaan:
Ik heb een .htaccess bestand gemaakt met de volgende code:
En ik heb uiteraard ook de 404.php en 403.php in de root geplaatst.
Ik heb nu nog één vraag.
Bestaat er ook een ErrorDocument of een andere regel voor url's die eindigen met een slash?
Ik wil dit graag toepassen mdat google search console/ dekking pagina's uitsluit voor indexering. Al die pagina's die worden uitgesloten eindigen met een slash.
Naar aanleiding van een eerder aangemaakt topic heb ik op mijn website een 404 pagina aangemaakt.
Ik heb dat op de volgende manier gedaan:
Ik heb een .htaccess bestand gemaakt met de volgende code:
En ik heb uiteraard ook de 404.php en 403.php in de root geplaatst.
Ik heb nu nog één vraag.
Bestaat er ook een ErrorDocument of een andere regel voor url's die eindigen met een slash?
Ik wil dit graag toepassen mdat google search console/ dekking pagina's uitsluit voor indexering. Al die pagina's die worden uitgesloten eindigen met een slash.
Gewijzigd op 17/03/2019 21:36:12 door Fester Splinter
Dan strip je toch die slash in je requests?
Het is makkelijker om een lijst van "goedgekeurde" URL's te hebben (whitelist) in plaats van het formuleren van allerlei uitzonderingen die niet geaccepteerd worden (blacklist). Het probleem van een blacklist is dat wanneer je een geval hebt waar je niet aan had gedacht de blacklist zijn werk niet goed doet.
Als we het over routing en .htaccess hebben zou mijn advies nog altijd zijn dat er één RewriteRule voor routing in je .htaccess-bestand staat die alle verzoeken delegeert naar index.php. Index.php op zijn beurt analyseert de oorspronkelijke aanroep (te vinden onder $_SERVER['REQUEST_URI']) en bepaalt via interne (whitelist) logica of de aanroep valide was. Dit kan bijvoorbeeld in zijn eenvoudigste vorm neerkomen op, ik zeg maar wat, een file_exists() controle op een intern pad ofzo. Slaagt deze controle: laad bijbehorende code. Slaagt deze controle niet: voeg een 404 statuscode toe aan de response en serveer een bijbehorende page-not-found pagina.
Dit heeft een aantal voordelen. Zo handel je alle (verdere) routing logica af in PHP-code zelf (gedelegeerd vanuit .htaccess) en houd je je .htaccess bestand schoon en overzichtelijk voor belangrijkere zaken.
Als we het over routing en .htaccess hebben zou mijn advies nog altijd zijn dat er één RewriteRule voor routing in je .htaccess-bestand staat die alle verzoeken delegeert naar index.php. Index.php op zijn beurt analyseert de oorspronkelijke aanroep (te vinden onder $_SERVER['REQUEST_URI']) en bepaalt via interne (whitelist) logica of de aanroep valide was. Dit kan bijvoorbeeld in zijn eenvoudigste vorm neerkomen op, ik zeg maar wat, een file_exists() controle op een intern pad ofzo. Slaagt deze controle: laad bijbehorende code. Slaagt deze controle niet: voeg een 404 statuscode toe aan de response en serveer een bijbehorende page-not-found pagina.
Dit heeft een aantal voordelen. Zo handel je alle (verdere) routing logica af in PHP-code zelf (gedelegeerd vanuit .htaccess) en houd je je .htaccess bestand schoon en overzichtelijk voor belangrijkere zaken.
Quote:
Dan strip je toch die slash in je requests?
Hoe kan ik een slash strippen? Ik beheers geen php of .htaccess?
Ik had al even gegoogeld maar ik vind het allemaal nogal complex wat ik tegenkom.
Dus voordat ik het echt ga gebruiken wil ik zeker weten dat het goed is wat ik gebruik. Want ik weet dat je met een htaccess bestand je hele website naar de kloten kan gaan.
Daarom vraag ik toch maar voor de zekerheid of de volgende code goed is om te gebruiken:
Dus voordat ik het echt ga gebruiken wil ik zeker weten dat het goed is wat ik gebruik. Want ik weet dat je met een htaccess bestand je hele website naar de kloten kan gaan.
Daarom vraag ik toch maar voor de zekerheid of de volgende code goed is om te gebruiken:
Code (php)
1
2
3
2
3
RewriteEngine on
RewriteCond %{REQUEST_URI} /+[^\.]+$
RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ [R=301,L]
RewriteCond %{REQUEST_URI} /+[^\.]+$
RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ [R=301,L]
Gewijzigd op 17/03/2019 23:43:07 door Fester Splinter
Zoals in dat andere draadje al was aangegeven kon je dat dus oplossen met een base href zodat alle relatieve verwijzingen relatief zijn vanaf de webroot en niet relatief vanaf de huidige directory.
Het is niet nodig om nog meer te prutten in je .htaccess bestand.
edit: er werd zelfs een waarschuwing gegeven over 301 redirects (als je het eerste resultaat raadpleegde), als je niet zeker weet wat er gebeurt is het in ieder geval niet verstandig om daarmee te beginnen...
Het is niet nodig om nog meer te prutten in je .htaccess bestand.
edit: er werd zelfs een waarschuwing gegeven over 301 redirects (als je het eerste resultaat raadpleegde), als je niet zeker weet wat er gebeurt is het in ieder geval niet verstandig om daarmee te beginnen...
Gewijzigd op 17/03/2019 23:42:44 door Thomas van den Heuvel
Mark Coenie op 17/03/2019 23:39:46:
Want ik weet dat je met een htaccess bestand je hele website naar de kloten kan gaan.
Zeg maar 'onbereikbaar' als je ontwetend wat doet. Maar je kan het toch uittesten?
Lukt het niet? Check je error_log en rol de aanpassing terug.
Het is niet zo dat .htaccess een permanente werking heeft
Reguliere expressies kan je ook op https://regexper.com ontleden.
Maar base-dir is wat je zoekt.
Gewijzigd op 17/03/2019 23:46:25 door - Ariën -
- Ariën - op 17/03/2019 23:45:17:
Het is niet zo dat .htaccess een permanente werking heeft
Nee maar het effect is wel permanent totdat je je browser cache leegmaakt als je 301 redirects gebruikt... Dit is gewoon hopeloos verwarrend en onnodig complex.
Quote:
Zoals in dat andere draadje al was aangegeven kon je dat dus oplossen met een base href zodat alle relatieve verwijzingen relatief zijn vanaf de webroot en niet relatief vanaf de huidige directory.
Als ik met die base-tag aan de gang ga dan moet ik meer dan 750 pagina's aanpakken.
En het is niet lullig bedoeld Teun maar je komt steeds met een ander antwoord dan waar ik eigenlijk op hoop.
Ik wil graag die slash wegwerken en dan is mijn probleem opgelost.
Gewijzigd op 17/03/2019 23:54:07 door Fester Splinter
Hoe zit je site dan in elkaar?
Heb je voor elke pagina een compleet HTML-document? Hoe wil je bijv. dan je header of menu aanpassen? Ook 750 pagina's aanpassen?
Heb je voor elke pagina een compleet HTML-document? Hoe wil je bijv. dan je header of menu aanpassen? Ook 750 pagina's aanpassen?
nee header en menu maak ik gebruik van includes
als ik het per diepte zou moeten aanpakken dan zou ik met drie bestanden klaar zijn.
Maar toch snap ik de werking van base-tag niet helemaal.
Zover ik begrijp(maar ik kan het fout hebben) is de base-tag een alternatief voor alle links op de pagina?
als ik het per diepte zou moeten aanpakken dan zou ik met drie bestanden klaar zijn.
Maar toch snap ik de werking van base-tag niet helemaal.
Zover ik begrijp(maar ik kan het fout hebben) is de base-tag een alternatief voor alle links op de pagina?
Het staat duidelijk uitgelegd op w3schools etc? Anyway, dit hoort in je head-sectie.
Zie/speel ook met: https://www.w3schools.com/tags/tag_base.asp
Zie/speel ook met: https://www.w3schools.com/tags/tag_base.asp
Gewijzigd op 18/03/2019 00:04:25 door - Ariën -
Wie is Teun? lol. En volgens mij ben ik tot nu toe redelijk consequent geweest in mijn voorgestelde aanpak. Je moet niet allerlei dingen gaan afvangen om probleemsituaties recht te buigen, je moet ofwel en bij voorkeur het probleem wegnemen ofwel zorgen dat het niet uitmaakt als deze situatie zich voordoet. Wat je met .htaccess tracht te doen is symptoombestrijding, en op een nogal omslachtige en ingrijpende manier.
Wat als iemand nu straks weer iets verzint wat jouw site breekt? Ga je dan weer een RewriteRule toevoegen? Of sla je dit gewoon in 1x plat door ofwel centraal te regelen welke pagina's zijn toegestaan ofwel je document zo op te zetten dat dit geen invloed meer heeft op relatieve verwijzingen... Your choice.
Dat jij op iets anders had gehoopt... sja.
Wat als iemand nu straks weer iets verzint wat jouw site breekt? Ga je dan weer een RewriteRule toevoegen? Of sla je dit gewoon in 1x plat door ofwel centraal te regelen welke pagina's zijn toegestaan ofwel je document zo op te zetten dat dit geen invloed meer heeft op relatieve verwijzingen... Your choice.
Dat jij op iets anders had gehoopt... sja.
Gewijzigd op 18/03/2019 00:16:53 door Thomas van den Heuvel
Quote:
Het staat duidelijk uitgelegd op w3schools etc? Anyway, dit hoort in je head-sectie.
bedankt voor de tip. ik ga er morgen mee aan de slag
Lees het bovenstaande bericht nog even of negeer dit en ploeter lekker verder.
Quote:
Wie is Teun?
Sorry ik bedoelde inderdaad Thomas. Ik ken persoonlijk een Teun van den Heuvel, vandaar :)
Begrijp me niet verkeerd Thomas. Ik waardeer je reacties zeker en ik snap dat ik geen onnodige risico's moet lopen.
Ik wil alleen graag dat als google search console een pagina indexeerd met een slash erachter dat het door verwezen wordt naar een goedwerkende url zonder slash.
En dan moet je toch je URL's op orde brengen. Blijkbaar indexeert Google dit zo omdat de URL's een trailing slash hebben.
Quote:
En dan moet je toch je URL's op orde brengen. Blijkbaar indexeert Google dit zo omdat de URL's een trailing slash hebben.
Ik heb alle URL's gecontroleerd Ariën. zowel in de sitemap als op de pagina's.
Nergens staat een slash achter. Daar ben ik 100% zeker van.
Maar ik ondek meer rare dingen onder search console/ dekking. Google sluit URL's uit voor indexering die helemaal niet bestaan.Hoe komt google bij die URL's die helemaal niet bestaan? Ze komen in elk geval niet voor in de HTML of in de sitemap. Daar ben ik 100% zeker van. Mijn site heeft het altijd goed gedaan en de groei zat er goed in tot een dikke week geleden. Toen begonnen plots deze problemen.
Geef eens voorbeelden?
Dat kan van alles zijn, mogelijk/voornamelijk bots. Waarom zou een bezoeker zelf dingen in gaan typen die afwijken van de reeds aanwezige navigatie en daarmee bewust van de getreden paden af gaan? En als dit dus statistieken of de werking van hulprogramma's vertroebelt dan zul je dus echt een mechanisme moeten hebben die een onjuiste aanroep echt afkeurt. De meest ondubbelzinnig manier om dit te doen is deze rechtstreeks een 404 status geven (door een 404 pagina op te hoesten met bijbehorende 404 status). Als Google die pagina's dan nogmaals inspecteert dan zal deze zien dat de pagina niet (meer) bestaat en zal daar dan verder niet meer naar omkijken. Op deze manier wordt dit probleem ook automatisch opgeschoond. De makkelijkste manier is (wat mij betreft nog steeds) een heel strict beleid: een aanroep is correct of incorrect. Er is geen grijs gebied waarbij een aanroep soms na enige aanpassing wellicht toch juist is.
Gewijzigd op 18/03/2019 01:06:42 door Thomas van den Heuvel




