mtrojan-ub/vufind-module-composer-test

There is no license information available for the latest version (v10.2.1.0) of this package.

An extension module for vufind-org/vufind that can be added via composer, testing several mechanisms for overriding folder structures, versioning etc.

v10.2.1.0 2026-01-09 14:41 UTC

Requires

• php: >=8.0

Requires (Dev)

• friendsofphp/php-cs-fixer: 3.89.2
• laminas/laminas-view: ^2.27.0
• phing/phing: 3.1
• phpmd/phpmd: 2.15.0
• phpstan/phpstan: 2.1.32
• rector/rector: 2.2.8
• squizlabs/php_codesniffer: 4.0.1

Unknown License

README

vufind-module-composer-test

This is a simple extension module for VuFind to be included via composer.

Effects

• A JavaScript popup will be shown everytime you call a page, similar to the default local_example_mixin
• There is a new page being added Content/mypage which uses a View Helper from the module to generate a simple example text

To include

• Add a "require"-entry to your composer.local.json

"require": {
    "mtrojan-ub/vufind-module-composer-test": "dev-main"
}

• Execute composer update
• Make sure the custom module is loaded in your ENV variables VUFIND_LOCAL_MODULES=MyModule (Webserver config, CLI, ... depending on what you want to do)
• Make sure that MyMixin is loaded in your theme.config.php 'mixins' => ['MyMixin'], see https://vufind.org/wiki/development:architecture:user_interface
  • Add a Symlink in your themes folder to ../vendor/mtrojan-ub/vufind-module-composer-test/themes/MyMixin

Special thoughts for further evaluation

• Typically other modules only add "module"-related code, but we also want to override other parts of the code:
  • Templates: Can we solve the manual symlink in another way? (e.g. a directive in composer.local.json and/or a small sh/bat script)
  • Config: Should we provide separate config files instead of extending existing ones? (might depend on what our module is about)
• What versioning should be used? e.g. if you want the module to be compatible with different VuFind versions, should we provide several tags for each version? Do we need to extend the versioning schema for this? (e.g. if we write a version for 11.0 and the VuFind Version is 11.0.1, and we fix a bug, do we need to use sub-versions like 11.0.1.0, 11.0.1.1 and so on, and provide separate versions for 10.2 like 10.2.0.0, 10.2.0.1, ...)
• QA-Tasks are experimentally included as well (copied from vufind-org/vufindhttp), with the following limitations/changes
  • So far only for "module" and not for "themes"
  • comment-related rules will be skipped in phpcs.xml for now (lots of duplicate stuff with mandatory comments when you have type hinting, redundant information in the same file, etc.)
  • ci.yaml only runs with a single PHP version and without PHPUnit (which is not yet used in this test module anyway)