CSS verdwijnt bij trailing slash (/) in URL
Ik krijg perfect de gewenste pagina, maar; ZONDER trailing slash MET CSS - en MET trailing slash ZONDER CSS.
Heeft iemand enig idee hoe dit gedrag is te voorkomen?
Waarom het gebeurt is me inmiddels wel duidelijk.
ZONDER trailing slash achter het URL blijkt uit het Netwerk overzicht dat de stylesheet style.css wordt aangeroepen als:
http:://localhost:3000/assets/css/style.css; dit beschouw ik als de normale aanroep.
MET trailing slash achter het URL geeft het Netwerk overzicht aan dat de stylesheet style.css aanroep is:
http:://localhost:3000/home/assets/css/style.css; en dat pad bestaat niet in de site - dus geen CSS.
Op zich begrijpelijk dat het niet werkt, maar hoe ontstaan deze twee verschillende aanroepen?
En - belangrijker - hoe kan ik dit vermijden?
O ja, de redirect in .htaccess luidt:
RewriteRule ^(.+)$ index.php?url=$1 [QSA,L]
Toevoeging op 11/02/2020 14:44:28:
Bijzonder, maar ook dit probleem heeft zich weer snel opgelost.
Ik heb de link naar het style sheet gewijzigd in:
Even een helder moment na toch wel vrij lang sukkelen.
Dit lost het probleem op, maar ik wil ook graag weten hoe het ontstaan.
Iemand een verklaring?
Gewijzigd op 11/02/2020 14:45:31 door Jan Kila
Op het moment dat er slashes in je URL zitten zit je dus niet langer in de "root" van je webdirectory, maar één of meerdere niveaus lager. Het maakt daarbij niet uit of je rewriterules hebt die alles naar index.php sturen (dit is een server-aangelegenheid). De browser (client side) ziet "hee ik zit in het pad /news/whatever en ik heb een relatieve verwijzing naar /css/style.css, dus die zou dan in /news/css/style.css moeten zitten" (want /news is je huidige directory).
De browser heeft ook geen kennis van de technische oplossing aan de serverkant, alle "bestanden" die je opvraagt zijn in wezen "virtueel" maar jouw browser weet dat niet, noch is het de taak van de browser om dit te snappen, deze werkt gewoon met het HTTP(S) protocol en behandelt ze gewoon als fysieke bestanden en volgt de logica die ze altijd volgt, conform de protocollen die hiervoor gelden.
Het probleem ontstaat doordat deze relatieve verwijzingen geen vast uitgangspunt hebben. Omdat je deze niet expliciet opgeeft zal de huidige directory het uitgangspunt zijn, en die wordt dus aan het pad naar het CSS-bestand toegevoegd.
Dit kun je op meerdere manieren oplossen, bijvoorbeeld door:
- absolute verwijzingen (volledige URLs) te gebruiken
- een <base> tag toe te voegen in het <head> gedeelte, zodat er expliciet een vast uitgangspunt staat ingesteld
Heb je dit alles m.b.v. een tutorial gebouwd trouwens, want dit:
Code (php)
1
RewriteRule ^(.+)$ index.php?url=$1 [QSA,L]
is in principe niet verkeerd, maar de toevoeging ?url=$1 is compleet overbodig, en zorgt er ook voor dat je querystring ($_GET) wordt geïnjecteerd met onzichtbare waarden wat esthetisch gezien niet heel erg verantwoord is.
Het kan ook onvoorspelbare gevolgen hebben op het moment dat je deze "gereserveerde" variabele toevoegt aan een "nette url", dus bijvoorbeeld /news/whatever?url=woops. Wat gebeurt er dan?
Indien je geen specifieke reden hebt voor deze toevoeging dan zou ik dat deel ook verwijderen. Alle informatie (dus wat je ten overvloede nogmaals in $_GET['url'] stopt) is gewoon beschikbaar via $_SERVER['REQUEST_URI']. Vervolgens kun je hier standaard PHP-functies zoals parse_url() op loslaten om het "applicatiepad" te extraheren.
PS welkom in de wereld van relatieve en absolute paden. Op het moment dat je met rewriterules aan de slag gaat zul je hier nog veel plezier mee gaan krijgen :).
Gewijzigd op 11/02/2020 16:22:53 door Thomas van den Heuvel
In dit geval zorgen beide voorgestelde oplossingen ervoor dat het wel of niet hebben van een slash aan het einde van de URL er niet toe doet dus dat is in zekere zin niet heel erg relevant.
Neemt niet weg dat je een goed uitgewerkt plan moet hebben over de manier waarop je navigatie intern en extern werkt, vooral als je met schone URLs / rewriterules / routers etc. werkt.
Ik realiseer me nu dat de meeste frameworks ook enkel een URL wijzigen als het opgevraagde bestand (of directory) niet bestaat.
Een .htaccess bestand die dat in zich heeft zou er ongeveer zo uit zien:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
RewriteEngine On
# Alleen als het om een niet bestaand bestand gaat
RewriteCond %{REQUEST_FILENAME} !-f
# Alleen als het om een niet bestaande directory gaat
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php [QSA,L]
# Alleen als het om een niet bestaand bestand gaat
RewriteCond %{REQUEST_FILENAME} !-f
# Alleen als het om een niet bestaande directory gaat
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php [QSA,L]
Gewijzigd op 11/02/2020 20:36:35 door Frank Nietbelangrijk
Thomas van den Heuvel op 11/02/2020 20:24:02:
En dan zonder ?url=$1 :p
En dat vergat ik natuurlijk :o
Toch maar even aangepast.
Gewijzigd op 11/02/2020 20:37:32 door Frank Nietbelangrijk
Het werkt prima met: $_SERVER['REQUEST_URI']. Parsen gaat op de manier zoals het al ging.
Met $_SERVER['REQUEST_URI'] zijn er minder handelingen; en minder handelingen betekent dat er minder fout kan gaan; en daar ben ik vóór!
Met jullie hulp werkt m'n MVC-framework(je); vanaf hier is het meer van hetzelfde. Het is trouwens wel heel veel werk om die crawler gelukkig te maken; heel leerzaam ook!
De database connectie was nog een dingetje, maar ook dat heb ik opgelost.
Toevoeging op 12/02/2020 15:52:06:
Toch nog even zeuren.
Bij gebruik van $route = $_SERVER['REQUEST_URI']; geeft een url a la: http://localhost:3000/story/single na:
Code (php)
1
$parts = explode('/', $route);
de volgende output:
route: /story/single
Array
(
[0] =>
[1] => story
[2] => single
)
1
Nu is het eerste element van het array leeg; en bij gebruik van $_GET['url'], lee s ik daar: [0] => story
Dat is even wennen.
Heb ik nu ook de garantie dat het eerste element ALTIJD leeg is, of is er nog een afhankelijkheid?
QSA zou ik gewoon laten staan. Misschien gebruik je het nu niet, maar dat komt mogelijk nog, bijvoorbeeld bij een soort van pagina-navigatie of zoekfunctionaliteit. Zou dat alles niet op voorhand uitsluiten.
Dus eigenlijk min of meer dit.
Maar géén slash achter de site root (localhost:3000story) geeft wel een vreemd resultaat:
https://www.google.com/search?client=safari&rls=en&q=localhost:3000story&ie=UTF-8&oe=UTF-8
Dát zou ik wel willen afvangen.
Toevoeging op 12/02/2020 16:33:00:
RewriteBase /
Als ik je goed begrijp.
edit: als je gewoon je website-voorpagina aanroept is het array leeg, als dat het geval is dan pak je een default route/stuk code.
edit 2: maak ook onderscheid tussen:
#1 de URLs die jouw applicatie produceert
#2 de afhandeling van het opvragen van een specifieke URL
dit zijn twee verschillende dingen die op elkaar aan zouden moeten sluiten.
Gewijzigd op 12/02/2020 16:57:59 door Thomas van den Heuvel