Mela Cms Laravel Package

Getting Started

composer require melasistema/mela-cms:^0.12.1
php artisan vendor:publish --provider="MelaSistema\MelaCms\MelaCmsServiceProvider"
php artisan migrate

1. You are jumping four minor lines. If you are on 0.9.1 (the last version covered by the previous assessment), v0.12.1 lands you across 0.10, 0.11, 0.12.0, and 0.12.1. Only the 0.12.1 patch note is reproduced here — read the changelog for 0.10.0, 0.11.0, and 0.12.0 in full before upgrading, since on a 0.x line every minor may break. Do not treat this as a drop-in patch.
2. The Packagist install fix from 0.9.1 still holds. No GitHub token is required. If you carried auth.json, github-oauth config, or a repositories block pointing at the VCS URL, remove it and re-run composer install to confirm you are clean.
3. Look first at the published config/mela-cms.php — it remains the single place describing content types, route prefixes, middleware, and storage/disk settings. Read it before the source; it is the intended entry point.
4. First use case: scaffold one content type, publish a record through the admin, and render it on a front-end route. That exercises migrations, config, routing, and the view layer in one pass and is the fastest way to validate the install.

Verify with php artisan about and php artisan route:list --path=<your-cms-prefix>. Then hit / — see the Gotchas entry on the root placeholder, because 0.12.1 deliberately changes what / returns.

Implementation Patterns

Pin and lock deliberately. Four minors of drift in one upgrade is exactly the scenario 0.x semver allows. Pin ^0.12.1, commit composer.lock, and treat 0.13.0 as a review-required upgrade with a changelog read and a test run.

Clean CI install. Unchanged from 0.9.1 — no token secret, no composer config github-oauth.github.com:

- run: composer install --no-interaction --prefer-dist --no-progress

If you maintain a private mirror or a repositories block pointing at the GitHub VCS URL, remove it; leaving it in place forces Composer back to a git clone and reintroduces the token requirement.

Upgrade in a branch, not on main. Because you are crossing several minors at once, run composer update melasistema/mela-cms --with-dependencies on a throwaway branch, boot the app, and run your existing suite before touching application code. Diff the published config and any published views against what you have locally — this is the single highest-value step for a multi-minor jump.

Content modelling over controller sprawl. Define content types and fields in config (or the package's model layer) and let the package own routing and rendering. Keep custom business logic in your own service classes and hook them in via events or by binding implementations in a dedicated CmsServiceProvider in your app, rather than editing published files.

Own the root route if you care about /. Since 0.12.1 the package answers the root placeholder with a 200 rather than letting the stock Laravel 404 through. If your app defines its own / (landing page, redirect, health probe), register it explicitly and confirm which one wins with php artisan route:list --path=/. Do not rely on the package's placeholder as a not-found signal.

View overrides. Publish views to resources/views/vendor/mela-cms and override only what you need. This survives package updates and keeps the upgrade diff small — still the most important habit on a 0.x line.

Separate CMS data from app data. Use a distinct database connection or at minimum distinct migration paths for CMS tables so you can seed, truncate, and restore CMS content in tests without touching application tables.

Test against a migrated database. Use RefreshDatabase plus a fixture of one content type and one record; assert the front-end route resolves and the rendered output contains the record's title. Add an explicit assertion for the root path so a future change to placeholder status codes fails loudly instead of silently.

Gotchas and Tips

• Root path status code changed in 0.12.1. The placeholder at / now returns 200 so the stock Laravel test passes. Any test asserting assertNotFound() on /, any uptime monitor keyed on a 404, and any SEO/canonical logic that assumed "no content = 404" will now behave differently. Fix by overriding the route or by pointing monitoring at a path you control.
• Multi-minor upgrade, single-line release note. The 0.12.1 note describes one commit. It tells you nothing about 0.10.0–0.12.0. Treat the changelog for those tags as required reading; if it is thin, diff the published config and run the suite on a branch before merging.
• Stale Composer state. If you installed an older line via the GitHub VCS, your composer.lock may still record a source of type git. composer update melasistema/mela-cms --with-dependencies rewrites the lock to the Packagist dist; composer clear-cache if you see old archive warnings.
• The token fix is install-time, not runtime. Persistent deploy failures are almost always a leftover repositories override, a global ~/.composer/auth.json, or a CI cache of vendor/. Debug with composer why melasistema/mela-cms and composer install -vvv, and read the URL it actually fetches.
• Never commit auth.json. If one exists for the old install path, remove it and rotate the token — it is pure liability now.
• Stale config cache. After publishing or editing config/mela-cms.php, run php artisan config:clear locally. In production config:cache is part of deploy; a stale cached config is the most common cause of "my new content type doesn't appear," and it is especially likely right after a multi-minor upgrade.
• Migration order. Publish and run the package migrations before your own CMS-dependent migrations. On fresh CI databases this is usually fine; on long-lived databases, php artisan migrate:status will reveal out-of-order batches — check it explicitly after crossing 0.10–0.12, where new migrations are plausible.
• Asset publishing is a separate tag. vendor:publish --tag=views, --tag=config, and --tag=assets are independent; running only the provider-wide publish may not refresh compiled assets.
• Extension points to prefer: events emitted around content create/update, custom field/block types registered in config, and container bindings for storage or rendering. Subclassing vendor classes directly is the least upgrade-safe option on a 0.x line.
• Pre-1.0 expectation setting. Budget a review pass per minor release: read the changelog, run the suite, diff the published config. This release is a single low-risk commit on its own, but it arrives bundled with three unreviewed minors — so the risk is in the gap, not the patch.