Chuckcms Template Starter Laravel Package

Getting Started

Install the starter into an existing ChuckCMS application:

composer require chuckbe/chuckcms-template-starter

Then publish the package’s config, views, and frontend assets. The exact tags depend on the service provider, so run php artisan vendor:publish and select the chuckcms-template-starter groups. After publishing, clear caches:

php artisan config:clear
php artisan view:clear
php artisan route:clear

First places to look:

• config/chuckcms-template-starter.php for template/theme and form settings.
• The package’s resources/views directory for layouts, page templates, and the new x-honeypot component.
• The package service provider for publish tags, Blade component registration, and middleware bindings.
• ChuckCMS core docs for how page templates are resolved, since the starter is only useful once ChuckCMS is installed and configured.

The first practical use case: scaffold a ChuckCMS-powered marketing site with ready-made page templates, then drop <x-honeypot /> into the contact form to reduce spam without adding a CAPTCHA.

Before upgrading, confirm your Laravel and PHP versions. v0.4.0 advertises Laravel 11, 12, and 13 support; Laravel 13 will likely require a newer PHP runtime than older Laravel 10 projects.

Implementation Patterns

Page and template rendering. Use ChuckCMS page records to select templates provided by the starter. Keep your app-specific overrides in resources/views/vendor/chuckcms-template-starter rather than editing vendor files. If the starter provides layouts, extend them from your own views so upgrades remain manageable.

Contact and lead forms. Add the honeypot component inside each form:

<form method="POST" action="{{ route('contact.store') }}">
    @csrf
    <x-honeypot />

    <input type="email" name="email" required>
    <button type="submit">Send</button>
</form>

Pair the component with the package’s honeypot validation rule or middleware. If the component only renders the hidden field, add a FormRequest rule that rejects submissions where the honeypot is filled or submitted too quickly. Keep server-side validation authoritative; never rely on client-side hiding alone.

Asset pipeline. If the starter ships CSS/JS, publish those files into your app’s resources directory and import them from resources/css/app.css and resources/js/app.js, then reference them through Vite. If the package provides its own compiled assets, include them with the documented Blade directive instead of duplicating them.

Theme overrides. Prefer overriding individual views over republishing everything. Use view composers or app-level Blade components for custom data, not changes inside vendor views. If you need to replace a starter section, create a new Blade component and reference it from your published layout.

Multi-site or locale setups. If ChuckCMS supports multiple sites or locales, keep starter templates locale-agnostic and resolve labels/URLs through your app’s translation and routing layer. Avoid hard-coding route names inside vendor views; wrap them in helpers or config.

Upgrade workflow. Because this is a 0.x package, treat minor releases as potentially breaking. Pin the version in composer.json for production, run the test suite, and visually check forms and page templates after upgrading.

Gotchas and Tips

• Laravel 13 is forward-looking. Verify PHP and dependency constraints before upgrading. If you are on Laravel 10, stay on the v0.3.x line unless you are ready to upgrade the framework.
• Honeypot is not a complete spam solution. Bots that execute JavaScript may fill hidden fields. Combine the honeypot with rate limiting, CSRF protection, and server-side validation. Do not use display:none alone without an accessible hidden-field pattern.
• Caching can break session-based honeypots. If the component relies on session state or timestamps, full-page caching may cause false positives. Exclude form pages from full-page cache or use a stateless honeypot implementation.
• Publishing views creates upgrade friction. Once published, package view fixes will not reach your app. Publish only what you need, and document overrides so future upgrades are predictable.
• Clear caches after config or view changes. Run php artisan config:clear, php artisan view:clear, and php artisan route:clear when behavior does not match the published files.
• Check package discovery. If the Blade component is not available, run php artisan package:discover and confirm the service provider is registered in bootstrap/providers.php or config/app.php.
• Use php artisan route:list and php artisan about for debugging. These quickly confirm whether the starter’s routes, middleware, and service provider are active.
• Extension points to prefer: custom Blade components, view composers, form requests, middleware groups, and container bindings. Avoid modifying vendor files directly so you can upgrade safely.