hij laat css niet door htaccess
ik ben bezig met eigen framework voor me website
ik loop nu allee tegen het volgende op
ik wil me php document linken met css via html
maar .htaccess blockt het omdat alles wordt omzegt naar _GET
hoe zou ik dit probleem kunnen fixen?
dit is wat ik heb
mis je nog
-l staat voor "link", ofwel "shortcut"
Waarom doet met dit altijd? Hiermee "reserveer" je effectief $_GET['url'] en prop je het opgeroepen pad hierin.
Waarom niet gewoon:
Vervolgens zit alle informatie (zowel pad als $_GET) in $_SERVER['REQUEST_URI'].
En laat daar nou een functie zijn die alles in 1x uitleest: parse_url(). Voor de querystring variabelen kun je nog altijd $_GET gebruiken natuurlijk.
Alles (eerst) in $_GET['url'] proppen is gekunsteld en onnodig. Je vervuilt hiermee in zekere zin $_GET.
Althans, ik denk dat je CSS het niet doet in je HTML.
Daar doel je toch op, met deze zin: ik wil me php document linken met css via html?
Je gooit een CSS-saus over je HTML. PHP heeft daar niets mee te maken.
dus
site/php/forum
en dan een <img src="images/foto.jpg" >
Met base kun je dan zorgen dat de foto niet in /php/forum/images/foto.jpg gezocht wordt.
Maar met bovenstaande rewriterule wordt alles herschreven.
zelfs site.nl/index.php wordt tot site.nl/index.php?url=/index.php
in je .htaccess indien een bestand bestaat deze gewoon laden en niet via je index laten lopen.
ik ben bezig met eigen framework voor me website
ik wil me php document linken met css via html
Het is mijn of m'n framework of document, maar nooit me ...
- de CSS gewoon in de HTML zetten. Dynamisch met data-uri's. Kost iets meer bandbreedte, scheelt een boel HTTP requests en maakt netto dat je site sneller laadt.
- de CSS links niet direct naar .css-bestanden laten verwijzen, maar naar hetzelfde index.php script. Met wat GET-parameters kan je het index.php script vertellen welk CSS-bestand je hebben moet, en het script kan de CSS dan met readfile() oid. sturen. Extra voordeel: je kunt via PHP nog wat spelen met HTTP headers, en CSS dynamisch laten genereren, bijvoorbeeld op basis van tijd (donkerder/lichter thema) of gebruikersvoorkeuren voor bepaalde kleuren (hoog contrast, kleurenblindheidsprofieltje, of domweg rood ipv blauw..)
Toevoeging op 03/09/2015 20:53:00:
@Ozzie: nog correcter Nederlands: m?n site! :-)
http://www.fileformat.info/info/unicode/char/0133/index.htm
Toevoeging op 03/09/2015 20:53:24:
Owhja, vergeten.. phphulp ondersteunt geen Unicode :-( (waarom eigenlijk niet?)
Remco van der Velde op 03/09/2015 12:05:25:
Hier staat in feite (als ik mij niet vergis) "als het opgevraagde ding een bestand of een directory is, dan doe niets".
Ik denk dat je beter uitzonderingen kunt definiëren, dus middels RewriteRules aangeeft wanneer er wel iets speciaals moet gebeuren. De bovenstaande regels zijn nogal loos als je het mij vraagt. Je geeft daar expliciet aan wanneer er niets hoeft te gebeuren :/.
An tje op 03/09/2015 20:48:33:
Owhja, vergeten.. phphulp ondersteunt geen Unicode :-( (waarom eigenlijk niet?)
Voor dit soort (noodzakelijk) onderhoud is blijkbaar geen tijd/geld. Je moet begrijpen dat het budget zeer beperkt is. Dat gaat ook meestal meteen op aan belangrijkere zaken zoals het toevoegen van minuscule icoontjes aan de activiteitenfeed (die overigens ook nog steeds geen charset aanduiding heeft).
Gewijzigd op 03/09/2015 21:35:25 door Thomas van den Heuvel
De roots van PHP liggen in het preprocessen van (tekst)files zoals HTML. Waarom dan liever geen JS en CSS? Ik heb dat optioneel ingebouwd in m'n eigen raamwerkje, en ik vind het wel handig werken voor variabelen, cross browser code (of aanbieden van legacy code als iemand IE8 gebruikt), gebruikersvoorkeuren als locale-instellingen. Dan kan je die NLS-strings allemaal uit een database vissen ipv. dat je tig bestanden krijgt die je (handmatiger) moet onderhouden?
An tje op 03/09/2015 21:35:41:
Maar waarom zou je CSS files en JavaScript files niet door het index.php script laten lopen?
Omdat het niet nodig is.
Ik zou zeggen, houd het simpel + clean.
Ik gebruik zoiets.
En ook maar een intern linkje waar iets soortgelijks voorbij kwam, anders krijg ik weer commentaar dat ik naar mijn eigen site link lol (ondank het feit dat het relevante informatie bevat; ik heb geen zin om hetzelfde verhaal 2x te typen)
Onder het motto vrijheid+blijheid wil ik ook m'n index.php kunnen gebruiken om dynamische content anders dan HTML te kunnen genereren (JS, CSS, binaire files..) maar dat doe ik liever via functies die URL's voor me genereren die weer naar index.php wijzen. Dan kan ik in PHP ervoor kiezen om die functies te gebruiken of niet.
Is everybody happy?
Als jij het vervolgens leuk vindt om een javascript bestand te serveren als je /blaat/hai/hoipipeloi?secret=xyz als pad invoert dan heb je die vrijheid.
Veel flexibeler wordt het niet?
Het is overigens volgens mij een goede gewoonte om "one point of entry" te hebben in je applicatie. Dit is index.php. Alle URL's die "onbekend" zijn worden aan index.php gegeven als een soort van "gateway": "Hey ik heb hier een URL waar ik niks mee kan, weet jij wat ik hiermee moet doen?" Het uiteindelijke antwoord kan dan trouwens alsnog het serveren van een 404 pagina zijn, inclusief 404 HTTP-header.
Gewijzigd op 03/09/2015 21:59:27 door Thomas van den Heuvel
Thomas van den Heuvel op 03/09/2015 21:29:08:
Hier staat in feite (als ik mij niet vergis) "als het opgevraagde ding een bestand of een directory is, dan doe niets".
Ik denk dat je beter uitzonderingen kunt definiëren, dus middels RewriteRules aangeeft wanneer er wel iets speciaals moet gebeuren. De bovenstaande regels zijn nogal loos als je het mij vraagt. Je geeft daar expliciet aan wanneer er niets hoeft te gebeuren :/.
Voor dit soort (noodzakelijk) onderhoud is blijkbaar geen tijd/geld. Je moet begrijpen dat het budget zeer beperkt is. Dat gaat ook meestal meteen op aan belangrijkere zaken zoals het toevoegen van minuscule icoontjes aan de activiteitenfeed (die overigens ook nog steeds geen charset aanduiding heeft).
Remco van der Velde op 03/09/2015 12:05:25:
Hier staat in feite (als ik mij niet vergis) "als het opgevraagde ding een bestand of een directory is, dan doe niets".
Ik denk dat je beter uitzonderingen kunt definiëren, dus middels RewriteRules aangeeft wanneer er wel iets speciaals moet gebeuren. De bovenstaande regels zijn nogal loos als je het mij vraagt. Je geeft daar expliciet aan wanneer er niets hoeft te gebeuren :/.
An tje op 03/09/2015 20:48:33:
Owhja, vergeten.. phphulp ondersteunt geen Unicode :-( (waarom eigenlijk niet?)
Voor dit soort (noodzakelijk) onderhoud is blijkbaar geen tijd/geld. Je moet begrijpen dat het budget zeer beperkt is. Dat gaat ook meestal meteen op aan belangrijkere zaken zoals het toevoegen van minuscule icoontjes aan de activiteitenfeed (die overigens ook nog steeds geen charset aanduiding heeft).
Klopt, im mijn eigen .htaccess doe ik dan bijvoorbeeld dit:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
RewriteEngine On
#
# Don't rewrite if dir/link/file exists
#
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule .* - [L]
#
# Handle in route class...
#
RewriteCond %{HTTPS} off
RewriteRule .* - [E=REQUEST_SCHEME:http]
RewriteCond %{HTTPS} on
RewriteRule .* - [E=REQUEST_SCHEME:https]
RewriteRule ^/?(.*)$ /index.php?request=$1 [L,QSA]
#
# Don't rewrite if dir/link/file exists
#
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule .* - [L]
#
# Handle in route class...
#
RewriteCond %{HTTPS} off
RewriteRule .* - [E=REQUEST_SCHEME:http]
RewriteCond %{HTTPS} on
RewriteRule .* - [E=REQUEST_SCHEME:https]
RewriteRule ^/?(.*)$ /index.php?request=$1 [L,QSA]
deze nog eens zou ik zeggen.
@Remco: Mja, lees Gewijzigd op 04/09/2015 19:32:58 door Thomas van den Heuvel
Quote:
e moet begrijpen dat het budget zeer beperkt is. Dat gaat ook meestal meteen op aan belangrijkere zaken zoals het toevoegen van minuscule icoontjes
Logisch, ik vind icoontjes ook leuker dan Unicode support :) En strikt genomen is Unicode voor Nederlands ook niet nodig, al was het voor de 'ras'-echte "ij" wel leuk geweest.