Categorie archief: SQL

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:

WordPress oude URL’s vervangen met nieuwe URL’s

Bij Pronamic ontwikkel ik WordPress websites en zetten we regelmatige bestaande websites om naar WordPress. Hierbij komt het vaak voor dat er bestaande berichten omgezet moeten worden naar WordPress. Met allerlei handige tools zoals bijvoorbeeld OutWit en de vele WordPress importeer plugins gaat dit vaak relatief eenvoudig.

Bij het importeren van berichten van een website naar een nieuwe WordPress website is het vaak erg handig om de bron URL op te slaan bij het nieuwe WordPress bericht. De extra velden functionaliteit bij WordPress berichten zijn hier zeer geschikt voor. Zodra de content is omgezet is het vaak noodzakelijk om interne koppeling bij te werken. Daarnaast is het vaak gewenst om oude URL’s netjes om te leiden (HTTP 303 redirect) naar de nieuwe URL’s.

Doordat de oude en nieuwe URL’s netjes zijn weggeschreven in de WordPress database kan dit met een aantal slimme MySQL queries gerealiseerd worden. De volgende query zal een lijst met queries genereren die de inhoud van alle WordPress berichten en pagina’s doorzoekt en oude URL’s vervangt met de nieuwe WordPress URL’s:

SELECT
	CONCAT(
		'UPDATE wp_posts SET post_content = REPLACE(post_content, ' ,
		QUOTE(meta.meta_value) , ', ' ,
		QUOTE(post.guid) , ');'
	)
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 != '';

De output van bovenstaande query zijn nieuwe queries welke uiteraard uitgevoerd moeten worden. Het komt soms voor dat de interne links relatief zijn aan de berichten zelf. Dit maakt het vervangen van de oude URL’s in veel gevallen veel complexer. Als de URL’s relatief zijn aan de domeinnaam dan is waarschijnlijk interessant om eerst de volgende query uit te voeren:

UPDATE wp_posts SET post_content = REPLACE(post_content, 'href="/', 'href="http://www.domeinnaam.nl/');

In andere gevallen zullen er slimme queries uitgevoerd moeten worden, zoals bijvoorbeeld:

UPDATE wp_posts SET post_content = REPLACE(post_content, 'href="../../../nieuws/', 'href="http://www.domeinnaam.nl/nieuws/');

Daarnaast kan met de volgende query een overzicht gemaakt worden van alle oude en nieuwe URL’s. Dit overzicht kan vervolgens geïmporteerd worden naar de Redirection plugin waarmee eenvoudig omleidingen zijn te beheren.

SELECT
	REPLACE(meta.meta_value, 'http://www.domeinnaam.nl', '') AS source ,
	post.guid AS target ,
	0 as hits
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 != '';