Debuggen in PHP wordt vaak gedaan met behulp van de var_dump() en print_r() functies. In veel gevallen werkt dit prima, maar het heeft als nadeel dat de debug output vaak tussen de overige output staat. Gelukkig zijn er handige tools waarmee dit probleem verholpen kan worden. Zo kun je met behulp van FirePHP of ChromePHP debug informatie weergeven in een balk van je webbrowser.
Sinds collega Leon Rowland bij Pronamic aan het werk is worden we dagelijks getrakteerd op handige tools. Zo werden we recent gewezen op de DocHub website (http://dochub.io/). DocHub is een handige website gemaakt door Rafael Garcia om direct documentatie te vinden over CSS, HTML, JavaScript, DOM, jQuery, PHP en Python. Helaas staat WordPress hier nog niet tussen, maar wellicht wordt deze nog toegevoegd.
Een overzicht van de winnaars van voorgaande jaren:
| Jaar | 1e | 2e | 3e | 4e |
|---|---|---|---|---|
| 2005 | Remco Tolsma | Jelke Boonstra | ? | |
| 2006 | Yteke Veenstra | Jelke Boonstra | Karel-Jan Tolsma | |
| 2007 | Peter Vonk | Karel-Jan Tolsma | ? | |
| 2008 | Leo Oosterloo | Wietze Tolsma | Peter Vonk | |
| 2009 | Hilda Broersma | Jelke Boonstra | Martijn Cordes | |
| 2010 | Wietze Tolsma | Christa Tolsma | Martijn Cordes | |
| 2011 | Peter Vonk | Leo Oosterloo | Martijn Cordes | Karel-Jan Tolsma |
| 2012 | Peter Vonk | Karel-Jan Tolsma | Remco Tolsma | Christa Tolsma |
Binnen WordPress kunnen menu’s eenvoudig aangemaakt en beheert worden. Bij grotere menu’s kunnen er echter problemen ontstaan. Menu’s worden soms niet meer goed opgeslagen of het aantal menu items is beperkt. Binnen het WordPress forum zijn hier verschillende topics over te vinden:
Dit probleem wordt veroorzaakt door de Suhosin module van PHP. Deze module beschermt servers tegen onveilig gebruik van PHP. Dit doet Suhosin onder andere door verschillende beperkingen te activeren.
Eén van de beperking is het aantal ‘post’ en ‘request’ variabelen. WordPress werkt met deze variabelen om menu’s op te slaan. Een minder handige constructie omdat je tegen limieten van bijvoorbeeld Suhosin kunt aanlopen.
Gelukkig kunnen de limieten in veel gevallen verhoogd worden. Vaak moet dit uitgevoerd worden door de hosting partij. Als je echter zelf een server beheert dan kun je dit ook eenvoudig zelf doen. Ik wil graag dat deze limieten per directory in een .htacces bestand geconfigureerd kunnen worden.
Hiervoor heb ik de volgende wijziging doorgevoerd in het “suhosin.ini” configuratie bestand:
nano /etc/php5/apache2/conf.d/suhosin.ini
Vervolgens heb ik de volgende regel gewijzigd van:
suhosin.perdir = "0"
naar:
suhosin.perdir = "pr"
De ‘p’ en ‘r’ karakters geven aan dat ‘post’ en de ‘request’ configuratie instellingen per map zijn in te stellen. Dit onderdeel van Suhosin is niet goed gedocumenteerd, maar in de broncode van de Suhosin bibliotheek is de werking hiervan eenvoudig te raadplegen.
Vervolgens kunnen we het volgende opnemen in het .htaccess bestand om groter menu’s te kunnen beheren binnen WordPress:
# BEGIN PHP <IfModule mod_php5.c> php_value suhosin.post.max_vars 2048 php_value suhosin.request.max_vars 2048 </IfModule> # END PHP
Meer informatie:
Helaas is Google Apps niet meer gratis te gebruiken, er moet nu € 4,- per gebruiker per maand betaald worden. Bestaande Google Apps accounts blijven voorlopig gratis, maar het zal me niks verbazen als hier straks ook voor betaald moet gaan worden.
Toen Google Apps gelanceerd werd konden er 200 gratis gebruikers aangemaakt worden, dit werd echter al snel gewijzigd naar 100 gebruikers. In januari 2009 werd dit beperkt naar 50 gebruiker en 2011 werd het zelfs beperkt tot slechts 10 gebruikers. Op 6 december 2012 trekt Google de stekker uit de gratis Google Apps variant.
Google Apps zal nog steeds voor veel bedrijven een goedkopere oplossing zijn dan een eigen e-mail server. Voor kleinere bedrijven kan Google Apps echter toch vrij duur zijn, voornamelijk omdat er genoeg gratis alternatieven zijn.
Gebruikers van WooCommerce weten dat de knop waarmee bezoekers een product kunnen toevoegen in het Engels standaard de tekst ‘Add to cart‘ bevat. Als we dit vertalen naar het Nederlands wordt dit ‘Toevoegen aan winkelwagen‘. Sommige mensen zijn geneigd om dit vertalen naar een kortere variant, bijvoorbeeld ‘Toevoegen’. Ik vind echter dat je geen informatie moet weglaten binnen een vertaling. Daarom hanteren we in de ‘WooCommerce (nl)‘ plugin de volledige vertaling.
Doordat de Nederlandse volledig vertaling echter vrij lang is in vergelijking met de Engelse tekst komt dit echter niet altijd mooi uit binnen WordPress/WooCommerce thema’s.
Daarom ging ik op zoek naar een methode waarmee we de tekst eenvoudig kunnen aanpassen. Gelukkig past WooCommerce een filter (‘add_to_cart_text’) toe op de betreffende tekst waarmee we de tekst eenvoudig kunnen aanpassen. Met onderstaand voorbeeld is daardoor de tekst te wijzigen naar een korte variant, bijvoorbeeld: ‘Add’.
function prefix_add_to_cart_text( $text ) {
$text = __( 'Add', 'text_domain' );
return $text;
}
add_filter( 'add_to_cart_text', 'prefix_add_to_cart_text' );
Bovenstaande code kan toegevoegd worden aan het WordPress functies thema bestand (functions.php). Vaak kan de code zonder problemen aan het eind van dit bestand toegevoegd worden. Als je niet werkt met een maatwerk thema dan kan het overigens handig zijn om deze toevoeging binnen een child thema of plugin te definiëren. Op die manier kun je zonder problemen je thema blijven bijwerken.
Mocht je zelf ook tegen vergelijkbare problemen aanlopen en op zoek zijn naar een oplossing dan kun je altijd even contact met me opnemen.
Onlangs had ik op een test- en ontwikkel server wat problemen met een /var map die vol aan het lopen was. Bij de installatie en configuratie van de server had ik waarschijnlijk de /var map partitie iets te klein ingesteld. Minder handig, maar via de volgende commando’s was er gelukkig vrij snel weer wat ruimte vrij te maken.
df -h
Via de ‘df -h’ commando zijn eenvoudig de verschillende partities en de beschikbare ruimte te raadplagen. Hieruit kon ik opmaken dat het het bestandssysteem gekoppeld aan /var aan het vollopen was.
Bron: http://www.cyberciti.biz/faq/howto-find-out-or-learn-harddisk-size-in-linux-or-unix/
Vervolgens was ik wel benieuwd wat zoveel ruimte in nam binnen de /var map. Via de ‘du‘ commando zijn samenvattingen over het gebruik op te vragen. Via de volgende commando kon ik de 20 grootste bestanden opvragen:
du -a /var | sort -n -r | head -n 20
Bron: http://www.unixmen.com/how-to-find-large-files-and-directories-in-linux/
Update 15 mei 2013: Met volgende commando krijg je alleen bestanden te zien en niet mappen.
find . -type f -exec du -a {} + | sort -n -r | less
Bron: http://unix.stackexchange.com/a/22448
Hieruit bleek dat met name de log bestanden vrij veel ruimte in namen. Het wordt niet geadviseerd om de log bestanden verwijderen. Het is beter om deze periodiek op te schonen en te archiveren. Hiervoor kan ‘logrotate‘ gebruikt worden, deze is handmatig aan te roepen via het volgende commando:
logrotate -vf /etc/logrotate.conf
Bron: http://www.randomsequence.com/articles/running-logrotate.d-manually/
Om een WordPress netwerk site domeinnaam te wijzigen kunnen de volgende stappen genomen worden:
UPDATE wp_2_options SET option_value = REPLACE(option_value, 'huidige-domeinnaam.nl', 'nieuwe-domeinnaam.nl') WHERE option_value NOT LIKE '%:{%';
UPDATE wp_2_posts SET post_content = REPLACE(post_content, 'huidige-domeinnaam.nl', 'nieuwe-domeinnaam.nl');
UPDATE wp_2_posts SET guid = REPLACE(guid, 'huidige-domeinnaam.nl', 'nieuwe-domeinnaam.nl');
UPDATE wp_2_postmeta SET meta_value = REPLACE(meta_value, 'huidige-domeinnaam.nl', 'nieuwe-domeinnaam.nl') WHERE meta_value NOT LIKE '%:{%';
UPDATE wp_2_links SET link_image = REPLACE(link_image, 'huidige-domeinnaam.nl', 'nieuwe-domeinnaam.nl');
Wijzig ‘wp_2′ naar de prefix van de network site, ‘huidge-domeinnaam.nl’ naar de huidige domeinnaam en ‘nieuwe-domeinnaam.nl’ naar de nieuwe domeinnaam.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?huidige-domeinnaam\.nl
RewriteRule (.*)$ http://nieuwe-domeinnaam.nl/$1 [R=301,L]
</IfModule>
Wijzig ‘huidge-domeinnaam.nl’ naar de huidige domeinnaam en ‘nieuwe-domeinnaam.nl’ naar de nieuwe domeinnaam.
Voor meer informatie over adreswijziging van WordPress network websites, zie ook:
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%'
;
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:
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.