README

Application Framework

All-in-one PHP framework and UI layer for building web and intranet applications.

Introduction

The framework is designed to be a solid foundation for custom-built web applications. The integrated functionality helps to focus on the application logic, while being able to create the necessary administration screens, APIs and more with minimal effort.

Note that it is not a CMS: it is exclusively a tool for building custom applications. Supporting features are available out of the box, like the notepad or image library, but anything your application needs to do must be implemented by you.

One of the core functionalities of the framework is to provide an extensive ecology of classes for accessing custom data stored in the database. This includes complex filtering capabilities as well as a versioning system with record state tracking (draft, published, etc.).

Features overview

PHP helper classes for UI elements
Form building system - every screen is a form
Rule-based application environment detection
Advanced database-stored data handling tools
Class-based extensible templating system
Localization system for UI translation
News central (release notes, etc.)
Event handling system
Image media library and UI
Tagging system and UI
Versioning system with state tracking
Disposables system for automated garbage collection
API response caching (file-based, opt-in via Interface + Trait; TTL and manual strategies)
SSO via CAS
Interface Translations: English, German, French
Build-time module documentation generators (Modules Overview, Keyword Glossary)
Own ecology of supporting libraries

Requirements

PHP 7.4 or higher (fully PHP 8 compatible)
Composer
MariaDB or MySQL database with InnoDB support
Webserver

Installation

The framework can be installed as a regular Composer dependency. However, the required application skeleton of folders and files can currently only be generated dynamically using the Framework Manager, which is currently still a private project.

Documentation on how to set up an application using the framework is still in progress. In the meantime, the example application can be used as a reference (see Example application).

Example application

The framework includes a sample application which is used as a reference for available features, best practices, and testing. It can also be used as the basis for a new application.

You will find it in the tests/application folder.

Installation

The quickest way to set up the example application is with the interactive setup command:

composer setup

This will prompt you for database and UI settings, create the database if it does not exist, import docs/sql/pristine.sql, and seed the test data automatically. Re-running the command is safe — existing values are shown as defaults and pressing Enter preserves them.

Manual setup (alternative)

Import the SQL file docs/sql/pristine.sql into a database.
Open the folder tests/application/config.
Copy test-db-config.dist.php to test-db-config.php.
Copy test-ui-config.dist.php to test-ui-config.php.
Edit the settings in both files.
Run composer seed-tests to seed the test data.

After setup, access the tests/application folder via the webserver.

Note: The generated config files (test-db-config.php, test-ui-config.php) are listed in .gitignore and must never be committed to version control — they contain local credentials and are derived from the .dist.php templates.

Composer commands

These are custom Composer commands that are available when developing locally.

Build

The build step generates module documentation artefacts from module-context.yaml files discovered throughout the codebase, updates the CTX generated-at.txt timestamp, regenerates the API method index, and rebuilds offline event listeners.

composer build

For the full development build (includes module glossary and keyword index):

composer build-dev

Setup

Interactive one-command setup for the local development environment. Prompts for database and UI settings, generates test-db-config.php and test-ui-config.php from their .dist.php templates, creates the database if it does not exist, imports docs/sql/pristine.sql, and runs composer seed-tests automatically on completion.

composer setup

Re-running the command is safe (idempotent): existing config values are read back and shown as defaults; pressing Enter without typing preserves them. If the database connection fails, the script re-prompts for credentials until a successful connection is established.

The script can also be invoked directly:

php tools/setup-local.php

Requires an interactive terminal (TTY). Do not pipe or redirect input to this command — stty -echo (used to suppress password echo) relies on an attached TTY and will behave unexpectedly in non-interactive contexts.

Seed test database

Truncates all tables in the test database and re-populates them with the standard framework seed data (system users, locales, and countries). Run this once after importing docs/sql/pristine.sql, and again whenever the test database needs to be reset to a known state.

composer seed-tests

The command runs two process-isolated steps in sequence:

php tools/seed-truncate.php — empties all base tables
php tools/seed-insert.php — inserts system users, locales, and countries

The command requires the test database to be accessible and configured (see tests/application/config/test-db-config.php). It is idempotent: running it on an already-seeded database produces the same result with no errors. On failure it prints a human-readable error message and exits with code 1, making it safe to use in CI pipelines.

Clear caches

Clears all caches used by the framework, including the dynamic class cache.

composer clear-caches

Developer Tools

The tools/ directory contains local-development CLI scripts. These are version-controlled and intended for developer use only — they are not part of the framework runtime.

Getting started as a contributor

The fastest way to get your local environment up and running is the interactive developer menu. From the project root, run:

# Unix / macOS
./menu.sh

# Windows
menu.cmd

The menu will automatically run composer install if vendor/ is missing, then present a numbered list of common tasks. Choose option 1 to run the interactive local-environment setup wizard, which configures the database and generates the required config files.

Setup Script

tools/setup-local.php is the interactive local-environment setup script (see composer setup above). It can be run directly with php tools/setup-local.php or via composer setup.

Generated files and version control

The script generates tests/application/config/test-db-config.php and tests/application/config/test-ui-config.php from their .dist.php counterparts. Both generated files are listed in .gitignore and must not be committed — they contain local database credentials. The .dist.php templates (which contain no credentials) are version-controlled and serve as the canonical structure reference.

Platform and TTY notes

Scenario	Behaviour
Unix / macOS (interactive TTY)	Password input is hidden via `stty -echo`. Ctrl-C restores echo via a `pcntl_signal` SIGINT handler.
Windows	Password input is visible in the terminal — `stty` is not available on Windows. A warning is printed before the password prompt.
Windows (some PHP builds)	`pcntl_signal` may not be compiled in. If you interrupt the script with Ctrl-C during a password prompt, terminal echo may remain suppressed. Run `stty echo` in your terminal to restore it manually.
Non-interactive / piped context	The script is not designed for non-interactive use. Running it without an attached TTY (e.g. via pipe or CI) may leave echo enabled and produce garbled output.

CAS authentication mode

By default the setup script writes TESTS_SESSION_TYPE = 'NoAuth' into test-ui-config.php. This setting is not prompted interactively — it must be changed manually when CAS authentication is required.

To enable CAS mode:

Open tests/application/config/test-ui-config.php and change the constant:
```
const TESTS_SESSION_TYPE = 'CAS';
```

Copy the CAS configuration template and fill in your server details:

cp tests/application/config/test-cas-config.dist.php \
   tests/application/config/test-cas-config.php

Edit test-cas-config.php and set the following constants to match your CAS / LDAP environment:

Constant	Description
`APP_CAS_HOST`	CAS server hostname (e.g. `cas.example.com`)
`APP_CAS_PORT`	CAS server port (default `443`)
`TESTS_CAS_FIELD_EMAIL`	CAS response field for the user's email address
`TESTS_CAS_FIELD_FIRST_NAME`	CAS response field for given name
`TESTS_CAS_FIELD_LAST_NAME`	CAS response field for family name
`TESTS_CAS_FIELD_FOREIGN_ID`	CAS response field used as the external user ID
`APP_LDAP_HOST` / `APP_LDAP_PORT`	LDAP server connection details
`APP_LDAP_DN` / `APP_LDAP_USERNAME` / `APP_LDAP_PASSWORD`	LDAP bind credentials

test-cas-config.php is gitignored alongside the other generated config files — it must never be committed.

CLI Utility Library

tools/include/cli-utilities.php is the shared helper library included by every script in tools/. It provides four console I/O functions:

Function	Signature	Description
`writeln`	`writeln(string $text = '') : void`	Writes a line to STDOUT followed by a newline. Pass an empty string for a blank line.
`color`	`color(string $text, string $color) : string`	Wraps text in ANSI colour codes. Supported values: `green`, `red`, `yellow`, `cyan`, `bold`. Returns plain text (no ANSI codes) when the colour name is unrecognised, or when running on Windows (`PHP_OS_FAMILY === 'Windows'`). The Windows fallback is intentionally conservative — plain text is returned for all Windows environments to avoid a dependency on runtime terminal-capability detection. Modern terminals such as Windows Terminal and PowerShell 7+ do support ANSI, but detecting them reliably requires additional checks.
`prompt`	`prompt(string $label, string $default = '') : string`	Displays a labelled prompt and reads a trimmed line from STDIN. Returns `$default` when the user submits an empty line.
`promptPassword`	`promptPassword(string $label, string $default = '') : string`	Like `prompt`, but suppresses character echo on Unix-like systems via `stty -echo`. On Windows or when `stty` is unavailable, input is read with echo visible and a warning is shown.

All functions are guarded with function_exists() so the file can be safely included more than once.

Developer Menu

An interactive numbered menu that groups the most common developer tasks in a single entry point. Launch it from the project root with:

# Unix
./menu.sh

# Windows
menu.cmd

# Direct (any platform)
php tools/menu.php

If the vendor/ directory is missing when the menu starts, composer install is run automatically before the menu is displayed.

Available options

#	Label	Command invoked
1	Setup local environment	`php tools/setup-local.php`
2	Build	`composer build`
3	Run tests	`composer test` (full) or `composer test-filter -- <pattern>`
4	Clear caches	`composer clear-caches`
5	Seed test database	`composer seed-tests`
6	PHPStan analysis	`composer analyze`
0	Exit	—

Option 3 (Run tests) sub-prompts for an optional filter pattern. Leaving it empty runs the full test suite; entering a pattern runs only matching tests.

The menu loops after each action completes so you can run multiple tasks in sequence without re-launching the script.

Launchers

File	Platform	Notes
`menu.sh`	Unix / macOS	Executable (`chmod +x`). Uses `#!/usr/bin/env bash` for portability.
`menu.cmd`	Windows	Uses `cd /d "%~dp0"` to handle drive-letter differences.
`tools/menu.php`	Any	Core implementation; can be invoked directly with `php`.

Build-Time Documentation Generators

The Application\Composer namespace provides build-time utilities that generate two Markdown documentation artefacts automatically on every composer build:

Modules Overview (docs/agents/project-manifest/modules-overview.md) — a Markdown table of all modules, their source paths, context doc locations, and inter-module dependencies. Discovered from module-context.yaml files.
Keyword Glossary (docs/agents/project-manifest/module-glossary.md) — a Markdown glossary mapping opaque domain terms to the modules that define them. Application modules can contribute custom sections via the DecorateGlossaryEvent offline event.

To register a module for discovery, add a module-context.yaml next to its classes:

moduleMetaData:
  id: "my-module"
  label: "My Module"
  description: "What this module does."
  keywords:
    - "Widget (the core UI component)"

See src/classes/Application/Composer/README.md for full API documentation and the offline-event integration guide.

CTX Integration

The project uses CTX to generate context files for AI-assisted development, and to provide an MCP server for integration with IDEs like PHPStorm to access the framework's AI tools.

Related commands

Start the MCP Server

ctx server

Generate all files

ctx generate

Server information

This fetches a JSON-lines list of configurations and tools available in the server.

(echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test-client","version":"1.0.0"}}}'; \
 echo '{"jsonrpc":"2.0","method":"notifications/initialized"}'; \
 echo '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}') | ctx server -c context.yaml

Documentation

The framework's documentation is available locally by pointing a browser to the docs folder, and online in the separate Framework Documentation package.

It is ideally viewed through the framework's documentation screen, as there are some features that are only available there (like code samples that are included dynamically).

Vendor Package

For convenience, a copy of the documentation is automatically checked out into the vendor folder during the Composer install process.

It can be found at mistralys/application-framework-docs.

History

The framework has its origins in several projects where the same development paradigms were used and refined over time. In 2013, it started to crystallize into a recognizable entity, and in 2015, it was officially split off into its own project.

It was migrated to Github in february 2021, and modernizing the code has been ongoing ever since. As a result, the current state of the code is a mix of namespaced and non-namespaced code, with the goal of eventually moving to a fully namespaced codebase.

mistralys / application_framework

Maintainers

Package info

Statistics

Security