wp_options Tabel – Automatisch geladen opties opruimen

wp_options Tabel – Automatisch geladen opties opruimen

Wat is de wp_options-directory?

De wp_options-directory bevat allerlei soorten gegevens voor je WordPress-site, zoals:

-Site – URL, Home – URL, Admin – e-mail, standaardcategorie, berichten per pagina, tijdformaat, enzovoort.
-Instellingen voor plugins, thema’s, widgets
-Tijdelijk gecachte gegevens

wp_options Directory
wp_options Directory

De directory bevat de volgende velden, waarvan er één meer nadruk legt op prestaties:

option_id
option_name
option_value
Autoload

De wp_options-tabel is een cruciale prestatiefactor in WordPress omdat alle items met autoload = ‘ja’ bij elke paginaweergave in het geheugen worden geladen. Als oude plugin-restjes en onnodig grote datastructuren zich daar ophopen, zal je site merkbaar trager zijn.

Basis: Begrijpen wp_options en autoload

Table wp_options bevat globale instellingen van WordPress, thema’s en plugins; De kolommen option_name, option_value en autoload zijn bijzonder relevant. De autoloadwaarde bepaalt of deze optie bij elke oproep wordt geladen (“ja”) of alleen wanneer nodig (“nee”), waardoor grote autoload-data een direct prestatierisico vormt.

Het eerste wat je kunt doen is de huidige automatisch geladen grootte op je WordPress-site controleren. Klik in je phpMyAdmin op je database links en vervolgens op het SQL-tabblad. Typ dan het volgende commando in en druk op “Go”.

SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';

Je moet de bovenstaande query mogelijk optimaliseren als je WordPress-site een ander prefix gebruikt dan wp_.

Je kunt ook een langere query gebruiken zoals hieronder. Dit toont de automatisch geladen gegevens, het aantal vermeldingen in de directory en de eerste 10 vermeldingen per grootte.

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;

De autoload_size wordt gegeven in bytes. Een KB bestaat uit 1024 bytes, een MB uit 1024 KB. In ons voorbeeld komen 939.774 bytes overeen met ongeveer 0,91 MB, wat een niet-kritische waarde is voor deze pagina. Als de waarde kleiner is dan 1 MB, is er meestal geen actie nodig. Als het resultaat echter aanzienlijk hoger is, kun je doorgaan met de volgende stappen uit deze tutorial.

Een typische start is een overzicht van de grootte van de automatisch geladen data. Bijvoorbeeld, in phpMyAdmin of een andere MySQL-client kun je de volgende query gebruiken om de totale grootte en het aantal te zien en de grootste chunks te identificeren:

SELECT 'autoload_size_kb' AS label,
       ROUND(SUM(LENGTH(option_value))/1024) AS value
FROM wp_options
WHERE autoload = 'yes'
UNION ALL
SELECT 'autoload_count',
       COUNT(*)
FROM wp_options
WHERE autoload = 'yes'
UNION ALL
SELECT option_name,
       LENGTH(option_value) AS value
FROM wp_options
WHERE autoload = 'yes'
ORDER BY value DESC
LIMIT 10;

Als ruwe vuistregel geldt dat 300-1000 KB autoload-data als gezond wordt beschouwd; Enkele megabytes duiden meestal op een noodzaak tot schoonmaak.

Typische oorzaken van opgeblazen autoladingen

Grote autoload-blokken worden voornamelijk gemaakt door plugins die veel configuratiegegevens of logs naar wp_options schrijven en autoload op “ja” zetten. Vaak blijven hun vermeldingen in de database staan, zelfs na verwijdering, omdat de plugin niet goed wordt opgeschoond tijdens het verwijderen of WP cron-taken falen.

Geserialiseerde arrays met veel vermeldingen (bijv. cachegegevens, logboeken, trackinginformatie) of oude transiënten die nooit zijn verwijderd, zijn bijzonder problematisch. Deze vermeldingen zijn niet langer nodig, maar ze laden nog steeds elke keer dat de pagina wordt geladen, waardoor MySQL-queries en PHP-uitvoering vertragen.

Een goede praktijk is om specifiek kritieke option_name-waarden te analyseren die voorkomen in de “top 10” van de grootste autoload-items. Je kunt op “Bewerken” klikken in phpMyAdmin en de inhoud bekijken – vaak kun je aan de hand van het naamgevingsschema zien welke plugin verantwoordelijk is (bijvoorbeeld voorwoorden zoals transient, plugin_xyz_, rankmath_, wpseo_, enz.).

Handmatige analyse en schoonmaak via SQL

Als je vertrouwd bent met SQL, kun je specifiek zoeken naar grote autoload-opties en verdachte vermeldingen markeren. Bijvoorbeeld, een eenvoudige lijst van alle automatisch geladen opties, gesorteerd op grootte, ziet er als volgt uit:

SELECT option_id,
       option_name,
       LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 100;

Voordat je iets verandert of verwijdert, is het essentieel dat je een volledige database-back-up maakt en deze idealiter test in een staging-omgeving. Voor entries waarvan je zeker weet dat ze alleen caches, verlopen transienten of oude plugin-data bevatten, zijn er twee relatief veilige stappen:

1. Zet Autoload eerst op “nee” en kijk of er iets kapot gaat:

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'DEIN_OPTION_NAME';

2. Als alles na een paar dagen stabiel is, verwijder dan de invoer:

DELETE FROM wp_options
WHERE option_name = 'DEIN_OPTION_NAME';

Voor transiënten die toch zouden moeten verlopen, kun je ook hele groepen wildcards verwijderen, zoals:

DELETE FROM wp_options
WHERE option_name LIKE '\_transient\_%'
   OR option_name LIKE '\_site\_transient\_%';

Je moet zulke massacommando’s alleen gebruiken als je weet dat je cache/transientsysteem ze aankan, want veel data moet achteraf opnieuw worden opgebouwd.

WP-CLI Voorbeelden van Terugkerende Schoonmaak

WP-CLI is geschikt voor reguliere opruiming omdat je het kunt gebruiken om scriptlijsten, filters en verwijdercommando’s te maken. Een voorbeeld van een overzicht van de grootste automatische laadopties:

bashwp option list \
  --autoload=on \
  --fields=option_name,autoload,size \
  --format=json \
  --orderby=size \
  --order=desc \
  --field=option_name \
  --page=1 --per-page=20

Om een optie te verwijderen, kun je WP-CLI zo gebruiken:

bashwp option delete DEIN_OPTION_NAME

Of je kunt autoload instellen op “nee” via WP-CLI zonder direct te verwijderen:

bashwp db query "UPDATE wp_options SET autoload='no' WHERE option_name='DEIN_OPTION_NAME';"

Dergelijke commando’s kunnen worden verpakt in een cron-script of een klein onderhoudsscript dat bijvoorbeeld eens per maand draait nadat een back-up is gemaakt.

Gebruik van plugins voor automatische reiniging

Als je niet direct in de database wilt werken, kun je speciale optimalisatie-plugins gebruiken. Tools zoals Advanced Database Cleaner, WP-Optimize of overeenkomstige functies in prestatie-plugins analyseren de wp_options-tabel en bieden interfaces om oude transiënten, revisies en bepaalde opties te verwijderen.

Deze plugins kunnen geautomatiseerde routines aanmaken, bijvoorbeeld het regelmatig schoonmaken van verlopen transiënten of het verwijderen van verweesde plugin-invoeren. Ze erkennen echter niet altijd alle problematische opties; Voor complexe of bedrijfskritische systemen wordt een handmatige controle van de grootste autoload-invoer aanbevolen.

Visuele ondersteuning: diagrammen en screenshots

Om de situatie beter te communiceren, is een eenvoudige visualisatie de moeite waard. Een staafdiagram met de top 10 autoload-opties per grootte maakt aan belanghebbenden duidelijk waarom bepaalde plugins of opties problematisch zijn. Zo’n diagram kan worden gegenereerd uit de SQL-resultaten (option_name versus size_bytes) in een BI-tool of zelfgebouwd dashboard.

Screenshots van phpMyAdmin of Adminer, die de wp_options weergave met filters WHERE autoload = 'yes' en gesorteerde groottes tonen, zijn ook nuttig. Gemarkeerde lijnen (bijvoorbeeld met gekleurde opmerkingen in documentatie of presentaties) maken het makkelijker om ze later aan specifieke plugins en metingen toe te wijzen.

Best practices en vangnet

Ongeacht de methode zijn er een paar basisregels: maak een volledige back-up vóór elke opruiming, bij voorkeur testen in een staging-omgeving, en plan een onderhoudsvenster voor productiesystemen. Daarnaast moeten na grote verwijderingsacties prestatiemonitoring, foutlogboeken en belangrijke functies (login, winkel, contactformulieren) worden uitgevoerd om snel ontbrekende opties te identificeren.

Op de lange termijn is het de moeite waard om op plugin-niveau op te schonen: verwijder echt ongebruikte plugins en thema’s, deactiveer niet alleen thema’s, en let goed op hoe ze wp_options aanpakken bij het kiezen van nieuwe extensies. Vooral met page builders, SEO-tools, beveiligingsplugins en complexe integraties is het de moeite waard om de documentatie te bekijken om te zien of grote hoeveelheden data in het autoload-gebied terechtkomen – en of er instellingen zijn die dit verminderen.

Met zo’n mix van analyses, gerichte SQL/WP CLI-acties, ondersteunende plugins en duidelijke processen kan de wp_options-tabel slank worden gehouden of weer gezond worden. Het resultaat is snellere databasequeries, minder geheugenverbruik en over het algemeen merkbaar betere prestaties van je WordPress-installatie.

Hoe identificeer ik plugin-restjes in wp_options automatisch geladen data bij WPML- en WooCommerce-integratie?

Automatisch geladen plugin-restjes in wp_options kunnen gemakkelijk worden gedetecteerd via een combinatie van SQL/WP-CLI, naamgevingspatronen en wat WPML/WooCommerce-kennis.

Basisprincipe: analyseer autoload-opties

De eerste stap is altijd om de grootste autoload-opties te vinden, want daar vallen pluginrestjes en verkeerde configuraties het meest op. In een SQL-tool (of via WP-CLI) kun je de topvermeldingen als volgt krijgen, bijvoorbeeld:

SELECT option_id,
       option_name,
       LENGTH(option_value) AS size_bytes
FROM   wp_options
WHERE  autoload = 'yes'
ORDER  BY size_bytes DESC
LIMIT 100;

Veel overblijfselen zijn te herkennen aan het voorvoegsel van de option_name:

• WPML slaat opties op met patronen zoals icl_%, wpml_%, , translatiecaches, stringindexen en meer.
• WooCommerce en add-ons gebruiken vaak woocommerce_%, _transient_wc_% of plugin-specifieke prefixen zoals wcs_, yith_%.

Als hier grote vermeldingen van plugins die je al lang hebt verwijderd, of duidelijk cache-/loggegevens voorkomen, zijn dit typische kandidaten voor “plugin-resten”.

WPML- en WooCommerce-specifieke patronen

Voor sites met WPML en WooCommerce is het de moeite waard om eens goed te kijken naar opties met betrekking tot vertalingen en winkelfuncties. WPML kan veel automatisch geladen opties genereren voor taalmapping en stringvertaling; WooCommerce slaat bijvoorbeeld belasting-, verzend-, sessie- of rapportagegegevens op.

Filters op basis van naampatronen zijn nuttig, zoals:

SELECT option_id, option_name, LENGTH(option_value) AS size_bytes
FROM   wp_options
WHERE  autoload = 'yes'
AND   (option_name LIKE 'icl\_%'
    OR option_name LIKE 'wpml\_%'
    OR option_name LIKE 'woocommerce\_%'
    OR option_name LIKE '\_transient\_wc\_%')
ORDER BY size_bytes DESC;

Als je vermeldingen vindt die behoren tot add-ons die niet meer in het systeem zitten (bijvoorbeeld oude betaalgateways, oude vertaaltools), kun je ze classificeren als plugin-restanten. Het is belangrijk om eerst te controleren of de bijbehorende plugin echt niet meer actief is, dan een back-up te maken en pas daarna autoload op “nee” te zetten of te verwijderen.

Geautomatiseerde ondersteuning via analysetools

Voor meer gemak zijn er speciale optimalisatie-plugins die automatisch geladen opties scannen en proberen deze toe te wijzen aan specifieke plugins of thema’s. Voorbeelden zijn:

• Autoload-checker of “Option Optimizer”: toont het aantal, de grootte en de naam van alle autoload-opties, markeert wees-opties en geeft aanwijzingen naar de oorsprong.
• Advanced Database Cleaner: scant de wp_options-tabel, geeft opties op basis van grootte, autoload-status en vermoedelijke plugin-mapping, en maakt gefilterde verwijdering mogelijk.

Deze toewijzing is echter niet onfeilbaar: opties worden vaak aan de verkeerde plugins toegewezen of als “wees” gemarkeerd, ook al zijn ze nog in gebruik. Daarom geldt het volgende: Gebruik tools om kandidaten te vinden, maar neem altijd handmatig beslissingen – vooral in een setup met WPML en WooCommerce.

Procedure in de praktijk

Een pragmatische workflow ziet er als volgt uit:

• Bepaal de totale grootte en de hoogste autoload-invoer, groepeer verdachte option_name op plugin-prefixen.
• Controleer welke plugins (vooral WPML-modules, WooCommerce-add-ons) daadwerkelijk nog actief zijn.
• Markeer duidelijke alternatieve plugins en noteer hun optienamen.
• Stel eerst de automatische lading van deze items in op “nee”, test de pagina (frontend, afrekenen, vertaling).
• Als er na een paar dagen geen fouten meer zijn, verwijder dan de betreffende opties.

Op deze manier kunnen pluginresiduen op een gerichte manier uit wp_options worden gehaald zonder de functionaliteit van WPML of WooCommerce in gevaar te brengen.

SELECT option_id, option_name, LENGTH(option_value) AS size_bytes FROM wp_options WHERE autoload = 'yes' ORDER BY size_bytes DESC LIMIT 50