Als WordPress ontwikkelaar kom ik regelmatig thema’s tegen waarin in functie bestanden zoals functions.php een afsluiten ?> PHP tag wordt gebruikt. Deze afsluitende PHP-tag kan problemen geven als daar nog een spatie of lege regel achter staat. Als je de broncode van een website bekijkt zie je dan vaak bovenaan voor de DOCTYPE declaratie een spatie of een lege regel.
?>
Hierdoor kunnen probleem ontstaan met bijvoorbeeld de XML-RPC-server of XML-sitemaps binnen WordPress. Binnen Eclipse kan gelukkig eenvoudig gezocht worden met behulp van reguliere expressies. Met behulp van de volgende zoekopdracht kan ik dergelijke problemen eenvoudig opspeuren binnen een Eclipse-project:
\?>\s\z
De \s zal overeenkomen met white space en de \z met het einde van het bestand.
We adviseren zelf altijd om PHP niet af te sluiten met een ?> PHP-tag, dit levert vaak meer problemen op dan dat je er profijt van hebt.
Op mijn werk bij Pronamic maken we al enige tijd gebruik van Git voor het bijhouden van ontwikkelingen in een versiebeheersysteem. We werkten hierbij voornamelijk met één tak, de ‘master’ branch. Sinds ons team echter is versterk met een extra ontwikkelaar bleek dit echter niet altijd meer even handig te werken. Collega Leon stelde daarom voor om te gaan werken volgens het branching model van Vincent Driessen.
Vicent heeft een eenvoudige en logische manier van vertakken binnen Git in kaart gebracht. Hieronder is een mooi overzicht te zien van hoe het vertakken in de praktijk gebruikt kan worden:
WPEngine is naar mijn idee één van de weinige partijen die echt goed weten wat er komt kijken bij het hosten van WordPress websites. Ze bieden een krachtige hosting oplossing aan die schaalbaar is voor de grotere WordPress websites. Ook bieden ze veel informatie over welke WordPress plugins je beter niet kunt gebruiken en hoe je je WordPress website kunt optimaliseren.
Mark Kelnar (@renderandserve) geeft in een presentatie tijdens WordCamp Atlanta 2012 een aantal WordPress optimalisatie tips. De presentatie is terug te vinden op de volgende pagina en zeker de moeite waard om eens door te lezen:
In WooCommerce versie 2.0.5 kunnen de vertalingen voor de WordPress beheerdersomgeving ingeladen vanuit een eigen bestand. Op die manier hoeven niet alle WooCommerce vertalingen altijd geladen te worden. In de WooCommerce ‘load_plugin_textdomain’ function is duidelijk te zien hoe dit is opgezet.
Om de vertalingen zo efficiënt mogelijk op te zetten moeten er 2 .PO of .POT bestanden aangemaakt worden. Normaliter scande ik altijd met behulp van Poedit naar alle vertaalbare teksten binnen een plugin. Echter kan ik met Poedit niet onderscheid maken tussen vertalingen binnen de admin omgeving.
Er zijn meerdere gebruikers van Poedit die wel graag van een dergelijke functionaliteit gebruik willen maken. De ontwikkelaar van Poedit geeft echter in een ticket het volgende aan:
The scanning feature of Poedit is intended for basic, simple uses. If you have more demanding needs, they you should write a proper makefile and call xgettext in it to create a POT file from your sources; then use Poedit just to translate PO catalogs and update them from that POT file.
At this time, I don’t want additional complications in this part of Poedit. Maybe later, when all the other, more serious, problems are fixed.
Ik ben me daarom gaan verdiepen in de werking van xgettext:
Bovenstaande commando’s bestaan uit 2 delen, een ‘find’ commando waarmee alle PHP-bestanden binnen de plugin worden gevonden. En een ‘xgettext’ commando die alle vertalingen binnen deze bestanden op zoekt. Hier worden de WordPress vertaalfuncties als ‘keyword’ meegegeven.
Mocht je overigens bij het uitvoeren van het tweede commando een “Segmentation” fout krijgen dan moet je misschien je gettext pakket updaten. Ik kreeg op mijn Mac deze fout met gettext versie 0.18.1. Na het updaten van gettext via MacPorts naar versie 0.18.2 was dit probleem opgelost:
sudo port selfupdate
sudo port upgrade outdated
Vervolgens hebben we de gegenereerde .POT-bestanden toegevoegd aan onze GlotPress installatie.
Waar in WooCommerce 1.6.6 nog 2058 teksten in één bestand stonden en altijd geladen werden is dit met deze wijziging bijna gehalveerd. Deze verbetering hebben we ook verwerkt in de “WooCommerce (nl)” plugin. Met behulp van een Makefile kunnen we eenvoudig de 2 .POT-bestanden aanmaken:
Gebruikers van de “W3 Total Cache” plugin weten dat je per “User Agent Groups”, ook wel browser groepen, verschillende pagina caches kunt hanteren. Dit is erg handig voor als je WordPress website voor mobiele apparaten anders is opgebouwd dan voor desktop browsers. Met de wp_is_mobile() functie kun je dan eenvoudig je WordPress thema aanpassen voor mobiele appareten.
We liepen echter tegen problemen dat de wp_is_mobile() functie check niet overeenkwam met de standaard W3 Total Cache “User Agent Groups”. Hierdoor werd soms op desktop browsers toch de mobiele versie van de website weergegeven. Daarom zijn we opzoek gegaan naar een manier om de W3 Total Cache check te gebruiken.
Na het doorzoeken van de W3 Total Cache code kwamen uit op de volgende classes en functies:
In het bericht “WooCommerce ‘Toevoegen aan winkelwagen’ tekst wijzigen” schreef ik al hoe je een specifieke WooCommerce tekst kon wijzigen. Helaas zijn met behulp van deze oplossing niet alle WooCommerce teksten te wijzigen. Toch komt het wel eens voor dat ook andere teksten gewijzigd moet worden. Binnen bepaalde webwinkels is “Bestellen” bijvoorbeeld een betere vertaling voor “Checkout” in plaats van “Afrekenen”.
Met behulp van de volgende code kunnen alle WooCommerce teksten eenvoudig aangepast worden.
/**
* Translate WooCommerce text
*
* @link http://codex.wordpress.org/Plugin_API/Filter_Reference/gettext
*/
function prefix_translate_woocommerce( $translated_text, $text, $domain ) {
if ( $domain == 'woocommerce' ) {
switch ( $text ) {
case 'Checkout →' :
$translated_text = 'Bestellen';
break;
case 'Add to Cart' :
case 'Add to cart' :
$translated_text = 'Bestellen';
break;
}
}
return $translated_text;
}
add_filter( 'gettext', 'prefix_translate_woocommerce', 20, 3 );
Binnen Twinfield kunnen facturen gemaakt worden op basis van Word sjabloon. Deze sjablonen kunnen eenvoudig met behulp van Word gewijzigd worden. In de volgende YouTube video is te zien hoe dit gerealiseerd kan worden:
We maken bij Pronamic echter geen gebruik van Word, maar van OpenOffice en/of LibreOffice. Als we de sjablonen met deze programma’s wijzigden dan ontstonden er helaas problemen. Hierdoor konden we bij Pronamic de Twinfield factuur sjablonen helaas niet wijzigen.
In de Twinfield Knowledge Base staan verschillende voorbeelden van hoe een factuur sjabloon er uit moet zien:
Hoe maak ik een Word-factuur, een aanmaning of een betaalspecificatie?
How do I create a Word-invoice, a dunning or a payment specification?
Helaas gaan deze Word samenvoeg velden verloren bij het opslaan van .doc bestanden in LibreOffice. Na veel uitzoekwerk bleek dit te komen doordat de samenvoeg velden niet gekoppeld zijn aan een database.
Binnen LibreOffice kan er net als in Microsoft Word gewerkt worden met samenvoeg velden. In het LibreOffice worden deze samenvoeg velden ook wel “Mail merge fields” genoemd.
Deze “Mail merge fields” kunnen echter niet vrij ingevoerd worden. In plaats daarvan moeten er kolommen uit een database tabel geselecteerd worden. Door een CSV bestand aan te maken met alle beschikbare Twinfield samenvoeg velden is dit echter eenvoudig te realiseren.
Dit bestand kan opslagen worden in Twinfield.csv en vervolgens gebruikt worden bij het invoegen van een “Mail merge field”. Vervolgens kun je je sjabloon helemaal naar wens inrichten en opslaan in het ODF Text Document (.odt) formaat.
Zodra het sjabloon geüpload moet worden naar Twinfield is een bestandsnaam met de extensie .doc, .dot, .docx of .dotx nodig. Bij het uploaden van andere bestanden zal Twinfield de volgende foutmelding weergeven:
Selecteer een DOC-, DOT-, DOCX- of DOTX-bestand.
Als we ons ODF Text Document echter opslaan volgens het “” of “” formaat geeft Twinfield de volgende foutmelding:
De Word-sjabloon bevat geen samenvoegvelden.
Daarom slaan we ons bestand niet op volgens dit formaat maar wijzigen we ons “bestandsnaam.odt” simpelweg naar “bestandsnaam.odt.dot”. Vreemd genoeg kan Twinfield het ODF Text Document met een geldige extensie gewoon correct verwerken.
Helaas werken niet alle aspecten van een ODF Text Document even goed in Word en dus Twinfield. Zo wordt de opmaak van afbeeldingen en frames niet altijd goed over genomen. Dit probleem is echter vrij eenvoudig te omzeilen door puur met een tabellen opmaak te werken.
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:
Bij de WordPress update van 3.4.2 naar WordPress 3.5 liepen we bij een aantal websites tegen de volgende foutmelding aan:
HTTP-fout 500 (Internal Server Error): Er is een onverwachte voorwaarde gevonden toen de server het verzoek wilde uitvoeren.
Via de Apache fouten logboek zagen we de volgende foutmelding voorbij komen:
Website 1
[Fri Jan 18 09:14:18.400710 2013] [:error] [pid 17051] [client *.*.*.*:*] PHP Warning: Missing argument 1 for get_post(), called in /public_html/wp-includes/link-template.php on line 1125 and defined in /public_html/wp-includes/post.php on line 380
[Fri Jan 18 09:17:25.937590 2013] [:error] [pid 17268] [client *.*.*.*:*] PHP Warning: Division by zero in /public_html/wp-includes/functions.php on line 3237
[Fri Jan 18 09:17:26.019925 2013] [:error] [pid 17144] [client *.*.*.*:*] PHP Fatal error: Call to undefined function get_current_blog_id() in /public_html/wp-includes/user.php on line 671, referer: http://domainname.tld/wp-admin/update-core.php?action=do-core-upgrade
Website 2
[Fri Jan 18 09:44:52.166372 2013] [:error] [pid 18936] [client *.*.*.*:*] PHP Warning: Division by zero in /public_html/wp-includes/functions.php on line 3237
[Fri Jan 18 09:44:52.190437 2013] [:error] [pid 18936] [client *.*.*.*:*] PHP Fatal error: Call to a member function register_handler() on a non-object in /public_html/wp-includes/media.php on line 944
Waardoor deze problemen werden veroorzaakt was een groot raadsel. Ook na een handmatige update van WordPress was het probleem niet opgelost. Uiteindelijk kwamen we tot de ontdekking dat er een caching techniek (XCache) actief was op de hosting omgeving.
Hierdoor werd na de WordPress 3.5 update op de hosting omgeving nog steeds gebruik gemaakt van PHP bestanden/functies uit WordPress 3.4.2. Uiteindelijk hebben we het probleem kunnen oplossen door tijdelijke XCache uit te schakelen.
Het uitschakelen van XCache kan met behulp van de volgende regels in het .htaccess bestand:
php_flag xcache.cacher Off
php_flag xcache.size 0
php_flag xcache.stat Off
Mocht je zelf ook een keer tegen onverklaarbare foutmeldingen aanlopen na een WordPress update dan is het wellicht goed om eens na te gaan welke caching technieken actief zijn.
.
