Zum Inhalt springen

DACore · coming December 2026

What DACore is in DotApp PHP Framework

DACore is the admin module for DotApp PHP Framework 2.0. It is almost finished and still in testing. The release is planned for December 2026. You can already read what it will do: it installs the base database and the administration shell, so people who need login, users, firewall, devices, menu, and a free template stop rebuilding that stack for every project. After DACore is in place, a programmer writes only their own module — and that module must follow a contract DACore can install and uninstall.

Common mistakes

Wrong Right
Treat DACore as another copy of the framework installer. The framework installer boots DotApp. DACore is a module that boots an administration workspace on top of DotApp.
Rewrite login, users, and menu inside every new module. Call DACore APIs. Your module owns business tables, pages, and rights — not a second auth stack.
Edit files under app/modules/DACore/ to “add a feature”. Put the feature in app/modules/YourModule/. The next DACore update wipes local patches.
Ship a framework install.php inside a DACore plugin ZIP. Ship dainstall.php. DACore rejects packages that look like a one-shot framework install.
Assume AI agents will guess the admin contract. Copy AIRULES-DACORE/ into the project as AIRULES/. The overlay exists so agents write secure plugins.

Why DACore exists

DotApp is modular on purpose. A Shop module and a Docs module can live in the same app without sharing one routes file. That is still true. What teams kept rewriting anyway was the administration surface: who can log in, who can open which page, which device is still trusted, which IP is allowed, where the sidebar item sits, and how a ZIP of another module gets installed without leaving junk in the database.

DACore is that surface as one module. It seeds the core user tables, its own dacore_* tables, a first administrator when the database becomes ready, and a Materio-style admin shell you do not have to design from scratch. The free template is not a demo skin. It is the chrome every DACore-bound page uses through DACore:Page@withMenu!.

What you stop writing

For anyone who wanted “just the admin things”, the old path was: run the framework installer, then hand-build users, 2FA, lockout, devices, a menu, error pages, and a package story. DACore takes that work:

  • Base database for users, rights, roles, sessions, and remember-me tokens
  • Login, registration toggles, password reset, TOTP / email / SMS two-factor
  • Brute-force lockout and a login audit
  • Per-user IP firewall and URL firewall
  • Browser devices you can name and revoke
  • Groups (roles), module-scoped permissions, last-root protection
  • A database-driven sidebar with drag-and-drop ordering
  • Notifications in the navbar
  • An embedded AI assistant with a tool registry
  • A ZIP plugin installer that can install, update, and uninstall modules that keep the contract

Your job after that is a module: tables named {lowercase_modulename}_*, routes under the DACore URL prefix, rights, menu ids, optional AI tools. DACore already solved authentication. You still check your permissions in PHP on every persist.

The contract in one paragraph

A DACore plugin is not a random folder dump. The package must include dainstall.php, versioned Installation.php, and canonical copies of init/module.init.php and init/module.listeners.php. During install the module registers permissions with DACore:Rights@*, menu rows with DACore:Menu@register, and optional tools with DACore:AITools@register. Uninstall reverses the same rows and drops the module’s tables. The sample that shows the full loop is TestInstalatora — see how to write a DACore module.

AI-friendly from day one

The framework already ships AIRULES so Cursor, Claude, and GPT do not invent Laravel or Blade. DACore adds an overlay: docs 3037 plus Cursor rule 08-dacore.mdc. Together they tell the agent the hard laws that keep a plugin safe: do not edit DACore, do not write SQL into dacore_menu, use <fo-rm> and re-check rights in PHP, keep your own Middleware/Rights.php. That is why this module is suitable for AI-assisted coding. The rules are not a blog afterthought. They ship with the product. Full walkthrough: How AIRULES-DACORE keeps AI agents writing secure code.

Release status

DACore is in testing. Expect the public release around December 2026. This site describes the product so teams can plan modules against the contract now. There is no download of DACore from these pages yet. Do not treat the copy in a local workspace as a production package.

When it ships, you still install DotApp first. DACore then occupies an URL prefix (commonly /dacore or /admin from config) and, if you allow it, can claim site / for the admin home. Public sites keep their own modules. DACore is the administration workspace, not the whole internet.

What DACore is not

It is not framework core. Files under app/parts/ stay forbidden. DACore lives in app/modules/DACore/ and is updated as a complete package. It is not a multi-tenant “organization” table. Access is organized as permission groups (roles) plus module-scoped rights assigned to users. It is not a replacement for creating a normal DotApp module. You still scaffold with DotApper. DACore is the admin host those modules plug into when they need a desk, not a public page only.

FAQ

When can I download it?

The planned window is December 2026, after testing. These articles are the public specification, not a beta channel.

Do I still need DotApp?

Yes. DACore is a module. It needs the framework, app/config.php, and a MySQL database. It does not replace Router, Renderer, DSM, or fo-rm.

Can I build a public website without DACore?

Yes. Framework-only projects keep using install.php and AIRULES without the DACore overlay. Use DACore when you want the admin workspace.

Why mention AI in a product page?

Because the failure mode of an unconstrained agent is to patch the admin core. AIRULES-DACORE forbids that by default and points the agent at your module folder.

See also