Stisla Templates Laravel Package

Getting Started

Prerequisites. Laravel app + infyomlabs/laravel-generator installed and published (php artisan infyom:publish). This package is the view layer — the generator does the scaffolding, Stisla provides the Blade it writes.

Install.

composer require infyomlabs/stisla-templates

Point the generator at the Stisla template set. In config/infyom/laravel_generator.php set:

'templates' => 'stisla-templates',

Alternatively, publish the views directly to inspect/override them:

php artisan vendor:publish
# pick the StislaTemplates service provider entry

First use case — generate one CRUD and eyeball the output.

php artisan infyom:scaffold Post --fromTable --tableName=posts

Then check resources/views/posts/ (index, create, edit, show, fields) and resources/views/layouts/. Those two directories are your entire surface area: layouts for chrome, CRUD views for page bodies.

Where to look first

1. resources/views/layouts/app.blade.php — the master shell (sidebar, navbar, footer, scripts).
2. resources/views/layouts/partials/ — sidebar/nav items you will edit on every project.
3. resources/views/posts/fields.blade.php — the form-field partial every generated screen reuses.

Implementation Patterns

Publish-once, commit, own the files. Treat published views as application source. Don't depend on the vendor copy — you'll be editing sidebar, branding, and CSS on day one anyway.

php artisan vendor:publish --tag=stisla-templates   # tag name varies by version; confirm in the interactive list
git add resources/views/layouts resources/views/vendor

Consistent route/nav wiring. After each infyom:scaffold, add the resource to layouts/partials/menu.blade.php (or wherever the sidebar is defined) so generated pages are reachable:

<li class="nav-item {{ request()->is('posts*') ? 'active' : '' }}">
    <a class="nav-link" href="{{ route('posts.index') }}">
        <i class="fas fa-file-alt"></i> <span>Posts</span>
    </a>
</li>

Reuse the generated partials for hand-written pages. The CRUD views decompose into fields, table, show_fields. Extend and reuse instead of hand-writing Bootstrap markup:

@extends('layouts.app')
@section('title', 'Reports')
@section('content')
    <div class="section-body">
        @include('crud.table', ['dataTable' => $reports, 'columns' => $columns])
    </div>
@endsection

Auth screens come from the layout, not the package generator. Stisla ships auth blades (login/register/password) matching the theme — point your auth controllers' views at them, or copy them into resources/views/auth/ so Laravel's default Fortify/Breeze routing resolves without config changes.

Overriding in a team. Prefer Laravel's vendor view override (resources/views/vendor/<namespace>/...) for upstream bug fixes you don't want to lose on a re-publish, and keep app-specific customization in resources/views/layouts/ so an upgrade can swap the vendor tree cleanly.

Asset strategy. Stisla bundles Bootstrap 4-era CSS/JS. Serve from public/vendor/stisla/ (published) rather than CDN so the layout matches local asset paths; if you migrate to Vite, rip the <script>/<link> block out of the layout and import equivalents in resources/js/app.js.

Gotchas and Tips

It's archived — treat Laravel 9 as the ceiling. Last release v4.0.0 (2022-02-25), Laravel 9 only. On Laravel 10/11 the layouts will usually render (Blade syntax is stable) but you get no security fixes, no compatibility guarantees, and any Blade/Bootstrap drift is on you. Decide up front: pin the framework, or fork the template tree into your app and own it.

Do not edit vendor/. Publish, then edit. Re-running vendor:publish without --force won't overwrite; --force will silently wipe your customizations. Guard against this in CI or docs.

Template resolution is a config string, not a path. If infyom:scaffold emits AdminLTE markup, the templates key is wrong or the config is cached. Fix with:

php artisan config:clear
php artisan view:clear

Then re-read config('infyom.laravel_generator.templates').

Generated views are a starting point, not finished code. Expect small manual fixes per scaffold: relationship select options, date pickers, file uploads, and old()/validation error bindings. Verify @csrf and @method are present on generated forms after any template edit.

Bootstrap 4 vs 5 conflicts. If your app already loads Bootstrap 5, loading Stisla's bundled Bootstrap 4 alongside it will cause subtle style breakage (grid gutters, utility class renames). Pick one: strip Stisla's Bootstrap and restyle, or scope the admin area.

Validation error display is layout-dependent. The Stisla layout renders errors via a shared partial — if your custom @section bypasses the layout, errors vanish silently. Confirm $errors->any() is surfaced before shipping a form.

Extension points worth knowing

• layouts/app.blade.php — swap theme chrome wholesale.
• layouts/partials/* — surgical edits; smallest blast radius.
• CRUD view stubs (index/create/edit/show/fields) — customize the generator, not each generated page, by editing the published template.
• Asset directory — replace Stisla's CSS with your own build while keeping the markup.

Debugging checklist when a page looks broken: view:clear → confirm which layout is being extended (@extends) → check public/vendor/ assets were published → verify the route name matches route() calls in the sidebar → confirm Bootstrap isn't double-loaded.

Upgrade path. This is a scaffolding tool, not runtime code — the cheapest long-term move is to copy the published views into your repo once and drop the composer dependency. You keep the UI, lose the version churn, and unblock any Laravel upgrade independently of the vendor.