count() TypeError na een PHP 8-update oplossen

Voor je begint

Bewaar de volledige foutmelding en het tijdstip in een privénotitie. Noteer welke pagina of handeling de fout oproept en wat er vlak daarvoor veranderde. Een screenshot van alleen een lege pagina is minder bruikbaar dan de eerste foutregel uit het log.

Deel geen wachtwoorden, klantgegevens of volledige serverpaden in een openbaar forum.

Maak een back-upEen back-up is een kopie van je hele website, apart bewaard, zodat je hem kunt terugzetten als er iets misgaat. van bestanden en database voordat je iets wijzigt. Controleer ook hoe je die terugzet. Werk bij voorkeur op een afgeschermde testkopie met dezelfde PHP-versieEen PHP-versie is het nummer van de uitgave van PHP waarop jouw website draait, zoals 8.3..

Schakel daar echte betalingen en uitgaande klantmails uit. Verander één onderdeel per proef en schrijf op wat je hebt aangepast, zodat een mislukte poging eenvoudig terug te draaien is.

Wat count() verwacht

count() telt elementen in een array of in een object dat Countable ondersteunt. De officiële PHP-documentatie vermeldt dat een ongeldig type vanaf PHP 8.0 een TypeError oplevert. Eerdere versies reageerden anders.

Daardoor kan bestaande code die onvoldoende controleert ineens stoppen na de upgrade.

Een array is een verzameling waarden. Null betekent dat er geen waarde aanwezig is, en false kan bijvoorbeeld een mislukte bewerking aangeven. Die betekenissen zijn niet onderling uitwisselbaar.

De vraag is daarom niet alleen hoe je de foutmelding voorkomt, maar ook waarom de verwachte verzameling ontbreekt.

Oplossen in vijf stappen

1. Bewaar de foutregel met bestand, regelnummer en genoemd type. Noteer welke pagina, filterkeuze of zoekopdracht de fout oproept. Vermeld of het alleen gebeurt bij lege resultaten. Deel geen persoonlijke zoektermen of klantgegevens als die niet nodig zijn voor het onderzoek.
2. Laat vaststellen welk onderdeel count() aanroept. Bij een pluginEen WordPress-plugin is een uitbreiding die je aan je WordPress-site toevoegt voor een extra functie, zoals een formulier of een webshop. controleer je de beschikbare update en de opgegeven PHP-compatibiliteit. Bij maatwerk laat je de ontwikkelaar terugzoeken waar de waarde vandaan komt. Een databasevraag of externe koppeling kan eerder in de route een ander resultaat hebben gegeven.
3. Bepaal wat de toepassing met een leeg resultaat hoort te doen. Een lege lijst kan terecht nul items bevatten. Een mislukte gegevensopvraag moet mogelijk juist als fout worden afgehandeld. Laat dit verschil expliciet vastleggen voordat iemand overal een terugval naar een lege array toevoegt.
4. Test de gerichte code- of pluginwijziging op de testkopie. Laat zowel een normale lijst, een lege lijst als een mislukte opvraag controleren. Een typecontrole kan nuttig zijn, maar mag geen echte fout verbergen. De gekozen oplossing moet passen bij de betekenis van de gegevens.
5. Controleer de uitkomst in de interface. Kloppen aantallen, paginering en lege-resultaatmeldingen? Bekijk ook het nieuwe log. Het verdwijnen van de TypeError is slechts één controle; bezoekers moeten nog de juiste informatie krijgen wanneer er wel of geen resultaten zijn.

Waarom nul niet altijd een oplossing is

Denk aan een voorraadkoppeling die geen antwoord geeft. Dat is niet hetzelfde als een geldige melding dat er nul producten zijn. Blind alle onverwachte waarden omzetten naar een lege lijst kan dat onderscheid verliezen.

Dit voorbeeld illustreert waarom een ontwikkelaar de gegevensstroom moet controleren, ook wanneer een korte typecontrole de fout lijkt op te lossen.

Wanneer je dit beter laat doen

Gebruik het hulpformulier hieronder als de telling invloed heeft op voorraad, bedragen of rapportages, of als de waarde uit meerdere plugins komt. Geef een voorbeeld van een geslaagde en een mislukte handeling zonder privégegevens. Vraag om tests voor normale, lege en foutieve invoer.

Daarmee maak je het herstel controleerbaar voor iemand die het probleem later opnieuw moet beoordelen.

Controle na herstel

Herhaal eerst precies de handeling die misging. Controleer daarna inloggen, een formulier versturen en de belangrijkste route van jouw website. Gebruik voor een winkel een testbestelling zonder echte afschrijving.

Bekijk het log op nieuwe meldingen met een recent tijdstip. Alleen een werkende homepage bewijst nog niet dat het hele probleem weg is.

Bewaar de gebruikte versies, de uitgevoerde wijziging en het resultaat bij je onderhoudsnotities. Spreek af wie de eerstvolgende update controleert. Stop als dezelfde fout terugkomt terwijl de veronderstelde oorzaak al is opgelost.

Dat is een reden om de diagnose opnieuw te bekijken, geen reden om steeds meer instellingen tegelijk te veranderen.