Categorieën
Geen categorie

Kunstmatige intelligentie (AI) inzetten voor generen foto’s

Begin dit jaar kreeg ik de vraag van een klant of kunstmatig intelligentie (AI) ook ingezet kan worden voor het genereren van foto’s van een persoon in een bepaalde situatie in de branch waarin deze klant actief is. Voor marketingdoeleinden kan dat wel handig zijn om bepaalde situaties voor je (potentiële) klanten duidelijker te maken.

Nou volg ik via X wel een beetje de ontwikkelingen op het gebied van kunstmatige intelligentie en zie zo regelmatig leuke voorbeelden DALL·E (van de makers van ChatGPT → OpenAI), Midjourney en Adobe Firefly voorbij komen op mijn tijdlijn.

Zo ben ik zelf ook wat aan testen gegaan met deze tool, maar de resultaten vielen mijn persoonlijk nog een beetje tegen. Het was vaak wel duidelijk te zijn dat de foto’s gegenereerd waren en er zaten vaak wel wat onjuistheden in deze foto’s. Daarnaast bleek het lastig om telkens dezelfde persoon in de foto’s te krijgen. Een paar weken later zag ik een bericht van Chase Lean op X waarin hij dit ook aankaart:

Hij geeft aan dat hij met Scenario wel goede resultaten heeft kunnen bereiken. De tool richt zich voornamelijk op het generen van afbeeldingen voor games, daardoor is de style misschien niet altijd heel realistisch. Maar voor bepaalde doeleinden kan Scenario zeker wel leuke afbeeldingen generen in een consistente stijl. Voor marketing en het opvullen van een webpagina kan dit zeker van pas komen.

Craft unique and style-consistent game assets with custom-trained AI models.

Scenario

Nog weer later kwam ik het volgende bericht tegen:

Hier noemen ze de diensten van https://rendernet.ai/ en https://remix.ai/. Op de website van RenderNet noemen ze een techniek genaamd FaceLock:

Consistent characters… always!

Upload a photo of a person and create realistic AI characters with the same face.

RenderNet

Spelenderwijs zijn er zo heel veel tools beschikbaar en ontwikkelingen op dit gebied lijken razendsnel te gaan. Voor situaties waarbij het belangrijk is dat dezelfde persoon op de foto’s komt te staan is het handig om tools te zoeken die zich ook richten ‘character consistency’.

Categorieën
PHP WordPress

Output buffering in WordPress

Het is alweer een paar weken geleden dat ik een bericht van Tanner Record op X voorbij zag komen op mijn tijdlijn over het gebruik van ‘output buffering’ in WordPress plugins:

Vergelijkbare constructies gebruiken we bij Pronamic ook regelmatig, maar ik herinnerde me ook een GitHub-issue binnen het “WordPress Coding Standards” voor PHP_CodeSniffer project: Add sniff to warn against using output buffering #1422. In dit issue stelt Juliette Reinders Folmer voor om een ‘sniff’ toe te voegen die gaat waarschuwen voor het gebruik van ‘output buffering’. Blijkbaar kunnen er ook problemen ontstaan bij het gebruik van ‘output buffering’ binnen WordPress. Zelf hebben we nog nooit met de genoemde problemen te maken gehad. Het is echter wel goed om te realiseren dat er dergelijke problemen kunnen ontstaan. In de reacties op het bericht van Tanner wordt ook voorgesteld om een PHP ’template engine’ zoals Blade of Twig te gebruiken. Een dergelijke ’template engine’ kan de nadelen van ‘output buffering’ wegnemen. Voor eenvoudige projecten zal ‘output buffering’ prima functioneren.

Categorieën
E-commerce

Verwijder de termen “creditcards” en “debitcards” op je betaalpagina

In de Buckaroo partner nieuwsbrief met onderwerp “Partner nieuwsbrief Q1” verstuurd op 11 januari 2024 had Buckaroo een item “Communicatie Mastercard en Visa” opgenomen met de volgende inhoud:

Communicatie Mastercard en Visa

Door het invoeren van nieuwe regels vanuit Mastercard en Visa is het niet meer toegestaan om de termen “creditcards” of “debitcards” te gebruiken als betaalmogelijkheid op een betaalpagina. Dit specifieke woord moet vervangen worden door Cards. Daarnaast moeten de juiste (actuele) logo’s van Mastercard en Visa worden gebruikt. Wij hebben dit in al onze plug-ins standaard verwerkt. Klanten die de Buckaroo plug-ins gebruiken hoeven dit niet aan te passen, maar wanneer ze niet gebruikmaken van onze plug-ins moeten ze dit zelf aanpassen.

Buckaroo

Op de achterliggende pagina “Verwijder de termen “creditcards” en “debitcards” op uw betaalpagina” geeft Buckaroo uitleg over deze nieuwe regels vanuit Mastercard en Visa:

Verwijder de termen “creditcards” en “debitcards” op uw betaalpagina

Door het invoeren van nieuwe regels vanuit Mastercard en Visa is het niet meer toegestaan om de termen “creditcards” of “debitcards” te gebruiken als betaalmogelijkheid op uw betaalpagina. Dit specifieke woord moet vervangen worden door de term “Cards”. Daarnaast moeten de juiste (actuele) logo’s van Mastercard en Visa worden gebruikt. Wij hebben dit in principe in al onze Plug-ins standaard verwerkt. Als u onze Buckaroo plug-ins gebruikt hoeft u dit dus niet zelf aan te passen.

Er is een uitzondering. Wanneer u het veld “Front-end Label” heeft aangepast dan dient u dit zelf aan te passen. Hieronder vindt u een voorbeeld hoe dit eruitziet bij WooCommerce. U kunt dit veld zelf handmatig aanpassen.

Gebruikt u geen Buckaroo Plugins?

Wanneer u zelf uw betaalpagina heeft ingericht en daarbij apps heeft gebruikt die niet van Buckaroo zijn dient u dit zelf aan te passen. Wij kunnen dit dan niet voor u doen. Heeft u het beheer van uw website uitbesteed en weet u niet zeker welke plug-ins u gebruikt? Neem dan contact op met uw websitebeheerder om dit te controleren en verder te regelen.

Waarom is deze regel opgesteld?

De naam creditcard en of debitcard wordt nu soms nog gebruikt als een soort verzamelterm voor meerdere betaalmogelijkheden (bijv. visa, credit en debit). Dit mag niet meer, omdat dit niet klopt. De term “cards” mag hiervoor wel gebruikt worden.

Controle

Mastercard en Visa gaan controles uitvoeren om te kijken of dat de termen creditcard en debitcard niet meer gebruikt worden op betaalpagina’s. Wanneer u deze termen nog in uw checkout heeft staan kunt u hierop worden aangesproken en worden er vervolgacties uitgevoerd als u dit negeert.

Buckaroo

Bij Pronamic waren we wel benieuwd naar de originele berichtgeving hierover van Mastercard en/of Visa. Op de websites van Mastercard en Visa konden we hier echter geen informatie over vinden.

Een aantal weken later kregen we bericht van een Adyen-gebruiker die ook bezig was met de naamgeving van de creditcard betaalmethode. Adyen heeft op de pagina “Co-badged cards compliance” hier ook het één en andere over vermeld:

Do not discriminate between card products

If you accept both credit and debit cards, to be compliant, your checkout must have a cards section that refers to both debit and credit cards. You cannot present only a credit card section. The following are examples of compliant labels for the card payments section in your checkout form:

  • Cards
  • Card payment
Adyen

Deze richtlijn komt blijkbaar voort uit de EU IFR-verordening 2015/751 artikel 8. Dat zal waarschijnlijk ook de reden zijn waarom organisaties zoals Mastercard en Visa aansturen op het vermijden van de termen “creditcards” en “debitcards”.

We hadden via de “Mollie Developer Community” Discord-server ook nog geïnformeerd naar het standpunt van Mollie in deze. Daar gaf een productmanager van Mollie het volgende aan:

In NL people are still used to Credit Card, since that was the only card you could use for online payments. But this will change with all the banks moving from Maestro/VPay to MasterCard Debit or Visa Debit.

In other countries (like the UK), it was already possible to make online payments with a debit card. So this is why you may see “Cards” for UK localization, but maybe still “Credit Card” for Dutch. But “Cards” is the most future proof 😉
Also, a recommended practice is to leverage our Methods API to get the correct name. You add a locale property so it will be translated. That way you should always be good.

Mollie

Dit alles heeft waarschijnlijk ook weer te maken met het Project DCA (Debit Card Acceptatie).

Er lijkt wat dat betreft zeker het één en andere te veranderen op het gebied van betaalpassen.

Categorieën
WooCommerce

WooCommerce order referrer en order attribution tracking

Een aantal maanden geleden kwam ik op het idee om per WooCommerce-bestelling de ‘referrer’ bij te gaan houden. Op die manier zou ik per bestelling kunnen bekijken vanaf welke website de koper op mijn webwinkel is gekomen en vervolgens een bestelling heeft geplaatst. Voor dit idee heb ik uiteindelijk de experimentele plugin “Pronamic Order Referrer for WooCommerce” geschreven. En nu lijkt het er op dat WooCommerce een vergelijkbare functionaliteit heeft geïntroduceerd. Toevallig zag ik vorige week namelijk een bericht van James Kemp, een WooCommerce productleider, op X over een nieuwe ‘order attribution tracking’ functionaliteit in WooCommerce:

Meer informatie over WooCommerce order attribution tracking is te lezen op: https://woo.com/document/order-attribution-tracking/ 🎉. Deze functionaliteit is toegevoegd vanaf WooCommerce versie 8.5.0, gelanceerd op dinsdag 9 januari 2024. Het originele ‘pull request’ voor het toevoegen van deze functionaliteit dateert al vanaf 12 augustus 2023: https://github.com/woocommerce/woocommerce/pull/39701.

Categorieën
iDEAL

Aantal iDEAL-transacties en totaal bedragen volgens het CBS t/m oktober 2023

Het Centraal Bureau voor de Statistiek (CBS) publiceerde op 1 december 2023 weer een tabel met betalingstransacties naar betaalmethode per maand. In het bericht “Betalingstransacties naar betaalmethode, aantallen en bedragen per maand” kan het Excel-document met de details gedownload worden. Voor iDEAL staat het er als volgt voor.

20192020202120222023

aantalaantalaantalaantalaantal

× 1000× 1000× 1000× 1000× 1000






Januari52.30063.70096.800101.660109.408
Februari45.90058.20088.30088.25198.685
Maart50.60062.80096.900100.206111.149
April50.40069.40093.50098.168108.449
Mei56.80075.80096.000106.171117.559
Juni56.10076.20095.800104.643115.533
Juli56.90077.70092.600103.210116.945
Augustus54.10074.80089.20097.744109.665
September56.80073.70089.200100.779111.175
Oktober59.70081.10096.100105.855118.212
November62.70084.100101.100112.556
December64.50092.900107.313113.507
Aantal betalingstransacties met iDEAL per maand
20192020202120222023

mln euromln euromln euromln euromln euro






Januari4.2945.4918.2579.64010.457
Februari3.5294.7047.5287.5828.729
Maart3.9525.8198.3238.67710.158
April4.0015.0128.3638.3369.120
Mei4.6605.4439.1379.58610.755
Juni4.4215.6828.1179.23910.909
Juli4.5405.8267.5548.77710.531
Augustus4.2715.3797.4278.4109.928
September4.4295.3537.3978.4629.468
Oktober4.5675.8477.9188.80710.810
November4.8746.7128.9679.581
December5.8178.1819.06010.233
Totaal bedrag betalingstransacties met iDEAL per maand

Daarmee lijkt oktober 2023 in de boeken te gaan als de meest succesvolle maand voor de iDEAL-betaalmethode. In totaal ruim 118.212.000 iDEAL-transacties met een totaalbedrag van € 10.810.000.000, dat is een gemiddelde van ~ € 91,45 per iDEAL-transactie.

Black Friday heeft miljoenen transacties opgeleverd: winkels en online shops verkochten dit jaar meer dan ooit. Volgens betaalplatform iDEAL is een recordaantal van 7,1 miljoen betalingen verricht.

NU.nl – https://www.nu.nl/economie/6291292/winkels-verkochten-opnieuw-meer-dan-ooit-tijdens-black-friday.html
Categorieën
iDEAL

Aantal iDEAL-transacties en totaal bedragen volgens het CBS

Het Centraal Bureau voor de Statistiek (CBS) publiceerde op 24 oktober 2023 weer een tabel met betalingstransacties naar betaalmethode per maand. In het bericht “Betalingstransacties naar betaalmethode, aantallen en bedragen per maand” kan het Excel-document met de details gedownload worden. Voor iDEAL staat het er als volgt voor.

20192020202120222023

aantalaantalaantalaantalaantal

× 1000× 1000× 1000× 1000× 1000






Januari52.30063.70096.800101.660109.408
Februari45.90058.20088.30088.25198.685
Maart50.60062.80096.900100.206111.149
April50.40069.40093.50098.168108.449
Mei56.80075.80096.000106.171117.559
Juni56.10076.20095.800104.643115.533
Juli56.90077.70092.600103.210116.945
Augustus54.10074.80089.20097.744109.665
September56.80073.70089.200100.779111.175
Oktober59.70081.10096.100105.855
November62.70084.100101.100112.556
December64.50092.900107.313113.507
Aantal betalingstransacties met iDEAL per maand
20192020202120222023

mln euromln euromln euromln euromln euro






Januari4.2945.4918.2579.64010.457
Februari3.5294.7047.5287.5828.729
Maart3.9525.8198.3238.67710.158
April4.0015.0128.3638.3369.120
Mei4.6605.4439.1379.58610.755
Juni4.4215.6828.1179.23910.909
Juli4.5405.8267.5548.77710.531
Augustus4.2715.3797.4278.4109.928
September4.4295.3537.3978.4629.468
Oktober4.5675.8477.9188.807
November4.8746.7128.9679.581
December5.8178.1819.06010.233
Totaal bedrag betalingstransacties met iDEAL per maand

Volgens de laatste berichten moet november 2023 de cijfers hierboven weer ruim gaan overtreffen:

Black Friday heeft miljoenen transacties opgeleverd: winkels en online shops verkochten dit jaar meer dan ooit. Volgens betaalplatform iDEAL is een recordaantal van 7,1 miljoen betalingen verricht.

NU.nl – https://www.nu.nl/economie/6291292/winkels-verkochten-opnieuw-meer-dan-ooit-tijdens-black-friday.html
Categorieën
Hosting

SiteGround Access Logs analyseren met GoAccess deel 2

In 2021 schreef ik al eens het bericht “SiteGround Access Logs analyseren met GoAccess”, in dit bericht een vervolg met enkele verbeteringen. SiteGround houdt de access logs per dag bij in de volgende map: /home/customer/www/example.com/logs. De bestanden zijn ingepakt en hebben de volgende notatie: example.com-2023-07-01.gz. Voor het analyseren van de access logs is het vaak handig om de logs van meerdere dagen te gebruiken. In dit bericht is te lezen hoe dat eenvoudig te doen is.

Categorieën
E-commerce iDEAL WooCommerce WordPress

Self-billing factuur van Mollie, Buckaroo, etc.

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.

Categorieën
Gravity Forms PHP WordPress

Koppeling Realworks Wonen API met WordPress en Gravity Forms

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

WordPress bedrijven op GitHub