Veel website ontwikkelaars zullen wel eens een website in beheer hebben gehad die geïnfecteerd is geraakt met een virus. Na het opschonen van een website kan met online tools gecontroleerd worden of de website nog gemarkeerd wordt als onveilig of geïnfecteerd. Een aantal populaire online tools zijn:
Als WordPress ontwikkelaar volg ik ook graag de WordPress Coding Standards in de WordPress plugins en thema’s die ik ontwikkel. Ook bij Pronamic, het bedrijf waar ik voor werk, volgen we strikt deze standaarden. Sinds kort gebruik ik PHP CodeSniffer en de WordPress Coding Standards sniffs om projecten te controleren op de WordPress Coding Standards.
Op een Mac kan met behulp van Brew eenvoudig de PHP CodeSniffer package geïnstalleerd worden. Hiervoor kan de volgende commando in de Terminal uitgevoerd worden:
$ brew install php-code-sniffer
Als de installatie is voltooid kan met de volgende commando gecontroleerd worden welke versie van PHP CodeSniffer is geïnstalleerd.
$ phpcs --version
PHP_CodeSniffer version 1.5.2 (stable) by Squiz (http://www.squiz.net)
Vervolgens kan met het volgende commando gecontroleerd worden welke PHP CodeSniffer standaarden zijn geïnstalleerd.
$ phpcs -i
The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz and Zend
Standaard worden de WordPress Coding Standards sniffs niet meegeleverd in de PHP CodeSniffer package. De WordPress Coding Standards zijn echter eenvoudig te installeren via de volgende commando:
Als goed is staat hierna “WordPress” tussen de lijst met de geïnstalleerde PHP CodeSniffer standaarden.
$ phpcs -i
The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz, WordPress and Zend
Standaard zal er gebruik gemaakt worden van de WordPress Coding Standards in de ‘master’ branche. De ‘develop’ branche is echter veel interessanter, daarom is het interessant om over te schakelen naar de de ‘develop’ branche. Hiervoor kunnen de volgende commando’s uitgevoerd worden:
$ cd /usr/local/Cellar/php-code-sniffer/1.5.2/CodeSniffer/Standards/WordPress
$ git checkout develop
Hierna kan een WordPress thema of plugin met de volgende commando gecontroleerd worden op de WordPress Coding Standards:
$ phpcs -p -s -v --standard=WordPress .
Zelf maak ik veel gebruik van Grunt om ontwikkel taken verder te automatiseren. Er is een Grunt PHP CodeSniffer taak beschikbaar die hierbij van pas komt. Deze taak kan met de volgende commando geïnstalleerd worden.
$ npm install grunt-phpcs --save-dev
Binnen de Pronamic iDEAL plugin is te zien hoe we ‘phpcs’ Grunt taak verder hebben geconfigureerd. We gebruiken daar ook een “phpcs.ruleset.xml” bestand om een aantal mappen/bestanden en sniffs uit te schakelen.
Vandaag heb ik een probleem onderzocht waarbij de betalingsstatus updates van de OmniKassa niet binnen kwamen op de WordPress omgeving. Hierdoor werd de status van de betaling niet bijgewerkt en in het geval van WooCommerce de status van de bestelling ook niet. Al snel bleek dat dit probleem beperkt was tot de specifieke WordPress installatie van een Pronamic iDEAL gebruiker. Na wat debug werk bleek een SSL-forceer script van Yoast voor een conflict te zorgen.
Binnen de Pronamic iDEAL plugin wordt ingehaakt op de WordPress ‘template_redirect’ actie om te luisteren naar OmniKassa betalingsstatus requests:
De luisterfunctie van de Pronamic iDEAL plugin haakt in op de ‘template_redirect’ actie met de standaard prioriteit van 10. Yoast zijn SSL-forceer functie wordt in zijn voorbeeld toegevoegd met prioriteit van 1. Hierdoor zal Yoast zijn functie altijd voor de Pronamic iDEAL plugin uitgevoerd worden. Doordat Yoast in zijn functie een HTTP-redirect header verstuurd en vervolgens het script stopt met een exit(); aanroep zal de Pronamic iDEAL luisterfunctie nooit uitgevoerd worden.
Door Yoast zijn doorverwijzing naar een https:// URL zal de OmniKassa POST-data niet meegestuurd worden. Hierdoor zal de betalingsstatus update van de OmniKassa dus nooit de Pronamic iDEAL plugin bereiken.
Om dit conflict op te lossen hebben we de Pronamic iDEAL pluign aangepast zodat deze niet langer de ‘template_redirect’ actie gebruikt om te luisteren naar betalingsstatus updates. In plaats daarvan gebruiken we nu de ‘wp_loaded’ actie.
De ‘wp_loaded’ actie wordt eerder uitgevoerd dan de ‘template_redirect’ actie, hierdoor krijgt de Pronamic iDEAL plugin voorrang op de SSL-forceer functie van Yoast. Ook is de ‘wp_loaded’ functie waarschijnlijk geschikter voor het luisteren naar betalingsstatus updates. De ‘template_redirect’ functie is waarschijnlijk ook meer bedoeld voor thema/templates gerelateerde doorverwijzingen. In de volgende commit is de aanpassing terug te zien:
Om gebruik van te maken van de Vimeo JavaScript API moet echter de embed code aangepast worden. Ze moet de video van de URL in de iframe uitgebreid worden met een ‘api’ parameter.
http://player.vimeo.com/video/VIDEO_ID?api=1
Als je meerdere URL’s op 1 pagina hebt ingevoerd moet daar ook nog een ‘player_id’ parameter aan toegevoegd worden:
Helaas ondersteund WordPress en Vimeo oEmbed deze parameters nog niet. Dit is echter eenvoudig te corrigeren met behulp van de volgende fiter functies. Met behulp van de eerste filter voegen we de ‘api’ en ‘player_id’ parameter toe aan de video URL:
In de tweede filter functie zorgen we dat het ‘iframe’ element dezelfde ‘id’ attribuut krijgt als de ‘player_id’:
Vervolgens kunnen we de volgende shortcode gebruiken om gebruik te maken van WordPress oEmbed en de Vimeo API en player ID:
Een paar weken geleden kwam ik het blog bericht “Mistakes I’ve Made (And Lessons Learned Along The Way)” van Jeremy Girard op Smashing Magazine tegen. In zijn blog schrijft hij over fouten die hij gemaakt heeft en wat hij daar van geleerd heeft. Ik denk dat veel van deze fouten worden gemaakt door bedrijven. Voor mij als ontwikkelaar bij Pronamic daarom ook zeker een leerzaam bericht.
Fout #1: Voortgang belangrijker vinden dan projecten (en personen)
Jeremy verteld in zijn blog over een project waarbij hij minder goed kon opschieten met de opdrachtgever. Om het project wel in goede banen te leiden hield hij zich vast aan een proces. Dit kwam de samenwerking met de opdrachtgever echter niet ten goede.
Fout #2: Vertellen in plaats van laten zien
Veel bedrijven vertellen hoe fantastisch hun product en/of dienst is. Dit terwijl iedereen het spreekwoord “Praatjes vullen geen gaatjes” kent. Door klanten niet te laten zien hoe het product kunnen er verkeerde verwachtingen ontstaan. Dit is eenvoudig te voorkomen door het product of dienst te laten zien.
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:
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.
