[PHP4] Niet-bugvrij includen

[Scyth]

Hoi medeprogrammers, vraagje. Ik include in een loop een stel plug-ins, die niet noodzakelijk bugvrij hoeven te zijn. Immers, hoe kan je een plug-in testen als deze niet geïmplementeerd kan worden op de manier waarop het bedoeld is.

De vraag is nu; PHP4 ondersteunt geen try-catch constructie, dus moet ik de loop met includes met een if-constructie schrijven. Ik héb een eigen errorhandler geschreven, errRep( [...] ), die de errors afhandeld, maar die moet dus apart gecalled worden. Echter, als ik een PHP include met kritiek foute code, halt de PHP-eigen parser. Logisch, maar de rest van m'n code wordt niet meer uitgevoerd.

Als ik alles include met @include(' [...] '); werkt niets meer, dus the easy way 'errors afvangen' werkt dus niet.

Iemand ideëen?

[WormLord]

Ik heb hier wel 2 ideeen voor.

1) De fatale fout oplossen .
2) In de error-handler de foute include ergens opslaan (file/database/whatever), de pagina refreshen (indien mogelijk) en dan de opgeslagen includes niet meer includen.

[Mr. Bondt]

http://nl3.php.net/manual/nl/function.set-error-handler.php
Misschien heb je daar iets aan?

[Scyth]

WormLord schreef op dinsdag 19 december 2006 @ 15:43:
Ik heb hier wel 2 ideeen voor.

1) De fatale fout oplossen .
2) In de error-handler de foute include ergens opslaan (file/database/whatever), de pagina refreshen (indien mogelijk) en dan de opgeslagen includes niet meer includen.

1: Onmogelijk, want een plugin werkt in harmonie met een geheel, als 't geheel gewoon crasht omdat je een plugin aan het devven bent... Nouja, you get the point.
2: Insgelijks onmogelijk, omdat 't script niet verdergaat na de foute plugin. Opslaan lukt dus dan niet.

Mr. Bondt schreef op dinsdag 19 december 2006 @ 15:43:
http://nl3.php.net/manual/nl/function.set-error-handler.php
Misschien heb je daar iets aan?

Die had ik al gevonden, maar ik had gehoopt dat er iets simpelers mogelijk was; lees: gewoon false returnen op een include, en verder gaan ofzo. Om nu al een héle errorhandler te gaan schrijven vind ik een beetje overdreven.

[McKaamos]

wat dacht je van

PHP:

include('somefile.php') or die(mijnerrorhandler("errormelding"));

?

[ Voor 10% gewijzigd door McKaamos op 19-12-2006 15:52 ]

[LuCarD]

De plugin eerst ophalen via http of via php execute, en dan testen op de waarde fatal error.

PHP:

$contents=file_get_contents("http://<SERVER_URL>/include/plugin.php");

// of
// $content=exec("php -q PLUGIN_DIRECTORY/plugin.php");

if (strpos($contents, "fatal") === false) {
include "http://<SERVER_URL>/include/plugin.php";
}
else {
echo "plugin has an error";
}

McKaamos schreef op dinsdag 19 december 2006 @ 15:51:
wat dacht je van

PHP:

include('somefile.php') or die(mijnerrorhandler("errormelding"));

?

Leuk bedacht maar hij komt nooit tot de die command.

[ Voor 25% gewijzigd door LuCarD op 19-12-2006 15:58 ]

[Scyth]

LuCarD schreef op dinsdag 19 december 2006 @ 15:57:
De plugin eerst ophalen via http of via php execute, en dan testen op de waarde fatal error.

PHP:

$contents=file_get_contents("http://<SERVER_URL>/include/plugin.php");

// of
// $content=exec("php -q PLUGIN_DIRECTORY/plugin.php");

if (strpos($contents, "fatal") === false) {
include "http://<SERVER_URL>/include/plugin.php";
}
else {
echo "plugin has an error";
}

Maar betekent dit niet dat hij in feite alles tweemaal include? Hier moet toch een veel makkelijkere oplossing voor zijn?

[McKaamos]

LuCarD schreef op dinsdag 19 december 2006 @ 15:57:
De plugin eerst ophalen via http of via php execute, en dan testen op de waarde fatal error.

PHP:

$contents=file_get_contents("http://<SERVER_URL>/include/plugin.php");

// of
// $content=exec("php -q PLUGIN_DIRECTORY/plugin.php");

if (strpos($contents, "fatal") === false) {
include "http://<SERVER_URL>/include/plugin.php";
}
else {
echo "plugin has an error";
}

[...]


Leuk bedacht maar hij komt nooit tot de die command.

denkje?
Op MySQL commands die het script laten stoppen werkt het iig... lijkt me wel waard om even te proberen iig.

[Foxl]

LuCarD schreef op dinsdag 19 december 2006 @ 15:57:
De plugin eerst ophalen via http of via php execute, en dan testen op de waarde fatal error.

PHP:

$contents=file_get_contents("http://<SERVER_URL>/include/plugin.php");

// of
// $content=exec("php -q PLUGIN_DIRECTORY/plugin.php");

if (strpos($contents, "fatal") === false) {
include "http://<SERVER_URL>/include/plugin.php";
}
else {
echo "plugin has an error";
}

Dan moet de plugin wel op zichzelf kunnen draaien, iets wat vaak niet het geval is lijkt me.

[ Voor 5% gewijzigd door Foxl op 19-12-2006 16:24 ]

[LuCarD]

Scyth schreef op dinsdag 19 december 2006 @ 16:18:
[...]

Maar betekent dit niet dat hij in feite alles tweemaal include? Hier moet toch een veel makkelijkere oplossing voor zijn?

E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR zijn fout meldingen die NIET kan afvangen zijn tijdens het draaien van een script.

Foxl schreef op dinsdag 19 december 2006 @ 16:23:
[...]


Dan moet de plugin wel op zichzelf kunnen draaien, iets wat vaak niet het geval is lijkt me.

Nee de plugin zou eigenlijk helemaal niks moeten doen. Je doet eigenlijk alleen maar een check of de code van de php correct is.

[ Voor 6% gewijzigd door LuCarD op 19-12-2006 16:37 ]

[Scyth]

McKaamos schreef op dinsdag 19 december 2006 @ 16:21:
[...]

denkje?
Op MySQL commands die het script laten stoppen werkt het iig... lijkt me wel waard om even te proberen iig.

Zelfs als ik 't zo doe: include($file) or die("errormelding");
Krijg ik een ellenlange lijst met rare foute includes. Hij vind 't niet leuk in ieder geval:

code:

/srv/blaat.com/_includes/_system/connect.php
Warning: doincludes(1): failed to open stream: No such file or directory in /srv/blaat.com/_includes/_system/boot.php on line 47

Warning: doincludes(): Failed opening '1' for inclusion (include_path='.:/tmp/upload:/usr/share/php/') in /srv/blaat.com/_includes/_system/boot.php on line 47
/srv/blaat.com/_includes/_system/parser.php
Warning: doincludes(1): failed to open stream: No such file or directory in /srv/blaat.com/_includes/_system/boot.php on line 47

enz.. enz...

haal ik het 'or die("errormelding");' gedeelte weg, stopt hij weer netjes bij de include die een fout genereerd.

[Shadowman]

php -l: Syntax check only (lint)

^ lijkt me de methode (cli, maar kun je wel parsen) die je zoekt .

@ hierboven: gaat niet werken, include is een language-construct, wat er uitgevoerd wordt is dit:
include $file or die(); > $file == true
effectief wordt er include (true) uitgevoerd.

[ Voor 47% gewijzigd door Shadowman op 19-12-2006 16:37 ]

[Scyth]

Shadowman schreef op dinsdag 19 december 2006 @ 16:35:
php -l: Syntax check only (lint)

^ lijkt me de methode (cli, maar kun je wel parsen) die je zoekt .

Mja, maar om nou commandline te gaan gebruiken

Ik wil gewoon èn runtime een include negeren als 't niet wil, how hard can it be?

* Scyth gaat even kijken naar een eigen errorhandler schrijven die 't script niet died.

[ Voor 4% gewijzigd door Scyth op 19-12-2006 16:39 ]

[ReLexEd]

Wat wij hier doen is een mapje toewijzen aan de plugins (die op zichzelfstaand allemaal individuele functies zijn), en die als volgt laten meenemen:

code:

    $currentDirectory = dirname(__FILE__);
    if ($handle = opendir($currentDirectory."/functionPlugins")) {
        while (false !== ($file = readdir($handle))) {
            if (substr($file,-4)==".php" && substr($file,0,9)=="function.") include_once "$currentDirectory/functionPlugins/$file";
        }
    }
    closedir($handle);

Waarbij de plugins dus qua naamgeving aan voorwaarden moeten voldoen. (beginnen met function. en eindigen op .php)

Als je er vervolgens voor zorgt dat je de functies afzonderlijk hebt gedefinieerd, zul je merken dat je een groot gedeelte van je debuggen kunt doen door de plugin gewoon aan te roepen....

Neemt niet weg dat structurele fouten in je syntax brackets te veel/te weinig niet kunt tegenhouden, zonder dat je met een eigen error-handler aan de slag gaat..

[Scyth]

ReLexEd schreef op dinsdag 19 december 2006 @ 16:44:
[...]
Neemt niet weg dat structurele fouten in je syntax brackets te veel/te weinig niet kunt tegenhouden, zonder dat je met een eigen error-handler aan de slag gaat..

En dát is nou precies wat ik óók doe, maar ook bij jullie crasht de hele zooi op parse errors in de functies dus. Dat wil ik niet. Nou lees ik dus net op de pagina's van php.net over set_error_handler():

quote: http://nl3.php.net/manual/en/function.set-error-handler.php

The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called.

Ik denk dat ik aan de oplossing van LuCarD vastzit. Eens even proberen.

[TheDane]

Zo doe ik 't:

PHP:

    $cmd = 'php -l '.$include_dir;

    $retval = shell_exec($cmd.'bestand.php');
    if (strstr($retval, 'Errors parsing')) $errors = 'errors in bestand.php';

    if ($errors) {
       // do nothing
    } else {
      include($include_dir.'bestand.php');
    }

Bij veel include-files is dit overigens wel gruwelijk traag ...

edit:
alsof dat nog niet tig keer gezegd is

[ Voor 7% gewijzigd door TheDane op 19-12-2006 16:59 ]

[Blaise]

Kan je niet iets doen met output buffering? (ob_start). Dat kan je ook gebruiken (misbruiken?) als basis voor een soort try / catch.

[WormLord]

Scyth schreef op dinsdag 19 december 2006 @ 15:48:
[...]

1: Onmogelijk, want een plugin werkt in harmonie met een geheel, als 't geheel gewoon crasht omdat je een plugin aan het devven bent... Nouja, you get the point.

Ehm, als je een plugin aan het ontwikkelen bent en er zit een fout in die het geheel laat crashen, dan is het juist zaak om de fout op te lossen. En als dat volgens jou onmogelijk is, dan get ik the point niet.

2: Insgelijks onmogelijk, omdat 't script niet verdergaat na de foute plugin. Opslaan lukt dus dan niet.

Ok, dat was ook maar een ideetje.

[_JGC_]

TheDane schreef op dinsdag 19 december 2006 @ 16:58:
Zo doe ik 't:

PHP:

    $cmd = 'php -l '.$include_dir;

    $retval = shell_exec($cmd.'bestand.php');
    if (strstr($retval, 'Errors parsing')) $errors = 'errors in bestand.php';

    if ($errors) {
       // do nothing
    } else {
      include($include_dir.'bestand.php');
    }

Bij veel include-files is dit overigens wel gruwelijk traag ...

edit:
alsof dat nog niet tig keer gezegd is

Waarom de output parsen? Je kunt veel beter de return code bekijken, wat 0 is bij een goed script, of iets anders bij een willekeurige fout (255 bij een script met fouten hier). Als PHP ineens besluit een andere foutmelding te geven in een nieuwere versie hang je met je string parsing.

[Janoz]

McKaamos schreef op dinsdag 19 december 2006 @ 16:21:
[...]

denkje?
Op MySQL commands die het script laten stoppen werkt het iig... lijkt me wel waard om even te proberen iig.

Het lijkt mij dat je je misschien eens ietsje beter moet verdiepen in waarom die constructie werkt bij sql commando's. Je hoeft je niet te schamen, volgens mij weet 90% van de php-devvers niet dat die constructie is gebaseerd op lazy evaluation.

Gezien de return value van een include niet afhankelijk is van het wel of neit hebben van een fatal error is het gebruik van de or die 'constructie' onzin.

[Janoz]

WormLord schreef op dinsdag 19 december 2006 @ 17:08:
[...]

Ehm, als je een plugin aan het ontwikkelen bent en er zit een fout in die het geheel laat crashen, dan is het juist zaak om de fout op te lossen. En als dat volgens jou onmogelijk is, dan get ik the point niet.

Het is onmogelijk om de webapplicatie maar verder te laten gaan met het request na de fatale fout. De fout is immers neit voor niks fataal. Waar zou het script verder moeten. Het script weet niet welk deel de plug in is en welk deel framework enz enz.

[TheDane]

_JGC_ schreef op dinsdag 19 december 2006 @ 17:10:
[...]


Waarom de output parsen? Je kunt veel beter de return code bekijken, wat 0 is bij een goed script, of iets anders bij een willekeurige fout (255 bij een script met fouten hier). Als PHP ineens besluit een andere foutmelding te geven in een nieuwere versie hang je met je string parsing.

Hmm, good point Was eigenlijk allang blij dat dit ze werkte

[Scyth]

Janoz schreef op dinsdag 19 december 2006 @ 17:20:
[...]

Het is onmogelijk om de webapplicatie maar verder te laten gaan met het request na de fatale fout. De fout is immers neit voor niks fataal. Waar zou het script verder moeten. Het script weet niet welk deel de plug in is en welk deel framework enz enz.

True, maar een include is een éxtra stukje code. Als dat niet werkt, kan het script wat de include aanroept evt. gewoon doorgaan, echter zonder de include.

Dit gaat fout zodra het hoofdscript dingen uit de include gebruikt, maar in het geval van plugins is dit niet het geval. Het script kan gewoon lekker doorgaan, en de include af laten sterven.

Misschien dat, als wat ik wil niet mogelijk is, ik moet kijken naar een andere constructie, maar vooralsnog probeer ik eerst iets hierop te vinden. Iets met een whitelist/blacklist ofzo.

[WormLord]

Janoz schreef op dinsdag 19 december 2006 @ 17:20:
[...]

Het is onmogelijk om de webapplicatie maar verder te laten gaan met het request na de fatale fout. De fout is immers neit voor niks fataal. Waar zou het script verder moeten. Het script weet niet welk deel de plug in is en welk deel framework enz enz.

*Zucht* Dat klopt dan wel, maar blijft het punt dat iemand die plugin aan het ontwikkelen is en dus die fatale fout zal moeten oplossen. En dat iemand die plugin aan het systeem toevoegd heeft, en die plugin dus ook zou kunnen verwijderen omdat erdoor een fatale fout optreed.
Soms moet je gewoon proberen om het probleem bij de bron aan te pakken, en in dit geval is dat dus een plugin die zorgt dat een applicatie niet werkt. Dus: aanpassen of verwijderen die plugin!

Dat het automatisch blacklisten van de plugin niet werkt op de manier die ik in eerste instantie voorstelde, dat snap ik. Dat was ook maar even een ideetje zonder enige garantie of test. Maar het aanpassen van een plugin die in ontwikkeling is, dat kan toch nooit van z'n lang zal ze leven onmogelijk zijn? Ik bedoel, het was ook mogelijk om de fatale fout in de plugin te introduceren!

Maar goed, blijkbaar denk ik te simpel. Ik ben dan ook maar een devver.

[Janoz]

Ik weet niet waar de zucht voor nodig is. Ik probeer alleen duidelijk te maken wat Scyth met 'onmogelijk' bedoeld. Natuurlijk is het mogelijk om die plugin weer weg te halen. Het punt is dat de topicstarter zijn applicatie zo slim wil maken dat hij zelf dat ding weigert te includen.

[SchizoDuckie]

Kan je niet gewoon iets met http://nl3.php.net/manual/en/function.php-check-syntax.php?

edit:
oops... php5

[Scyth]

SchizoDuckie schreef op woensdag 20 december 2006 @ 10:37:
Kan je niet gewoon iets met http://nl3.php.net/manual/en/function.php-check-syntax.php?

edit:
oops... php5

Mja, als ik 't geheel PHP5 compatible maak wordt m'n leven een stuk makkelijker. check-syntax is idd dan een optie, maar try-catch ook. Echter, we moeten reeel blijven; op niet alle webservers draait reeds PHP5.

Nou kan ik m'n eigen server waarop ik aan het devven ben btw wel op php5 zetten, maar dit is eigenlijk 't uiterste wat ik wil doen. Daar komt bij dat dit mogelijk moet zijn in PHP4, als dit niet werkt, is m'n hele insteek al verkeerd, want er zijn genoeg plugin-based systemen geschreven in PHP4.

Ik heb overigens gekeken naar de shell-exec command en dan php -l aanroepen, maar de hele include lijst duurt dan bijna anderhalve seconde langer. Dat is niet een verslechtering van een paar cruciale milliseconden, maar in een redelijke lijst met plugins een verslechtering van etterlijke duizenden milliseconden. Ontoelaatbaar. Die optie valt dus af.

edit:

Ik zie net ook dat de functie check_syntax al weer deprecated is, en zelfs al geremoved. In alleen PHP 5 <= 5.0.4 werkt 't.

Misschien dat ik 's moet gaan kijken naar een simpele regexp die checkt op correcte functiegebieden (afbakening door { en } ) en regelafsluiting: ;

[ Voor 11% gewijzigd door Scyth op 20-12-2006 11:27 ]

[SchizoDuckie]

Scyth schreef op woensdag 20 december 2006 @ 11:23:
[...]

Mja, als ik 't geheel PHP5 compatible maak wordt m'n leven een stuk makkelijker. check-syntax is idd dan een optie, maar try-catch ook. Echter, we moeten reeel blijven; op niet alle webservers draait reeds PHP5.

Kijk dat vind ik dus als programmeur momenteel echt een non-reden om nog php4 te coden. Zolang als jij je code voor php4 compatible houdt worden beheerders van webservers niet geforced om te upgraden. Ik stel gewoon als *eis* tegenwoordig dat je PHP5 draait als je een van mijn scripts wil gebruiken c/q er via mijn werkgever een site gebouwd wordt voor je. (maar dat is afhankelijk van je doelgroep natuurlijk verder)

Ik zie dat hele php5 / php4 verhaal steeds meer een ie6/ie4 / ie/netscape verhaal worden. Depricated troep die gewoon uitgefaseerd moet worden, ook al willen sommige mensen dat niet.

Om even back on-topic te komen:
Als oplossing voor je probleem kan je ook een lijstje bijhouden met een checksum van de bestanden in je plugins dir. Als de checksum van een bestand gewijzigd , of hij komt nog niet voor in de plugins dir, kun je eenmalig een php -l uitvoeren en de checksum lijst updaten en deze weer wegschrijven naar een file of database ofzo. Je wil namelijk gewoon niet dit soort 1malige acties elke run uitvoeren, dus daar verzin je dan een soort caching voor

[ Voor 26% gewijzigd door SchizoDuckie op 20-12-2006 11:39 ]

[Scyth]

SchizoDuckie schreef op woensdag 20 december 2006 @ 11:33:
Om even back on-topic te komen: als oplossing voor je probleem kan je ook een lijstje bijhouden nog eventueel met een checksum van de bestanden in je plugins dir en als de checksum van een bestand gewijzigd is kun je eenmalig een php -l uitvoeren en de checksum lijst updaten.
In je plugin include functie check je dan de checksums, of ie voorkomt in je lijstje met goedgekeurde plugins en voila

Da's nog niet eens zo'n slecht idee... En is te doen met file_get_contents() ofzo. Dan hoeft PHP de file niet te parsen, alleen maar op te halen, te checken en te validaten adhv de checksum/whitelist.
Dat is volgens mij ook nog eens sneller dan steeds een check_syntax module.

Echter, ik heb me nu als doel gesteld een simpele check_syntax module te schrijven; aangezien ik een gegronde aversie heb tegen shell gebruik in scripts als ' the easy way out' .

[SchizoDuckie]

Scyth schreef op woensdag 20 december 2006 @ 11:39:
[...]

Da's nog niet eens zo'n slecht idee... En is te doen met file_get_contents() ofzo. Dan hoeft PHP de file niet te parsen, alleen maar op te halen, te checken en te validaten adhv de checksum/whitelist.
Dat is volgens mij ook nog eens sneller dan steeds een check_syntax module.

Echter, ik heb me nu als doel gesteld een simpele check_syntax module te schrijven; aangezien ik een gegronde aversie heb tegen shell gebruik in scripts als ' the easy way out' .

Een check_syntax module impliceert dus dat je de complete php parser met syntax checks gaat nabouwen? Lijkt me een leuk leerzaam projectje voor tussendoor ergens maar niet echt nuttig verder Verder hoef je de hele *inhoud* van de file op te halen, maar je hoeft alleen de checksum er van te berekenen, en daar heeft php al standaard functies voor.

En 'the easy way out' is natuurlijk een kwestie van inzicht, zoals ik het vanaf hier zie zal die functie alleen zeer sporadisch uitgevoerd worden bij site-onderhoud en is het daar gewoon the right tool for the job zeg maar

[updateje] interessant linkje nog voor je maybe? klik

[ Voor 5% gewijzigd door SchizoDuckie op 20-12-2006 11:48 ]

[RaZ]

Ik, als n00b, doe ook maar even een gooi.

In de directory waar je include PHP files staan, maak je van elk bestand, een .ok extentie
Voor je het bestand include, kijk je of het .ok bestand bestaat, zoja, de .php includen.
Zodra het php bestand geinclude wordt, mik je het .ok bestand weg, en aan het einde van het bestand maak je weer een .ok bestand aan.

Beukt je plugin er waar dan ook uit, is er geen .ok bestand meer, dus wordt'ie de volgende keer ook niet ge-include.

Lijkt me vrij haalbaar, toch?

[SchizoDuckie]

RaZ schreef op woensdag 20 december 2006 @ 11:48:
... verhaal ...

Waarom zou je elke keer zo'n hoop file operations willen als dat niet nodig is? Een bestand hoef je alleen maar te checken als het gewijzigd is

[Scyth]

SchizoDuckie schreef op woensdag 20 december 2006 @ 11:42:
[updateje] interessant linkje nog voor je maybe? klik

Die had ik al gevonden, maar als je in de source kijkt is 't een zwaar overrated applicatie die ook gewoon commandline php -l gebruikt. Er zit alleen een leuk roze knisperpapiertje om