Categorieën
WordPress

WordPress koppelen aan AI met MCP

Ik ben de afgelopen tijd wat aan het experimenteren met het koppelen van WordPress-installaties aan AI-chatapps. Het idee is interessant: niet alleen een AI-chatbot over je website laten praten, maar een AI-client daadwerkelijk toegang geven tot WordPress via het Model Context Protocol (MCP).

WordPress heeft daar sinds versie 7.1 ook steeds meer bouwstenen voor gekregen. Daarmee wordt het interessanter om WordPress als databron of zelfs als onderdeel van een AI-workflow te gebruiken.

Maar voordat je zover bent, moet je natuurlijk eerst verbinding maken.

En daar liep ik tegen een probleem aan.

Even terug naar augustus

Op 18 augustus deed ik een eerste poging om een WordPress-installatie via MCP aan Claude Desktop te koppelen. Ik had inmiddels wat gelezen over MCP en OAuth en het leek allemaal redelijk overzichtelijk.

De WordPress-kant had alleen nog geen standaard MCP-server die je zomaar kunt activeren. Ik volg verschillende Nederlandse WordPress-ontwikkelaars op social media en zo was ik eerder ook de Albert AI Butler plugin van Mark Jansen van YourMark tegengekomen.

De plugin zag er technisch interessant uit en het uitgangspunt was eigenlijk precies wat ik zocht: een MCP-server voor WordPress, inclusief OAuth-authenticatie.

Het idee was simpel:

  1. Installeer Albert op een WordPress-site.
  2. Gebruik de MCP-server-URL in je AI-client.
  3. De client ontdekt dat authenticatie nodig is.
  4. Je logt in op WordPress.
  5. Klaar.

Dat klonk goed.

In de praktijk was het minder eenvoudig.

Ik heb verschillende clients geprobeerd, waaronder Claude Desktop, de ChatGPT desktop-app, Jan en Open WebUI. Met een WordPress Application Password kreeg ik sommige dingen wel aan de praat, maar voor een minder technisch persoon is dat niet bepaald de ideale gebruikerservaring.

OAuth is hier veel logischer.

Alleen kreeg ik die OAuth-flow niet goed werkend.

“Dit zou toch gewoon moeten werken?”

Op 9 september kwam ik een post van Remkus de Vries tegen over precies dit onderwerp:

Daarin werd ook Albert AI Butler genoemd.

Dat maakte me opnieuw nieuwsgierig. Als dit inmiddels daadwerkelijk gebruikt en beschreven wordt, zou de OAuth-flow toch gewoon moeten werken?

Ik besloot het nog eens te proberen.

Dat leverde onder andere deze melding op in Claude:

Couldn’t register with sign-in service.

Ik begon daarom wat verder te graven en kwam uiteindelijk ook bij de MCP Inspector terecht. Dat hielp om iets beter te begrijpen wat er achter de schermen allemaal gebeurt, maar ik was zelf nog relatief nieuw met MCP en OAuth.

Dus op 14 september besloot ik Mark maar eens een berichtje te sturen.

Even de maker vragen

Ik ken Mark een beetje vanuit de WordPress-community. We hadden elkaar eerder gesproken via de WordPress Nederland Slack (wpnl.slack.com), dus ik stuurde hem daar een bericht met mijn bevindingen.

Mijn eerste vraag was eigenlijk heel simpel: zou Cloudflare of SiteGround misschien roet in het eten gooien?

Ik gaf hem mijn MCP-endpoint en de foutmelding uit Claude.

Mark gebruikte zelf primair Claude Desktop als MCP-client en dook er direct in. Al snel bleek dat Claude ondertussen iets aan zijn kant had veranderd in de manier waarop custom connectors en OAuth worden afgehandeld.

Dat was interessant, maar nog geen verklaring waarom het bij mij niet werkte.

We testten vervolgens een demo-installatie van Albert. Met de demo-URL kon ik wel door de OAuth-flow heen.

Claude stuurde me naar de Claude-loginpagina en daarna leek de flow verder goed te gaan.

Daarmee werd het zoekgebied kleiner.

Het zat dus waarschijnlijk niet fundamenteel in Albert, Claude of OAuth.

Wat was dan het verschil tussen de demo en mijn eigen WordPress-installatie?

Hallo /.well-known/

Bij OAuth en MCP spelen een aantal discovery-endpoints een belangrijke rol. Een client kan daarmee automatisch ontdekken waar authenticatie geregeld wordt en welke endpoints daarvoor beschikbaar zijn.

Een van die endpoints zit onder:

/.well-known/

En laat dat nou net een directory zijn waar SiteGround zelf iets mee doet.

Ik testte bijvoorbeeld:

https://www.remcotolsma.nl/.well-known/oauth-protected-resource

Maar in plaats van de JSON-response van WordPress kreeg ik een SiteGround 404.

Ik heb SiteGround vervolgens gevraagd hoe zij omgaan met /.well-known/.

Het antwoord kwam, zoals dat tegenwoordig vaker gaat, van de AI-supportbot.

De uitleg kwam er kort gezegd op neer dat SiteGround een Nginx reverse proxy gebruikt die verzoeken naar /.well-known/ rechtstreeks probeert af te handelen. Als er geen fysiek bestand op de server staat, krijgt de request een 404 voordat Apache of WordPress überhaupt aan de beurt komt.

De voorgestelde oplossing was dan ook: maak de benodigde JSON-bestanden fysiek aan in public_html/.well-known/.

Technisch gezien zou dat kunnen werken.

Maar dat voelde niet als een oplossing die je wilt voorschrijven voor een WordPress-plugin.

Een WordPress-plugin die bij installatie bestanden in een specifieke directory op de server moet gaan schrijven, alleen omdat een hostingplatform /.well-known/ op een bepaalde manier afhandelt, opent weer een hele nieuwe doos met problemen.

Zoals Mark het verwoordde:

“Opening up a whole other can of worms haha”

Daar was ik het wel mee eens.

Een andere route

Mark ging verder zoeken in de MCP-specificatie en de manier waarop clients discovery uitvoeren.

Daar bleek een interessante mogelijkheid te zitten.

Een goede MCP-client kan discovery in meerdere stappen uitvoeren. De /.well-known/-routes hoeven daarbij niet noodzakelijk rechtstreeks in de root van het domein te staan.

Mark paste Albert daarop aan.

In plaats van de discovery-informatie op een plek te zetten die door veel hostingplatforms wordt onderschept, werd het pad aangepast zodat de benodigde /.well-known/-informatie onder een subdirectory van de MCP-server beschikbaar komt.

Mark stuurde me vervolgens een beta van versie 1.4.1 om te testen.

Ik installeerde hem op mijn site, koppelde dezelfde MCP-server opnieuw aan Claude en dit keer werkte de OAuth-flow wel.

Geen Application Password, geen handmatig geknutsel met OAuth-gegevens. Gewoon de MCP-server-URL toevoegen, OAuth laten detecteren en door de login-flow heen.

Precies zoals ik in eerste instantie verwachtte dat het zou werken.

Van probleem naar release

De wijziging is uiteindelijk onderdeel geworden van Albert AI Butler 1.4.1.

Interessant daarbij is dat het probleem niet specifiek voor SiteGround bleek te zijn. Tijdens het testen bleek dat Remkus tegen een vergelijkbaar probleem aanliep bij Servebolt. Ook daar werkte de aangepaste oplossing.

Mijn experiment met MCP had daarmee niet alleen op mijn eigen installatie resultaat.

Wat dit voor WordPress interessant maakt

Voor mij wordt het vanaf hier eigenlijk interessanter.

De MCP-koppeling is één ding, maar uiteindelijk gaat het natuurlijk om wat je ermee kunt doen.

WordPress heeft inmiddels ook een Abilities API. Daarmee kunnen plugins functionaliteit op een gestandaardiseerde manier beschikbaar stellen aan andere systemen. In combinatie met MCP wordt dat interessant voor AI-clients.

Dat betekent bijvoorbeeld dat je niet alleen algemene WordPress-functionaliteit beschikbaar kunt maken, maar ook functionaliteit uit je eigen plugins.

Dat is voor mij een stuk interessanter dan alleen vragen stellen over pagina’s en berichten.

Zo hebben we voor een klant bijvoorbeeld een behoorlijk complexe Twinfield-schaduwdatabase binnen WordPress gebouwd. Daarin wordt financiële informatie uit Twinfield verwerkt en beschikbaar gemaakt voor de applicatie die we rondom WordPress hebben gebouwd.

Als je daar vervolgens relevante abilities voor definieert, ontstaat ineens de mogelijkheid om vanuit een AI-client vragen te stellen over die Twinfield-data.

Bijvoorbeeld niet alleen:

“Welke berichten staan er op mijn website?”

maar veel meer richting:

“Welke ontwikkelingen zie je in de financiële gegevens van deze administratie?”

Of:

“Welke transacties vallen op als ik de afgelopen periode vergelijk met dezelfde periode vorig jaar?”

Daarmee wordt WordPress niet alleen een CMS waar een AI-client toevallig wat data uit kan lezen. Het kan ook een interface worden naar functionaliteit en data die specifiek voor een bepaalde toepassing in WordPress is gebouwd.

En dat vind ik een stuk interessanter.

Zeker omdat systemen als Twinfield zelf op dit vlak nog lang niet altijd dezelfde mogelijkheden bieden. Als je de relevante data al via een eigen WordPress-applicatie beschikbaar hebt, kun je daar met abilities en MCP een nieuwe interface bovenop zetten.

Eerst maar eens verder experimenteren

Mijn eerste doel was eigenlijk vrij bescheiden: een WordPress-installatie koppelen aan Claude via MCP.

Dat bleek iets meer uitzoekwerk te zijn dan verwacht.

Uiteindelijk leverde het wel een werkende OAuth-koppeling op, een verbetering aan Albert AI Butler en voor mij vooral een beter beeld van hoe MCP, OAuth, WordPress en hosting zich tot elkaar verhouden.

De volgende stap is voor mij dan ook niet zozeer nóg een WordPress-installatie aan Claude koppelen.

Ik ben vooral benieuwd wat er gebeurt als je eigen WordPress-plugins functionaliteit beschikbaar gaan stellen via de Abilities API en je die vervolgens via MCP aan een AI-client kunt aanbieden.

Daar begint het wat mij betreft pas echt interessant te worden.

Categorieën
Geen categorie

ScanSnap S1300i werkte niet meer op macOS Tahoe

Een paar weken geleden leek mijn Fujitsu ScanSnap S1300i plotseling niet meer te werken met mijn MacBook. Het blauwe lampje bleef maar knipperen en de scanner werd niet meer herkend.

Mijn eerste gedachte was dat het aan de USB-C-poorten van mijn MacBook lag. Mijn LG-monitor heeft daar namelijk ook wel eens kuren mee. Dus: kabels wisselen, opnieuw aansluiten, herstarten… maar niets hielp.

Langzaam begon ik al te vrezen dat mijn ScanSnap S1300i na al die jaren toch echt de geest had gegeven.

Vandaag bedacht ik me dat het misschien ook wel eens aan een macOS-update zou kunnen liggen. Na wat zoeken kwam ik deze Reddit-thread tegen:

Daar las ik dat het met een nieuwe versie van ScanSnap Home weer zou moeten werken. Na het updaten van de software werkte de scanner inderdaad weer.

Even was ik bang dat Fujitsu hetzelfde had gedaan als bij de oudere Fujitsu ScanSnap S1300, waarvan de macOS-ondersteuning stopte bij macOS Catalina. Destijds heb ik toen maar een nieuwe scanner gekocht, ook al zie ik nu dat iemand daar een workaround voor heeft bedacht:

https://github.com/forflo/vagrantfile-fujitsu-scansnap-s1300

Overigens blijf ik ScanSnap scanners erg prettig vinden. Vooral het dubbelzijdig scannen en meerdere pagina’s tegelijk via de document feeder verwerken is echt ideaal.

Gelukkig bleek mijn S1300i dus nog niet overleden. Soms is een software-update toch gewoon de oplossing.

Categorieën
PHP WordPress

Bug met `style_handle` bij block styles in WordPress

De WordPress-thema’s die we tegenwoordig bij Pronamic ontwikkelen, zijn doorgaans volledig opgebouwd met blokken. We zetten daarbij ook steeds meer in op Full Site Editing (FSE)-thema’s. Bij maatwerkontwerpen maken we daarbij vaak intensief gebruik van blockpatronen, blockstijlen en blockvariaties.

Bij het registreren van een block style kun je een style_handle meegeven. Tijdens het ontwikkelen van een maatwerkplugin viel het me eerder dit jaar (in maart) al op dat de bijbehorende stylesheet niet automatisch werd ingeladen. Destijds heb ik dat opgelost door de stijl handmatig te laden in een block render callback, waarbij ik controleerde of de custom style actief was. Onlangs liep ik bij het uitwerken van een campagnesite opnieuw tegen hetzelfde probleem aan. Ik ben de documentatie nog eens gaan nalezen en heb gezocht naar gerelateerde GitHub-issues. Al snel vond ik WordPress/Gutenberg issue #27244, waarin een gebruiker aangaf dat hij het probleem ook had ontdekt via de officiële documentatiepagina: https://developer.wordpress.org/themes/features/block-style-variations/.

Op die pagina staat inmiddels ook een duidelijke waarschuwing:

style_handle currently has a bug where it only enqueues the stylesheet in the editor but not on the front end. Until that linked ticket is addressed, its use is not recommended.

Block Style Variations – Theme Handbook | Developer.WordPress.org

Dat had ik eerder niet gezien. Ik ging er eigenlijk vanuit dat style_handle de aanbevolen en nette manier was om block-CSS aan te bieden, maar dat blijkt dus niet (meer) het geval te zijn. In de laatste reactie binnen het GitHub-issue wordt zelfs aangegeven dat de optie nooit echt goed gewerkt heeft en dat verwijderen misschien overwogen moet worden. Misschien is het gebruik van een inline_style voorlopig dus nog wel de meest betrouwbare aanpak.

<?php

\add_action(
	'init',
	function() {
		$url = \get_block_asset_url( __DIR__ . '/images/beige-cutout-1.svg' );

		\register_block_style(
			'core/group',
			[
				'name'         => 'custom-beige-cutout-1',
				'label'        => __( 'Beige cutout 1', 'custom' ),
				'inline_style' => <<<END
					.wp-block-group.is-style-custom-beige-cutout-1 {
						background-image: url("$url");
						background-repeat: no-repeat;
						position: calc( 100% + ( ( 1920px - 100vw ) * 0.2 ) ) top;
					}
					END,
			]
		);
	}
);

https://core.trac.wordpress.org/ticket/55184

Categorieën
Geen categorie

Oude Knab-banktransacties importeren in Firefly III

In het verleden heb ik een aantal jaar gebankierd bij Knab. Een prima online bank, maar per januari 2022 ben ik daar van afgestapt. Toch had ik nog een reeks oude exportbestanden liggen met mijn transacties, in het CSV-formaat dat Knab aanbiedt.

Die bestanden hebben de volgende headers:

Rekeningnummer;Transactiedatum;Valutacode;CreditDebet;Bedrag;Tegenrekeningnummer;Tegenrekeninghouder;Valutadatum;Betaalwijze;Omschrijving;Type betaling;Machtigingsnummer;Incassant ID;Adres;Referentie;Boekdatum;

Een paar jaar geleden kwam ik al eens in aanraking met Firefly III, een open source project voor persoonlijke financiën dat me wel interessant leek. Ik ben er nu eindelijk eens aan toegekomen om Firefly III te testen via een Docker-container. Als proef wilde ik mijn oude Knab-transacties importeren via de Firefly III data importer.

  • Rekeningnummer
  • Transactiedatum
  • Valutacode
  • CreditDebet
  • Bedrag
  • Tegenrekeningnummer
  • Tegenrekeninghouder
  • Valutadatum
  • Betaalwijze
  • Omschrijving
  • Type betaling
  • Machtigingsnummer
  • Incassant ID
  • Adres
  • Referentie
  • Boekdatum

Geen bestaande importconfiguratie

Firefly III heeft een verzameling importconfiguraties per land: https://github.com/firefly-iii/import-configurations. Daar stond geen configuratie voor Knab tussen, dus ik heb zelf een configuratiebestand gemaakt dat goed werkt met de CSV-export van Knab.

Mijn Knab-importconfiguratie

Hieronder de configuratie die ik gebruik in de Firefly III CSV-importer (versie 1.8.2):

{
    "version": 3,
    "source": "ff3-importer-1.8.2",
    "created_at": "2025-10-10T14:05:19+02:00",
    "date": "d-m-Y",
    "default_account": 0,
    "delimiter": "semicolon",
    "headers": true,
    "rules": true,
    "skip_form": false,
    "add_import_tag": true,
    "roles": [
        "account-number",
        "date_transaction",
        "currency-code",
        "generic-debit-credit",
        "amount",
        "opposing-number",
        "opposing-name",
        "date_interest",
        "note",
        "description",
        "note",
        "sepa_db",
        "sepa_ci",
        "note",
        "external-id",
        "date_book"
    ],
    "do_mapping": [
        false,
        false,
        false,
        false,
        false,
        true,
        true,
        false,
        false,
        false,
        false,
        false,
        false,
        false,
        false,
        false
    ],
    "mapping": {},
    "duplicate_detection_method": "cell",
    "ignore_duplicate_lines": true,
    "unique_column_index": 14,
    "unique_column_type": "external-id",
    "flow": "file",
    "content_type": "csv",
    "custom_tag": "",
    "identifier": "0",
    "connection": "0",
    "ignore_spectre_categories": false,
    "grouped_transaction_handling": "",
    "use_entire_opposing_address": false,
    "map_all_data": false,
    "pending_transactions": false,
    "access_token": "",
    "accounts": {},
    "new_account": [],
    "date_range": "",
    "date_range_number": 30,
    "date_range_unit": "d",
    "date_range_not_after_unit": "",
    "date_range_not_after_number": 0,
    "date_not_before": "",
    "date_not_after": "",
    "nordigen_country": "",
    "nordigen_bank": "",
    "nordigen_requisitions": {},
    "nordigen_max_days": "90",
    "conversion": false,
    "ignore_duplicate_transactions": false
}

Belangrijke keuzes in deze configuratie

  • Scheidingsteken: semicolon, omdat Knab puntkomma’s gebruikt in CSV-exporten.
  • Datumformaat: d-m-Y, hetzelfde als in de Knab-bestanden.
  • Referentie is gemapt als external-id, zodat Firefly dubbele transacties kan herkennen en voorkomen.
  • Mapping is alleen aan bij tegenrekeningvelden (Tegenrekeningnummer en Tegenrekeninghouder), zodat vaste tegenpartijen automatisch worden herkend.

Dubbele transacties voorkomen

Toen ik een CSV van een Knab-spaarrekening importeerde, merkte ik dat Firefly overschrijvingen dubbel toevoegde. Door het veld Referentie te gebruiken als unieke external ID (unique_column_index: 14) worden zulke duplicaten netjes overgeslagen.

Conclusie

Met deze configuratie lukt het om oude Knab-exportbestanden goed in Firefly III te importeren. Misschien dat ik de configuratie nog toevoeg aan de officiële Firefly III import-configuraties op GitHub, zodat anderen er ook gebruik van kunnen maken. Voor nu was het vooral een leuke manier om Firefly III eens rustig te verkennen.

Update 12 oktober 2025

Inmiddels de Knab import configuratie toegevoegd aan het Firefly III imort configuraties project:

https://github.com/firefly-iii/import-configurations/blob/b6b60fcc6b05d53a5c6608fff51f5e54247de57f/nl/knab/knab.json

Categorieën
Geen categorie

Video draaien via de command line

Soms staat een videobestand ondersteboven en moet het gedraaid worden. Natuurlijk is dit in een videobewerkingsprogramma op te lossen, maar als programmeur kan ik een snel terminalcommando ook wel waarderen. Met FFmpeg, een veelzijdige tool voor video en audio, kan dit eenvoudig worden gedaan:

ffmpeg -i video.mp4 -c copy -metadata:s:v:0 rotate=180 video-rotated.mp4

Toelichting:

  • -i video.mp4 geeft het bronbestand aan.
  • -c copy kopieert video en audio zonder opnieuw te coderen, waardoor de kwaliteit behouden blijft en de verwerking snel gaat.
  • -metadata:s:v:0 rotate=180 draait de video 180 graden.
  • video-rotated.mp4 is het resultaatbestand.

Op deze manier kan een videobestand eenvoudig en efficiënt worden gedraaid, zonder dat er grafische videobewerkingssoftware nodig is.

Categorieën
Homebrew Mac

Terug naar de tijd van RAR-bestanden

Onlangs kwam ik tijdens het opruimen van wat oude bestanden een RAR-archief tegen. Voor wie met Windows 95, Windows 98, Windows XP, etc. is opgegroeid, roept dat mogelijk herinneringen op. RAR-bestanden waren in die tijd allerminst ongewoon. Illegale kopieën van software, muziek of films werden vaak in dit formaat verspreid, en wie de beruchte Twilight-cd’s of -dvd’s kende, herinnert zich ongetwijfeld dat veel downloads als een reeks .rar-bestanden binnenkwamen.

RAR had in die tijd een paar voordelen. Het bood betere compressie dan ZIP, en met de ingebouwde mogelijkheid om grote bestanden in meerdere delen op te knippen, was het ideaal om grote releases te verspreiden via toenmalige trage internetverbindingen. Bovendien waren er populaire tools zoals WinRAR, die bijna iedereen wel op zijn pc had staan (al dan niet in de “probeerversie” die je eindeloos kon blijven gebruiken).

Fast forward naar vandaag: RAR-bestanden zijn zeldzaam geworden. Het ZIP-formaat wordt standaard ondersteund op vrijwel ieder besturingssysteem, en voor serieuze compressie of distributie zijn formaten als 7z of zelfs gewoon tar.gz populairder.

Toch belandde ik dus met een ouderwets RAR-archief op mijn MacBook. Mijn eerste reflex:

brew install rar

of

brew install unrar

Helaas, die formula’s bestaan niet meer. Gelukkig bleek er een alternatief:

brew install unar
unar bestand.rar

En daarmee was het probleem opgelost.

Het voelde bijna nostalgisch om weer met een RAR-bestand bezig te zijn, alsof je even terug bent in de tijd van Windows XP, kazaa-downloads en cd’tjes vol software.

Categorieën
WordPress

WordPress 6.7 en Twenty Twenty-Five

WordPress 6.7 staat gepland voor lancering op dinsdag 12 november 2024 en wordt de derde grote WordPress-update van dit jaar. De volledige ontwikkelingscyclus van WordPress 6.7 is te volgen via: https://make.wordpress.org/core/6-7/. Deze release introduceert naar verwachting ook het nieuwe standaardthema “Twenty Twenty-Five”, aangekondigd op 15 augustus 2024 in het bericht “Introducing Twenty Twenty-Five”. Bij Pronamic zijn we inmiddels bezig met het testen van onze plugins voor compatibiliteit met WordPress 6.7. De belangrijkste nieuwe functies en wijzigingen zijn beschreven in de WordPress 6.7 ‘field guide’. Vooral de verbeteringen in de Block Bindings en HTML API zijn veelbelovend, en een nieuw standaardthema is altijd interessant. Een demo van “Twenty Twenty-Five” is beschikbaar op https://2025.wordpress.net/.

Categorieën
iDEAL

Aantal iDEAL-transacties en totaal bedragen volgens het CBS t/m september 2024

Het Centraal Bureau voor de Statistiek (CBS) publiceerde op 18 september 2024 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.

201920202021202220232024

aantalaantalaantalaantalaantalaantal

× 1000× 1000× 1000× 1000× 1000× 1000






Januari52.30063.70096.800101.660109.408120.200
Februari45.90058.20088.30088.25198.685110.690
Maart50.60062.80096.900100.206111.149119.900
April50.40069.40093.50098.168108.449119.620
Mei56.80075.80096.000106.171117.559127.520
Juni56.10076.20095.800104.643115.533125.850
Juli56.90077.70092.600103.210116.945123.910
Augustus54.10074.80089.20097.744109.665117.150
September56.80073.70089.200100.779111.175122.150
Oktober59.70081.10096.100105.855118.212
November62.70084.100101.100112.556122.430
December64.50092.900107.313113.507123.490
Aantal betalingstransacties met iDEAL per maand
201920202021202220232024

mln euromln euromln euromln euromln euromln euro






Januari4.2945.4918.2579.64010.45712.180
Februari3.5294.7047.5287.5828.72910.440
Maart3.9525.8198.3238.67710.15811.399
April4.0015.0128.3638.3369.12011.680
Mei4.6605.4439.1379.58610.75511.910
Juni4.4215.6828.1179.23910.90911.500
Juli4.5405.8267.5548.77710.53112.190
Augustus4.2715.3797.4278.4109.92810.750
September4.4295.3537.3978.4629.46810.750
Oktober4.5675.8477.9188.80710.810
November4.8746.7128.9679.58110.890
December5.8178.1819.06010.23311.890
Totaal bedrag betalingstransacties met iDEAL per maand

Categorieën
WooCommerce

Van WooCommerce naar Woo en terug

WooCommerce gebruikers hebben misschien wel iets voorzij zien komen over de naamswijziging van WooCommerce naar Woo. Op 31 oktober 2023 kondigde David Callaway in het bericht “Say hello to Woo.com” officieel de naamswijziging aan. In de weken hiervoor zagen we bij Pronamic al dat Automattic bezig was met de voorbereidingen hiervan. Inmiddels is de naamswijziging weer teruggedraaid, maar wat is het verhaal hier achter? In dit bericht een korte uitleg met tijdlijn.

Categorieën
E-commerce Gravity Forms iDEAL WooCommerce WordPress

Hoe kan ik Mollie koppelen aan WordPress of WooCommerce?

Het koppelen van Mollie aan WordPress of WooCommerce is goed mogelijk en er zijn verschillende oplossingen beschikbaar. Welke optie het beste is, hangt af van verschillende factoren. Wil je Mollie aan WordPress of WooCommerce koppelen? Hier vind je alle benodigde informatie.