[wordpress] Site kapot na wp upgrade met memory issues

[superduper]

Ik probeer een Wordpress site weer tot leven te wekken nadat deze tijdens de upgrade naar v6 kapot is gelopen.

De site geeft nu 'there has been a critical error on this website'

In de debug logs vind ik dat diverse script de grens van 256M over gaan. Maar als ik die grens probeer te verhogen naar 512 oid, dan krijg ik een 503 error en komen er geen nieuwe entries in de log, dus blijkbaar start PhP helemaal niks meer.

Ik kan helaas niet in de portal van de hoster. Ik heb wel een 'backup', gemaakt voor de upgrade, maar die (blijkt nu) alleen een XML, db en subfolder te bevatten, en niet de core wordpress mappen.

Wat is nu de handigste manier om dit te repareren?

[AW_Bos]

Wat meldt je hosting over de 503 error? Zij lijken de enigen die hierin een oplossing kunnen bieden. Blijkbaar mag je niet meer geheugen gebruiken dan is toegestaan.

Je kan proberen wat plugins uit te zetten. Misschien is er eentje die niet dringend nodig is, en teveel geheugen gebruikt.

[ Voor 27% gewijzigd door AW_Bos op 18-06-2023 11:42 ]

[superduper]

AW_Bos schreef op zondag 18 juni 2023 @ 11:42:
Wat meldt je hosting over de 503 error? Zij lijken de enigen die hierin een oplossing kunnen bieden. Blijkbaar mag je niet meer geheugen gebruiken dan is toegestaan.

Je kan proberen wat plugins uit te zetten. Misschien is er eentje die niet dringend nodig is, en teveel geheugen gebruikt.

Ik kan niet direct bij het hosting paneel, dus ga daar maandag naar informeren. Ik heb alle plugins al uitgezet maar dat maakt geen verschil dus het lijkt al de core Wordpress te zijn. Ik twijfel zelfs over de versie van php maar kan dat ook niet zien.

[AW_Bos]

Wat zegt dit over de versie?

PHP:

<?php
phpinfo();
?>

[ Voor 10% gewijzigd door AW_Bos op 18-06-2023 12:35 ]

[superduper]

Daar zit hem het issue idd: v7.1.3, hopeloos verouderd en dit moet ik dus duidelijk zelf even eerst checken. Omdat ik dit niet zelf kan aanpassen en wordpress ook geen melding gaf dat de upgrade niet aan de eisen voldeed dacht ik dat het goed zat. Enfin, assumption is the mother of all FUs.

Zal contact opnemen met diegene die het hosting panel beheerd en ga er dan even vanuit dat er dan vanalles op zijn plek valt.

[jurroen]

PHP 7.1 is al drie-en-een-half jaar EOL. Nu kan het wel zo zijn dat de hoster gebruik maakt van CloudLinux HardenedPHP (die security fixes backport) - maar dan kunnen ze net zo goed ook PHP Selector bieden

Heel persoonlijk zou ik naar een andere partij gaan kijken. Want dit zo - onveilig - aanbieden is alles behalve wenselijk. 7.1.3 specifiek stamt van 16 maart 2017, is lek en niet compatible met een groot deel van de thema's, plugins, etc.

[ Voor 75% gewijzigd door jurroen op 18-06-2023 14:07 ]

[superduper]

jurroen schreef op zondag 18 juni 2023 @ 14:00:
PHP 7.1 is al drie-en-een-half jaar EOL. Nu kan het wel zo zijn dat de hoster gebruik maakt van CloudLinux HardenedPHP (die security fixes backport) - maar dan kunnen ze net zo goed ook PHP Selector bieden

Heel persoonlijk zou ik naar een andere partij gaan kijken. Want dit zo - onveilig - aanbieden is alles behalve wenselijk.

Het maakt het vooral lastig dat ik niet zelf in de portal kan en dat de .ini files dat niet kunnen regelen.

Maar naast dit heb ik liever idd de hele hosting anders..

[jurroen]

superduper schreef op zondag 18 juni 2023 @ 14:05:
[...]


Het maakt het vooral lastig dat ik niet zelf in de portal kan en dat de .ini files dat niet kunnen regelen.

Maar naast dit heb ik liever idd de hele hosting anders..

Is de partij die dit voor je beheert ook de hoster of zijn dat twee verschillende partijen?

Afhankelijk van de output van die phpinfo() - als HardenedPHP gebruikt wordt kun je het via een andere ini file oplossen. Maar dat kan bijna niet het geval zijn als 7.1.3 in gebruik is, dat zou 7.1.33 moeten zijn.

In die phpinfo() zie je daar een configuratiepad met alt-php erin?

[Oon]

Oudere WP op modernere PHP zorgt vaak voor een hoop issues, maar je kan niet altijd zomaar updaten.

Gelukkig is de moderne WP wel backwards compatible met oudere PHP versies, dus je kunt de WP core updaten, de PHP versie verhogen, en dan al je plugins updaten. Kans dat je website daarna stuk is is relatief groot (tenzij je alleen plugins in de top 100 meest gebruikte plugins gebruikt en je eigen thema), maar dan zou je wel weer verder moeten kunnen met fixen.

[superduper]

jurroen schreef op zondag 18 juni 2023 @ 14:10:
[...]

Is de partij die dit voor je beheert ook de hoster of zijn dat twee verschillende partijen?

Afhankelijk van de output van die phpinfo() - als HardenedPHP gebruikt wordt kun je het via een andere ini file oplossen. Maar dat kan bijna niet het geval zijn als 7.1.3 in gebruik is, dat zou 7.1.33 moeten zijn.

In die phpinfo() zie je daar een configuratiepad met alt-php erin?

Het is idd weer een andere partij die het panel beheerd. En het is idd volledig 7.1.33. Ik ize geen alt-php.

De originele hoster is kort geleden overgenomen (opgeslokt) door weer een andere partij dus we gaan maar eens even het hele pakket bekijken.

[superduper]

Hmm, net de php versie naar 7.4.13 gezet (hoogste 7 versie voor 8 ) en ik krijg nog steeds dezelfde foutmeldingen dat er meer memory nodig is dan de toegestane 256 MB. Dit met uitgeschakelde plugins etc, dus de core wordpress al en dat lijkt me sterk.

[eLScha]

WordPress core gebruikt niet zoveel geheugen. Als je alle plug-ins al hebt uitgeschakeld is het je thema of een enorme transient-tabel in de database. Ik zet in op het thema.

[superduper]

eLScha schreef op maandag 19 juni 2023 @ 08:45:
WordPress core gebruikt niet zoveel geheugen. Als je alle plug-ins al hebt uitgeschakeld is het je thema of een enorme transient-tabel in de database. Ik zet in op het thema.

Daar ben ik nu ook naar aan het kijken. Als ik de folder met dat thema verwijderd laad hij helemaal niet, dus ik moet even zoeken hoe je ergens kan opgeven om naar het default thema terug te vallen

[BernardV]

Wat je kunt proberen is handmatig de laatste 5.x versie downloaden.
Dan eerst even een volledige backup maken van je site, dan de wp-admin, wp-includes folders uploaden (eerst de huidige verwijderen).
Met een beetje geluk draait het dan weer goed op 5.x

[superduper]

inmiddels heb ik weer toegang en 'draait' het eea weer. Helaas is het custom thema wat we jaren geleden hebben laten ontwerpen wel wat kapot dus daar moet ik wat tijd in steken.

[DJMaze]

superduper schreef op maandag 19 juni 2023 @ 11:05:
Helaas is het custom thema wat we jaren geleden hebben laten ontwerpen wel wat kapot dus daar moet ik wat tijd in steken.

Wat tijd?!?
Normaal zou een website niet meer dan 16MB moeten gebruiken (8 is redelijk normaal).
Ok, met WordPress misschien 32 af en toe.
Maar als je aan 200MB niet genoeg hebt, vraag ik mij toch echt af hoeveel meuk er in het geheugen geladen is dat niet op het het scherm getoond wordt.

[jurroen]

DJMaze schreef op maandag 19 juni 2023 @ 19:32:
[...]

Wat tijd?!?
Normaal zou een website niet meer dan 16MB moeten gebruiken (8 is redelijk normaal).
Ok, met WordPress misschien 32 af en toe.
Maar als je aan 200MB niet genoeg hebt, vraag ik mij toch echt af hoeveel meuk er in het geheugen geladen is dat niet op het het scherm getoond wordt.

Ik denk dat jij wat dingen door elkaar haalt. 8MB redelijk nornaal - voor wat? Een full page load? Daarvoor is het zelfs aan de wat hoge kant (gemiddeld).

Echter, we hebben het hier over een PHP memory_limit. Of anders, vertel mij eens hoe je met 32MB geheugen een database van bijvoorbeeld 1GB efficient wil indexeren, cachen, etc. Mind you - we hebben het hier over serverside dynamische pagina's.

[superduper]

Persoonlijk denk ik dat die memory issues 'niet echt' waren, maar verkeerde syntax voor de php versies waardoor een script ontspoort/crasht. De error afhandeling is niet top nee, en dat zette me lange tijd wel op het verkeerde been. Ik zie dat die php_mem_limit van 256 vaak gebruikt wordt dus laat ik lekker staan al ben ik met jullie eens dat dit niet nodig zou zijn.

[jurroen]

superduper schreef op dinsdag 20 juni 2023 @ 08:34:
Persoonlijk denk ik dat die memory issues 'niet echt' waren, maar verkeerde syntax voor de php versies waardoor een script ontspoort/crasht. De error afhandeling is niet top nee, en dat zette me lange tijd wel op het verkeerde been. Ik zie dat die php_mem_limit van 256 vaak gebruikt wordt dus laat ik lekker staan al ben ik met jullie eens dat dit niet nodig zou zijn.

256M is vaak nodig voor de wat inefficientere of zwaardere sites. Denk aan bijvoorbeeld zo'n multi thema met sitebuilder (zoals Divi) of Woocommerce met meer dan een handvol producten.

Overigens is de memory_limit van PHP niet het enige wat meetelt. Er is ook nog een WP_MEMORY_LIMIT variabele.