badaso/content-module
Badaso content module adds structured content management to the Badaso Laravel headless CMS. Create content types and entries, manage them from the admin dashboard, and serve them through APIs to any frontend or mobile app. Includes CRUD operations and API endpoints.
Architecture fit. badaso/content-module is not a standalone Laravel package in the conventional sense — it is a plugin for the Badaso headless CMS/admin framework (also maintained by uasoft-indonesia). Its architecture is therefore inseparable from Badaso core: it registers entities and migrations through Badaso's module manifest, exposes admin CRUD screens through Badaso's Vue-based dashboard, and depends on Badaso's permission and menu systems. Fit is binary — if you have already adopted Badaso as your content/admin layer, this module is a natural extension; if you are on stock Laravel, adopting it means adopting Badaso wholesale. The 2.2.0 release does not change this: it is a maintenance/compatibility release, not an architectural one.
Integration feasibility. Low-to-moderate for teams already inside the Badaso ecosystem; high friction otherwise. The module's surface is mostly migrations, seeders, model/controller registration, and admin UI hooks, which is straightforward for a Laravel engineer to read and modify. The real cost is the transitive commitment to Badaso core, its frontend build, and its versioning cadence. 2.2.0 adds Laravel 11 support, which materially widens the addressable stack — but that support is only real if Badaso core itself ships a Laravel 11-compatible release, and that pairing is the thing to verify before planning an upgrade.
Technical risk. The dominant risk remains adoption and bus factor, not code quality: still ~2 stars, 0 dependents, single-vendor maintenance. Signals improved slightly with 2.2.0: an active release cadence, a Laravel 11 compatibility PR, and a first-time outside contributor (@TaufiqTzy). That last point is a genuine positive but should not be over-read — one drive-by contributor is not a community. Secondary risks are unchanged and now sharper: tight coupling to Badaso core version (this release explicitly tracks Laravel 11, so core must track it too), undocumented schema that becomes your content source of truth, and an admin surface that is a security-sensitive attack vector. Note also that 2.2.0 ships a migration/setup-table change ("update badasocontentsetup tabel hidden"), which is a schema-touching edit in a minor version — verify the diff before applying to an existing install.
Key questions.
composer.json?badasocontentsetup table in 2.2.0 — is it a column/visibility change, and is it idempotent on existing databases?Stack fit. Assumes Laravel (Badaso's supported versions, now including Laravel 11 as of 2.2.0), PHP matching Badaso core, Composer for installation, and Badaso's Vue/Node build pipeline for the admin UI. If your stack already runs Badaso, this is a Composer require plus module registration — clean fit, and 2.2.0 makes a modern Laravel 11 stack viable where 2.1.x would have blocked it. If you are not on Badaso, the fit is still poor and you should evaluate whether you actually want Badaso as your CMS before evaluating this module.
Migration path. Greenfield is strongly preferred: stand up Badaso core plus this module on a fresh Laravel app — and on greenfield, start at 2.2.0/Laravel 11 rather than back-porting. Brownfield retrofit requires introducing Badaso core into an existing application, which touches routing, auth, admin layout, and asset builds — treat that as a separate, larger decision. Data migration off the module later should be planned for up front: keep content exportable via a thin service layer rather than letting controllers talk to module models directly. For anyone already on 2.1.x, treat the 2.1.1 → 2.2.0 hop as a small but real migration: review the badasocontentsetup change, confirm the Laravel constraint shift, and test against a database snapshot.
Compatibility. Pin both Badaso core and the module to exact versions and verify the Laravel/PHP matrix against your runtime — now a three-way constraint (module 2.2.0 ↔ Badaso core with Laravel 11 support ↔ Laravel 11.x). Because the module is version-coupled to core, an unpinned ^ constraint here is an operational hazard, not a convenience; with a Laravel major version now in the matrix, a loose constraint can silently pull you across a framework upgrade.
Sequencing.
badasocontentsetup change and confirm it applies cleanly and repeatably to an existing database.Maintenance. Expect to own this code eventually. With one maintainer organization and negligible community, plan for a vendored fork or an internal patch queue. Budget effort for each Badaso core bump, since the module must track core migrations and manifest changes — 2.2.0 is a concrete example of why: a Laravel 11 rollout and a setup-table migration arrived together in a minor version. The recent release cadence buys you time; it does not buy you a support contract.
Support. Community channels only, likely centered on Badaso's own docs and Indonesian-language resources. No SLA, no commercial backing evident from the repository. Ramp-up cost for new engineers includes Badaso's module conventions and Vue admin patterns — non-trivial and poorly documented outside the core project.
Scaling. Content CRUD and reads scale like any standard Laravel/MySQL workload; the module is not the bottleneck. Watch database schema coupling (content tables become load-bearing), admin asset payload, and any N+1 patterns in Badaso's listing screens. Horizontal scaling of the app tier is unaffected; caching should sit in front of your own service layer, not inside module models. A Laravel 11 baseline is a modest operational plus — longer framework security support than an older pinned runtime.
Failure modes. (a) Badaso core introduces a breaking change and the module lags — your upgrade path stalls; the Laravel 11 support in 2.2.0 is only useful if core matches it. (b) Package goes dormant and a security issue lands in the admin surface with no patch. (c) Schema assumptions leak into your application code, making exit expensive. (d) Rich-text/file-upload content introduces stored XSS or unrestricted upload if Badaso's defaults are not hardened. (e) New in 2.2.0: a schema-touching change in a minor release that behaves differently on existing vs. fresh databases.
Ramp-up. One to two weeks for a Laravel-fluent engineer to become productive in Badaso conventions and this module's data model; add another week for the admin build and deployment pipeline. Mitigate by assigning a single owner early, documenting the schema contract in your own repo, and writing integration tests at your wrapper boundary rather than against module internals.
How can I help you explore Laravel packages today?