Onderwerp: [PHP] Object Scope probleem

Hallo Allen,

Ik loop tegen een zeer raar probleem aan omtrent de scope van Objecten.
Ik maak gebruik van PHP5 op een DirectAdmin server.

Wat is het geval? Open even de bijlage dat maakt het een stukje duidelijker.

Ik ben bezig met een eigen CMS te schrijven, opzich werkt alles goed. Diverse modules al.
Voor site specifieke aanpassingen en functionaliteiten heb ik ondersteuning voor special configs. Deze worden bij het starten al geladen en maken diverse grote aanpassingen mogelijk.

Standaard starten we natuurlijk met de index.php, laden een config (generieke settings).
Laden vervolgens een 'engine'. Deze engine definieert een object $SITE en een object $USER. Deze worden correct gedefinieerd.
Dit geheel vind plaats via diverse control structures maar zonder enige functies tot op heden. Er worden wel functies en classes gedefinieerd maar nog niet gebruikt.
$SITE is eigenlijk onze engine en doet content beheer etc.
Voordat we $SITE->Execute(); doen om de engine te starten, willen we een aantal hooks toevoegen via een special config.
In $SITE zit een constructor die via de HTTP_HOST al wat site details heeft geladen in het object. Onder andere het FQDN (de HTTP_HOST eigenlijk).

De te laden special config is genoemd naar het FQDN met de extensie .php
Bijvoorbeeld voor de website www.example.org laden we het bestand www.example.org.php.
Dit gaat allemaal goed, echter wanneer we in www.example.org.php het $SITE Object willen benaderen resulteert PHP NULL, Het gehele $SITE Object komt niet terug tussen de 'variabelen' met de PHP functie get_defined_vars().

En dit terwijl het object is gebruikt om het betreffende bestands te kunnen laden. (Let op het bestand is niet vanuit $SITE geladen, maar de bestandsnaam is gevormd met behulp van een variable in $SITE).

Mijn grootste probleem op dit moment is dat het object $SITE niet te gebruiken is op dit punt.
Ook het maken van een functie in het laatste bestand en dat aan te roepen en vervolgens global $SITE; levert niet het gewenste resultaat.

Mijn hoop is nu eventjes gevestigd op mensen hier, die mij wakker schudden en in de juiste richting kunnen duwen. (Wakker schudden op deze tijd juist omdat ik al vroeg op was. Reeds om 4 uur).

Probeer is in zowel je config bestand, als waar je $SITE defineerd dit te doen:

Code:

global $SITE;

Dit globaliseerd site, waardoor je het altijd moet kunnen benaderen binnen dezelfde thread.

Verders, hoe laad je die config?
Neem aan dat dit zoeits is als require_once o.d.

Waar zit je ergens als je de include van dat laatste bestand doet? Zit je dan in een functie of in class ofzo, of is dat gewoon nog in de 'root' van je script?

Cakkie, in feite zit ik nog in de 'eerste laag', buiten elke functie of class die ik zelf definieer. Alleen wel 2 includes later. (DIe niet in een fucntie of class plaats hebben gevonden).

QBell, ga ik meteen proberen.

Oorspronkelijk geplaatst door QBell

Probeer is in zowel je config bestand, als waar je $SITE defineerd dit te doen:

Code:

global $SITE;

Dit globaliseerd site, waardoor je het altijd moet kunnen benaderen binnen dezelfde thread.

Verders, hoe laad je die config?
Neem aan dat dit zoeits is als require_once o.d.

Config wordt geladen via een require_once inderdaad, een global $SITE in de config extra (config voordat het object wordt gemaakt, global $SITE direct na dat het object wordt gemaakt en in het bestand waar ik het wil gebruiken heeft geen effect).


Nog iets raars dat ik ontdek, als ik onderstaande code uitvoer:

Code:

echo "Dit zou als eerste moeten komen.";
include_once("special.php");
echo "Dit zou als laatste moeten komen.";

en in special.php staat:

Code:

echo "Dit is de middelste regel!";

evert een output op van:

Code:

Dit is de middelste regel!
Dit zou als eerste moten komen.
Dit zou als laatste moeten komen.

Terwijl PHP bij mijn weten toch echt linear door de bestanden heen zou lopen.

Over het laatste, zoiets heb ik laatst ook gehad. Toen zat er een bug (probeerde een subklasse aan te maken van een class die nog niet gedefineerd was), waar precies het zelfde met de includes gebeurde.

PHP5 is soms nogal beroerd kwa error reporting (die staat al op hoogste stand enzo?), maar dit kan dus veroorzaakt worden door een bug ergens in een andere include, en php geeft hier 0 debug-informatie over.

zou eens beginnen met:
<?php
ini_set('dispay_errors', true);
error_reporting(E_ALL | E_STRICT);
?>
ofzoiets (zie php.net, ben lui en weet niet zeker of het klopt)

blaaat, daar had ik ook aan zitten denken, omdat gettype en een print_r op het object niets opleverde. (NULL)
Echter is het betreffende object eerder nog gebruikt voor het laden van het betreffende bestand. De naamgeving van het te laden bestand is afhankelijk van de inhoud van een variabele in het object. Het bestand wordt dus niet vanuit het object geladen!

Waat ook raar is, is dat echo's die vooraf aan het includen werden gegeven, worden geoutput nadat het bestand is uitgevoerd.

ikkuh, ik krijg geen fout over dat het object niet bestaat, geen notice en geen error. En toch krijg ik een leeg/niet bestaand object zegt PHP.

simpelste is om gewoon eens met een PHP debugger er doorheen te lopen.

Maar een oplossing lijkt me om $SITE in de superglobals op te nemen, dus:
$GLOBALS['SITE'] = je object;

Als er iets mis gaat met de volgorde waarin alles uitgevoerd wordt, dan ga je hetzelfde resultaat krijgen, gezien de superglobal dan ook nog niet ingesteld is. Welke versie van PHP is het precies? De laatste versie al eens geprobeerd?

Oorspronkelijk geplaatst door groenleer

blaaat, daar had ik ook aan zitten denken, omdat gettype en een print_r op het object niets opleverde. (NULL)
Echter is het betreffende object eerder nog gebruikt voor het laden van het betreffende bestand. De naamgeving van het te laden bestand is afhankelijk van de inhoud van een variabele in het object. Het bestand wordt dus niet vanuit het object geladen!

Waat ook raar is, is dat echo's die vooraf aan het includen werden gegeven, worden geoutput nadat het bestand is uitgevoerd.

Ik snap dat je het niet uit object lade, maar waar ik meer op doelde was dat php soms nogal onvoorspelbaar kan worden als er _ergens_ iets mis gaat, hoeft niet in dat zelfde object te zijn.

Het was in mijn geval een andere classe die alleen gedefineerd werd, nog niet eens gebruikt. dus misschien heb je ergens anders nog classes staan? Bij mij gebeurde ook het zelfde met de echo's, dat simpele echo/prints op verkeerde volgorde ge-execute worden.

Misschien kan je even kijken met get_declared_classes en get_ declared_ interfaces of alles wel klopt?