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.

Categorieën
PHP WordPress

Namespace in WordPress filter/action hooks

In februari stuitte ik op een bericht van Tanner Record waarin hij het gebruik van slashes in WordPress filter- en action-hooks voorstelde. Hij suggereert bijvoorbeeld de volgende conventie te volgen:

apply_filters( '{prefix}/{plugin}/{hook-name}', $data );

Gebruik in populaire WordPress plugins

Ik was een vergelijkbare notatie al wel tegen gekomen in populaire plugins zoals “Query Monitor” en “Advanced Custom Fields”:

Query Monitor

// 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://querymonitor.com/wordpress-debugging/profiling-and-logging

Advanced Custom Fields

add_action('acf/init', 'my_acf_init');

function my_acf_init() {
    // Get ACF version.
    $version = acf_get_setting('version');

    // Do something.  
}

Andere plugins

Mijn collega Reüel kwam nog met een reguliere expressie Github-zoekopdracht om het gebruik van deze notatie op te speuren in GitHub-repositories:

/do_action(\s['"]\w+\/\w+['"]\s(,.*?))/ language:PHP

Op basis hiervan heb ik al wel eens overwogen om een vergelijkbare notatie te introduceren in Pronamic-plugins. In de reacties op het bericht van Tanner worden echter ook een aantal nadelen genoemd.

Waarschuwing door “WordPress Coding Standards for PHP_CodeSniffer”

Bij het gebruik van de volgende notatie zal de “WordPress Coding Standards for PHP_CodeSniffer” bibliotheek een waarschuwing geven:

do_action( 'pronamic/plugin/init' );
Words in hook names should be separated using underscores. Expected: 'pronamic_plugin_init', but found: 'pronamic/plugin/init'.

De WordPress.NamingConventions.ValidHookName.UseUnderscores sniff waarschuwt hierover:

https://github.com/WordPress/WordPress-Coding-Standards/blob/29488feb64b723674fe463e691a4f83682c2dd5e/WordPress/Sniffs/NamingConventions/ValidHookNameSniff.php#L31

In de “Coding Standards Handbook” staat namelijk het volgende vermeld:

Use lowercase letters in variable, action/filter, and function names (never camelCase). Separate words via underscores.

https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#naming-conventions

Nou is het prima mogelijk om af te wijken van de “WordPress Coding Standards”. Bij Pronamic hanteren we ook een eigen standaard, die op een paar punten afwijken van de “WordPress Coding Standards”: https://github.com/pronamic/wp-coding-standards.

Lastiger te selecteren en kopieren

Bij het dubbel klikken op een tekst zoals pronamic_plugin_init zal direct de hele tekst geselecteerd worden. Bij het dubbel klikken op de tekst pronamic/plugin/init zal alleen een deel tussen de slashes geselecteerd worden. Dit maakt het dat ik voor nu nog de pronamic_plugin_init notatie zal aanhouden.