Mf Laravel Package

Getting Started

First, verify what you're actually installing. The metadata points at pozoltd/mf while the linked repository is pozonz/mf — confirm which is live before investing time. Check the Packagist page, the composer.json require block (a December 2023 release most likely pins Laravel 9/10 illuminate/* constraints), and the repo's src/ tree for a service provider.

Install into a throwaway Laravel app first, not your main project:

composer require pozoltd/mf
php artisan vendor:publish   # interactive; pick the mf provider/tags
php artisan migrate

If auto-discovery doesn't fire, the provider is listed manually in config/app.php or under extra.laravel.providers.

Where to look first, in order:

1. The published config (config/mf.php or similar) — route prefix, middleware, content model classes, upload disk.
2. boot() in the service provider — this is the real table of contents for what URLs and bindings the package owns.
3. database/migrations/ — the schema is the API surface for a CMS: content types, pages, blocks, revisions.
4. src/Models/ — relationship graph, and critically whether models are final.

First use case worth proving: define one "page" content type, create a record in the admin, render it at a catch-all route, and load it in the browser. If that loop isn't working inside an hour, that is your answer about day-to-day leverage.

Implementation Patterns

Treat the package as the admin/content layer and keep your application as the renderer.

• Route ownership. Let the package own its admin prefix; keep public routes in routes/web.php and resolve content by slug in a controller or Route::fallback(). Register your routes first so the package's catch-all can't swallow them.
• Adapter layer. Build one repository class and one renderer class that touch PozoLtd\Mf\*. Everything else in your app depends on the adapter. This is the single highest-value pattern here — it makes the eventual swap a day's work instead of a rewrite.
• Model extension. If the package models aren't final, subclass them and rebind in a service provider. If they are, wrap them; never edit vendor/.
• Views over package views. Publish views and override in resources/views/vendor/mf/. Upgrades become a diff rather than a merge.
• Content types as config. Define types in config, not in hand-edited migrations — staging/prod drift on a CMS schema is miserable.
• Single render path. One render(Content $c) entry point dispatching to mf::types.{type} views. Adding a type is then a view plus a config entry.
• Media. Point the upload disk at S3 or a named disk in config/filesystems.php; don't leave it on public in production without storage:link in the deploy script.
• Cache reads. Wrap slug lookups in Cache::remember() and flush via a model observer on save. The package almost certainly does not cache for you.

Gotchas and Tips

• The metadata is the gotcha. Zero stars, zero dependents, no release since December 2023, and a repo URL that doesn't match the vendor name. Assume no security patches and no Laravel 11/12 support until you've verified otherwise. Read the illuminate/* constraints before committing.
• You inherit the schema. Once those migrations run, the tables are yours to maintain forever. Dump them and decide now whether you're comfortable owning them.
• Silent publish. If vendor:publish finds nothing, read register() and boot() directly — that's the entire manual.
• Route caching. Package routes using closures break under php artisan route:cache. Test that in CI, not just locally.
• Guards and middleware. Confirm the admin area uses your web + auth group and not its own guard. Mismatched guards are the most common "can't log into the CMS" failure.
• Frontend assets. If it ships JS/CSS, check whether it publishes to public/vendor/mf and wire that into your build — otherwise the admin 404s in production.
• Debugging order: php artisan route:list --path=admin, php artisan about, then tinker against the content model. Faster than reading source for most questions.
• Extension points to confirm: model-class overrides in config, events on content save, and a view namespace. If none of the three exist, don't adopt — fork it into app/ as first-party code or use a maintained alternative (Filament plus a Page model, Statamic, Twill).
• Pragmatic recommendation: given the maintenance signals, "using" this package most defensibly means forking the useful parts into your own codebase and owning them. Adopting it as a live Composer dependency is a bet the maintainer returns.