Laravel Admintw Laravel Package

Getting Started

• Install with composer require dcblogdev/laravel-admintw, then run the package's publish command(s) to expose config, views, and compiled assets (check the service provider's $this->publishes() tags — typically config, views, and public assets). Follow with php artisan migrate if you're using the bundled user/auth tables.
• Look first at the package's route file and the published Blade views. That's where the package's conventions live: layout to extend, component names, form partials, and the admin route prefix/guard. Read those before writing any admin screens.
• First use case: boot the app, visit the configured admin entry point (commonly /admin), complete registration/login, and confirm you land on the dashboard. That single flow exercises routing, auth guard, layout, form components, and asset pipeline in one pass — if it works, the package is wired correctly.
• In v6.0.3 specifically, verify the registration flow end-to-end (the modal close event was fixed) and open a CKEditor-backed form to confirm the editor loads and image upload works before building on it.

Implementation Patterns

• Extend, don't edit vendor. Publish views once, then treat them as your app's views. Build admin pages by extending the package layout and reusing its Blade components rather than hand-rolling Bootstrap markup — this keeps you compatible with package upgrades.
• CRUD via modals. The v6.0.3 modal close event fix means you can drive create/edit forms in modals and rely on the close event to reset state and refresh lists. Pattern: trigger modal from an index table row, submit via the package's form components, listen for the close event to reload the datatable or clear validation errors.
• Rich text with CKEditor 5. Bind the editor to your textarea through the package's component/field. Image upload is now handled by CKEditor 5's upload adapter — configure the upload endpoint (or storage disk) in the published config and point the editor's image upload at it. Use this for any content model (posts, pages, product descriptions) instead of manually integrating CKEditor.
• Dynamic selects. The enhanced select component now supports dynamic data. Pattern: pass a data source (route/URL or closure) to the select component and let it populate options asynchronously — useful for country/city, category, or user pickers that are too large to inline. Error states are surfaced through the component now, so pair it with standard Laravel validation and render @error blocks consistently.
• Auth scaffolding. Use the package's registration/login controllers as the baseline, then override routes/controllers via config or route registration if you need custom onboarding (invites, roles, email verification). Keep registration inside a modal where the flow allows — that's the path the release explicitly hardened.
• Error pages. The 403 layout was refactored; if you brand error pages, publish and extend the new structure rather than copying the old markup, so future refactors are easier to absorb.

Gotchas and Tips

• CKEditor 4 → 5 is a config migration, not a drop-in. Toolbar config, plugin list, and event names differ. Any custom CKEditor 4 plugin or CKEDITOR.replace() call will not work; rebuild configuration against the v5 API and re-test paste, source, and image upload. Budget time for this if you had customized the editor.
• Image upload needs the full chain. Storage disk + php artisan storage:link, an authenticated upload route, validation (mime/size), and correct CSRF handling. A silently failing upload is almost always a 419 (CSRF) or a 401 on the upload endpoint — check the network tab before touching editor config.
• Dynamic select expects a specific payload. Confirm the JSON shape your endpoint returns matches what the component consumes; mismatches show up as an empty dropdown with no error. Also ensure the endpoint is behind the right middleware so it doesn't 302 to login and return HTML where JSON is expected.
• Remove modal workarounds. If you previously hacked around the modal close event (manual hidden.bs.modal triggers, custom reset scripts), delete them after upgrading — they'll now double-fire and can cause flicker or stale form state.
• Re-publish views after upgrading. The 403 page and UI fixes change markup; if you've overridden those views you won't see the fixes, and if you re-publish blindly you'll overwrite your customizations. Diff before republishing.
• phpstan fixes are internal but touch code. Low risk, but run your test suite and click through auth/registration after upgrading; static-analysis cleanups occasionally alter null-handling or return types in edge paths.
• Pin the version in CI. As a 6.x patch release, keep ^6.0 and rely on the changelog; if you're not ready to migrate CKEditor configs, constrain below the release that introduced v5 until you've tested.