open-foundations/kirby-base

A set of base classes and blueprint for web development in a plugin format using Kirby CMS

3.32.1 2026-08-13 15:57 UTC

Requires

• php: >=8.3.0 <8.5.0
• ext-pdo: *
• getkirby/composer-installer: ^1.2

Requires (Dev)

• dealerdirect/phpcodesniffer-composer-installer: ^1.1
• getkirby/cms: ^5.0.0
• phpunit/phpunit: ^12.5
• rector/rector: ^2.3
• setasign/fpdi: ^2.6
• slevomat/coding-standard: ^8.0
• squizlabs/php_codesniffer: *
• tecnickcom/tcpdf: ^6.11

Suggests

• ext-gd: Required for BMP to PNG conversion when Imagick is unavailable (uncompressed BMP only)
• ext-imagick: Required for BMP to PNG conversion (supports all BMP variants including RLE-compressed)
• setasign/fpdi: Required only to render certificates (BSBI\WebBase\certificates). Install alongside tecnickcom/tcpdf.
• tecnickcom/tcpdf: Required only to render certificates (BSBI\WebBase\certificates). Install alongside setasign/fpdi.

MIT

• James Drever

Published on Packagist.org on 2026-08-13 15:58 UTC

README

Shared Kirby plugin used by several BSBI sites. Released by git tag; consumers pin an exact version in their own composer.json.

Consuming sites must provide these dependencies themselves

This plugin declares runtime dependencies in its own composer.json:

Package	Why
setasign/fpdi	reads an existing PDF so a certificate can be overlaid onto the designer's artwork
tecnickcom/tcpdf	writes the PDF; UTF-8 native, so names like Siân or Ó Briain survive

How those reach the site depends on how the plugin is being used, and the two differ:

• Installed by Composer (servers, and any site not developing the plugin) — Composer flattens our requirements into the site's vendor/, and they autoload with everything else. Nothing to do.

• Checked out as a git submodule (local development) — our composer.json is never seen by the site's Composer, so those packages are absent from the site's vendor/. Anything touching certificates then fails with:

  Class "setasign\Fpdi\PdfReader\PdfReader" not found
  

  even though the same code works on a server.

What a consuming site should do

Declare them in the site's own composer.json and install with a targeted update:

"require": {
    "setasign/fpdi": "^2.6",
    "tecnickcom/tcpdf": "^6.11"
}

composer update setasign/fpdi tecnickcom/tcpdf

Targeted, never a bare composer update: this plugin is installed to site/plugins/kirby-base, the same path as the submodule, so an untargeted run deletes the submodule working tree.

This duplicates our requirement into each consuming site, which is not lovely. It is deliberate: the alternative is for this plugin to require its own vendor/autoload.php, and it must not. Our require-dev includes getkirby/cms, so that directory holds a second Kirby, and Composer's generated autoloader registers with prepend = true — loading it would put the wrong Kirby ahead of the site's for every class not yet loaded. Two declared lines beat that.

Working on this plugin

See CLAUDE.md for the development workflow, testing and version management.