Badaso Content Module Laravel Package

Getting Started

This is a Badaso CMS module, not a standalone package. It must be installed alongside uasoft-indonesia/badaso (the core) — installing it on its own will leave you with an unregistered provider and no admin UI to drive it.

1. Install the core CMS first, then the module:

   composer require uasoft-indonesia/badaso
   php artisan badaso:install
   php artisan badaso:admin [email protected]
   composer require uasoft-indonesia/badaso-content-module
   

2. Publish and migrate (the module ships its own migrations and assets):

   php artisan vendor:publish --tag=badaso-content-module
   php artisan migrate
   

3. Where to look first — config/badaso-content-module.php (if published), the package's src/Providers/*ServiceProvider.php to see what it registers (routes, menus, migrations, seeders), and src/Models/ to understand the entity/field tables it owns.
4. Log into /admin, find the Content menu entry, and create your first content type with a couple of fields. That's the canonical first use case: define a schema in the UI, let the module generate the backing table + CRUD, then hit the auto-generated API endpoint.

If it works end-to-end in the admin panel but you can't see the API route, that's a routing/middleware registration issue, not a content problem — check core's badaso.api config and the module's route file.

Implementation Patterns

Schema-as-configuration. The core workflow is: create a Content Type → add Fields → the module provisions a physical table and a CRUD entry. Treat the UI as a migration generator, and immediately capture the resulting schema in a seeder or a checked-in dump so a fresh environment can be rebuilt without clicking through the panel.

Programmatic seeding of content types. For repeatable environments, seed content types and fields via the module's models (or core's CRUD model) inside a dedicated seeder, rather than relying on production data dumps. Wrap it in firstOrCreate calls keyed on the content-type slug so re-running the seeder is idempotent.

API consumption. Generated CRUDs are exposed through the core's API layer (typically versioned under /api/v1/...) behind Badaso's auth middleware. Consume them from a separate frontend rather than mixing admin and public concerns — and check whether a given content type is flagged public or requires a token before you build your client around it.

Extending with custom fields. When the built-in field types don't cover a case (e.g. relational pickers, media with transforms), the extension point is a custom field type registered through the module's field-type registry/component system, not a fork. Keep custom field logic in your own package so upgrades stay clean.

Hooking into lifecycle events. For anything that must happen after a content entry is written (search indexing, cache busting, webhooks), prefer the model/CRUD events emitted by core over overriding controllers. This keeps you compatible across minor releases.

Multi-environment installs. Because the module ships menus and permissions via seeders, your deploy pipeline should include the module's seed step (db:seed --class=...) — otherwise a fresh staging box has tables but no admin menu entries, which is a confusing first-run experience.

Gotchas and Tips

• Laravel 11 support is new in 2.2.0. This is the headline change in this release (along with a hidden setup table and StyleCI fixes). Before upgrading an existing install, confirm your badaso core version also supports Laravel 11 — the module's constraint alone is not sufficient, and a version mismatch surfaces as cryptic container/middleware errors at boot rather than a clean composer conflict.
• Never edit files in vendor/. Migrations, config, and Vue assets all originate there. Override via published config, published views/assets, or a subclass in your app. Upgrades will silently wipe vendor edits.
• Publishing tags are easy to get wrong. The publish tag in the core install command differs from the module's tag. If your config file never appears, run php artisan vendor:publish interactively once to discover the actual tag names the module registers.
• Hidden system tables. 2.2.0 adjusts which setup table is hidden from the admin CRUD listing. If you had bookmarked or scripted against that table's admin route, re-verify after upgrading — hiding is usually cosmetic, but any hardcoded URL will 404.
• Migration ordering. Module migrations must run after the core's. On existing databases, php artisan migrate alone may not apply the hidden-flag change if it's delivered as a config/seeder update rather than a schema change — check the release diff if the UI doesn't reflect it.
• Asset cache. After upgrading, admins commonly see the old UI because published JS/CSS wasn't refreshed. Re-publish assets and clear view:clear + browser cache.
• Permission drift. Content types created in production are invisible to roles that only exist in your seeder-defined permission set. Whenever you add a content type, add the corresponding permission entries to your seed data, or non-superadmin users will get 403s on the generated endpoints.
• Debugging content entries. When an API write fails validation, the error originates from the dynamically generated CRUD config, not your code. Inspect the CRUD record's field definitions (required/min/max/type) before debugging your controller.
• Release cadence is low and the changelog is thin. Commit messages are contributor-driven and sometimes non-descriptive ("update ... tabel hidden"). Before jumping onto a minor release, skim the compare diff for config and migration changes rather than trusting the summary; pin exact versions in composer.json and upgrade deliberately.

Bottom line: 2.2.0 is a compatibility release whose value is Laravel 11 support. It's a safe upgrade for most installs, with the caveats above around core-version alignment, re-publishing assets, and verifying any admin routes that touched the now-hidden setup table.