Door
Tim Wolf
op 30-01-2016 09:41
gewijzigd op 30-01-2016 14:26
2.140 views
Goedemorgen PHPHulp,
Ik heb een script gevonden als een map niet is gevonden of geen inhoud heeft dat hij de homepagina include:
# Not found include mine page
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
Maar nu heb ik de vraag of er een code bestaat dat php weet dat het niet de homepagina is en dan een warning message geeft (zelf al gevonden).
Alvast bedankt,
Tim
[update]
Spellingsfout eruit gehaald.
[/code]
Met ?path=$1 geef je de oorspronkelijke URL door en kun je die in PHP vervolgens in $_GET['path'] terugvinden. De instructie QSA (Query String Append) geeft op dezelfde wijze eventuele andere URL-variabelen door.
[edit]
Het werkt nu maar hoe kan ik met $_GET['path'] ervoor zorgen dat hij merkt dat alleen als je bijv.: domain.com intypt dat er geen warning komt maar wel als je domain.com/path intypt wel?
Maar ik heb (bijna) helemaal geen kennis van php (ik heb nu een cursus HTML + CSS.)
Ik zou het daarom fijn vinden als je een voorbeeldje hebt. Op het web ben ik niet veel wijzer geworden.
@Ward: waarommmmmmmmmmmm willen mensen toch altijd het pad aan de URL plakken? Dat is helemaal niet nodig!
Controleer simpelweg $_SERVER['REQUEST_URI']. Daarin staat je pad al. En hier is een hele simpele functie voor om deze in 1x te scheiden van mogelijke $_GET argumenten: parse_url().
Met de door jouw gebruikte constructie reserveer je ook exclusief $_GET['path'] voor dit doel, wat helemaal niet intuïtief is, omdat je dit niet terugziet in de URL in je adresbalk. Op deze manier kunnen er allemaal "verborgen" $_GET variabelen zijn waar je geen weet van hebt!
Je zou dan, als er ergens iets misgaat in je code $_GET continu moeten dumpen om te kijken of er daar toevallig iets raars aan de hand is. Als je hier uberhaupt aan denkt.
@Thomas Er leiden meerdere wegen naar Rome, maar als iemand vraagt hoe je daar met de auto komt, ga ik in eerste instantie niet uitleggen dat wandelen heel gezond voor je is.
@Ward, ook zonder uitleg zou een oplossing met mijn kanttekeningen -naar mijn mening- simpeler en transparanter zijn. Ik motiveer mijn alternatieve oplossing ook. Ik probeer hier te onderstrepen dat het wellicht niet zo'n strak plan is om je querystring op voorhand te manipuleren als je dit kunt vermijden. Ben je het hiermee oneens? Hoor ik graag je redenatie.
Als je mensen dan toch naar Rome wilt sturen, doe dat dan over een gebaand pad en niet een doolhof waar mensen mogelijk de weg kwijt raken.
Ten eerste is het geen doolhof al je denkt in domeinen. Dit beginnetje van het geheel is het exclusieve domein van de webserver, niet van een of andere applicatieserver voor PHP, ASP of Java:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
Ik vind het ook fijn (heel fijn zelfs) dat ik ontzettend veel kan regelen met PHP, maar we mogen als speler van de tweede viool nooit de dirigent van het orkest vergeten.
Ten tweede is er nog zoiets als de expressiviteit van code. (Daarvoor kan ik het werk van ome Bob aanbevelen.) Dan kun je je namelijk afvragen of dit wel zo'n fijne overweging is:
RewriteRule . /index.php [L]
Er staat namelijk: kan mij niet schelen wat je wilt (.), draag alle zooi die hier niet te vinden is maar over aan één enkel PHP-bestand (index.php). Effectief verklaart de webserver zich daarmee onbevoegd: "Sorry, verkeerde loket." Je kunt duidelijker uitdrukken wat nou precies de bedoeling is door het expliciet te maken:
Per saldo maakt het niet uit of je nu $_GET['path'] of $_SERVER['REQUEST_URI'] gebruikt, maar hiermee heb je niet alleen duidelijker gezegd wat je precies met die $1 wilt doen, maar ook de mogelijkheid open gehouden om iets met een $2 of een $3 te ondernemen, en dat dan ook nog buiten het domein van PHP.
Als bedrijfskundige heb ik geleerd dat er géén ‘one best way of organizing’ is. Zou de ideale organisatievorm namelijk wel bestaan, dan zouden alle andere organisatievormen onder de druk van concurrentie bezwijken en uitsterven. Met programmeren is dat nauwelijks anders: probeer vooral niet de theoretisch beste oplossing te vinden, want die bestaat door wisselende feiten en omstandigheden zelden of nooit.
Scopes nodeloos vervuilen lijkt mij in ieder geval niet de bedoeling, wat je met het bovenstaande in wezen aan het doen bent.
Overigens draag je met rewriterules de taak of een URL hout snijdt al deels over aan het script wat verder zal moeten bepalen of hier sprake van is, dus begrijp ik niet helemaal dat je dat hier als argument tegen lijkt te gebruiken, omdat je hetzelfde doet?
Hoe verschilt "^([^?]*)" in deze van "."? Het enige wat je doet is de querystring er vanaf kappen. Lood om oud ijzer?
Daar ging het hier ook niet om - het ging erom of je troep in je querystring wilt injecteren. Tis maar net hoe je met $_GET om wilt gaan. Als ik in mijn URL heb staan: lala.php?hoi=blaat en ik vervolgens een dump doe van $_GET, dan verwacht ik in eerste instantie niet hoi = blaat en nog allerlei andere zut.
En wat als ik in functionaliteit van mijn code onverhoopt "path" in mijn navigatie gebruik? Het resultaat is dan onvoorspelbaar, omdat dat interfereert met jouw RewriteRule. Je neemt hier op voorhand ook een (ontwerp)beslissing waarbij "path" gereserveerd is.
