Coreui Templates Laravel Package

Getting Started

What you're actually installing. This is not a runtime library — it's a set of Blade view stubs, layouts, partials, locale files, and CSS/JS assets that infyomlabs/laravel-generator renders when it scaffolds CRUD. Almost nothing happens at request time; the value is entirely in what gets written to resources/views and public/ during generation.

Minimum viable setup:

composer require infyomlabs/laravel-generator infyomlabs/coreui-templates
php artisan vendor:publish --provider="InfyOm\Generator\InfyOmGeneratorServiceProvider"
php artisan vendor:publish --provider="InfyOm\CoreUITemplates\CoreUITemplatesServiceProvider"

Then in config/infyom/laravel_generator.php point the template source at this package:

'templates' => 'coreui-templates',

Clear caches before you generate anything, because the template path is read from config:

php artisan optimize:clear

Where to look first, in order:

1. vendor/infyomlabs/coreui-templates/resources/views/ — the layouts, common/, and per-CRUD stubs. Read the layout before generating; it defines the sidebar, navbar, breadcrumbs, and where @yield('content') lands.
2. config/infyom/laravel_generator.php — templates, model_path, api_controller, paginate, and the localized/locales keys that the v1.0.3 release note ("Added missing locale files") is about.
3. vendor/infyomlabs/coreui-templates/resources/assets/ — the CoreUI CSS/JS you'll publish to public/.

First use case — prove the pipeline end to end with a throwaway model before touching a real one:

php artisan infyom:scaffold Post \
  --fieldsFile=fields.json \
  --datatables=true \
  --paginate=15

fields.json:

[{"name":"title","type":"string","required":true},
 {"name":"body","type":"text"}]

Then php artisan route:list | grep posts, log in, and confirm the CoreUI layout renders: sidebar present, Bootstrap grid intact, flash messages styled, pagination controls visible. If the page renders unstyled, the asset publish step failed — fix that before writing feature code, because everything downstream inherits the same broken asset references.

Implementation Patterns

Pattern 1 — Generate once, then own the views. Don't edit files in vendor/. Generate a resource, run php artisan infyom:publish (or the vendor publish tag for views) to copy the stubs into resources/views, commit them, then switch config to a local stub directory:

// config/infyom/laravel_generator.php
'templates' => 'local',
'local_template_path' => resource_path('views/vendor/coreui-templates'),

From then on, regeneration reuses your customized stubs, so a template tweak (e.g., adding an "export CSV" button to the index header) propagates to every future scaffold.

Pattern 2 — Customize the layout, not the 30 generated views. Almost every day-to-day change (branding, extra nav item, a global search box, breadcrumb format) belongs in the shared layout and partials. Keep generated index/create/edit/show views as thin as possible so regenerating them is cheap and lossless. Reserve per-view edits for genuinely resource-specific UX.

Pattern 3 — Sidebar as a maintained partial. The CoreUI sidebar is a hand-edited list of links; the generator does not update it. Treat the menu partial as configuration: one block per resource, consistent icon set, and a wrapper that highlights the active route. When you scaffold a batch of models, add all the menu entries in a single commit — otherwise every CRUD generation produces a follow-up "forgot the menu link" ticket.

Pattern 4 — Two variants per resource. Generate the plain server-rendered variant first (fast, easy to debug), then regenerate a Datatables variant only for resources that truly need client-side search and export:

php artisan infyom:scaffold Order --fieldsFile=orders.json --datatables=true --force

Keep a --datatables column in your team's resource checklist rather than deciding per-commit; mixing conventions across resources is what makes these admin panels feel incoherent.

Pattern 5 — Layer API scaffolding on the same models. infyom:api_scaffold doesn't touch CoreUI views at all, so it's safe to run alongside web scaffolding for the same model. Useful when a Vue/Inertia widget inside a CoreUI page needs JSON endpoints.

Pattern 6 — Feature work after generation. The generated controller is deliberately plain (validate → create → redirect). The intended flow is: scaffold for the boilerplate, then immediately refactor into a FormRequest, a service/action class, and API Resource responses. Don't build business logic into the generated store() — you'll regenerate it and lose the work.

Integration tip — assets. Publish CoreUI assets to public/vendor/coreui (keep the publish tag explicit; don't blanket-publish) and reference them via asset('vendor/coreui/...') in the layout. If the host app already has a Vite/Mix build, add CoreUI through the bundler instead and strip the layout's <link>/<script> tags — otherwise you ship two copies of Bootstrap.

Gotchas and Tips

The repo is archived. Last release 2022-02-03, 31 stars. Treat compatibility as frozen: pin infyomlabs/laravel-generator and this package to exact versions in composer.json, and expect friction on current Laravel/PHP majors. If you're on a recent Laravel, decide up front whether you'll maintain a fork — retrofitting an archived template set later is more expensive than forking on day one.

Publishing is destructive. The default publish overwrites existing files in the destination. In a project with hand-edited views, always run with --force deliberately and after a clean commit, or use a dry-run diff. This is the single most common way people lose work with generator-driven stacks.

Class 'Form' not found. Generated create/edit views rely on the LaravelCollective HTML form builder. If it isn't installed and aliased, every form page 500s while index/show pages look fine — a confusing first symptom.

Config cache freezes the template path. templates is read at generation time, but if you're debugging odd behaviour, php artisan config:cache can leave a stale path in bootstrap cache. When template changes "don't take effect," run php artisan optimize:clear before anything else.

Blade view cache after publishing. Newly published views sometimes render the old compiled version. php artisan view:clear fixes the "I edited the stub but the page is identical" complaint.

Bootstrap version collisions. CoreUI here is Bootstrap 4-era. If the host app loads Bootstrap 5 or Tailwind globally, modals, dropdowns, and card spacing break in subtle ways (jQuery-dependent dropdowns silently no-op). Isolate CoreUI on admin routes only, or commit to one Bootstrap across the app.

jQuery ordering. CoreUI's JS assumes jQuery is loaded first. Mixing it with a bundler that defers scripts is a classic source of "sidebar toggle dead, no console error."

Locale files are a real behaviour, not cosmetics. v1.0.3 added missing locale files; if you override resources/lang/vendor/... keys, keep them in sync, and check the config's locales list before assuming translations are wired up.

Regeneration overwrites silently. infyom:scaffold ... --force will replace controller and views. Keep generated code in its own commit, and keep business logic in classes the generator never touches (FormRequests, Actions, Policies).

Duplicate route names. Scaffolding several models in one sitting occasionally produces colliding resource route names or duplicate Route::resource lines. Run php artisan route:list and eyeball the diff after each batch.

Extension points worth knowing: the templates config key (swap or point at a local path), the --fieldsFile JSON schema for repeatable generation, per-resource publish tags for views vs. assets, and the layout's @yield/@section slots — those yields are the stable contract for injecting your own CSS/JS without editing generated views.

Debugging order when a page looks broken: view:clear → check published asset URLs in the page source (404s on vendor/coreui/*) → check Bootstrap/jQuery load order → config:clear if templates recently changed → only then read the Blade stub.