Ik heb onlangs mijn gehele scripting zo goed als mogelijk omgezet van 5.4 naar 7.4.
Alles werkt gelukkig naar behoren. Maar als ik nu naar versie 8 overschakel dan loopt mijn website vast. Ik zie geen error afhandeling op de pagina dus ik weet ook niet wat ik aan moet passen. Ik vernam dat er diverse drastische aanpassingen zijn gedaan in 8.0 maar kom er niet goed uit welke dat allemaal zijn.
Is er een tool om mijn huidige script in te laden en advies krijg van de tool wat er fout is of anders moet?
Is er een lijst met een overzicht van de wijzigingen?
Als de pagina leeg is, is de HTML-broncode dat ook? Of zie je kenmerken van je site?
En wat als je in .htaccess je eigen error_ log defineert? Als deze geen errors aangeven zal er iets anders mis zijn in je script. Dan zul je het probleem moeten isoleren.
Broncode is leeg als ik hem op versie 8 zet. Heb dus ergens een fatal error in mijn code. Maar welke? Met versie 7.4 werkt de website prima.
Ik heb echt geen kennis om een eigen error log te definiëren. Kan/wil je helpen?
Met zoiets? Uiteraard een geldig pad, en schrijfbaar bestand.
php_flag log_errors On
php_value error_log "/home/username/php_errors.log"
Maar als Strato zegt dat ze een error_log hebben, dan moet je het daar in vinden. Test het eens uit met een opzettelijke error. Zie je niks bij Strato in de error_log dan moet je dit bij hun melden.
Je klikt toch wel op de knop [Toon error log] hè, en je niet in de access_log aan het graven bent?
Met zoiets? Uiteraard een geldig pad, en schrijfbaar bestand.
php_flag log_errors On
php_value error_log "/home/username/php_errors.log"
Maar als Strato zegt dat ze een error_log hebben, dan moet je het daar in vinden. Test het eens uit met een opzettelijke error. Zie je niks bij Strato in de error_log dan moet je dit bij hun melden.
Mijn grote dank, ik ga dit eens proberen. Ben benieuwd.
Een heel simpele manier van debuggen is door na een stukje code deze PHP-regel te plaatsten:
<?php
exit('*** Hij doet het nog! ***');
?>
Deze regel stopt de code en toont de tekst *** Hij doet het nog! *** op je beeldscherm.
Zet deze regel na bijv. de eerste 20 regels. Zie je de tekst in beeld komen? Prima, dan werkt de code op dat moment nog. Haal de regel nu weg en plaats 'm een stukje verder. Komt de tekst weer in beeld? Prima, het werkt nog steeds tot dat punt. Zo ga je door todat je de tekst niet meer in beeld ziet. Dan zit er dus iets fout in dat laatste stukje. Op deze manier kun je het probleem proberen te isoleren. Als je weet waar het probleem ongeveer zit, kun je je gaan bedenken waar het mis zou kunnen gaan.
?Onbekende gebruiker
30-06-2022 14:08
Ozzie PHP op 29/06/2022 16:42:45
Ad Fundum, begrijp me niet verkeerd hoor, maar kun je je "afkeur" of hoe je het ook wil noemen jegens PHP niet gewoon achterwege laten?
Ik zal er op gaan letten. Het is er min of meer ingeslopen na 21 jaar programmeren in PHP. In die tijd heeft PHP aardig wat veranderingen ondergaan die lang niet allemaal prettig waren.
Enige ergernis is gekomen nadat ik met ontwikkelaars van PHP heb gesproken, die het (op hun manier) verbeteren van PHP (uiteraard) meer aandacht gaven dan het überhaupt op orde hebben van documentatie voor stervelingen als ondergetekende. En dan is zo'n opmerking als over de Backward Incompatible Changes van elke 'minor' release ook een terechte: je loopt ook steeds achter de feiten aan. Ik had liever dat ze alle domme functies (zoals utf8encode()) zouden schrappen en gewoon een enkele (of paar) goede standaarden zouden hebben, en die goed documenteren. Dat zou al helpen voor beginnende PHP-ers. In plaats daarvan werden 'generator'functiess een stuk interessanter gevonden. Persoonlijk vind ik dat weinig dienstbaar, maar niet iedereen is zoals ik (gelukkig).
Mijn afgeven op PHP komt ook omdat het lastig is om toe te geven dat PHP voorziet in een behoefte. Namelijk de behoefte om op relatief eenvoudige wijze veel voor elkaar te krijgen. Ondanks alle kritiek van derden is het ook een vaste taal in de Linux-omgeving. En ik kom er zelf slecht van af, als je de meeste valkuilen kent, werkt het gewoon erg goed. PHP is overal.
[size=xsmall]Toevoeging op 30/06/2022 14:17:16:[/size]
Ward van der Put op 29/06/2022 18:01:26
Ad Fundum is een van de weinigen hier op het forum die beseft dat hij problemen voor had kunnen zijn met unit tests. En überhaupt een van de weinigen die weet wat unit tests zijn...
Ward, je slaat de spijker op z'n kop. Maar ook hiervoor geldt: ik loop achter de feiten aan. Ik had van meet af aan met unit tests moeten beginnen, geen speld tussen te krijgen. Met Unit tests zou ik veel breaking changes voor kunnen zijn.
En ik zou het hebben gedaan, ware het niet dat de software die ik met PHP heb geschreven onverkoopbaar is, omdat PHP de broncode niet kan compileren naar objectcode. Klanten zouden dan beschikken over de source code, wat ik geen optie vind. Voor de tussenperiode werk ik met SourceGuardian. SaaS was niet voor al mijn klanten een optie, en NEN-7510 certificering lag ook niet meteen voor de hand. Vandaar dat ik ook wel iets anders moest gaan doen dan PHP. Zoals ik eerder heb laten weten ben ik nu heerlijk in Rust bezig. Verklaart ook mijn bias 'doe zoveel mogelijk in de database, niet in PHP', scheelt weer porteren naar een andere taal.
In ieder geval dank voor de positieve inbreng met de aankomende veranderingen in PHP 8.2 en 9.0, het wordt nog wel eens wat!
Ik ben al enige stappen verder inmiddels en kom erachter dat het meeste wel draait onder 8.0
Ik begrijp alleen even niet hoe om te gaan met de wijziging van de controle of iets bestaat of niet. De != afhandeling is gewijzigd en werkt niet in php 8.
Nu vraag ik me ook af of ik hier niet beter een function van kan maken, maar daar werk ik nooit mee. Zou je me alsjeblieft willen helpen hiermee?
$controle_ip_in_mandje = mysqli_query($connect_agenda, "SELECT * FROM Mandje where IP='$ip_x'");
$row_x = mysqli_fetch_object($controle_ip_in_mandje);
if ($row_x['IP'] != $ip_x && $row_x['Port'] != $ses_id)
