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.
Alle logs worden niet aangevuld met errors als ik de betreffende pagina bezoek. Als ik een error zie op een andere pagina, dan zie ik die errors wél in die logs verschijnen. Meaning: de logs worden succesvol aangevuld bij errors. En dus: geen errors bij die witte pagina's.
Toch heb ik nog wat andere notifies en warnings gevonden en weggewerkt. Al kwamen die warnings niet naar voren op die witte pagina. Dit had geen effect.
Evengoed dacht ik wel in die richting en heb dus
error_reporting(0);
en
ini_set('display_errors', 0);
ingesteld. Ook dit had geen effect.
Kortom, ik ben helemaal verblind door die witte pagina en weet niet meer waar ik moet kijken.
De method *getSmartyObject()* doet in principe een *new Smarty()* en voegt wat variabelen toe met *->assign()*. Niet heel bijzonder denk ik. Of zie jij of iemand anders een verouderde manier van Smarty binnenhalen in de code hierboven?
Dank!
[size=xsmall]Toevoeging op 30/05/2022 11:53:25:[/size]
Dit lijkt ook niet te werken:
$orders = new ordersDataObject();
$smarty->registerObject('testObject', $orders, null, false);
en dan...
{testObject->getLinkTo}
[size=xsmall]Toevoeging op 30/05/2022 13:08:03:[/size]
Plus:
De template_c file wordt inderdaad gecreëerd. Dus schrijfrechten is het ook niet.
[size=xsmall]Toevoeging op 30/05/2022 13:15:30:[/size]
Om preciezer te zijn:
1. Als ik {translate}Vertaal iets{/translate} toevoeg wordt de template NIET aangemaakt.
2. Als ik alleen maar <div>Vertaal iets</div toevoeg, wordt de template wél aangemaakt en wordt de pagina wel gerenderd.
Dus ja, het probleem zit hem niet in schrijfrechten, maar registerObject() en registerPlugin() genereren bij gebruik zelf géén foutmelding, maar zorgen er wel voor dat tijdens de rendering van de templates ik een witte pagina krijg.
Ik zie niet waar ik ze kan benaderen behalve dan voor promotie of reclame. Op Reddit is hun community, maar die is niet heel actief. Het duurt soms maanden eer je een reactie krijgt.
Maar ik heb daar ook maar een bericht neergezet. Wellicht komt daar toch nog iemand langs. Ondertussen ga ik nog maar even graven. Mocht ik het weten, dan zet ik de oplossing hier neer. Mocht er iemand hier langskomen die het weet: please, do tell!
Met @ voor file_exists onderdruk je een mogelijke foutmelding. Ik zeg niet dat dit de oplossing is, maar wellicht is er sprake van een niet-bestaand bestand of is de inhoud van de variabele onjuist. De foutmelding die dit normaal gesproken zou opleveren krijg je nu niet te zien. Ik zou die @ daar dus sowieso even weghalen.
Helaas is dit het niet. Overigens staat de app wel vol met oude en wankele code. Dus elke opmerking is wel handig, want inderdaad...dat zou het zomaar eens kunnen zijn.
Alleen juist in dit geval - en door jou ben ik gaan zoeken - is de code die ik gaf nou net niet de code die wordt uitgevoerd voor déze smarty problemen. Door de hele applicatie heen staan dezelfde van dit soort codes. En juist op de pagina waar het mis gaat is het net even anders:
Let ook op *fetch()*. Ik zag dat Smarty een DEBUG functie heeft. Wauw! De oplossing is nabij! Maar hij rendert het niet. Je kunt $debugging = true ergens instellen en dan zou hij een debug-scherm moeten toveren. Doet ie niet. Komt door onder andere die fetch. Je moet display() gebruiken.
Maar helaas, als ik daar *display()* van maak doet ie niks nieuws. Maar wellicht is dit wel een optie om te onderzoeken en die debug temp aan de praat te krijgen.
Ik heb de PHP Storm debug aan de praat gekregen door de applicatie lokaal te draaien. Dus met Xampp en de professionele serverinstellingen krijg je exact hetzelfde probleem. Op zich ook interessant, want dan lijkt het niet aan serverinstellingen te liggen.
En dan zie je dat hij tot heel diep in de Smarty engine komt. Tot aan het bestand 'smarty_internal_smartytemplatecompiler' waar hij de 'lexers' parset. In ieder geval zijn dat die {translate} items. En dan gaat het mis, maar waarom? Geen idee. Vandaag met frisse moed weer verder debuggen met méér breakpoints om te zien of ik echt nog dieper kan gaan tot het werkelijke punt waar het fout gaat.
**Saillant detail**
{translate}Vertaal dit{/translate} dat gaat fout.
Maar als je een variable wilt weergeven met {$foo}, dat lukt wel.
