Joomla troubleshooting: problemen vinden en oplossen, stap voor stap
Elke Joomla-site loopt vroeg of laat vast: een wit scherm na een update, een 500-fout die uit het niets opduikt, een inlogfunctie die niet meer werkt, een wijziging die maar niet zichtbaar wordt. Wat het verschil maakt tussen een stressvolle middag en een oplossing in vijf minuten is geen geluk, het is een methode. Probleemoplossing is een vak met regels, en Joomla biedt je daarvoor betere hulpmiddelen dan de meeste mensen beseffen. En ja, soms is die oude "have you tried turning it off and on again?" grap echt het antwoord: een herstart van PHP lost echt een hele reeks cacheproblemen op.
Dit artikel is een systematische handleiding voor het oplossen van problemen in Joomla. Het behandelt de diagnosemethode en eerste stappen voor site-eigenaren, de klassieke storingen – witte schermen, 500-fouten, inlogproblemen, defecte extensies, updateproblemen – met bijbehorende oplossingen voor beheerders, en stacktraces, bisectie en de commandoregel-reddingskit voor ontwikkelaars.
Het bouwt voort op de Focus Op-artikelen over de debugmodus (de diagnostische instrumenten) en back-ups (je vangnet); hier passen we ze toe op een defecte website. De patronen zijn afkomstig uit mijn jarenlange praktijkervaring met ondersteuning op websites van klanten en uit het modereren van het Joomla-forum en Stack Overflow, waar duizenden discussies over defecte websites volgens hetzelfde handjevol patronen verlopen.
Een defecte site is geen raadsel. Het is een machine met een storing, en storingen kunnen stapsgewijs worden opgespoord..
Het doel is eenvoudig: je van "de site is stuk" naar "ik weet precies wat er gebeurd is" brengen - rustig, en in de juiste volgorde.
1. De basis
1.1 De troubleshooting-denkwijze
Bijna elke Joomla-storing volgt een wet: er is iets veranderd. Een update draaide, een extensie werd geinstalleerd, een instelling werd opgeslagen, de hostingprovider upgradde PHP, een certificaat verliep. De eerste vraag is nooit "hoe repareer ik dit?" maar "wat is er veranderd sinds het voor het laatst werkte?". Beantwoord die, en de helft van je problemen lost zichzelf op.
1.2 De drie regels
- Reproduceer eerst: laat het probleem op commando gebeuren. Een storing die je kunt oproepen, is een storing die je kunt traceren.
- Een wijziging tegelijk: verander een ding, test, noteer het resultaat. Vijf wijzigingen tegelijk betekent dat je niet weet welke het repareerde (of verergerde).
- Schrijf het op: wat je zag, wat je probeerde, wat er gebeurde. Het voorkomt dat je in cirkels draait, en het wordt het incidentlogboek waar het beveiligingsartikel om vraagt.
1.3 Je instrumentenpaneel
Joomla en de browser dragen de diagnostische gereedschappen al bij zich: het Debug systeem met zijn query- en profilingconsole (het Focus On-artikel over debug-modus behandelt het diepgaand), de logbestanden in administrator/logs (of je verplaatste logmap), het foutenlog van de webserver, en de developer tools van de browser (console- en netwerktabblad). De console benoemt ook JavaScript-fouten en mixed-content-waarschuwingen - de klassieke stortvloed na een HTTPS-migratie. Het grootste deel van dit artikel is weten welk instrument welke vraag beantwoordt.
2. Eerste reactie: triage
2.1 Vier vragen om het in te perken
- Waar? Frontend, backend of beide? Een pagina of alle pagina's?
- Wie? Alle bezoekers, alleen ingelogde gebruikers, een account, alleen jij?
- Sinds wanneer? Sinds wanneer precies - en wat gebeurde er vlak daarvoor (update, installatie, opslaan, hostwijziging)?
- Wat precies? Een lege pagina, een foutcode, verkeerde uitvoer, of trage uitvoer? Kopieer de exacte melding.
Deze vier antwoorden snijden negentig procent van het zoekgebied weg. "De site is stuk" is onoplosbaar; "de frontend toont sinds de PHP-update van gisteravond op alle pagina's een 500" is bijna opgelost.
Een antwoord verwijst ergens anders heen: is het symptoom "traag" in plaats van "stuk", schakel dan over naar de meetmethode in het Focus On-artikel over prestaties - traagheid is een prestatieprobleem met een eigen gereedschapskist, geen storing om op te jagen.
2.2 Voordat je iets aanraakt
Twee disciplines uit het back-upartikel gelden dubbel op een kapotte site. Ten eerste: maak nu een back-up, kapot en wel - als een reparatiepoging het erger maakt, kun je terug naar deze toestand. Ten tweede: vermoed je een hack in plaats van een storing, stop dan en volg de incident response-stappen uit het artikel over security hardening: onderzoek komt daar voor reparatie, en reparaties vernietigen bewijs.
2.3 Koop rust met de offline-pagina
Zet bij een zichtbaar kapotte publieke site Site offline aan (Algemene configuratie, of php cli/joomla.php site:down). Joomla serveert dan de offline-pagina met een correcte 503 Service Temporarily Unavailable-status - bezoekers zien een nette melding en zoekmachines weten dat ze later terug moeten komen. Nu kun je werken zonder publiek.
2.4 Op de juiste manier om hulp vragen
Soms is de snelste reparatie andere mensen - het Joomla-forum en Stack Overflow zitten er vol mee. Twee gewoonten bepalen of je binnen een uur antwoord krijgt of nooit. Ten eerste: zoek voordat je vraagt: plak de exacte foutmelding in het zoekveld; op die schaal is iemand jouw probleem vrijwel zeker eerder tegengekomen. Ten tweede: stel een vraag die beantwoord kan worden. Na jaren modereren op beide platforms kan ik je vertellen dat de vragen die snel opgelost worden allemaal dezelfde vorm hebben:
- De exacte Joomla- en PHP-versies, en de versies van de betrokken extensies.
- De exacte foutmelding, gekopieerd - niet uit het hoofd geparafraseerd.
- Wat er vlak voor het stukgaan veranderde (je antwoorden uit sectie 2.1).
- Wat je al geprobeerd hebt, en wat er gebeurde toen je het probeerde.
- Een probleem per topic, met een titel die het symptoom benoemt.
"Mijn site is stuk, help alsjeblieft!!" blijft dagen onbeantwoord. "500 op alle frontend-pagina's sinds de PHP 8.3-upgrade, serverlog wijst naar plugins/system/xyz" is vaak binnen het uur opgelost. Het verschil is geen geluk - de tweede vraag bevat de triage al.
Het Joomla-forum heeft een tool die het meeste hiervan voor je verzamelt: de Forum Post Assistant (FPA). Je uploadt een PHP-script naar de root van je site, opent het in de browser, en het produceert een forumklaar rapport van je Joomla-, PHP-, database- en serverconfiguratie - en daarom vragen forumvrijwilligers in de meeste supporttopics om een FPA-rapport. Lees het wel na voordat je het plaatst en verwijder wat je als vertrouwelijk beschouwt; de tool formatteert, maar jij blijft verantwoordelijk voor wat je publiceert. En hij heeft een dankbaar tweede gebruik: lees het rapport eerst zelf, en je ziet de oorzaak regelmatig op eigen kracht - een verkeerde PHP-versie, een rechtenprobleem, een configuratiefout - en dan hoeft de vraag helemaal niet meer gesteld te worden.
Naar boven3. De echte fout zichtbaar maken
3.1 Leeg is alleen maar verborgen
Een productiesite verbergt fouten terecht (het beveiligingsartikel staat erop). Maar bij troubleshooting moet je ze zien. Zet op een ontwikkelkopie - of kort en bewust op productie - Foutrapportage op Maximum in Algemene configuratie → Server. De lege pagina wordt een foutmelding met bestandsnaam en regelnummer, en de jacht wordt drastisch korter.
3.2 Als je de backend niet kunt bereiken
Is de backend zelf kapot, zet het dan direct in configuration.php:
public $error_reporting = 'maximum';En toont zelfs dat niets, dan sterft de fout voordat Joomla start - lees dan de serverlogs: het PHP-foutenlog en het foutenlog van de webserver (locaties verschillen per host; het hostingpanel weet ze). Het serverlog heeft altijd de echte melding, ook wanneer de browser puur wit toont.
3.3 Een foutmelding lezen
Joomla- en PHP-fouten volgen een patroon: wat er misging (het exception- of fouttype), waar (bestand en regel), en hoe het daar kwam (de stack trace). Het bestandspad is de grootste aanwijzing: een pad onder plugins/system/naam/ wijst naar die plugin; een pad onder templates/ wijst naar het template of een override. Je hoeft de code niet te begrijpen om de verdachte aan te wijzen.
4. Het witte scherm des doods
4.1 Wat het is
Een volledig lege pagina betekent dat PHP fataal stopte voor er uitvoer was - en foutweergave staat uit, dus je ziet niets. Het is geen Joomla-toestand; het is een verborgen crash. De oorzaken, op volgorde van waarschijnlijkheid:
- Een extensie die niet compatibel is met je PHP- of Joomla-versie (vaak direct na een update van een van beide).
- PHP-geheugen uitgeput (
memory_limit). - Een syntaxfout in een recent bewerkt bestand - een override,
configuration.php, een template-bewerking. - Een corrupte of half afgeronde update.
4.2 De reparatievolgorde
- Maak de fout zichtbaar (sectie 3). Negen van de tien keer benoemt dit alleen al het schuldige bestand.
- Hoort het bestand bij een extensie: schakel die extensie uit (sectie 7) en test opnieuw.
- Bij geheugen: verhoog
memory_limitin de PHP-instellingen, en zoek dan uit waarom het uitgeput raakte - meestal een extensie in een lus. - Bij een recent bewerkt bestand: zet het terug uit de back-up of repareer de syntaxfout op de gemelde regel.
5. 500 Internal Server Error
5.1 Het "er ging iets stuk" van de server
Een 500 is de webserver die een fout meldt zonder details aan bezoekers te geven. De details bestaan wel - in het foutenlog van de server. Lees dat eerst; gokken bij een 500 zonder het log verspilt uren. De gebruikelijke Joomla-daders:
| Oorzaak | Typische aanleiding | Oplossing |
|---|---|---|
Kapotte .htaccess |
Bewerkingen, verhuisde site, opties die de host verbiedt | Hernoem .htaccess om te testen; herbouw vanaf htaccess.txt en voeg eigen regels een voor een terug. |
| PHP-versiewissel | Host upgradde PHP; een extensie is er niet klaar voor | Zoek in het log het falende bestand; schakel PHP tijdelijk terug, update of schakel de extensie uit. |
| Bestandsrechten/eigendom | Bestanden verplaatst of teruggezet als verkeerde gebruiker | Bestanden 644, mappen 755, eigendom van de PHP-gebruiker - zoals in het beveiligingsartikel. |
| mod_security-regels | Content opslaan met code-achtige tekst | Vraag de host het WAF-log te bekijken; zet de regel die afgaat op de uitzonderingslijst. |
5.2 De halveringstruc voor htaccess
Wanneer .htaccess de verdachte is maar het log vaag blijft: zet tijdelijk de helft van de eigen regels in commentaar, test, halveer opnieuw. Vier tests vinden de schuldige regel tussen tientallen. Dit bisectiepatroon keert in sectie 11 terug voor plugins - het is de universele troubleshooting-zet.
5.3 De andere statuscodes
De statuscode benoemt de falende laag nog voordat je een log gelezen hebt:
| Code | Wat hij je vertelt |
|---|---|
403 |
Iets weigert met opzet: bestandsrechten, een IP-blokkade, een WAF-regel, of een deny-regel in .htaccess. |
404 op pagina's die bestaan |
Routing: SEF-instellingen, het rewrite-blok in .htaccess, of een menuwijziging - het terrein van het redirects-artikel. |
301/302-lus ("too many redirects") |
Conflicterende redirect-regels: HTTPS geforceerd in zowel Joomla als de server, of een CDN dat terugverwijst. |
502 / 504 |
De webserver bereikt PHP niet, of PHP doet er te lang over: PHP-FPM gecrasht of overbelast - de hostinglaag, vraag de host. |
503 |
Joomla's offline-modus - bewust (sectie 2.3), of een onderhoudspagina van de host. |
6. Loginproblemen
6.1 "Waarom kan ik niet inloggen?"
Loginfouten hebben gelaagde oorzaken; test ze in volgorde:
- Inloggegevens: reset het wachtwoord. Per mail, of als mail stuk is, via de CLI:
php cli/joomla.php user:reset-password. - Accountstatus: geblokkeerd, niet geactiveerd, of gedwongen tot reset (de vlaggen in
#__usersdie het authenticatie-artikel beschrijft). - MFA-buitensluiting: een verloren tweede factor. Een andere Super User kan de MFA-methoden van de gebruiker resetten op diens accountpagina.
- Sessie-/cookieproblemen: het symptoom is een loginformulier dat stil terugkeert, zonder foutmelding. Zie hieronder.
- Rechten: "er is een fout opgetreden" na een correcte login betekent vaak dat de groep zijn loginrecht verloor - controleer
core.login.admin/core.login.sitein de termen van het ACL-artikel.
6.2 De stille login-lus
Een loginformulier dat gewoon opnieuw verschijnt, betekent dat de sessiecookie nooit blijft plakken. De klassieke oorzaken: een verkeerde cookie_domain of cookie_path in de Algemene configuratie (typisch na een domeinverhuizing - maak ze leeg), een browser die cookies blokkeert, of een volle/corrupte sessietabel. #__session legen is onschuldig - iedereen logt gewoon opnieuw in.
6.3 Volledig buitengesloten
Helemaal geen werkende Super User meer? Twee officiele ontsnappingsluiken: de CLI kan gebruikers aanmaken of repareren (user:add, user:reset-password, user:addtogroup) zonder web-login, en de noodinstelling root_user in configuration.php (beschreven in het ACL-artikel) kan tijdelijk een account kronen. Verwijder die laatste zodra je weer binnen bent.
7. Extensie-noodgevallen
7.1 Een plugin haalde de site neer
Systeemplugins draaien bij elk request, dus een defecte breekt alles - inclusief je weg naar het pluginbeheer. Twee schone reddingen, zonder bestanden te hacken:
# De beschaafde weg (werkt terwijl het web plat ligt):
php cli/joomla.php extension:list --type=plugin
php cli/joomla.php extension:disable <extensie-id>
# De databaseweg (phpMyAdmin of MySQL-client):
UPDATE #__extensions SET enabled = 0
WHERE element = 'verdachtenaam' AND type = 'plugin';Leeg daarna de cache en test opnieuw. Keert de site terug, dan heb je je dader - meld het bij de ontwikkelaar met je PHP- en Joomla-versies.
7.2 Het template brak de frontend
Een fatale fout in een template of zijn overrides maakt de frontend leeg terwijl de backend nog werkt. Schakel de standaardstijl naar Cassiopeia in Systeem → Site-templatestijlen (of zet zo nodig de kolom home in #__template_styles via de database), repareer het template op een kopie, schakel terug.
7.3 Installaties die mislukken
"Unable to write" of stille mislukkingen bij extensie-installaties zijn bijna altijd omgeving, niet extensie: een verkeerd of onbeschrijfbaar tmp_path in de Algemene configuratie, PHP-uploadlimieten (upload_max_filesize, post_max_size) onder de pakketgrootte, of schijfquota. Repareer het pad, verhoog de limieten, probeer opnieuw. Een half geinstalleerde extensie ruim je op met Systeem → Ontdekken of verwijder je via extension:remove. Een verwante limiet om te kennen: max_input_vars begrenst het aantal formuliervelden per request, en het opslaan van een heel groot menu of een grote module laat het overschot stilletjes vallen - verhoog hem wanneer grote formulieren items verliezen bij het opslaan.
8. Update-ellende
8.1 Kapot direct na een Joomla-update
De storingsvolgorde na een update, op volgorde van slagingskans:
- Leeg elke cache: die van Joomla (Systeem → Cache legen of
cache:clean), die van de browser, die van een eventueel CDN. - Verwijder
administrator/cache/autoload_psr4.php. Joomla herbouwt deze class-map-cache bij het volgende request; een verouderde veroorzaakt bizarre "class not found"-fouten na updates. Dit ene bestand verhelpt meer mysterieuze na-update-storingen dan wat dan ook. - Draai de database-updater: Systeem → Database → Structuur bijwerken (of
php cli/joomla.php maintenance:database) om schemawijzigingen toe te passen die de updater oversloeg. - Verdenk extensies: een extensie die niet compatibel is met de nieuwe versie toont zich hier het eerst. Bisecteer (sectie 11.2), update of schakel de dader uit.
8.2 Als de update zelf stierf
Een update die halverwege vastloopt (time-out, schijf vol) kan een gemengde installatie achterlaten. Draai hem niet blind opnieuw: zet de back-up van voor de update terug (precies dit scenario is waarom de update-checklist in het back-upartikel ermee begint), verhelp de oorzaak - meestal PHP-limieten of schijfruimte - en update opnieuw.
8.3 Extensie-updates die dingen breken
Dezelfde logica, kleinere straal: leeg caches, lees de changelog van de extensie, rol terug naar de vorige versie als de ontwikkelaar die aanbiedt, of zet terug uit de back-up. Meld het daarna - een goed geschreven bugmelding met versies en de exacte fout helpt de hele gemeenschap.
Naar boven9. Database- en contentproblemen
9.1 "Error connecting to the database"
Joomla kan MySQL/MariaDB niet bereiken. Of de inloggegevens zijn veranderd (vergelijk configuration.php met het hostingpanel - typisch na een migratie), of de databaseserver ligt plat of is overbelast (vraag de host), of de host wijzigde de database-hostnaam. De fout verschijnt voordat Joomla draait, dus alle reparaties gebeuren in configuration.php en het hostingpanel.
9.2 Vergrendelde content en spookbewerkingen
"Dit item wordt bewerkt door een andere gebruiker" lang nadat iedereen naar huis is, betekent oude check-outs. Systeem → Globaal inchecken geeft ze vrij, en de taak-plugin globalcheckin (zie de taakplanner) voorkomt herhaling.
9.3 Na een verhuizing: ontbrekende afbeeldingen, verkeerde paden
Een teruggezette of verhuisde site met intacte tekst maar kapotte afbeeldingen heeft meestal absolute paden in content of configuratie: controleer $tmp_path en $log_path in configuration.php (ze moeten naar de paden van de nieuwe server wijzen), en doorzoek de content op hard gecodeerde URL's van het oude domein. De herstel-checklist in het back-upartikel dekt de volledige volgorde.
10. Cache- en sessieverwarring
10.1 "Mijn wijziging verschijnt niet"
Het meest gemelde niet-probleem in Joomla. Iets cachet wel degelijk je oude pagina; de vraag is welke laag. Leeg ze in volgorde, en test na elke stap:
1. Joomla pagina-/systeemcache Systeem > Cache legen (of: cache:clean)
2. Browsercache hard herladen / prive-venster
3. CDN- of proxycache legen in het CDN-dashboard
4. OPcache (na bestandsedits) PHP-FPM herstarten of de host vragenTest eerst in een prive-venster - verschijnt de wijziging daar, dan was het probleem al die tijd je eigen browser, en had de server niets nodig.
10.2 Sessies die zich vreemd gedragen
Gebruikers die willekeurig uitgelogd worden, winkelwagens die leeglopen, tokens die geweigerd worden: sessieproblemen. Controleer de sessieduur (te kort?), de gezondheid van de tabel #__session, en - na hostingwijzigingen - of de sessiehandler nog past bij wat de server biedt (een geconfigureerde Redis-handler zonder bereikbare Redis faalt precies zo).
11. Onder de motorkap (ontwikkelaarsblik)
11.1 Een stack trace lezen als een kaart
Een stack trace lees je van onder naar boven als "hoe we hier kwamen" en van boven naar beneden als "waar het stierf". Het bovenste frame is de plek van de crash, maar de oorzaak is meestal het hoogste frame dat bij derde-partij- of eigen code hoort - de core is zelden de dader. Zoek het eerste niet-core-pad in de trace en begin daar.
11.2 Bisectie: de universele methode
Als er geen concrete aanwijzingen zijn voor een verdachte, halveer dan de mogelijkheden: schakel de helft van de niet-essentiële plug-ins uit, test, en halveer opnieuw. Met zes tests kun je zestig extensies afhandelen. Hetzelfde geldt voor .htaccess-regels (paragraaf 5.2), template-overrides (verplaats de helft uit de map html/) en aangepaste CSS/JS. Bisectie lijkt traag, maar is bijna altijd sneller dan intuïtie.
11.3 Vergelijken met schoon
Twijfels op bestandsniveau - "is er iets gewijzigd?" - beslecht je met vergelijken, niet met geheugen: git diff als de site in versiebeheer staat (het overrides-artikel raadt het aan), of een download van dezelfde Joomla-versie gediffed tegen de installatie. Gewijzigde core-bestanden betekenen of een hack (ga naar incident response) of de sluiproutes van een voorganger (documenteer, en maak ze ongedaan via nette overrides).
11.4 Schrijf je eigen spoor
Voeg bij storingen die af en toe optreden tijdelijke logging toe op de verdachte plek:
use Joomla\CMS\Log\Log;
Log::add('Import bereikte stap 3, id=' . $id, Log::DEBUG, 'com_example');Regels landen in de logmap en beantwoorden de vraag "komt de code hier uberhaupt?" - de vraag die de meeste lange debugsessies beeindigt. Verwijder de regels als je klaar bent. En wanneer loggen niet genoeg is - een waarde die ergens over vijftig functie-aanroepen verandert - pauzeert een step-debugger (Xdebug) de uitvoering en laat je variabelen live inspecteren, wat elke hoeveelheid geprinte uitvoer verslaat.
Naar boven12. De commandline-reddingskit
Alles in dit artikel ging ervan uit dat je backend misschien niet werkt - want de CLI trekt zich er niets van aan of de website rendert. De reddingskit, allemaal geverifieerde commando's:
php cli/joomla.php site:down / site:up offline-modus schakelen
php cli/joomla.php cache:clean Joomla-cache legen
php cli/joomla.php extension:list het extensie-id vinden
php cli/joomla.php extension:disable <id> de kapotte plugin uitzetten
php cli/joomla.php extension:remove <id> volledig deinstalleren
php cli/joomla.php user:reset-password toegang terugkrijgen
php cli/joomla.php user:add nood-beheerdersaccount
php cli/joomla.php maintenance:database schema repareren na updates
php cli/joomla.php config:get configuratiewaarden lezen
php cli/joomla.php core:update:check is er een update beschikbaar?De Web Services API speelt een kleinere troubleshooting-rol - hij heeft een gezonde Joomla nodig om te antwoorden - maar hij blinkt uit in monitoring: een extern script dat een licht endpoint bevraagt, merkt dat de site stuk is voordat je bezoekers je mailen. Combineer het met een uptime-monitor - bijvoorbeeld het gratis, zelf gehoste Uptime Kuma uit het artikel over de onderhoudschecklist - en "sinds wanneer?" (sectie 2) heeft altijd een antwoord. Onderhoud je meerdere sites, dan geeft een centraal dashboard zoals YourSites (behandeld in het artikel over security hardening) een tweede diagnostische kortere route: als een site zich misdraagt, zie je in een oogopslag of de buursites op dezelfde server nog in orde zijn - en dat scheidt een siteprobleem van een serverprobleem voordat je ook maar een log hebt geopend.
Naar boven13. SEO en metadata
Hoe een site faalt, maakt uit voor zoekmachines. Joomla's offline-modus geeft 503 Service Temporarily Unavailable terug - de status die crawlers vertelt "tijdelijk, kom later terug" en je posities beschermt tijdens reparaties. Een site die kapot blijft staan met 500-fouten of, erger, lege pagina's met 200 OK, leert Google dat de pagina's weg of leeg zijn, en herstel in de index duurt veel langer dan de storing zelf. Dus: zichtbare schade → offline-modus aan, repareren, offline-modus uit.
Werp na elke storing of reparatie een blik op Search Console: crawlfouten pieken tijdens incidenten en bevestigen zowel de bezoekersimpact als het herstel. En betrof de schade redirects of verplaatste URL's, test dan de redirect-ketens opnieuw - het artikel over redirects legt uit waarom kapotte ketens nog lang positie lekken nadat de site er weer gezond uitziet.
Voor precies deze verificatiestap bestaat een gereedschap. Na een reparatie of verhuizing vindt een site-brede crawl - Screaming Frog is de industriestandaard, en de gratis versie crawlt tot 500 URL's - in minuten wat rondklikken nooit vindt: kapotte links, redirect-ketens en -lussen, mixed content, en serverfouten op diepe pagina's waar niemand komt. In mijn eigen supportwerk brengt een crawl na een reparatie regelmatig nog twee of drie achtergebleven problemen boven water op sites die volledig genezen leken - en elk probleem dat zo gevonden wordt, is er een die Google en je bezoekers nooit tegenkomen.
Naar boven14. Veelvoorkomende fouten en valkuilen
14.1 Vijf dingen tegelijk veranderen
Symptoom: de site werkt weer, maar niemand weet waarom - tot hij volgende maand op dezelfde manier stukgaat.
Oplossing: een wijziging, een test, een notitie. De discipline voelt traag en is de snelste route die er is.
14.2 Gokken bij een 500 zonder het log te lezen
Symptoom: uren proberen terwijl de exacte foutmelding al die tijd in het serverlog stond.
Oplossing: logs eerst, altijd. Het serverfoutenlog voor 500's, het PHP-log voor witte schermen, Joomla's logs voor applicatiefouten.
14.3 Repareren zonder back-up van de kapotte toestand
Symptoom: een reparatiepoging maakte het erger, en nu is er geen weg terug naar slechts-kapot.
Oplossing: eerst een back-up, ook kapot. Schijfruimte is goedkoper dan spijt.
14.4 Core-bestanden bewerken om iets te "repareren"
Symptoom: een snelle patch in een core-bestand loste het symptoom op - en verdampte bij de volgende update, of brak die.
Oplossing: reparaties horen in configuratie, overrides of de update van de extensie zelf. Lijkt een core-bewerking de enige weg, dan hoort de echte bug in een melding aan het Joomla-project of de extensie-ontwikkelaar.
14.5 Diagnostiek aan laten staan
Symptoom: weken later zien bezoekers PHP-meldingen en de debugconsole; foutmeldingen lekken paden en query's.
Oplossing: foutrapportage Maximum en Debug systeem zijn chirurgische instrumenten - gebruiken, dan uitzetten, zoals het beveiligingsartikel erop staat. Zet "diagnostiek terugdraaien" op dezelfde notitie als de reparatie.
14.6 Een hack behandelen als een storing
Symptoom: vreemde bestanden "opgelost" door verwijderen, redirects "opgelost" door htaccess te bewerken - en binnen dagen terug.
Oplossing: onverklaarde contentwijzigingen, nieuwe beheerdersaccounts of redirects naar vreemde domeinen zijn incident response-terrein, geen troubleshooting: indammen, onderzoeken, dan terugzetten, in die volgorde (beveiligingsartikel, sectie 10.4).
Naar boven15. Best practices
Als je maar een paar dingen uit dit artikel onthoudt, onthoud dan deze:
- Begin met "wat is er veranderd?", en beantwoord "waar, wie, sinds wanneer, wat precies" voordat je iets aanraakt.
- Maak een back-up van de kapotte toestand voordat je repareert; zet de offline-pagina (een echte 503) aan bij zichtbare schade.
- Maak de fout zichtbaar voordat je hem repareert: foutrapportage, dan de serverlogs - gok nooit bij een 500.
- Ken de vier reddingszetten: plugin uitschakelen via CLI/database, terugschakelen naar Cassiopeia,
autoload_psr4.phpverwijderen, de database-updater draaien. - Leeg caches in volgorde (Joomla, browser, CDN, OPcache) voordat je een wijziging "werkt niet" verklaart.
- Bisecteer wanneer niets een verdachte benoemt - halveren verslaat intuitie.
- Houd de CLI-reddingskit in je notities; hij werkt wanneer het web dat niet doet.
- Vast? Zoek eerst op de exacte fout, en vraag dan op het forum met versies, de exacte melding, wat er veranderde en wat je al probeerde.
- Een wijziging tegelijk, altijd notities, diagnostiek daarna uit.
- Ruikt het naar een hack, schakel dan over naar incident response - "repareer" geen bewijs weg.
16. In het kort
TRIAGE wat veranderde er? waar / wie / sinds wanneer / wat precies
back-up van de kapotte toestand; site:down = echte 503
FOUTEN ZIEN Algemene configuratie > Foutrapportage: Maximum (dev/kort)
geen backend: $error_reporting = 'maximum'; in config
nog steeds leeg: PHP- + webserver-foutenlogs (hostingpanel)
WIT SCHERM fout zichtbaar maken > extensie? uitschakelen > geheugen?
verhogen + waarom vragen > recente bewerking? terugzetten
500-FOUT lees EERST het serverfoutenlog
.htaccess (hernoemen om te testen, herbouwen van htaccess.txt)
PHP-versiewissel / rechten 644-755 / mod_security
codes: 403 rechten/WAF - 404 routing - 30x lus redirects
502/504 PHP-FPM (host) - 503 offline-modus
LOGIN wachtwoord resetten (CLI: user:reset-password)
accountvlaggen > MFA-reset door andere beheerder
stille lus: cookie_domain/path leeg, #__session legen
buitengesloten: user:add via CLI, root_user (daarna weg!)
EXTENSIES extension:list + extension:disable <id>
of: UPDATE #__extensions SET enabled=0 WHERE element=...
template kapot: standaardstijl > Cassiopeia
installatie faalt: tmp_path, upload_max_filesize
UPDATES caches legen > VERWIJDER administrator/cache/autoload_psr4.php
> Systeem > Database > Structuur bijwerken > extensies
bisecteren; update halverwege gestorven: back-up terugzetten
VERSCHIJNT eerst prive-venster! dan: Joomla-cache > CDN > OPcache
NIET
DEV stack trace: eerste niet-core-pad = verdachte
plugins/regels/overrides bisecteren in helften
git diff / vergelijken met schone download
Log::add() om af-en-toe-storingen te traceren
CLI-KIT site:down|up cache:clean extension:list|disable|remove
user:reset-password user:add maintenance:database
config:get core:update:check
HULP zoek eerst op de exacte fout (forum.joomla.org, SO)
vraag met: versies, exacte fouttekst, wat veranderde,
wat je probeerde - een probleem per topic
FPA-rapport: script uploaden, draaien, nalezen, plaatsen
(vaak onthult het rapport alleen al de oorzaak)
GEHACKT? geen troubleshooting - incident response:
indammen > onderzoeken > opruimen > herstellen17. Samenvatting
Joomla troubleshooten is een methode, en de methode overleeft elke soort schade:
- Triage: wat veranderde er, waar, voor wie, sinds wanneer - plus een back-up van de kapotte toestand en een echte 503 terwijl je werkt.
- Zichtbaarheid: foutrapportage en de logbestanden veranderen lege pagina's en 500's in bestandsnamen en regelnummers.
- De klassiekers: witte schermen (verborgen PHP-crashes), 500's (htaccess, PHP-wissels, rechten), login-lussen (cookies en sessies), elk met een vaste diagnosevolgorde.
- De reddingen: extensies uitschakelen via CLI of database, terugvallen op Cassiopeia, de autoload-cache verwijderen, de database-updater draaien - vier zetten die de meeste noodgevallen oplossen.
- De lagen: cacheverwarring los je in volgorde op, van prive-venster tot OPcache.
- Het vak: stack traces, bisectie, vergelijken met schoon, en tijdelijke logging - de vier instrumenten van de ontwikkelaar voor de koppige tien procent.
- De grens: hacks zijn geen storingen; die krijgen incident response, geen reparaties.
Niets hiervan vereist genialiteit - het vereist rust, orde, en weten waar Joomla zijn antwoorden bewaart. De paniekversie van troubleshooting verandert willekeurige dingen tot iets helpt; de methodeversie leest de fout, benoemt de verdachte en repareert een ding. De tweede versie is elke keer sneller.
En sommige storingen weerstaan zelfs de methode - de sessiebug die af en toe optreedt, het conflict dat alleen onder belasting verschijnt, de site die traag is om redenen waar drie tools het niet over eens zijn. Dat zijn de puzzels waar ervaring met honderden kapotte Joomla-sites zich uitbetaalt, en precies het soort gestructureerd speurwerk waar een Joomla-specialist blij van wordt: hoe lastiger het mysterie, hoe bevredigender de eenregelige oorzaak aan het eind.
Naar boven
