Content Module Laravel Package

Getting Started

1. Confirm Badaso is installed first. badaso/content-module is an add-on, not a standalone package. You need a working Badaso admin (badaso/core) on a Laravel 8/9/10 app — and now Laravel 11 as of 2.2.0 — with the admin panel reachable at /badaso-dashboard before this module does anything useful. If you're on Laravel 11, pin badaso/content-module to ^2.2 and check that your badaso/core version also supports Laravel 11, since the two must move together.
2. Install via Composer alongside the core modules:

   composer require badaso/content-module
   

   Then run the module installer so its migrations, seeders, and menu entries register:

   php artisan badaso:setup content-module
   php artisan migrate
   php artisan db:seed --class=BadasoContentModuleSeeder
   

   (Command names have shifted between Badaso versions — check php artisan list | grep badaso and the module's README if badaso:setup doesn't accept the module slug in your version.)
3. Look first at src/ and database/migrations/ in vendor/badaso/content-module — the migration files are the fastest way to learn the data model (content types, content entries, and their relationships), and src/Routes/ shows the API surface you can call from a frontend.
4. First use case: log into the Badaso dashboard, create a Content Type (e.g., blog_post with fields title, slug, body, image), then add a Content entry against it. That two-step flow — define schema, then author entries — is the whole point of the module.

Implementation Patterns

• Content modeling is schema-first. Treat the dashboard as a CMS schema editor: define content types with fields once, then bulk-create entries. Build the frontend against those fixed shapes rather than reading arbitrary JSON at runtime.
• Reading content from Blade / controllers. Use the module's Eloquent models (or the repository classes it registers) to fetch published entries, scoping by content type slug:

  $posts = \Badaso\Module\Content\Models\Content::query()
      ->whereRelation('contentType', 'slug', 'blog_post')
      ->where('status', 'published')
      ->latest()
      ->paginate(12);
  

  Verify exact class namespaces against src/Models/ — the module has been renamed across versions.
• Headless consumption. The module exposes REST endpoints (typically under /api/v1/content/...). Use those endpoints when a separate SPA/mobile app consumes the CMS, and skip writing your own controllers. Inspect src/Routes/api.php for the actual URIs.
• Seeding for reproducible environments. Rather than clicking through the dashboard on every deploy, put content types and seed entries into your own seeder that calls the module's models/factories. This is the only reliable way to keep dev/staging data parity with a 2-star module.
• Frontend integration. Point Blade views or your JS fetch layer at the module's public content endpoints; cache responses (Redis or Cache::remember) since the module does not ship aggressive caching and content reads happen on most pages.

Gotchas and Tips

• Very low adoption (2 stars, no dependents). Expect sparse docs, no Stack Overflow trail, and unannounced breaking changes between minor versions. Pin an exact version in composer.json ("badaso/content-module": "x.y.z") and vendor-lock it.
• Coupling to badaso/core. Version mismatches between core and this module are the most common failure mode. If the dashboard menu item or migration throws after install, check the badaso/core version constraint in the module's composer.json first. The 2.2.0 Laravel 11 bump makes this sharper than ever: the module now supports Laravel 11, but you need a Laravel-11-compatible badaso/core too, or you'll get a half-working install.
• Migrations are module-owned. Running php artisan migrate after a composer update may pull new schema changes with no upgrade path documented. Take a DB dump before every module update. 2.2.0 touched the badaso_content_setups table (marking it hidden) — cosmetic, but confirm your setup records survived the upgrade if you're coming from 2.1.x.
• Menu/permission registration. If the module appears in composer.json but not in the sidebar, the seeder didn't run or the permissions didn't attach to your admin role. Re-run the module seeder and check badaso_menus / badaso_permissions tables. Note that the setup table is now hidden from the admin UI in 2.2.0 — if you relied on seeing it in the dashboard for troubleshooting, query it directly.
• Debugging entry issues. Content entries are stored with dynamic field payloads; when a field looks empty on the frontend, check the content type's field definition (type, validation, required) — malformed field configs silently drop values. Log the raw entry JSON before rendering to confirm what was actually saved.
• Extension points are thin. Prefer wrapping the module's models in your own repository/service classes over extending its classes directly, so a future update that renames internals only breaks one layer. For anything complex (versioning, workflows, i18n), assume you'll build it yourself on top.
• No active maintenance signals — but slightly improving. 2.2.0 adds a first-time contributor and Laravel 11 support, which is a positive signal after a long quiet stretch, but the release is still StyleCI housekeeping plus framework plumbing — no feature work. Budget time for reading source rather than documentation, and consider whether badaso/core's built-in CRUD generator covers your need before pulling in this extra package.