Na lang zoeken kwam ik er eindelijk achter waar je die vermaledijde titel kunt veranderen:

klik in je Dashboard op ‘Links’; het menu vouwt open.

klik op ‘Link Categories’

Bingo! Daar verschijnt dan eindelijk het venster dat je zo graag wilt zien:

wijzig de ‘Link Categorie name’ van ‘Blogroll’ in ‘links’; met of zonder hoofdletter of geef de categorie een heel andere naam. ‘Interessante links’, of ‘Kijk ook eens hier’ of  ‘Surftips’, enfin, vul maar in.
De ’slug’ kun je naar believen dezelfde naam meegeven of ongewijzigd laten; hetzelfde geldt voor de ‘Description’ of beschrijving.

klik op ‘Update Category’

en er verschijnt een venster dat je ‘Link Categories’ zijn bijgewerkt.

Je ziet in hetzelfde scherm nog de volgende mededeling staan:

‘Het verwijderen van een categorie betekent niet dat de links in die categorie ook zijn verdwenen. In plaats daarvan worden de links die gerelateerd waren aan de verwijderde categorie nu toegevoegd aan de categorie ‘links’.

En dat was dus precies de bedoeling!

Als je nu in de sidebar van je website kijkt, ziet het er zo uit:

Ach, de oplossing ligt soms in een klein hoekje…

De hackpogingen verlopen geautomatiseerd, met voorgeprogrammeerde scripts die dankbaar gebruik maken van de vele standaard-instellingen van wordpress. Upgraden naar de nieuwste versie van wordpress doe je natuurlijk al.

Maar je kunt nog veel meer doen op het gebied van veiligheid. De eerste stap om je wordpress-installatie verder te beveiligen, is dan ook zo veel mogelijk ‘defaults’ of standaardinstellingen te veranderen.

Hier komen er een paar:

1. zorg dat je geen gebruiker ‘admin’ hebt:
   1. maak een nieuwe gebruiker aan, bv ‘ik4feest’
   2. geef een andere naam die zichtbaar is in de publicaties, bv. ‘mijnnaam’
   3. geef de gebruiker ‘ik4feest’ beheersrechten
   4. log uit en log daarna weer in als de nieuwe gebruiker
   5. wis de gebruiker ‘admin’




2. gebruik geen standaardplaats om je wordpress blog neer te zetten:
   1. zet je blog niet op de root van de server waar je website wordt gehost
   2. maak een aparte map om je wordpress in te installeren
   3. noem die map GEEN ‘wordpress’ en GEEN ‘blog’, maar desnoods iets als ‘xkw53′




3. gebruik een niet het standaard prefix ‘wp_’ dat wordpress voor je database aanmaakt
   1. maar bedenk een ander , zoals ‘w8even’ en vermijd de meest voor de hand liggende afkortingen
   2. vergeet niet dit prefix ook in je wp_config.php aan te passen




4. gebruik moeilijk te kraken wachtwoorden: geen bestaande woorden, namen, geboortedata, kentekens en zo voorts, maar iets als H7^Ff3q*6% minimaal 10 tekens lang. Elk extra teken kost heel veel extra computerrekenwerk om het te kraken!




5. elke wordpressversie heeft z’n eigen kwetsbaarheden. Maak daarom je wordpress-versie-informatie onzichtbaar. Dat doe je zo:
   1. Open het bestand “header.php” in de folder ‘wp-content/themes/jouwthema’
   2. zoek de volgende regel:
   3. verwijder de regel en sla je bestand op.

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.

Voor het eerst zit ik op mijn eigen server geheel voor mezelf een blogje te schrijven.

Ziet er allemaal eenvoudig uit, maar er is heel wat aan vooraf gegaan. Allereerst wilde ik natuurlijk mijn eigen thema. Lastig als je bij voorbaat vindt dat de duizenden bestaande thema’s net niet zijn wat je zelf in je hoofd hebt.
Gevolg: bestaande thema’s bestuderen, de wordpress-codex bij mijn meest bezochte websites. Eindelijk (gedwongen) aan de slag met php, anders kon ik nooit mijn eigen wordpress-thema bouwen en al die andere webfacetten om tussen neus en lippen door wat meer van te leren; ik ben de afgelopen maanden weer heel wat wijzer geworden.
Alleen al de moeite die het kost om je website er in vier verschillende browsers (firefox, opera, safari, internet explorer) op verschillende besturingssystemen ongeveer hetzelfde uit te laten zien! Ik weet nu dus ook wat browserhacks zijn…

In ieder geval bevalt het wordpress-concept me:  een ideale manier om een dynamisch weblog te combineren met een doorlopende tentoonstelling van mijn werk.

Het informele karakter van een weblog waar je onbevangen je kiekjes en spontane invallen kunt plaatsen, gekoppeld aan de pagina’s met het professionele werk.

En dit is natuurlijk erg leuk zo lang je op je eigen server zit: – een regeltje erbij schrijven in de mysql-database zelf!!!