Core Module Laravel Package

Getting Started

This is not a standalone package — it is a sub-package of AsgardCMS. With 3 stars and 0 dependents, it exists as an internal building block of the asgardcms/platform meta-package. You will almost never composer require idavoll/core-module directly; instead you pull it in transitively:

composer create-project asgardcms/platform my-site

The module lands under Modules/Core/ (not vendor/idavoll/... in the normal sense — AsgardCMS copies module code out of vendor into the app's Modules/ directory so it can be customized in place). Look there first.

Where to look first, in order:

1. Modules/Core/Config/core.php and config/permissions.php — the settings registry and gate permissions.
2. Modules/Core/Providers/CoreServiceProvider.php — what binds, what publishes, what loads.
3. Modules/Core/Database/Migrations/ — the settings, menus, widgets tables that everything else assumes.
4. Modules/Core/Resources/views/admin/ — the dashboard scaffolding you'll extend.

First use case: getting the admin panel's sidebar menu and settings to render your own module. The Core module owns the Menu and Setting repository contracts (from nwidart/laravel-menus and asgardcms/settings). Your day-one task after install is usually "register my module's admin link in the sidebar and expose a settings group," and both are done through the Core module's contracts, not raw Laravel config.

Implementation Patterns

Module manifest registration. Every module, including Core, ships a module.json consumed by nwidart/laravel-modules:

{
    "name": "Blog",
    "alias": "blog",
    "providers": ["Modules\\Blog\\Providers\\BlogServiceProvider"],
    "requires": ["Core"]
}

Core is the one module everything else should list in requires. If you fork or rename it, module autoload breaks.

Settings via the Settings contract, never config(). Core's job is to persist runtime-editable values. The pattern is:

use Modules\Core\Contracts\Setting;

$setting = app(Setting::class);
$setting->get('core::site-name');
$setting->set('core::site-name', 'My Site');

Note the module::key namespaced convention. Store settings under your module's namespace and group them in the admin Settings screen by adding to your module's config/settings.php (or permissions.php for the gate).

Sidebar menu contribution. Register admin navigation from your module's service provider boot():

menu()->create('admin', function ($menu) {
    $menu->add('Blog', ['route' => 'admin.blog.post.index'])
         ->data('icon', 'fa-newspaper');
});

Core exposes the menu() helper; the admin layout reads this collection to build the sidebar tree. Ordering is controlled via ->data('weight', n).

Dashboard widgets. Extend Modules\Core\Widgets\Widget and register it in config/widgets.php (or via the boot hook). Widgets receive a $params array from the dashboard config — treat it as untrusted and validate before rendering.

Permissions and roles. Core wires Sentinel for auth. Guard admin routes with the can: middleware and permissions registered in your permissions.php:

$router->group(['middleware' => 'can:blog.posts.index'], function ($router) { ... });

Permissions are seeded via php artisan module:seed Core. If you skip this, every admin route 403s — a very common first-run failure.

Asset publishing. Core defines named asset collections (admin.scripts, admin.styles) via asgardcms/asset. Add your JS/CSS with asset()->add('admin.scripts', 'modules/blog/js/app.js') in boot; do not edit Core's views to hardcode <script> tags.

Gotchas and Tips

License is NOASSERTION. This is a real blocker for compliance review — the SPDX field could not be resolved from the repo metadata. Confirm the actual license in the repository before shipping commercially; the absence of a recognized identifier is not the same as permissive.

It's a monorepo artifact. The near-zero star count and 0 dependents are misleading: Core is consumed by asgardcms/platform, which is the package people actually install. Don't read the low numbers as "abandoned," but do check commit recency on asgardcms/platform before committing — Core tracks that project's Laravel version support (historically pinned to older Laravel/Sentinel majors; large version jumps are not trivial).

Never edit vendor; edit Modules/Core/. AsgardCMS copies modules out of vendor/ on install. If you edit vendor/idavoll/core-module, the next composer update wipes it. If Modules/Core is missing, run php artisan asgard:install or the module publish command to materialize it.

Cache is aggressive. After adding a menu item, widget, or setting group: php artisan cache:clear && php artisan config:clear. Core caches the menu tree and settings lookups; stale menus after a failed boot are the #1 "my link disappeared" report.

Migration ordering matters. Core's migrations create settings, menus, widgets, and translations tables. Any module migration with a foreign key into settings must sort after Core's timestamps or use Schema::withoutForeignKeyConstraints — Laravel won't know Core's ordering for you.

Sentinel coupling. Core's admin user resolution assumes Sentinel::getUser(). If you're building a modern Laravel app and replaced auth with Auth::user(), the admin dashboard, menu permission checks, and widget context will silently return null. Check Modules/Core/Providers/ for the auth bindings before integrating.

module.json schema is strict. A malformed requires array or a provider class typo produces a generic "Module not found" with no stack trace. Enable APP_DEBUG=true and run php artisan module:list to see what actually parsed.

Extension point: override Core views and routes by publishing them into your app, then re-point the route in your own service provider rather than patching the module. Core's views are designed to be overridden via asgardcms/theme view namespaces (core::admin.dashboard.index → your theme's admin/dashboard/index.blade.php).