Ik ben bezig met het upgraden van de applicatie die hier intern gebruikt wordt. We gaan van PHP7.2 naar PHP8.1. Daarnaast maakt het systeem gebruik van Smarty Templating. Bij het genereren van een template waarin Block Functions worden gebruikt, loopt het vast. Resultaat is géén error, maar een wit scherm.
Ik heb een test template met deze code:
<div>Een of andere tekst</div>
Deze wordt gerenderd. Geen probleem. Maar dan deze:
<div>{translate}Een of andere tekst{/translate}</div>
Wit scherm. Het 'registeren' van deze blockfunctie gaat goed. Want als ik de bedoelde method
smarty_waf_translate
hernoem, dan gaat die registry niet goed. Dus Smarty vindt de plugin wel degelijk.
Zo'n wit scherm had ik hier al eerder geplaatst. De functie
class_exists()
zorgt ervoor dat de autoload wordt afgevuurd en resulteerde óók in een wit scherm. Ik heb deze opgelost met een workaround. Maar nu zit ik dus vast aan een wit scherm bij het afvuren van block functions.
Ik heb xDebug in PHPStorm aan de praat gekregen en kan de code helemaal tot diep in smartyview code volgen. En dáár gaat het ergens fout. Dit, terwijl Smarty compatible zou moeten zijn met PHP8.1. Daarnaast, áls het überhaupt al ligt aan de code van Smarty, dan zou de hele wereld met het probleem moeten komen.
Dus wat nu dan?
Ik heb het gevoel dat het aan serverinstellingen ligt. Heb al de php.ini van de server met PHP 7.2 op mijn lokale PHP 8.1 server gezet. Dat gaf het verrassende resultaat dat mysqli_report() niet gedefinieerd was. Maar dit was een false flag. Dus daar kwam ik geen stap verder mee.
Dan kun je óf de betreffende class van tevoren al inladen (via require), of je moet een 2e (jouw eigen) autoload functie registreren. Die wordt dan aangeroepen als de eerste autoload functie geen resultaat oplevert.
Al met al lijken we het initiële probleem dus teruggbracht te hebben tot een probleem met het automatisch inladen van classes.
Om hier zeker van te zijn kun je voor de betreffende code de betreffende class eens inladen en kijken of ie het dan wel doet:
Dat betekent dus, als de class niet gevonden wordt stelt ie de var "self::$_tag_objects[ $tag ]" in op false. Waarna de rest van de code wordt uitgevoerd. Ik wíl dus dat ie dat ook doet. Dat ie de "ELSE" uitvoert, want die class bestaat terecht niet. Dat is normaal.
Maar hij kómt niet in de else, omdat de function "class_exists()" de hele PHP uitvoer laat klappen. De hele code compilatie vna PHP stopt als class_exists de class niet kan vinden. Dat is niet normaal. Het hoort dan gewoon een "false" terug te geven ipv vast te lopen.
Probleem anders beschreven:
if (class_exists('niet_bestaande_class') === false) {
echo 'class bestaat niet';
} else {
echo 'class bestaat wel';
}
Verwacht resultaat:
'class bestaat niet' wordt weergegeven.
In je code staat nergens een class_exists(). Het moet met class_exists() werken, want het gaat hier om 3rd Party code van Smarty Engine. Ik kan niet in die code gaan lopen wroeten.
Overigens voor jouw beeldvorming, dit...
if (false) {
// do anything
}
...is wat ik 'dode code' noem. Het 'do anything' wordt nooit uitgevoerd, omdat het in een 'if false' staat. Dat is nooit true.
De vraag was of als je die class_exists functie er (tijdelijk) even tussenuit haalt, of ie dan wel doet wat je verwacht. Hij zou dan direct door moeten gaan naar jouw eigen code. Dit om uit te sluiten dat het probleem in jouw eigen code zit.
Aha! Duidelijk. Ja, ik wist al dat de code het zou doen als ik dat probleem zou omzeilen. Maar goed.
Ik heb overigens vrij gedetailleerd nu de oorzaak gevonden. Nog niet de exacte code, maar wel welke module precies. Onze applicatie gebruikt een...hou je vast...16 jaar oude 3rdParty module van een developer die zelf ook aan de applicatie heeft gewerkt. Zodra die module wordt "geinclude" werkt class_exists() niet meer. Als ik die module skip, doet alles het weer, maar ik ben niet zeker van of ook echt alles het doet. Straks wordt die 'crudder' module toch ergens nog gebruikt en is het vitaal voor bepaalde delen van onze app.
Ik heb een PHP Storm "Code Inspection" uitgevoerd.
533 PHP errors
918 General errors
En nog veel meer.
Ik ga me bezinnen, maar helaas kan ik hier niet een detail weergeven van déze specifieke code veroorzaakt het. Mocht ik nog wat nuttigs ontdekken, dan meld ik het wel. Mocht iemand hier nog ideeën hebben hoe hiermee om te gaan, dan mag je altijd reageren natuurlijk. Ik houd deze thread nog wel even bij.
Bedankt allen.
[size=xsmall]Toevoeging op 01/06/2022 12:03:29:[/size]
Crudder importeert "phpdocx_free", dus nog gedetailleerder: het ligt dááraan. Als ik de crudder module aanpas zodat ie deze module skipt doet ie het ook.
Sorry voor de vele updates maar hier is de precieze reden van het breken van class_exists().
De "Crudder" includeerde een andere module, namelijk "phpdocx_free". Die registreerde ook enkele autoload functies. Daarin staan PHP5 notaties die dus in PHP8 fatal errors veroorzaken (zoals curly braces). Alleen...die module zette errornotaties uit met eigen code. Dus op de DEV veroorzaakte dat wel een error, maar dat zag je niet. En die error werd alleen veroorzaakt, als je de code ook actief maakte door.......de autoload af te vuren met "class_exists()".
Dus zodra je een class_exists() deed en de class werd niet gevonden, vuurde hij ook de autoloads af van "phpdocx_free" waarin fatal errors voorkwamen. Die zag je niet, want errors stonden in die module uit en dus had je een wit scherm.
Bedankt allen. Nu hoef ik echt geen hulp meer hier. Het is nu een kwestie van...hebben we crudder en phpdocx_free nodig of niet. Want updaten van die modules kan niet, ze zijn inmiddels overleden.
