De eerste stap die je zet is een maximum aantal post-revisions instellen. Hoe je dat doet, lees je in het artikel Wordpress: limiet aan post-revisions.

direct in je database werken

Wijzigingen doorvoeren in je database is niet moeilijk, maar pas wel op: als je eenmaal iets hebt veranderd, is dat definitief. Maak daarom ALTIJD een backup van je database voordat je er iets aan verandert.

Verder: werk stap voor stap en controleer of alles op de goede plek staat en of je de juiste selecties hebt gemaakt, voordat je op “Start” of “Go” klikt.

Erg veel providers hebben als databaseprogramma MySQL geïnstalleerd. Om met de database te kunnen werken, wordt vaak het programma PHPMyAdmin gebruikt.

Ook in de onderstaande handleiding is gebruik gemaakt van MySQL en PHPMyAdmin.

Andere ‘frontend’ programma’s dan PHPMyAdmin lijken erg op elkaar en maken geen verschil voor de werking van MySQL. Een ander databaseprogramma gebruikt echter andere opdrachten, zodat je in dat geval deze handleiding niet kunt gebruiken.

post revisions verwijderen uit de database

• ♦ log in op phpMyAdmin

• ♦ klik op de database die je gebruikt
  

• ♦ klik op de tab ’sql’
  

• ♦ tik de volgende opdracht in het query-veld:

delete x,y,z
from wp_posts x
left join wp_term_relationships y on (x.id = y.object_id)
left join wp_postmeta z on (x.id = z.post_id)
where x.post_type = 'revision'

• ♦ let op dat je bij de tabelnamen wp-posts, wp_term_relationships en wp-postmeta het prefix of voorvoegsel gebruikt van je eigen wordpress-installatie

• ♦ klik op ‘Start’

  

deze opdracht haalt alles weg wat met je herstelversies van je posts te maken heeft; niet alleen de revisieposts zelf, maar ook de bijbehorende metadata.

Let op: van elke post blijft de laatste versie, die je op het internet geplaatst hebt, gewoon bestaan. Deze posts zijn namelijk gelabeld als ‘actual’ en niet als ‘revision’

• ♦ ruim nu de restjes op: selecteer opnieuw de database
  

• ♦ en kijk in de kolom ‘overhead’

• ♦ klik op ’selecteer de tabellen met overhead’
  

• ♦ klik op de driehoek in het keuzevak en selecteer ‘Optimaliseer’ tabel
  

• ♦ klik op ’start’ en je krijgt het volgende resultaat:
  

De database is nu opgeruimd. Als je vaak tussendoor je post opslaat of vaak iets wijzigt, zul je merken dat je vele kilobytes kwijt bent. Bij voorbeeld bij onderstaande vergelijking tussen mijn databse vóór en na de opruiming:

Daarmee is je database kleiner geworden, ijn je overtollig wordpress-revisions opgeruimd en is je wordpress weblog een stuk sneller en weer wat verder geoptimaliseerd.

In ieder geval niet altijd. Als je gewend bent, zoals ik, om heel vaak tussendoor op te slaan – ik woon nu eenmaal op Curaçao, waar de stroomleverantie niet altijd gegarandeerd is – groeit je database in een oogwenk uit tot megaproporties.

post-revisions als herstelpunten

Hoe komt dat? Wordpress beschikt over een eigen systeem met ‘herstelpunten’ , de post-revisions. Elke keer als je je post wijzigt en opslaat, zet Wordpress een nieuwe versie in de database zonder de oude te wissen. Het aantal herstelpunten is daarmee oneindig, zoals je kunt zien op een lijst van mijn post-revisions toen ik iets uitprobeerde met html-code in een post. Het idee is natuurlijk heel mooi, maar in mijn geval wordt de database niet alleen snel erg groot, hij wordt ook erg traag. Dat is helaas direct in je browser te zien als je op je eigen weblog rondsurft.

post-revisions limiteren

Sinds Wordpress 2.6 is het gelukkig mogelijk hier heel eenvoudig iets aan te doen. Als je helemaal geen reserve-exemplaren van je posts wilt hebben, kun je de post-revisions uitschakelen.
Het is ook mogelijk een limiet te stellen aan het aantal herstelpunten dat je wilt hebben. Als je de limiet bij voorbeeld op 2 reserve-versies zet en je slaat je bestand voor de derde keer op, overschrijft Wordpress je oudste post-revision in de database. Je database wordt dus nooit groter dan, in dit geval, drie versies van je bericht: de meest recente en 2 backups.

post-revisions instellen

In de hoofdmap van je Wordpress-installatie zoek je het bestand ‘wp-config.php’ op.
Open het in een tekstverwerker (GEEN Word, WEL bv. Kladblok).

In het bestand zoek je de volgende regel op:

define('DB_COLLATE', '');

Op een nieuwe regel hierna voeg je de volgende regel toe:

define('WP_POST_REVISIONS', 2);

Het getal, in dit geval 2, geeft aan hoeveel post-revisions of herstelpunten je wilt bewaren. Wil je helemaal geen herstelpunten, vul dan de volgende regel in:

define('WP_POST_REVISIONS', false);

Hieronder zie je een voorbeeld:

Let op dat je de regel wel op deze plek zet, anders werkt het niet!

Vanaf nu zal je database in ieder geval niet meer groeien door een oneindig aantal revisions.
Hoe je de al bestaande revisions uit je database verwijdert, lees je in het artikel Wordpress: post-revisions en de database.

Wat gebeurde er?
Mijn Wordpress-site moest van mijn lokale server naar een webhost. Dat gaf meteen een importprobleem bij de MySQL-database. Verschillende fouten die mogelijk twee oorzaken hadden:
1.de beperkte rechten als gebruiker op de server van de webhost   i.t.t. beheerderspositie op de lokale server
2.verschillende Mysql-versies (host een verouderde, die ze pas over een paar maanden gaan updaten, leuk, hebben we dan weer een probleem???)
webhost: MySQL vs. 4.0.24 Standard
lokale server: MySQL vs. 5.1.

Gelukkig had ik een test-wordpress geïnstalleerd op de webhost èn een backup gemaakt van zowel de bestanden als de database bij de webhost.

Om alles over te zetten had ik het volgende voorbereid:
lokale server:
– backup gemaakt: sql-bestand “wp-lokaal.sql” van database op locale server

webhost:
– backup gemaakt: sql-bestand “testlog.sql” van Wordpress-testlog
– gewist: tables (alle tabellen in de db selecteren, drop tables, ok)
– in database wp-bij-host: importeer – van bestand €“ wp-lokaal.sql

Foutmeldingen

Helaas kreeg ik de volgende foutmelding:
Error

SQL query:

CREATE TABLE `blogdb_comments` ( `comment_ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `comment_post_ID` bigint(20) unsigned NOT NULL DEFAULT '0', `comment_author` tinytext NOT NULL, `comment_author_email` varchar(100) NOT NULL DEFAULT '', `comment_author_url` varchar(200) NOT NULL DEFAULT '', `comment_author_IP` varchar(100) NOT NULL DEFAULT '', `comment_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `comment_date_gmt` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `comment_content` text NOT NULL, `comment_karma` int(11) NOT NULL DEFAULT '0', `comment_approved` varchar(20) NOT NULL DEFAULT '1', `comment_agent` varchar(255) NOT NULL DEFAULT '', `comment_type` varchar(20) NOT NULL DEFAULT '', `comment_parent` bigint(20) unsigned NOT NULL DEFAULT '0', `user_id` bigint(20) unsigned NOT NULL DEFAULT '0', PRIMARY KEY (`comment_ID`), KEY `comment_approved` (`comment_approved`), KEY `comment_post_ID` (`comment_post_ID`), [...]

MySQL said: Documentation
#1064 - You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'DEFAULT CHARSET=utf8 AUTO_INCREMENT=6' at line 22

- vervolgens de db als platte tekst geïmporteerd maar alleen alles na de regel
'DEFAULT CHARSET=utf8 AUTO_INCREMENT=6' at line 22

- toen kwam de volgende foutmelding:
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
MySQL said: Documentation
#1193 - Unknown system variable 'SQL_MODE'

Verschillen versie 4 en 5

- gelukkig had ik een backup van de database van mijn testlog. Zowel testlog.sql als wp-lokaal.sql in een teksteditor geopend. Beetje scrollen gaf al snel een paar hele grote verschillen, nl.:

1. 1e regel van de code die uitgevoerd moet worden:
webhost:
witregels
localeserver:
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

2. character-encoding,
webhost:
/*!40101 SET NAMES latin1 */;
localeserver:
/*!40101 SET NAMES utf8 */;

3. aan het einde van elke tabel:
webhost:
) TYPE=MyISAM AUTO_INCREMENT=4 ;
localeserver:
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=6 ;

de oplossing

De volgende stappen waren simpel:
– maak voor de zekerheid een kopietje van wp-lokaal.sql, hernoem tot wp-lokaalORI.sql en ga het bestand wp-lokaal.sql aanpassen:
ad 1. verwijder de regel:
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

ad 2. verwijder de regel:
/*!40101 SET NAMES utf8 */;

ad 3. ga met de opdracht ‘zoek en vervang’ aan de gang.
Aan het einde van elke tabel komen de coderegels van punt 3. voor.
De waarde van AUTO_INCREMENT=6 is bij elke tabel anders, de tekst vind je wel bij allebei. Dat stukje code dus maar laten staan.
Blijkbaar is er een verschil tussen versie 4 en 5 van MySQL in het benoemen van MyISAM.
En de utf8-string levert ook foutmeldingen op, dus die moet weg.

De opdracht voor ‘zoek en vervang’ wordt dan als volgt:
zoek de string:
ENGINE=MyISAM DEFAULT CHARSET=utf8
en vervang door:
TYPE=MyISAM

- sla het bestand op en importeer opnieuw. Even wachten, even langer als het een groot bestand is, en voilà: de database is geïmporteerd!

O ja, dat de meest recente versie thuis op een windows-machine stond, terwijl de server van de webhost op Linux draait, heeft in dit geval blijkbaar weinig uitgemaakt.