README

Embeddable, SQLite-backed Content Management Framework for PHP.

iManager is a small CMS framework, not a CMS application: you embed it inside your own PHP app and get a typed domain model, a Repository layer over SQLite (JSON columns + FTS5), a Field-Type plugin system, file storage with on-demand thumbnails, and a CLI for schema and migration ops. Use it under any PHP front-end you like: a hand-rolled admin tool, a flat-file CMS, an internal API, a static-site generator that needs a typed content store. iManager has no opinion about how your application is shaped.

Status

Stable. Current line 2.2.x (latest: 2.2.1, 2026-05-17).

The 1.x line (flat-file, var_export-based, embedded library shape) stays available for legacy installs; see the migration guide for the upgrade path.

Quickstart

Install via Composer:

composer require bigins/imanager:^2.0

Boot the full standard service graph with DefaultBootstrap::boot() and start using the repositories:

require __DIR__ . '/vendor/autoload.php';

use Imanager\DefaultBootstrap;
use Imanager\Domain\Category;
use Imanager\Domain\Field;
use Imanager\Domain\Item;
use Imanager\Enum\FieldType;
use Imanager\Storage\CategoryRepository;
use Imanager\Storage\FieldRepository;
use Imanager\Storage\ItemRepository;

$container = DefaultBootstrap::boot(
    databasePath: __DIR__ . '/data/imanager.db',
    uploadsPath:  __DIR__ . '/data/uploads',
    uploadsUrl:   '/uploads',
    cachePath:    __DIR__ . '/data/cache',
);

$categories = $container->get(CategoryRepository::class);
$fields     = $container->get(FieldRepository::class);
$items      = $container->get(ItemRepository::class);

// Schema setup: ensure() is idempotent (insert-on-miss, return-on-hit),
// so this block is safe to run on every boot.
$blog = $categories->ensure(new Category(null, 'Blog', 'blog'));
$fields->ensure(new Field(null, $blog->id, 'title', 'Title', FieldType::Text));
$fields->ensure(new Field(null, $blog->id, 'body',  'Body',  FieldType::LongText));

// Persist an item.
$items->save(new Item(
    null,
    $blog->id,
    'hello-world',     // name:  URL-friendly identifier
    'Hello, world',    // label: human-readable title
    data: ['title' => 'Hello, world', 'body' => 'First post.'],
));

// Read back.
foreach ($items->findByCategory($blog->id) as $item) {
    echo $item->label . "\n";   // → Hello, world
}

DefaultBootstrap runs the SQLite schema migrations on first use, so the database file is created and populated automatically. The three filesystem roots — dirname($databasePath), $uploadsPath, $cachePath — are created on first boot if missing, so the snippet runs against a fresh project as-is. Subsequent composer update runs pick up new migrations the same way.

Need a leaner container or want to swap PDO / FileStorage / the event dispatcher? Use Imanager\Bootstrap::boot() instead and wire the parts you want. DefaultBootstrap is just a copy-paste-saver on top of it.

Concepts

iManager models content as four primitives:

• Category: a kind of thing (e.g. Blog, Page, User). Each category has its own field schema and its own slug.
• Field: a typed column on a category. The built-in field types are: text, longtext, editor, slug, password, integer, decimal, money, checkbox, dropdown, datepicker, hidden, array, fileupload, imageupload, filepicker. Custom types register via the FieldTypePlugin interface.
• Item: an instance of a category. Field values live in a typed FieldValueBag exposed as $item->data; hot fields are also promoted to SQLite generated columns for indexable queries.
• File: a binary asset (upload). Files are stored under <uploadsPath>/<itemId>/<fieldId>/ (the uploadsPath you pass to DefaultBootstrap::boot()), with on-demand thumbnails for image uploads under thumbnail/<W>x<H>_<file>.

Domain mutations (*Created / *Updated / *Deleted events) are published through a PSR-14 dispatcher so host applications can hook into them (cache invalidation, file cleanup, etc.) without monkey- patching the storage layer.

CLI

iManager ships a Symfony-Console CLI at vendor/bin/imanager for operational tasks. The same commands run inside the Docker dev container (docker compose run --rm imanager vendor/bin/imanager …).

Requirements

• PHP 8.2+
• Extensions: pdo_sqlite, mbstring, gd, dom, json
• Composer 2

Development

The repo ships with a Docker-based dev environment (PHP 8.3 CLI + SQLite + Composer). You don't need anything else on your host machine.

docker compose build
docker compose run --rm imanager composer install
docker compose run --rm imanager composer ci

Available composer scripts:

Docs

• Tutorial: docs/tutorial/, task-oriented walkthroughs for newcomers (setup, schema design, validation, …). Start here if you just installed the package and want a guided path past the Quickstart.
• API reference: docs/api/, index plus core detail pages for Domain, Storage, Query, and Field types.
• Field-types cookbook: docs/field-types.md, how-to companion to the Field-types reference.
• Query cookbook: docs/query-cookbook.md, predicate recipes, pagination, selector strings, full-text-search hand-off, performance.
• Deployment guide: docs/deployment.md, host requirements, webserver + PHP-FPM configs, a production Dockerfile, SQLite at runtime, backups, scheduled maintenance.
• Migration guide (1.x → 2.0): docs/migration-guide.md.
• Changelog: CHANGELOG.md.

License

MIT — © bigin / Juri Ehret