PHP-upgrade naar 8.x vanaf 7.4 trekt wordpress-site onderuit

[mikekiwi]

Ik ben als hobbyist betrokken bij het opzetten en onderhouden van de website van een lokale muziekvereniging. Draait in WordPress, waarbij we voor de lay-out gebruik hebben gemaakt van Avada.

Nu draait deze website nog op PHP 7.4, elke andere latere PHP-versie levert problemen op, de complete site gaat dan op zijn gat (HTTP error 500).

WP is up-to-date, thema is up-to-date, alle ongebruikte plugins heb ik al verwijderd en alle bestaande actieve plugins zijn geupdate.

Logging is aangezet in WP en geeft alleen de volgende melding:
[27-Mar-2026 06:52:35 UTC] PHP Deprecated: WPCF7_TagGenerator::add(): Gebruik van tag generator instanties ouder dan versie 2 is verouderd. Versie 1 instantie (WP Captcha) gedetecteerd. in /home/xx/domains/<domeinaam>/public_html/wp-includes/functions.php on line 6131

Op deze regel 6131 staat de algemene code
trigger_error( $message, $error_level );

Maar: deze fout-melding wordt ook gelogd als de PHP op versie 7.4 staat en de website geen error geeft.

Ik heb al de site gestart met een ander thema en PHP 8.x -> dezelfde HTTP 500 melding
Ik heb al de site gestart met alle plugins gedeactiveerd en PHP 8.x -> dezelfde HTTP 500 melding

Na het terugzetten naar PHP7.4 draait de website weer prima.

Ik weet even niet meer wat ik kan doen om te achterhalen waar de boosdoener zit. Iemand een (of meer) suggestie(s)?

[TheBorg]

Wat zegt de log van webserver (Apache/Nginx)?

[mikekiwi]

TheBorg schreef op zondag 29 maart 2026 @ 13:20:
Wat zegt de log van webserver (Apache/Nginx)?

Daar is dit terug te vinden:

[Sun Mar 29 13:33:15.008111 2026] [lsapi:error] [pid 432114:tid 139776516835072] [client 2a02:a444:7091:0:3c16:f960:a3e8:9a87:55214] [host www.arti-alphen.nl] Backend fatal error: PHP Fatal error:
Uncaught Error: Undefined constant "\xe2\x80\x98upload_max_size\xe2\x80\x99" in /home/deb22719/domains/arti-alphen.nl/public_html/wp-config.php:36\nStack trace:\n#0 /home/deb22719/domains/arti-alphen.nl/public_html/wp-load.php(50): require_once()\n#1 /home/deb22719/domains/arti-alphen.nl/public_html/wp-blog-header.php(13): require_once('/home/deb22719/...')\n#2 /home/deb22719/domains/arti-alphen.nl/public_html/index.php(17): require('/home/deb22719/...')\n#3 {main}\n thrown in /home/deb22719/domains/arti-alphen.nl/public_html/wp-config.php on line 36\n

Op die regel 36 staat dit:

[TheBorg]

Regel 36 die quotejes met kromming moeten zijn zoals op regel 35.

[_JGC_]

@mikekiwi Vervang die curly quotes maar eens met rechte quotes.

Edit: wat hierboven ook zegt dus

[ Voor 23% gewijzigd door _JGC_ op 29-03-2026 13:50 ]

[Reinier]

Verkeerde soort quootjes

Edit: sloom

[ Voor 25% gewijzigd door Reinier op 29-03-2026 13:51 ]

[mikekiwi]

Ook goedemorgen.... Jeetje, wat stom zeg. Dit staat er dus echt al een behoorlijke tijd in, maar nooit een probleem geweest bij PHP 7.4. Heb het nu aangepast en werkt prima op PHP 8.4.

Gewoon om mijn kennis wat aan te vullen: waarom is dit wel een issue bij PHP 8.x en niet bij 7.4 ?

[TheBorg]

@ onderdrukt de foutmelding. Misschien maakt 7 er daar door geen fatal error van.

[_JGC_]

PHP7 maakt van een undefined constant een string en logt een warning. Sinds PHP8 is dat een fatal error. Warnings kan je onderdrukken met een @, fatals niet.

[mikekiwi]

TheBorg schreef op zondag 29 maart 2026 @ 14:03:
@ onderdrukt de foutmelding. Misschien maakt 7 er daar door geen fatal error van.

_JGC_ schreef op zondag 29 maart 2026 @ 14:04:
PHP7 maakt van een undefined constant een string en logt een warning. Sinds PHP8 is dat een fatal error. Warnings kan je onderdrukken met een @, fatals niet.

Aha, duidelijk. Dank voor de toelichting en snelle reacties van allen
Heb op tig verschillende plekken al zitten kijken, maar dit gewoon over het hoofd gezien

[AW_Bos]

Misschien een handige pro-tip. Kan je deze settings anders in een (lokale) php.ini of .htaccess zetten?
Dan hoef je dat niet meer met PHP te regelen.

[ Voor 3% gewijzigd door AW_Bos op 30-03-2026 00:12 ]