__autoload() niet meer ondersteund na PHP-update

Betekenis van de melding

De melding __autoload() is no longer supported wijst op een oude manier om PHP-klassen te laden. Een klasse bundelt code voor een bepaald onderdeel. PHPPHP is de programmeertaal waarmee veel websites, zoals WordPress-sites, hun pagina's maken op het moment dat een bezoeker erom vraagt. 8 ondersteunt deze speciale functie niet meer.

De migratiegids verwijst naar spl_autoload_register(). Dit artikel gaat over de verwijderde laadfunctie, niet over iedere melding dat een klasse ontbreekt.

Voor je begint

Bewaar de volledige foutregel met tijdstip in een privénotitie. Noteer welke handeling misging, welke PHP-versieEen PHP-versie is het nummer van de uitgave van PHP waarop jouw website draait, zoals 8.3. nu draait en welke onderdelen tegelijk zijn bijgewerkt. Deel alleen gegevens die nodig zijn voor onderzoek.

Een openbaar forum is geen geschikte plek voor klantgegevens, toegangscodes of volledige serverpaden.

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 wijzigingen laat uitvoeren. Controleer of die back-up bruikbaar is. Gebruik een afgeschermde testkopie met dezelfde PHP-versie en relevante instellingen.

Schakel daar echte betalingen en uitgaande klantmails uit. Spreek af wie de wijziging uitvoert en wie het resultaat controleert. De onderstaande stappen zijn een onderzoeksadvies, geen diagnose van jouw website.

Mogelijke oorzaak

Zoek in het genoemde bestand naar de definitie van __autoload. Onderzoek of die 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., themaEen WordPress-thema is het ontwerp van je WordPress-site: het bepaalt hoe pagina's eruitzien en hoe ze zijn opgebouwd. of meegeleverde bibliotheek hoort. Een update van PHP kan oude laadcode zichtbaar maken, maar bewijst niet welk pakket verantwoordelijk is.

Laat eerst vaststellen wie het bestand onderhoudt. Alleen de functie hernoemen levert nog geen werkende registratie op.

Oplossen in vijf stappen

1. Noteer het bestand met de oude functie en het pakket dat dit bestand levert. Bewaar ook de versie van dat pakket, zodat de onderhoudspartij dezelfde code kan bekijken.
2. Controleer of de leverancier een geschikte update heeft. Laat bij maatwerk vaststellen welke klassen de bestaande lader hoort te vinden en waar die bestanden staan.
3. Laat de vervangende lader registreren via spl_autoload_register(). Vraag hoe deze samenwerkt met al aanwezige laders; vervang niet zonder onderzoek de complete laadvolgorde.
4. Test het eerste gebruik van de betrokken klasse in een nieuw verzoek. Een scherm dat de klasse niet gebruikt, is geen bewijs dat de reparatie werkt.
5. Controleer zowel de bezoekersroute als de beheeractie die hetzelfde pakket gebruikt. Leg vast welke klasse geladen werd en of nieuwe logs de oorspronkelijke melding nog bevatten.

Een concrete acceptatieproef

Gebruik als proef een WordPress-plugin die een documentvoorbeeld toont. Open op de testkopie zowel het voorbeeld als het instellingenscherm. Spreek vooraf af welk document en welke instellingen zichtbaar moeten zijn.

Herhaal de proef vanuit een nieuwe sessie. Dit is een testvoorstel, geen claim dat een bepaalde plugin deze fout bevat. Vraag bij een vervolgmelding over een ontbrekende klasse om onderzoek van het pad en de registratie, niet om willekeurig extra bestanden in te laden.

De verantwoordelijke code vinden

Vraag bij een plugin of thema eerst naar de versie die bij de bedoelde PHP-omgeving past. Geef de onderhoudspartij de foutregel en de handeling waarmee die ontstaat. Vraag om een gerichte wijziging met een uitleg van het verwachte resultaat.

Bij eigen code hoort dezelfde uitleg bij de overdracht aan de ontwikkelaar.

Laat niet tegelijk allerlei ongerelateerde onderdelen wijzigen. Bewaar het onderscheid tussen de oorspronkelijke melding en eventuele nieuwe meldingen na een aanpassing. Noteer per proef de gebruikte codeversie en de testgegevens.

Zo kun je een resultaat aan een concrete wijziging koppelen. Een proef waarbij niemand weet welke bestanden zijn veranderd, geeft geen bruikbaar acceptatiebewijs.

Spreek vooraf af wanneer een proef wordt afgekeurd. Denk aan verkeerde inhoud, verdwenen instellingen of een bezoekershandeling die niet meer kan worden afgerond. Het verdwijnen van een melding is maar een deel van de controle.

Laat de eigenaar van de website ook het resultaat beoordelen dat een bezoeker werkelijk nodig heeft.

Wanneer hulp nodig is

Gebruik de bestaande dienst PHP updaten of het hulpformulier hieronder als je geen toegang tot de code hebt of de betrokken bibliotheek niet zelf onderhoudt. Beschrijf de mislukte handeling en het gewenste resultaat. Stuur geen wachtwoorden mee.

Vraag welke correctie wordt voorgesteld en met welke proef die gecontroleerd wordt.

Gebruik de Exposure Check via de link Check je PHP-versie als eerste versiecontrole. Een openbare check kan de PHP-versie niet altijd vaststellen en bewijst geen oorzaak of herstel van deze fout. Vraag bij een onbekende uitkomst de hoster om de actieve versie van deze website.

Bewaar na herstel de versies, testuitkomst en nieuwe logregels bij je onderhoudsnotities. Laat de verantwoordelijke beheerder bepalen wanneer de geteste wijziging naar de echte website kan.

Vraag bij de overdracht ook welke test een foutieve klassenaam bewust controleert. Die proef helpt onderscheid maken tussen een werkende registratie en een toevallig al geladen bestand. Laat een ontwikkelaar de uitkomst verklaren voordat je de wijziging als afgerond beschouwt.