Bootstrap Cms Laravel Package

Getting Started

This is an application, not a library. There is no composer require into an existing service and no service provider to register. Day one is: clone it, own it, work inside it.

composer create-project graham-campbell/bootstrap-cms myapp --prefer-dist
# or: git clone https://github.com/BootstrapCMS/CMS.git && composer install
cd myapp
cp .env.example .env
php artisan key:generate
# set DB_*, MAIL_*, APP_URL in .env
php artisan app:install     # migrations + seed: admin user, groups, pages, settings
php artisan serve

Before you write a line of code, pin your runtime to what composer.json actually allows. Laravel 5.0/5.1 and PHP 5.6–7.x are the target; a PHP 8 machine will fail dependency resolution and you'll burn the day on Composer, not on features. Get a matching container (php:5.6-fpm or php:7.0-fpm + MySQL 5.6) running first — it is the single highest-leverage 20 minutes of setup.

Read these in this order:

1. composer.json — confirms the framework/PHP pin and lists the graham-campbell/* helper packages you're inheriting.
2. app/Http/routes.php (or the split under app/Http/routes/) — the fastest map of the real feature surface: pages, blog, events, users, groups, redirects, navigation, settings, uploads.
3. app/Models/ — Page, Post, User, Group, Redirect, Setting. Thin Eloquent models; read them to learn what is actually persisted before you design anything.
4. resources/views/ (Blade, admin UI) vs themes/ (Twig via TwigBridge, public site). Knowing which layer you're editing saves hours of "why isn't my Blade change showing up."
5. config/cartalyst/sentry.php and the graham-campbell/* config files — auth behaviour and helper-package defaults live here.

First use case: log in as the seeded admin, create a page in the admin, confirm it renders at its slug on the front end, then flip its permission so an unprivileged user can't see it. That one loop exercises routing, the model, the theme layer, and the Sentry permission stack — it's the loop you'll repeat for every feature you add, so get it green before touching anything else.

Implementation Patterns

Clone the Pages module for every new CRUD. Pages (and Blog next to it) is the canonical template: controller with index/create/store/edit/update/destroy, FormRequest or inline validation, model calls, Blade admin views, routes, migration, seeder, nav entry, permission keys. A new "Docs" or "Events-with-different-fields" module is a copy-rename of Pages. In an opinionated monolith, matching conventions beats refactoring toward your own — your edits should be indistinguishable in style from the surrounding code, because that's what makes the next upgrade/harvest pass tractable.

Decide the route group before you write the controller. Public routes are unauthenticated and resolve through the theme's Twig views; admin routes sit behind the auth + permission middleware stack. Register in the wrong group and you ship an unauthenticated admin screen. When adding a module, add the admin routes and the corresponding permission key in the same commit — the permission registry and the nav are both easy to forget and both cause "the menu item is there but it 403s" confusion.

Two templating layers, two jobs. Admin = Blade. Public site = Twig in themes/ via TwigBridge. When adding a public-facing view, put it in the theme, not in resources/views; when adding an admin screen, do the reverse. Keep this split rigid — developers who mix them create views that render in one context and 500 in the other.

Permissions are the ACL seam. Model authorization around Sentry's group/permission records rather than scattering if ($user->id === ...) checks. New capability → new permission key → assign to the relevant default groups in the seeder → guard it with middleware or @if in the view. This is the part of the codebase worth copying verbatim into anything you build later; it is also, per the TPM assessment, the highest-risk dependency — so isolate it behind your own thin helper (can('docs.edit')) rather than calling Sentry all over the app. That wrapper is what makes a future auth migration tractable.

Settings and redirects are configuration, not code. Use the settings model for anything an operator should change without a deploy, and the redirects table for URL hygiene. Reaching for a config file for operator-tunable values is the common mistake here.

Uploads: go through the existing image pipeline, not move_uploaded_file. The repo already wires Intervention Image; reuse the helper so you inherit whatever validation and resizing exists, and so a later swap to object storage is one seam, not a grep.

Workflow for a feature end-to-end:

php artisan make:migration create_docs_table
# edit migration, then:
php artisan migrate
# model, controller, routes (admin + public groups), Blade admin views,
# theme Twig view, permission key, seeder, nav entry
php artisan db:seed --class=...

Commit migrations and seeders together with the module — the seeded admin/permission state is how a fresh app:install produces a working app, and it's your only reproducible setup path.

For anything long-lived, treat the repo as a reference implementation. Fork read-only, harvest the domain model (entities, schema, permission taxonomy, page/blog relationships) and the admin UX patterns into a modern Laravel build. That's the recommended posture from the technical review, and it changes your day-to-day: you're writing the target app, not extending the EOL one. Keep your forks and the upstream diff small and documented.

Gotchas and Tips

Composer will fight you, and it will do so at the worst time. A clean rebuild on a new machine is the most likely failure point — 2015-era constraints resolve inconsistently under Composer 2, and abandoned packages emit constant warnings. Commit composer.lock, pin aggressively, and expect to add --ignore-platform-reqs or explicit constraint overrides. If you can, build your Docker image once and never rebuild it from scratch without a reason.

Twig 1.x sandbox risk is real if themes or page content are editable by non-developers. Raw HTML/Twig in page bodies is a stored-XSS vector; unfiltered Twig in user-editable templates is template injection. Treat "who can edit a theme file" as a security boundary, not a convenience feature.

Sentry's throttling table is on the auth path — it's a write on login attempts. Fine for a prototype, noticeable under load. If you're load-testing, check it before blaming your controller.

Password hashes are bcrypt and port with rehash-on-login, so user migration off Sentry is tractable — but the groups/permissions/throttles tables need a real mapping exercise into whatever replaces them. Don't assume the users table is the hard part; it isn't.

Debugging the theme/Blade split: if a view renders blank or errors, first confirm which layer is resolving it. Clear Twig caches when theme changes don't appear; cached compiled templates are the usual culprit for "my edit isn't live."

Config quirks to know: auth behaviour lives in config/cartalyst/sentry.php, not in config/auth.php — resist the reflex to edit the standard Laravel auth config. The graham-campbell/* packages each have their own config file; defaults are mostly fine, but read them before assuming a helper does nothing.

Extension points are the conventional ones, and that's the point. New module = routes + controller + model + migration + admin views + theme views + permission key + nav entry + seeder. There's no plugin API, no module registry, no event bus to hook. Extend by adding files that look like the existing files, and by respecting the route group and permission conventions. If you find yourself wanting a service-provider seam, that's the signal you should be harvesting patterns into a modern build instead of fighting this one.

Onboarding: engineers who worked in Laravel 5 will be productive in days. Everyone else will find Twig + Sentry + Bootstrap 3 foreign and thinly documented — budget for it and don't make this a system-of-record touchpoint for new hires.

Before you commit anything beyond a prototype: get a dependency audit and a security review of the auth and template layers, name an owner for the fork (or explicitly decide "no fork"), and write a sunset date into the decision record. That's the gate — and the day-to-day consequence is that every hour you spend here should be justified as either "ships the time-boxed demo" or "harvestable pattern," never as "long-term platform investment."