Problemen met MariaDB versie 10.1.16 op OS X El Capitan

In het bericht “Problemen met MariaDB versie 10.1.8 op OS X El Capitan” schreef ik al eerder over problemen met MariaDB. Inmiddels heb ik MariaDB bijgewerkt naar versie 10.1.16 met behulp van Brew. Helaas kreeg ik nu ook weer fouten bij het opstarten van MariaDB:

➜  ~ mysqld
2016-07-27  9:12:38 140735199690752 [Note] mysqld (mysqld 10.1.16-MariaDB) starting as process 7611 ...
2016-07-27  9:12:38 140735199690752 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: The InnoDB memory heap is disabled
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Memory barrier is not used
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Compressed tables use zlib 1.2.5
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Using SSE crc32 instructions
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Completed initialization of buffer pool
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Highest supported file format is Barracuda.
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: 128 rollback segment(s) are active.
2016-07-27  9:12:38 140735199690752 [Note] InnoDB: Waiting for purge to start
2016-07-27  9:12:38 140735199690752 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.30-76.3 started; log sequence number 3504876906
2016-07-27  9:12:38 123145313034240 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-07-27  9:12:38 140735199690752 [Note] Plugin 'FEEDBACK' is disabled.
2016-07-27  9:12:38 140735199690752 [Note] Recovering after a crash using tc.log
2016-07-27  9:12:38 140735199690752 [ERROR] Recovery failed! You must enable all engines that were enabled at the moment of the crash
2016-07-27  9:12:38 140735199690752 [ERROR] Crash recovery failed. Either correct the problem (if it's, for example, out of memory error) and restart, or delete tc log and start mysqld with --tc-heuristic-recover={commit|rollback}
2016-07-27  9:12:38 140735199690752 [ERROR] Can't init tc log
2016-07-27  9:12:38 140735199690752 [ERROR] Aborting

Dit keer kon ik het probleem echter oplossen door het tc log bestand te verwijderen:

mv /usr/local/var/mysql/tc.log /usr/local/var/mysql/tc.log.bak

Hier na kon ik MariaDB zonder problemen opstarten:

➜  ~ mysql.server start

Problemen met MariaDB versie 10.1.8 op OS X El Capitan

Na het updaten van MariaDB via Brew naar versie 10.1.8 had ik problemen met het opstarten van de MySQL server.

~  mysqld
2015-10-28 10:45:19 140735257919488 [Note] mysqld (mysqld 10.1.8-MariaDB) starting as process 1069 ...
2015-10-28 10:45:19 140735257919488 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: The InnoDB memory heap is disabled
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Memory barrier is not used
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Compressed tables use zlib 1.2.5
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Using CPU crc32 instructions
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Completed initialization of buffer pool
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Highest supported file format is Barracuda.
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: The log sequence numbers 2407038528 and 2407038528 in ibdata files do not match the log sequence number 2407038728 in the ib_logfiles!
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Database was not shutdown normally!
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Starting crash recovery.
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Restoring possible half-written data pages
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: from the doublewrite buffer...
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: 128 rollback segment(s) are active.
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Waiting for purge to start
2015-10-28 10:45:19 7000008b1000  InnoDB: Assertion failure in thread 123145311424512 in file btr0cur.cc line 5341
InnoDB: Failing assertion: rb_ctx != RB_NONE
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
151028 10:45:19 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.1.8-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467104 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x48000
0   mysqld                              0x000000010f93bd21 my_print_stacktrace + 61
0   mysqld                              0x000000010f3dfffc handle_fatal_signal + 632
0   libsystem_platform.dylib            0x00007fff9501552a _sigtramp + 26
0   ???                                 0x0000000000000009 0x0 + 9
0   libsystem_c.dylib                   0x00007fff9f50237b abort + 129
0   mysqld                              0x000000010f782e39 _ZL28btr_check_blob_fil_page_typemmPKhm + 0
0   mysqld                              0x000000010f8cf80d _Z14row_purge_stepP9que_thr_t + 2334
0   mysqld                              0x000000010f8a2a1a _Z15que_run_threadsP9que_thr_t + 822
0   mysqld                              0x000000010f8f9862 _Z9trx_purgemmb + 2812
0   mysqld                              0x000000010f8eccb1 srv_purge_coordinator_thread + 2484
0   libsystem_pthread.dylib             0x00007fff94b169b1 _pthread_body + 131
0   libsystem_pthread.dylib             0x00007fff94b1692e _pthread_body + 0
0   libsystem_pthread.dylib             0x00007fff94b14385 thread_start + 13
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Aangezien ik geen MariaDB/MySQL expert ben heb ik niet de oorzaak van dit probleem kunnen vinden. Gelukkig kun je met Brew eenvoudig terug naar een oudere versie.

brew switch mariadb 10.0.21

Hiermee was het probleem direct opgelost.

Een WordPress multisite/network omzetten naar een single WordPress installatie

Als je een WordPress site binnen een WordPress multisite/network wilt omzetten naar een individuele WordPress installatie zul je na een zoektocht op internet al snel het advies krijgen om de content te exporteren en te importeren. Dit heeft echter als nadeel dat gebruikers, instellingen, plugins, thema’s, etc. niet meegenomen worden. In de blog “The Return from Multiste” is te lezen hoe dit ook via enkele database queries gerealiseerd kan worden.

Aangezien ik veel gebruik maak van Gravity Forms, Pronamic iDEAL en Redirection moest ik nog de volgende extra queries uitvoeren:

RENAME TABLE 
OLDPRE_OLDNUM_rg_form TO NEWPRE_rg_form, 
OLDPRE_OLDNUM_rg_form_meta TO NEWPRE_rg_form_meta, 
OLDPRE_OLDNUM_rg_form_view TO NEWPRE_rg_form_view, 
OLDPRE_OLDNUM_rg_lead TO NEWPRE_rg_lead, 
OLDPRE_OLDNUM_rg_lead_detail TO NEWPRE_lead_detail, 
OLDPRE_OLDNUM_rg_lead_detail_long TO NEWPRE_lead_detail_long, 
OLDPRE_OLDNUM_rg_lead_meta TO NEWPRE_rg_lead_meta, 
OLDPRE_OLDNUM_rg_lead_notes TO NEWPRE_rg_lead_notes;
RENAME TABLE 
OLDPRE_OLDNUM_rg_ideal_feeds TO NEWPRE_rg_ideal_feeds, 
OLDPRE_OLDNUM_pronamic_ideal_configurations TO NEWPRE_pronamic_ideal_configurations, 
OLDPRE_OLDNUM_pronamic_ideal_payments TO NEWPRE_pronamic_ideal_payments;
RENAME TABLE 
OLDPRE_OLDNUM_redirection_404 TO NEWPRE_redirection_404, 
OLDPRE_OLDNUM_redirection_groups TO NEWPRE_redirection_groups,
OLDPRE_OLDNUM_redirection_items TO NEWPRE_redirection_items,
OLDPRE_OLDNUM_redirection_logs TO NEWPRE_redirection_logs,
OLDPRE_OLDNUM_redirection_modules TO NEWPRE_redirection_modules;

Daarnaast heb ik via de active_sitewide_plugins meta key in de OLDPRE_sitemeta tabel en http://www.unserialize.com/ nog even gecontroleerd welke plugins sitewide geactiveerd waren.

Homebrew MariaDB MySQL server has gone away

Bij het importeren van een grote WordPress database in mijn lokale MariaDB database server liep ik tegen de volgende fout aan:

ERROR 2006 (HY000) at line 40786: MySQL server has gone away

Na wat zoeken op internet kom je al snel berichten tegen dat dit te maken heeft met de ‘max_allowed_packet‘ configuratie instelling.

Na wat zoeken heb ik in mijn gebruikersmap (~) een MySQL configuratie bestand (~/.my.cnf) aangemaakt volgens de MariaDB documentatie.

https://mariadb.com/kb/en/mariadb/documentation/getting-started/configuring-mariadb-with-mycnf/#location-in-linux-unix-mac

Door hier het volgende in te zetten is de ‘max_allowed_packet’ instelling eenvoudig te verhogen.

[mysqld]
max_allowed_packet=1073741824

Vervolgens kan MariaDB database server eenvoudig herstart worden met behulp van het volgende commando:

mysql.server restart

WordPress database prefix wijzigen

Voor het wijzigen van de WordPress database prefix zijn verschillende plugins beschikbaar. Deze plugins wijzigen echter niet altijd alle prefixes. De WordPress database prefix wordt namelijk naast in de tabel namen ook gebruikt in de ‘options’ en ‘usermeta’ tabellen. Jan Egbert tipte me daarom over de volgende SQL query:

UPDATE wp_usermeta SET meta_key = REPLACE(meta_key, 'wp_', 'nieuweprefix_') WHERE meta_key LIKE 'wp\_%';

Via een aantal andere websites kwam ik er achter dat ook de ‘options’ tabel de WordPress database prefix wordt gebruikt. Daarom zal waarschijnlijk ook de volgende query uitgevoerd moeten worden:

UPDATE wp_options SET option_name = REPLACE(option_name, 'wp_', 'nieuweprefix_') WHERE option_name LIKE 'wp\_%';

Bovenstaande queries gaat echter fout zodra de WordPress database prefix terug komt in de optie naam of de user meta key.

umeta_id user_id meta_key meta_value
1 1 wp_pronamic_wp_version 3.5

Zal na het uitvoeren van de query gewijzigd worden naar:

umeta_id user_id meta_key meta_value
1 1 nieuweprefix_pronamic_nieuweprefix_version 3.5

De “Change DB Prefix” plugin lijkt uitgerust zijn met de juiste queries:

http://plugins.trac.wordpress.org/browser/db-prefix-change/tags/1.1/db_prefix.php#L83

Meer informatie:

WordPress meta veld met URL zonder http://

Afgelopen maanden ben ik een aantal keer WordPress websites tegen gekomen met berichten waarbij in een meta veld een URL naar een externe website werd opgeslagen. In veel gevallen was deze URL echter niet voorzien van het http:// protocol prefix. Dit resulteerde aan de voorkant van de website in onjuiste URL’s.

Als binnen een WordPress bericht in een meta veld ‘website’ alleen ‘www.domeinnaam.tld’ stond resulteerde dit in de volgende link: http://website.tld/2012/08/wordpress-bericht/www.domeinnaam.tld/, terwijl dit eigenlijk: http://www.domeinnaam.tld/ had moeten zijn. Dit probleem is echter eenvoudig op te lossen met een database query.

Met behulp van de volgende query zijn URL’s zonder de http:// protocol prefix op te vragen:

SELECT
	*
FROM
	wp_postmeta 
WHERE
	meta_key = 'website'
		AND
	meta_value != ''
		AND
	meta_value NOT LIKE 'http%'

Als de ouput van deze query correct is dan kan met behulp van de volgende query de URL’s uitgebreid worden met het http:// protocol.

UPDATE 
	wp_postmeta 
SET 
	meta_value = CONCAT('http://', meta_value)
WHERE
	meta_key = 'website'
		AND
	meta_value != ''
		AND
	meta_value NOT LIKE 'http%'
;

WordPress gebruikers niet in auteur dropdown

Bij veel geavanceerdere WordPress websites zijn de standaard WordPress gebruikersrollen en bijbehorende mogelijkheden (capabilities) niet meer voldoende. Gelukkig zijn deze gebruikersrollen eenvoudig met allerlei plugins te beheren en uit te breiden. Zo kan men bijvoorbeeld met behulp van de Members plugin dit alles via eenvoudige gebruikersinterface beheren.

Toch blijken er ook nog wel een aantal nadelen te kleven aan het inzetten van maatwerk gebruikersrollen. Zo loop ik regelmatig tegen het probleem aan dat gebruikers met maatwerk gebruikersrollen niet zichtbaar zijn de auteur dropdown. Hierdoor hebben eindbgeruikers niet de mogelijkheid om een gebruiker met maatwerk rol als auteur toe te wijzen aan een WordPress bericht.

Dit probleem wordt veroorzaakt doordat binnen de auteur meta box gebruik gemaakt wordt van de wp_dropdown_users() functie. De wp_dropdown_user() functie maakt op zijn beurt weer gebruik van get_users() en dus WP_User_Query. Met behulp van deze query klasse kunnen gebruikers opgevraagd. Met de ‘who’ parameter kan er geselecteerd worden op alle gebruikers of enkel auteurs.

Binnen de auteur meta box worden alleen de auteurs weergegeven. De implementatie van WP_User_Query vraagt de auteurs echter op aan de hand van het gebruikersniveau (level). WordPress gebruikersniveaus is een techniek die werd gebruik in WordPress versies voor 2.0. Tegenwoordig wordt bij het aanmaken van maatwerk gebruikersrollen deze gebruikersniveaus niet meer meegenomen.

In veel gevallen is het echterwel  verstandig om ook de gebruikersniveaus te koppelen aan maatwerk gebruikersrollen. Dit kan eenvoudig gerealiseerd worden door met behulp van de Members plugin respectievelijk de volgende mogelijkheden (capabilities) toe te voegen:

  • level_0
  • level_1
  • level_2
  • level_3
  • level_4
  • level_5
  • level_6
  • level_7
  • level_8
  • level_9
  • level_10

Dit zorgt ervoor dat zodra er gebruikers met een maatwerk gebruikersrol worden aangemaakt het gebruikersniveau niet op 0 blijft staan. Doordat deze niet op 0 blijft staan zullen deze gebruikers automatisch ook in de auteur dropdown weergegeven worden. Indien je al veel gebruikers met gebruikersniveau 0 in je systeem hebt staan dan kun je deze eenvoudig bijwerken met behulp van de volgende query:

UPDATE 
	wp_usermeta
SET 
	meta_value = 4
WHERE
	meta_key = 'wp_user_level'
		AND
	meta_value = 0
		AND
	user_id IN (
		SELECT 
			user_id 
		FROM (
			SELECT
				DISTINCT user_id 
			FROM 
				wp_usermeta
			WHERE 
				meta_key = 'wp_capabilities'
					AND
				meta_value LIKE '%company_author%'
		) AS temporary_table
	);

Met behulp van bovenstaande query upgrade ik gebruikers met de gebruikersrol ‘company_author’ en gebruikersniveau 0 naar gebruikersniveau 4.

WordPress Broken Link Checker en comment_author_url

Op een grote WordPress website waarbij we veel reacties geautomatiseerd hebben geïmporteerd gaf de Broken Link Checker plugin bij veel reacties aan dat er verbroken links aanwezig waren. Al snel bleek dat deze reacties zonder URL schema (http://, ftp://, etc.) in het systeem stonden. Hierdoor kon de Broken Link Checker plugin de URL’s niet correct transformeren naar volledige URL’s.

Een ‘comment_author_url’ die als ‘www.website.nl’ in de database stonden transformeerde de Broken Link Checker plugin naar ‘http://wordpress-website.nl/2012/06/nieuwsbericht/comment-page-1/www.website.nl’. In vrijwel alle gevallen resulteert dit in een link die resulteert in een 404. Gelukkig hebben we dit probleem eenvoudig kunnen verhelpen door de ‘comment_author_url’ in de database te corrigeren.

Met behulp van de volgende database query kunnen eenvoudig de URL’s die zonder ‘http://’ beginnen opgevraagd worden:

SELECT
	*
FROM
	wp_comments
WHERE
	comment_author_url != ''
		AND
	comment_author_url NOT LIKE 'http://%'

Vervolgens kunnen deze onvolledige URL’s eenvoudig aangevuld worden met ‘http://’ met behulp van de volgende query:

UPDATE
	wp_comments
SET 
	comment_author_url = CONCAT('http://', comment_author_url)
WHERE
	comment_author_url != ''
		AND
	comment_author_url NOT LIKE 'http://%'

Mocht je ook hulp nodig hebben met het omzetten van een maatwerk website naar een krachtige WordPress website dan kun je altijd eens contact opnemen met Pronamic. We hebben veel ervaring met het geautomatiseerd importeren van berichten, pagina en reacties naar een WordPress website.

WordPress berichten importeren MySQL join over 2 databases

Bij Pronamic zijn we afgelopen maanden druk bezig geweest met het omzetten van een grote maatwerk website naar WordPress. Hierbij hadden we ook de opdracht om alle bestaande berichten, foto’s, video’s, evenementen, etc. te importeren naar WordPress.

Het importeren van deze content naar WordPress realiseren we door de oude database in te lezen met PHP en de berichten in WordPress te plaatsen. Aangezien het om duizenden berichten gaat doen we het importeren in fases. We houden daarom in de oude database per item bij wat geïmporteerd is en wat fout ging. Hiervoor hebben een tweetal BOOLEAN kolommen toegevoegd aan een aantal tabellen.

ALTER TABLE content ADD wordpress_imported BOOLEAN NOT NULL DEFAULT FALSE;
ALTER TABLE content ADD wordpress_failed BOOLEAN NOT NULL DEFAULT FALSE;

ALTER TABLE media ADD wordpress_imported BOOLEAN NOT NULL DEFAULT FALSE;
ALTER TABLE media ADD wordpress_failed BOOLEAN NOT NULL DEFAULT FALSE;

Omdat de oude website nog steeds live staat en er nog dagelijks nieuwe berichten worden geplaatst ontvangen we regelmatig een nieuwe database dump. In deze nieuwe datadump zijn echter niet bovenstaande kolommen met data opgenomen. Om te voorkomen dat we oude berichten voor een tweede keer importeren moeten we deze kolommen dus weer toevoegen aan de nieuwe data.

Gelukkig kun je met MySQL eenvoudig in een query meerdere databases raadplegen en dus op deze manier gegevens uit meerdere databases synchroniseren. Allereerst zorgen we er voor dat we bovenstaande queries uitvoeren en vervolgens synchroniseren we de data met behulp van de volgende query:

UPDATE
	database_2.media AS targetTable
		INNER JOIN
	database_1.media AS sourceTable
			ON sourceTable.id = targetTable.id
SET
	targetTable.wordpress_imported = sourceTable.wordpress_imported ,
	targetTable.wordpress_failed = sourceTable.wordpress_failed
;

UPDATE
	database_2.content AS targetTable
		INNER JOIN
	database_1.content AS sourceTable
			ON sourceTable.id= targetTable.id
SET
	targetTable.wordpress_imported = sourceTable.wordpress_imported ,
	targetTable.wordpress_failed = sourceTable.wordpress_failed
;

Stackoverflow: http://stackoverflow.com/questions/1675333/php-mysql-joins-across-databases

We hebben bij Pronamic inmiddels vrij veel ervaring met het omzetten van zeer grote maatwerk websites naar WordPress. Mocht je ook een grote maatwerk website willen omzetten naar WordPress dan kunnen we helpen met het overzetten van de bestaande content.

WordPress oude URL’s doorverwijzen naar nieuwe URL’s

In het bericht “WordPress oude URL’s vervangen met nieuwe URL’s” beschreef ik dat het slim is om bij het overzetten van berichten naar WordPress het handig is om de oude / originele URL ook bij het nieuwe WordPress bericht op te slaan in een extra veld. Aan de hand daarvan kun je na het overzetten eenvoudig interne links bijwerken. Daarnaast kun je ook eenvoudig een overzicht creëren van alle oude en nieuwe URL’s zodat je oude URL’s kunt doorverwijzen naar de nieuwe URL’s met een HTTP 301 redirect.

Voor het doorverwijzen van oude URL’s naar nieuwe URL’s binnen WordPress kan de Redirection plugin gebruikt worden. Als je met deze plugin werkt en bij elk WordPress bericht ook de oude URL hebt opgeslagen in een extra (meta) veld kun je met een eenvoudige database query de redirects toevoegen aan de Redirection plugin. Hieronder zie je een query waarmee dit gerealiseerd kan worden:

INSERT
	INTO wp_redirection_items (
		url ,
		group_id ,
		action_type ,
		action_code ,
		action_data ,
		match_type
	)
	SELECT
		REPLACE(meta.meta_value, 'http://www.domeinnaam.nl', '') AS url ,
		3 AS group_id ,
		'url' AS action_type ,
		'301' AS action_code ,
		post.guid AS action_data ,
		'url' AS match_type
	FROM
		wp_posts AS post
			RIGHT JOIN
		wp_postmeta AS meta
			ON
				post.ID = meta.post_id
					AND
				meta.meta_key = 'legacy_url'
			WHERE
				post.guid != '';

Let wel op dat je de meta key waarin de oude URL staat opgeslagen wijzigt naar je eigen naamgeving. Uiteraard zal ook de domeinnaam in bovenstaande query aangepast moeten worden naar je eigen domeinnaam. Ik plaats de items overigens in een specifieke daarvoor aangemaakt Redirection group, hiervoor geef ik ‘group_id’ de waarde ‘3’.

Mocht je overigens hulp nodig hebben met het overzetten van berichten, pagina’s of andere content naar WordPress dan kun je contact opnemen met Pronamic. We hebben erg veel ervaring met het overzetten van content naar WordPress. We hebben al veel grotere maatwerk websites succesvol omgezet naar WordPress.

Update 01-08-2013: