Categorieën
E-commerce WooCommerce WordPress

WooCommerce: meer betalen en meer issues

De ontwikkelingen binnen de WooCommerce webwinkel plugin gaan razendsnel. Er wordt o.a. hard gewerkt aan betere ondersteuning voor de WordPress “Full Site Editing” (FSE) functionaliteiten en de blok-editor. Op 9 januari werd WooCommerce versie 8.5.0 gelanceerd en op 15 februari werd versie 8.6.0 alweer uitgebracht. En de 8.7.0 release kan er ook op elk moment aankomen. Hartstikke mooi natuurlijk dat de ontwikkelingen zo snel gaan, maar het gaat ook wel gepaard met de nodige problemen. Binnen de “WordPress Nederland” workspace op Slack was daar dan ook al een kleine discussie over:

Hey, de 8.x releases van WooCommerce verliepen -op z’n zachts gezegd- niet zo denderend. Naar mijn mening ligt het tempo met de maandelijkse update te hoog. Maar ik ben benieuwd naar jullie mening. Ik heb een open vraag gesteld in het core-channel van WooCommerce Slack, dus benieuwd naar andere meningen. Deel ze gerust daar. Merci!

Dave Loodts – https://wpnl.slack.com/archives/C016TSB5GV9/p1708338050376959

Gelukkig zijn de Woo-ontwikkelaars wel bezig om documentatie en changelogs e.d. verder te verbeteren. Maar grotere webwinkels kan het ook wel veel tijd en geld kosten om mee te gaan in alle ontwikkelingen. Daarnaast lijkt Automattic met de rebranding van WooCommerce naar Woo ook de prijzen van verschillende plugins flink verhoogd te hebben. Op X gaf Ryan Waterbury hierover bijvoorbeeld het volgende aan:

In eerste instantie lijkt de gratis webwinkel plugin WooCommerce een voordelige keuze, maar in de praktijk zie je toch ook wel snel dat er allerlei betaalde plugins en diensten nodig zijn om een succesvolle webwinkel te kunnen draaien. Als je bijvoorbeeld de “Woo Subscriptions” plugin gebruikt dan komt de “AutomateWoo” plugin vaak ook wel van pas.

En zo kan het qua licenties voor plugins al snel optellen tot een aanzienlijk maand/jaarbedrag. Voor degenen die voor de keuze staan tussen bijvoorbeeld WooCommerce en Shopify kan dat wel iets zijn om rekening mee te houden.

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
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
E-commerce PHP WooCommerce WordPress

WooCommerce teksten wijzigen

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 );
Categorieën
CSS E-commerce WooCommerce WordPress

WooCommerce wijzigt CSS selectors

Om de vormgeving van de producten op WooCommerce product archief pagina’s aan te passen maakte WooCommerce in versie 1.5.5 (of lager) altijd gebruik van de volgende CSS selector:

ul.products li {

}

Dit is ook terug te vinden in het WooCommerce less bestand waarin de standaard opmaak staat gedefinieerd:

http://plugins.trac.wordpress.org/browser/woocommerce/tags/1.5.5/assets/css/woocommerce.less#L392

We gebruikten vaak een sterkere CSS selector om de opmaak van producten op archief pagina’s aan te passen:

body ul.products li {

}

Vanaf WooCommerce 1.5.6 wordt er echter standaard een nieuwe CSS selector gebruikt. Deze selector is sterker als de door ons toegevoegde CSS selector, waardoor eventuele aanpassingen na een update niet altijd meer zichtbaar zijn.

ul.products li.product {

}

http://plugins.trac.wordpress.org/browser/woocommerce/tags/1.5.6/assets/css/woocommerce.less#L393

Dit probleem is uiteraard eenvoudig op te lossen door de eigen gedefinieerde selector ook weer specifieker te maken:

body ul.products li.product {

}

Het is echter wel de vraag in hoeverre het verstandig is om kleine aanpassingen aan het standaard meegeleverde WooCommerce thema op deze manier te realiseren. In hoeverre zijn de WooCommerce ontwikkelaars zich bewust van de gevolgen van dergelijke wijzigingen? En in hoeverre moeten de WooCommerce ontwikkelaars rekening houden met dergelijke zaken?

Categorieën
E-commerce PHP WooCommerce WordPress

WordPress Google Conversion shortcode

Om Google Conversion doelen bij te houden moet je soms op bepaalde pagina’s een zogenaamde Google Conversion code plaatsen. Binnen WordPress installatie kan het toevoegen van dergelijke codes soms lastig zijn. Daarom heb ik een eenvoudig WordPress shortcode gemaakt waarmee je eenvoudig een Google Conversion code kunt toevoegen aan je WordPress pagina’s.

/**
 * Google Conversion Code
 */
function prefix_shortcode_google_conversion_code($atts) {
	extract(shortcode_atts(array(
		'id' => null , 
		'language' => 'en' , 
		'format' => 3 , 
		'color' => '666666' , 
		'label' => '' , 
		'value' => 0 , 
	), $atts));

	$crlf = "\r\n";

	$noScriptImageUrl = sprintf('http://www.googleadservices.com/pagead/conversion/%d/', $id);
	$noScriptImageUrl = add_query_arg(array(
		'label' => $label , 
		'guid' => 'ON' , 
		'script' => 0
	), $noScriptImageUrl);

	$output = '';

	$output .= '<!-- Google Code for Bezoekers Pagina Douchegoten Remarketing List -->' . $crlf;
	$output .= '<script type="text/javascript">' . $crlf;
	$output .= '/* <![CDATA[ */' . $crlf;
	$output .= sprintf('var google_conversion_id = %d;', $id) . $crlf;
	$output .= sprintf('var google_conversion_language = "%s";', $language) . $crlf;
	$output .= sprintf('var google_conversion_format = "%s";', $format) . $crlf;
	$output .= sprintf('var google_conversion_color = "%s";', $color) . $crlf;
	$output .= sprintf('var google_conversion_label = "%s";', $label) . $crlf;
	$output .= sprintf('var google_conversion_value = %d;', $value) . $crlf;
	$output .= '/* ]]> */' . $crlf;
	$output .= '</script>' . $crlf;

	$output .= '<script type="text/javascript" src="http://www.googleadservices.com/pagead/conversion.js">' . $crlf;
	$output .= '</script>' . $crlf;

	$output .= '<noscript>' . $crlf;
	$output .= '<div style="display:inline;">' . $crlf;
	$output .= sprintf('<img height="1" width="1" style="border-style:none;" alt="" src="%s"/>', esc_attr($noScriptImageUrl)) . $crlf;
	$output .= '</div>' . $crlf;
	$output .= '</noscript>' . $crlf;

	return $output;
}

add_shortcode('google_conversion_code', 'prefix_shortcode_google_conversion_code');

Deze shortcode is met name interessant zijn in combinatie met WordPress webwinkel plugins zoals WooCommerce of Jigoshop. Om de shortcode ook op de product categorieën te kunnen gebruiken zullen de shortcodes ook toegepast moeten worden op de product categorieën beschrijvingen.

/**
 * Add shortcode support to term description
 */
function prefix_term_description($description) {
	if(is_archive()) {
		$description = do_shortcode($description);
	}

	return $description;
}

add_filter('term_description', 'prefix_term_description');
Categorieën
E-commerce iDEAL WordPress

iDEAL voor Shopp 1.2

Op woensdag 6 juli 2011 werd door de ontwikkelaars van de Shopp plugin versie 1.2 aangekondigd. Er werd een indrukwekkende lijst aan verbeterpunten en nieuwe functionaliteiten genoemd. Ik had gehoopt dat na deze aankondiging binnen een aantal weken Shopp 1.2 gelanceerd zou worden. Helaas heeft dit iets meer tijd gekost, maar lijkt Shopp 1.2 er nu toch aan te komen.

Het team achter Shopp heeft blijkbaar toch erg veel moeite moeten doen om de nieuwe versie zo in te richten dat gebruikers probleemloos kunnen overstappen van Shopp 1.1 naar versie 1.2. Met de grote lijst aan nieuwe verbeteringen en nieuwe functionaliteit kan ik me goed voorstellen dat dit een erg lastig klus is (of was). Eind december 2011 werd gelukkig de eerste release candidate van Shopp 1.2 beschikbaar gesteld.

Dit betekende voor Pronamic werk aan de winkel om de Pronamic iDEAL plugin te testen in combinatie met Shopp 1.2. De nieuwe Shopp plugin is uitgerust met een compleet nieuw systeem voor het afhandelen van bestellingen en betalingen. Hierdoor moesten er ook een aantal aanpassingen worden gedaan aan de Pronamic iDEAL plugin.

Door de code van een plugin te bekijken is vaak wel te zien hoe bepaalde functionaliteiten werken. In het geval van Shopp 1.2 was het echter lastig te overzien hoe en wanneer functies werden aangeroepen. Daarom heb ik een stroomdiagram gemaakt waarin te zien is welke functies en actie worden aangeroepen na het plaatsen van een bestelling.

Download ODF tekening

Aan de hand van dit diagram hebben we de Pronamic iDEAL plugin bijgewerkt en werkt deze sinds vandaag ook in combinatie met Shopp 1.2. Alle Shopp gebruikers die werken met de Pronamic iDEAL plugin kunnen straks zonder problemen updaten naar versie 1.2.