Omdat we bij Pronamic betaaloplossingen ontwikkelen voor payment providers zoals Mollie, Buckaroo, Pay.nl, etc. zijn we vaak partner van deze organisaties. In sommige gevallen krijgen we commissie voor succesvolle betalingen die via de Pronamic Pay plugin zijn opgestart. De payment providers betalen ons maandelijks of per kwartaal de opgebouwde commissie uit. Voor de boekhouding ontvangen we dan vaak een zogenaamde self-billing factuur. Waar voorheen nog wel eens creditnota’s werden verstuurd lijken de payment providers nu over te stappen naar self-billing facturen. Ik was tot vandaag niet heel bewust van dit concept. In dit bericht wat meer informatie over het self-billing principe.
Voor een makelaar hebben we een koppeling gemaakt met de Realworks Wonen API en Gravity Forms. Woningzoekers kunnen op de website van de makelaar een Gravity Forms formulier invullen met contactgegevens en woonwensen. Deze gegevens worden vervolgens automatisch doorgezet naar Realworks. Daarmee hoeft de makelaar de formulier inzendingen niet meer handmatig in Realworks te zetten.
Categorieën
WordPress bedrijven op GitHub
- https://github.com/pronamic/
- https://github.com/rtCamp/
- https://github.com/humanmade
- https://github.com/yoast
- https://github.com/inpsyde
- https://github.com/awesomemotive
- https://github.com/automattic/
- https://github.com/level-level
- https://github.com/10up
- https://github.com/CMB2
- https://github.com/deliciousbrains
- https://github.com/webdevstudios
Categorieën
Developer Roadmaps
Bij Pronamic hebben we als richtlijn dat we alles strict in het Engels programmeren. Stagiairs leren we daarom ook altijd om in het Engels te programmeren. Toch zijn er op internet ook vele voorbeelden te vinden waarin Nederlandse naamgeving wordt gebruikt in de code. Waarom heeft Engels dan bij ons de voorkeur? Ik ben voor de aardigheid eens op zoek gegaan naar goede argumenten. Al snel kwam ik een artikel tegen uit het boek “Het beste van PHP en MySQL“.
Engels of Nederlands
Amerikaans Engels is de voertaal onder programmeurs. Ook de meeste PHP-ontwikkelaars gebruiken Engels. Als je echter PHP-script alleen voor jezelf schrijft of als je in een team met alleen Hollanders en Vlamingen werkt, zijn er goede redenen om Nederlands te gebruiken.
Wanneer je Nederlands gebruikt voor alle namen die je zelf kunt kiezen, wordt broncode beter leesbaar. Het verschillen tussen Engelstalige termen uit PHP en zelfgekozen namen in dan direct zichtbaar. Dat is de reden waarom ik in dit boek vaker Nederlands gebruik dan Engels: het maakt de voorbeelden veel duidelijker als PHP nieuw voor je is.
De kans op naamconflicten neemt drastisch af als je Nederlands gebruikt. Als je Engels gebruikt voor bijvoorbeeld een functie die je zelf definieert, bestaat altijd het risico dat je per ongeluk een bestaande PHP-functie gebruikt. Naamconflicten kunnen ook voorkomen met andere talen die je in PHP gebruikt: HTML, CSS, SQL, HTPT, MIME, XML enzovoort gebruiken allemaal Engels.
Natuurlijk moet je niet overdreven vasthouden aan het Nederlands. Hoewel databank en gegevensbank foutloos Nederlands zijn, zeggen en schrijven ontwikkelaars altijd database. Het Nederlands kent al helemaal geen bruikbaar synoniem van query. In zulke gevallen kun je naamconflicten voorkomen door verschillende woorden of een samenstelling met Nederlands te gebruiken. Maak dan van
Ward van der Put$databaseen$querybijvoorbeeld$database_met_productenen$selectiequery.
In een boek zoals deze is het denk ik ook prima om Nederlandse code voorbeelden te gebruiken. Lezers kunnen op die manier waarschijnlijk sneller zaken herkennen. Het argument om Nederlands te gebruiken om naamconflicten te voorkomen vind ik wat minder sterk. Voor dat probleem zijn er in PHP denk ik namespaces geïntroduceerd.
Al met al nog niet hele sterke argumenten om wel of niet in het Engels of Nederlands te programmeren. Ik ben daarom verder gaan zoeken en kwam o.a. de volgende vragen / topics tegen:
- Software Engineering Stack Exchange: “Do people in non-English-speaking countries code in English?”
- Quora: “Is it better learning programming in English or in my native language (Portuguese)?”
- DEV Community: “Do you feel comfortable learning in your own language or do you prefer English? (For non English-native speakers)”
Velen geven aan dat Engels de voorkeur heeft, maar om programmeren te leren je moedertaal wel fijn kan zijn.
DomQ (een Fransman) noemde nog wel de volgende aandachtspunten:
• I speak the language that the target audience will most likely understand. When coding open-source software with a global ambition, I use English. For less widely useful stuff (for instance, my Emacs configuration file), I might use French.
• I acknowledge the fact that not everyone will master English. In that perspective, using my mother tongue might actually make my code more accessible instead of less (in the example above, nobody cares about an umpteenth .emacs, except if it happens to be written in a language that they understand).
• Better to write good French than bad English. I actively discourage my subordinates from writing half-assed English especially where concision matters, eg in docstrings and version control commit messages.
https://softwareengineering.stackexchange.com/a/1764
Mattias Kihlström (een Zweed) noemde volgende argumenten om Engels te gebruiken:
• Allmost all programming languages I have ever used have been written in English (mixing languages would make the code harder to read for me)
• Most popular frameworks and third party extension are written in English (again, mixing languages would only be a distraction)
• Swedish characters (åäö) are usually not allowed when naming variables and functions
• If the other team members are from different countries we can still collaborate
• If I need support from a platform vendor it is is much easier for them to help me if they can understand my code
• It is easier to outsource support
https://softwareengineering.stackexchange.com/a/1687
Ik sluit me persoonlijk aan bij de argumenten van Mattias, dat zijn denk ik ook de redenen waarom we bij Pronamic in het Engels programmeren.
Mocht je zelf ook nog goede redenen hebben om in het Engels of juist in het Nederlands te programmeren dan hoor ik ze graag. Laat daarom gerust een reactie achter.
GoAccess is een leuk tooltje voor het analyseren van log bestanden. Voor het analyseren van SiteGround Access Logs kan het volgende commando gebruikt worden.
export LANG=en_US.UTF-8
goaccess -f access.log --log-format='%h %v %^ [%d:%t %^] "%r" %s %b "%R" "%u"' --date-format='%d/%b/%Y' --time-format='%H:%M:%S'
Categorieën
Gitlabber
Als webontwikkelaar maak ik veel gebruik van Git en diensten zoals GitHub, GitLab en Bitbucket. Ook bij Pronamic maken we hier intensief gebruik van. Alle WordPress plugins en thema’s die we ontwikkelen staan keurig in een eigen Git repository. We hebben inmiddels dan ook een archief met duizenden repositories. Het komt soms voor dat we alle repositories moeten doorzoeken. Het kan dan een hele klus om alle repositories te clonen. Gelukkig zijn er tools zoals https://github.com/gabrie30/ghorg en https://github.com/ezbz/gitlabber die daarbij kunnen helpen (via https://stackoverflow.com/questions/29099456/how-to-clone-all-projects-of-a-group-at-once-in-gitlab). Ik ben vandaag eens aan de slag gegaan met gitlabber.
Bij Pronamic ontwikkel ik veel complexe WordPress oplossingen. Voor het snel monitoren van bijvoorbeeld database queries maak ik gebruik van de Query Monitor plugin. Vandaag kwam ik er achter dat de Query Monitor plugin ook een logging en profiling functionaliteit heeft. Hiermee is het mogelijk om in je eigen code zaken te loggen en de benodigde tijd te meten. Deze functionaliteit werd in 2018 (17 juli) al aangekondigd door John Blackbourn in het blog bericht “Profiling and Logging in Query Monitor“.
Profiling
// Start the 'foo' timer:
do_action( 'qm/start', 'foo' );
// Run some code
my_potentially_slow_function();
// Stop the 'foo' timer:
do_action( 'qm/stop', 'foo' );https://github.com/johnbillion/query-monitor#profiling
Logging
do_action( 'qm/debug', 'This happened!' );https://github.com/johnbillion/query-monitor#logging
😍
Veel WordPress website beheerders zullen wel eens meegemaakt hebben dat ze geen e-mailnotificatie kregen nadat een bezoeker een formulier had ingestuurd. Dit komt vaak doordat WordPress en het versturen van e-mails foutgevoelig is. Er kan namelijk op allerlei plekken iets fout gaan waardoor je als beheerder geen e-mailnotificatie binnen krijgt. In dit bericht zal ik een aantal scenario’s benoemen.
Formulieren plugin
Veel WordPress websites maken gebruik van een formulieren plugin. WordPress is namelijk standaard niet uitgerust met een formulieren functionaliteit. We maken bij Pronamic voornamelijk gebruik van de formulieren plugin Gravity Forms (affiliate link). Binnen Gravity Forms kunnen beheerders per formulier e-mailnotificaties instellen. Als een e-mailnotificatie niet binnen komt dan kan het zijn dat de e-mailnotificatie niet goed is ingesteld. Er is bijvoorbeeld een onjuist e-mailadres ingesteld of de e-mailnotificatie wordt alleen verstuurd bij bepaalde condities. Bij problemen is het daarom goed om altijd te controleren of e-mailnotificatie instellingen juist zijn. En of er misschien nog plugin updates beschikbaar zijn.
Standaard WordPress e-mail functie
WordPress is standaard uitgerust met een e-mail functie genaamd wp_mail(). Ontwikkelaars kunnen deze functie gebruiken voor het versturen van e-mails. Formulieren plugins zoals Gravity Forms maken vaak gebruik van deze functie. De wp_mail() functie maakt standaard gebruik van de PHPMailer bibliotheek. De PHPMailer bibliotheek maakt vaak weer gebruik van de PHP mail() functie. De PHP mail() functie roept vervolgens vaak weer de e-mail functionaliteit van het besturingssysteem aan. Binnen deze verschillende functies/technieken kan ook het één en andere fout gaan.
Maatwerk WordPress e-mail functie
De standaard WordPress e-mail functie kan door ontwikkelaars ook aangepast worden. Als iemand bijvoorbeeld geen gebruik wil maken van PHPMailer en/of de PHP mail() functie dan kan dat aangepast worden. Beheerders kunnen er bijvoorbeeld voor kiezen om e-mails te laten versturen door een e-mailprovider. Mijn collega Leo schreef op 29 februari 2016 in het bericht “4 gratis providers voor betrouwbare transactionele e-mails vanuit jouw WordPress website” hierover. Het voordeel van zo’n e-mailprovider is dat ze gespecialiseerd zijn in het versturen van e-mails. Deze partijen helpen je vaak ook om alle instellingen goed in te stellen.
- Mandrill
- SendGrid
- Mailjet
- MailGun
- SparkPost
- Postmark
- SendinBlue
Toch kan er bij het gebruik van een e-mailproviders nog steeds van alles misgaan. Zo komt het soms voor dat WordPress niet goed kan communiceren met de betreffende e-mailprovider. Bijvoorbeeld doordat de e-mailprovider API even niet goed bereikbaar is. Daarnaast werken deze e-mailproviders vaak met abonnementen en limieten. Indien een limiet wordt bereikt kan het versturen van e-mails geblokkeerd worden. Verder zijn deze e-mailproviders vaak erg populair en werken ze met gedeelde IP-adressen. Doordat de diensten zo populair zijn komt het ook vaker voor dat hun IP-adressen op een blacklist staan.
SPF neutral
Om te testen of je WordPress installatie e-mails goed verstuurd kun je gebruik maken van de Check Email plugin van Chris Taylor en de mail-tester.com tool van MailPoet & AcyMailing. Via deze tools kun je controleren of e-mailbeveiliging technieken zoals SPF en DKIM goed zijn ingesteld. Op een website gehost bij SiteGround viel mij daardoor recent de volgende SPF-melding op:
spf=neutral (google.com: 69.175.69.92 is neither permitted nor denied by best guess record for domain of ********@esm35.siteground.biz) smtp.mailfrom=********@esm35.siteground.biz
Return-Path: <********@esm35.siteground.biz>Het liefst zie je de spf=pass melding om meer zekerheid te hebben dat e-mails niet als ongewenst (spam) worden gezien. Na een zoektocht blijkt dat SiteGround standaard een @esm35.siteground.biz e-mailadres instelt als Return-Path. Hierdoor controleren e-mailservers of de server achter het esm35.siteground.biz adres wel e-mails mogen versturen namens de betreffende domeinnaam. Dit is neither permitted nor denied, dus niet toegestaan of geweigerd en daardoor neutral. Gelukkig kunnen we de Return-Path die SiteGround standaard instelt wel overschrijven. Tot 20 augustus 2016 deed WordPress dit standaard. Dit werd echter verwijderd omdat dit niet op alle hosting omgevingen goed werkt. Meer informatie hierover is te vinden in WordPress core Trac ticket 37736 (Git commit). Binnen een SiteGround hosting omgeving is dit echter geen probleem. De Return-Path kan bij SiteGround ingesteld via het php.ini bestand:
sendmail_path = "/usr/sbin/sendmail -t -i -f [email protected]"Eventueel kan ook de “wp_mail return-path” plugin van Barnaby Puttick gebruikt worden.
Het lijkt er op dat er steeds meer PHP-ontwikkelaars binnen namespaces gebruik gaan maken van zogenaamde ‘fully qualified name’ definities. Aan het gebruik van bijvoorbeeld globale PHP-functies zonder use function of \-prefix kleven namelijk een aantal nadelen. In het artikel “Optimizing PHP performance by using fully-qualified function calls” van Toon Verwerft is hier meer over te lezen. En ook op de website van DEV Community staat meer informatie:
Normally your code is namespaced (right?). So what happens when you call a function from the standard PHP library? The “compiler” (opcode producer) will look into the current namespace, then go up, and eventually use the global namespace. This means that if you add a “\” in front of standard functions (so effectively namespacing it in the global namespace explicitely), it will result in less opcode instructions, and that means faster code execution. Think it’s one of those useless micro-optimization like the use of single vs. double quotes? Think again.
DEV Community – https://dev.to/elabftw/optimizing-your-php-app-speed-3hd4
Ook op de website van PHP zelf is meer informatie te vinden over hoe PHP-namespaces werken qua naamgeving van classes, functies, constanten, etc. In de FAQ staan een groot aantal voorbeelden van hoe PHP omgaat met de naamgeving binnen namespaces.
- https://www.php.net/manual/en/language.namespaces.importing.php
- https://www.php.net/manual/en/language.namespaces.fallback.php
- https://www.php.net/manual/en/language.namespaces.rules.php
- https://www.php.net/manual/en/language.namespaces.faq.php
Inmiddels zijn er ook enkele tools beschikbaar die kunnen helpen bij het gebruik van ‘fully qualified name’ definities. Zo kun je bijvoorbeeld met “PHP Coding Standards Fixer” het volgende doen:
➜ ~ php-cs-fixer fix test.php --rules=native_function_invocation,native_constant_invocationNaast php-cs-fixer kwam ik ook de volgende tools geven:
- https://github.com/Roave/FunctionFQNReplacer
- https://github.com/dg/composer-backslasher
- https://github.com/kelunik/fqn-check
- https://github.com/slevomat/coding-standard
Waar ik echter geen goed antwoord op kon vinden was of je nou beter kunt prefixen met een \ of use statements kunt gebruiken. In de TYPO3 decision topic “Should we use fully qualified function (FQN) calls like \is_array in the core?” kwam ik uiteindelijk de volgende vraag tegen:
do I read you correctly that you prefer having slashes over “use…” imports?
why?
Tymoteusz Motylewski
Deze vraag werd als volgt beantwoord:
Because we use the same PHP function within a file mostly not more than one or two times. Hence, it’s a waste of space up there to have 10 lines for 10 different functions.
(and I do not consider PHP core functions as “dependencies” like other classes, which should be easily readable at the top of a file)
Markus Klein
Op basis van deze argumenten en de momenteel beschikbare tools lijkt het prefixen met \ de voorkeur te hebben. Het was me ook zelf opgevallen dat je al snel veel use function definities kunt krijgen:
use function apply_filters;
use function implode;
use function is_object;
use function json_decode;
use function sprintf;
use function wp_json_encode;
use function wp_remote_request;
use function wp_remote_retrieve_body;
use function wp_remote_retrieve_response_code;
use function wp_remote_retrieve_response_message;Het toevoegen van een prefix \ is in veel gevallen korter.
Bekijk ook eens de presentatie “For the love of code: Modernizing WordPress, plugins, and themes” van Juliette Reinders Folmer. Ze geeft in de presentatie aan op welke manier je PHP-code nog verder kunt moderniseren. Ze geeft ook nog een aantal goede ‘best practices’:
- Focus on function, not syntax
- Don’t attempt to do everything at once