badaso/post-module
Post module for Badaso, the Laravel-based headless CMS. It adds post management to your admin panel—create, edit, list, and publish content—and exposes it through Badaso's API so frontends can consume posts alongside your other CMS data.
Minimal install steps
Badaso modules are not standalone packages — they require badaso/core (admin panel), and for headless usage, badaso/api-module.
composer require badaso/core badaso/post-module
As of 2.4.0 the post module carries an updated badaso/core constraint, so composer require will resolve a core version chosen by the module rather than by you. Pin both explicitly ("badaso/core": "x.y.*", "badaso/post-module": "^2.4") before the first install, not after.
Then publish the module's config, migrations and assets. Tag names are module-specific, so list them first rather than guessing:
php artisan vendor:publish # find the badaso/post-module tags
php artisan vendor:publish --provider="Uasoft\Badaso\Module\Post\Providers\BadasoPostModuleServiceProvider"
php artisan migrate
Register the module so the admin UI picks it up — Badaso modules are recorded in badaso_modules and wired into the sidebar via badaso_menus. Either use Admin → Modules → Add Module in the panel, or re-seed badaso/core. Then grant the new permissions under Admin → Roles (Badaso permissions are namespaced, typically badaso_post_* — browse / create / read / update / delete).
Where to look first
database/migrations/ in the vendor package — this is the ground truth for the schema (posts, post_categories, post_tags, pivot tables, and whether comments exist). The docs are thin for a 3-star package, so read these before designing around it.config/badaso-post-module.php — table names, route prefixes, middleware, upload paths.src/Models/Post.php (or similarly named) — fillable fields, relationships, status enum.routes/ — the module ships both web (admin Vue) and API routes; know which prefix your front-end will hit.First use case
The intended path is: create a post in the Badaso admin (title, slug, content via the built-in editor, cover image via Badaso's media manager), set status to published, then consume it from a Nuxt/Next/Blade front-end through the API module (/api/v1/posts, /api/v1/posts/{slug}) or directly via Eloquent if your front-end is the same Laravel app.
Headless blog (most common)
Enable badaso/api-module, register the public post routes if they ship disabled, and point a JS front-end at them. Use the status/published-at fields to filter; do not rely on the admin UI alone — verify what the API serializes by hitting the endpoint with ?limit=1 before wiring your front-end.
Server-rendered site in the same app
Skip the API entirely and query the module's model:
use Uasoft\Badaso\Module\Post\Models\Post;
$post = Post::where('slug', $slug)
->where('status', 'published')
->firstOrFail();
Add a local scope in your own repository/service class rather than editing vendor code — Badaso modules are Composer packages and edits vanish on composer update.
Extending the module
Preferred integration points, in order:
config/badaso-post-module.php (table names, route prefix, per-page limits).AppServiceProvider if the module type-hints the interface rather than the concrete class. Verify by reading the controllers.database/migrations/ — these are now yours to own. Add SEO columns, translations, or soft-delete flags there.saved/deleted on the Post model to hook sitemap regeneration, cache invalidation, or revalidation webhooks (useful for Next.js ISR).Workflow: draft → schedule → publish
Model status as an enum in your own code even if it is a string column. Most Badaso modules store status as a plain string; enforce a whitelist in a Form Request before saving, because the admin UI is the only guard otherwise.
Multi-tenant / multi-site
Isolate by adding a site_id column in your published migration and applying a global scope in a subclass. This package makes no assumptions about tenancy, so you must do it yourself.
Blade + Vite admin coexistence
The module's admin assets are pre-built into public/. If you run npm run build for your own front-end, do not clean public/vendor/badaso — use a separate output directory.
Version drift against badaso/core — now the main risk. 2.4.0's only change is "update badaso core", i.e. the module's core constraint moved. That means a routine composer update badaso/post-module can silently drag badaso/core (and with it the admin UI, menu registration, and Blade components) to a new version. Lock both packages in composer.json, upgrade them as a pair in a branch, and re-run php artisan route:list and a manual admin login afterwards. Treat the post module's composer.json constraints as the thing to read before bumping either package.
No feature changes in 2.4.0. There are no new fields, routes, config keys, or migration changes documented — just the dependency bump and a first-time contributor (@TaufiqTzy). If you were hoping a release would add translations, comments, or SEO support, it did not. Any code you have already written against 2.3.x should continue to work; the upgrade is a dependency-resolution exercise, not a feature migration.
Permission cache. After adding or renaming permissions, Badaso caches them. Run php artisan cache:clear and php artisan config:clear, otherwise you will get inexplicable 403s from the admin UI routes. Also confirm the permission rows actually exist in badaso_permissions — the module's seeder is sometimes skipped.
Route collisions. The module registers posts / post-categories style routes. If your app already has a /posts or an API version prefix collision, either rename the module's prefix in config or namespace your own routes. Check php artisan route:list | grep post right after install.
Migration table names. If you have an existing posts table, publishing migrations will either collide or rename with a prefix depending on the config. Publish to a scratch directory first, read the file, then move it into database/migrations/.
Vendor-published assets vs. source. Editing anything under vendor/uasoft-indonesia/badaso-post-module/ is throwaway. Everything you must change should flow through config, a published migration, a bound subclass, or an event listener.
No i18n out of the box. For a multi-language news site you will be adding post_translations yourself. Do not expect the admin editor to give you per-locale tabs.
Thin ecosystem. Three stars and zero dependents means: no Stack Overflow answers, no third-party tutorials, and the README is your only doc. Budget time to read the source. The upside is that the source is small — a couple of controllers, one model, a handful of migrations — and reading it end-to-end takes under an hour.
Debugging a broken admin page. Open DevTools → Network and look for a 404 on the compiled JS chunk. Badaso serves module assets from public/vendor/badaso/...; if vendor:publish --tag=badaso-assets was never run, the page loads blank with no PHP error. Also check badaso_menus for a row with a URL that matches an actual registered route.
Upgrade path. Latest release is 2.4.0 (dependency bump on top of the 2025-06-30 2.3.3 release); treat the package as lightly maintained. Fork it into your own VCS ("repositories" in composer.json) before you need to patch it, so a future abandonment — or an unwanted core bump shipped as a patch release — does not block your releases.
When to skip it. If your requirements are just "a blog," the module's value is the admin CRUD + editor. If you are already comfortable with Filament or Laravel Nova, building a Post resource yourself will take about the same time as debugging this module's wiring, and you avoid the core-version coupling.
How can I help you explore Laravel packages today?