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