forked from fa/breadcrumb-the-shire
fs
2e73cb98b4
Existing systems used to have no automatic mechanism for the db/updates/*.sql idempotent updates after `git pull` — devs had to remember which files were already applied and run new ones manually with `mariadb < ...`. Mirror module:migrate to fix this: - New `bin/console db:migrate` walks db/updates/*.sql in alphabetical order, skipping anything already recorded in the new core_migrations tracking table. Each file runs in its own transaction; failure rolls back so the file is retried on the next run. - New `db:migrate --status` lists applied vs. pending files without running anything. Useful for ops debugging "schema seems stale" symptoms. - module:sync now runs db:migrate as its first step, so the standard post-pull command stays a single invocation. README's 3-step setup is unchanged — module:sync now also covers core schema updates. CoreMigrationRepository owns its own mysqli connection (using the same DB credentials as MintyPHP\DB) and runs raw `$mysqli->query()` instead of going through DB::query's prepared statement path — MariaDB rejects some DDL (e.g. ALTER TABLE … ADD CONSTRAINT CHECK) in the prepared protocol, which the existing 18 db/updates files trip on. ModuleMigrationRepository is left untouched (no module migration uses such DDL today and changing the vendor pattern is out of scope). End-to-end verified: against an existing DB the first run applies all 19 idempotent files as no-ops and records them, second run reports "all updates already applied". Against a freshly init'd DB the same thing happens — no double work, no surprises. All encrypted seed secrets keep decrypting because APP_CRYPTO_KEY is unchanged. Tests: tests/Console/CoreCommandsTest covers success/failure/status output shapes against a FakeModuleRunner (mirror of the existing ModuleCommandsTest pattern). 5 stale baseline entries in phpstan-baseline removed (covered by the new @api annotation on the test fixture class). Docs: CLAUDE.md and docs/reference-cli-commands.md document the new command + --status flag; docs/howto-fehlerbehebung.md gains a "schema seems stale after git pull" section pointing at db:migrate --status. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CoreCore
Mandantenfaehige Admin-Anwendung auf MintyPHP (PHP 8.5, MariaDB 11, Nginx, Memcached, Docker). Liefert Tenants, User, Rollen, Adressbuch, Mail, Scheduler, Microsoft SSO und ein Helpdesk-Modul mit Business-Central-Anbindung.
Setup (frischer Clone)
cp .env.example .env # 1. ENV (enthaelt APP_CRYPTO_KEY fuer Test-Secrets)
docker compose up --build -d # 2. Container starten + init.sql einspielen
docker compose exec php php bin/console module:sync # 3. Modul-Migrationen + Asset-Publish
App: http://localhost:8080 · phpMyAdmin: http://localhost:8081
APP_CRYPTO_KEYaus.env.examplenicht aendern — sonst lassen sich die geseeded Microsoft-SSO- und BC-Test-Secrets nicht entschluesseln.
Login
Alle Demo-User haben das Passwort Demo123:
| Rolle | |
|---|---|
demo@user.com |
Admin |
max@user.com |
Manager |
bernd@user.com |
User |
petra@user.com |
Auditor |
hilde@user.com |
Support |
Plus der Live-User fs@breadcrumb-solutions.de (alle Rollen, Passwort nur per Reset).
Microsoft SSO ist fuer den Tenant breadcrumb mediasolutions GmbH vorkonfiguriert (Domain breadcrumb-solutions.de).
Quality Gates
docker compose exec php vendor/bin/phpunit # Tests
docker compose exec php vendor/bin/phpstan analyse -c phpstan.neon # Static Analysis
docker compose exec php composer cs:fix # Code Style autofix
Wo was steht
- Architektur, Konventionen, Guards —
CLAUDE.md - Tutorials, How-Tos, Referenzen —
docs/index.md - Production-Deployment —
docs/howto-docker-produktiv.md - Schema + Seed —
db/init/init.sql, idempotente Updates indb/updates/ - Module —
modules/<id>/(eigene Migrationen untermodules/<id>/migrations/)
Lizenz
MIT (siehe LICENSE.md)