Ja — het grootste deel van ons bugfix-werk betreft thema’s, plugins of siteconfiguraties van derden die wij niet oorspronkelijk hebben opgezet. We werken met elke WordPress-installatie, ongeacht wie deze heeft gebouwd. De enige uitzondering is bugs in commerciële thema’s of plugins die worden veroorzaakt door de code van de leverancier en vereisen dat de leverancier een update uitbrengt — in die gevallen identificeren we het probleem, documenteren het duidelijk en bieden een tijdelijke oplossing terwijl de reparatie van de leverancier in afwachting is.

Een beschrijving van het probleem en wanneer het begon (bijv. na een update, na een inhoudswijziging), WordPress-admin-toegang en FTP- of SFTP-toegang tot de sitebestanden. Screenshots of een schermopname van de zichtbare fout zijn nuttig. Toegang tot het PHP-foutenlogboek versnelt de diagnose aanzienlijk. Hoe meer context je kunt geven over wat er is gewijzigd voordat het probleem verscheen, hoe sneller de diagnose — maar als je niet weet wat er is gewijzigd, kunnen we werken vanuit de foutenlogboeken.

Als hetzelfde probleem binnen 30 dagen na een door ons geleverde reparatie terugkeert, onderzoeken en lossen we het op zonder extra kosten. Terugkeer na een reparatie betekent meestal dat ofwel de diagnose van de hoofdoorzaak onvolledig was (onze verantwoordelijkheid) of dat er extern iets is veranderd — een nieuwe plugin-update, een wijziging in de hostingomgeving, of nieuwe inhoud die een randgeval activeert. We bepalen wat het geval is en handelen dienovereenkomstig.

Voor de meeste bugfixes, ja — wijzigingen worden aangebracht op staging en pas na verificatie op de live site geïmplementeerd. Sommige reparaties vereisen een korte onderhoudsmodus (meestal onder de 10 minuten) voor database-wijzigingen of bestandsvervangingen. We stellen je altijd van tevoren op de hoogte als er downtime voor de live site nodig is, en plannen dit waar mogelijk in voor een moment met weinig verkeer.