Archief - paden in php-files

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

wdelements

Legacy Member
Ik ging er altijd van uit dat paden in een php-file gewoon afhingen van de php-file zelf en dat een include er geen invloed op had, blijkbaar wel..

Een voorbeeld:
Code:
website root
   includes
        imagefunctions.php
   pages
         userpost.php
   admin
       pages
            newspost.php

In mijn .htaccess zorg ik ervoor dat alles via index.php gaat in de websiteroot.
Alles wat naar /admin/ gaat gaat naar /admin/index.php

in mijn index van de root doe ik dus include("includes/imagefunctions.php");
in mijn index van de admin doe ik dus include("../includes/imagefunctions.php");

In de pagina imagefunctions staat een functie "watermerk"
waarin ik de png voor het watermerk oproep.
$watermark = @imagecreatefrompng("files/images/watermark.png");

Als ik in userpost deze functie oproep wordt het watermerk gevonden en is alles ok.
Als ik echter via newspost.php in de adminmap ga niet, maar wel als er $watermark = @imagecreatefrompng("../files/images/watermark.png"); zou staan.

Ik dacht altijd dat je het pad in een php file moest opgeven ten opzichte van de php-file, maar je moet het dan eerder zien van de plaats waar de file werd geïnclude ?

alvast bedankt.

Cycloon

Legacy Member
Een include "kopieert" bij wijze van spreken de code van het ene bestand in het andere en wordt vanuit die locatie uitgevoerd. Het is dan ook vrij logisch dat paden die in de include gebruikt worden relatief zijn ten opzichte van de uitvoerlocatie. Wil je dat omzeilen dan gebruik je best altijd absolute paden. De variabele $_SERVER['DOCUMENT_ROOT'] kan daar bv bij helpen :)

wdelements

Legacy Member
ok merci, da's wat ik moest weten, documentroot is idd een goede oplossing.

wdelements

Legacy Member
Heb hieromtrent toch nog een vraagje:

Code:
website root
   index.php
   includes
        imagefunctions.php
        product.php
        config.php
   classes
        gebruiker.php
   pages
         userpost.php
   admin
       pages
            newspost.php

als ik in mijn product.php de file "config.php" wil includen dan kan ik gewoon zeggen include("config.php") alsook include("includes/config.php")

als ik een klasse wil gebruiken moet ik zeggen include("classes/gebruiker.php") dus wel het volledige pad opgeven en niet navigeren vanuit de includesmap dus ("../classes/gebruiker.php").

Hoe komt het dan dat bij config beide werkt?

wdelements

Legacy Member
Sorry voor het terug omhoogsmijten van deze topic, maar het was te gek om een nieuwe te openen.

Ik heb mijn laatste vraag met een beter voorbeeld verduidelijkt omdat ik t nog steeds niet snap waarom m dat doet:


Code:
ROOT
index.php
   PAGES
   info.php
      INCLUDES
      header.php
      datescript.php
Alles wordt naar index.php doorverwezen.
Stel de url http://www.website.be/info/
Dan zal index.php dus info.php includen.
Deze heeft header.php geinclude via include("includes/header.php");
In header heb ik een include("includes/datescript.php");
Dit werkt prima, maar als ik bij de header gewoon include("datescript.php"); zet werkt dit blijkbaar ook.

Hoe komt het dat hij deze toch vind terwijl door alle includes eigenlijk alles op rootniveau staat en je er dus eigenlijk de map ervoor moet zetten?

maw, includen gaat zonder pad mee te geven tenzij in dit geval "datescript.php" ook in je root staat, dan gaat hij dat nemen en ik vraag me af waarom.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan