Connect Cms Laravel Package

Getting Started

Connect-CMS is a Laravel application (a full CMS), not a Composer library you require into an existing app. "Leveraging the package" day-to-day therefore means running an instance and extending it, not importing classes into your own project.

Start on v2.44.1 or later. This release is a pure security patch: ten GHSA advisories (GHSA-hwpr-g53x-758h, GHSA-qrwp-cxq9-rvqx, GHSA-4j63-ggfv-x4j8, GHSA-pcq9-7m9x-6vfw, GHSA-f645-qv93-cc4j, GHSA-3cwf-77q9-9ghm, GHSA-93xf-m982-qx3x, GHSA-jqh3-q5f5-6vpf, GHSA-wgrp-h7mf-2r6v, GHSA-cx23-56j5-x9w8) are fixed with no documented API changes. Treat v2.44.0 and earlier as compromised — do not scaffold new work on them.

First steps:

1. Deploy per the project's install docs, set .env (APP_URL, APP_KEY, DB credentials, mail), then php artisan migrate.
2. Log in as the initial admin, create a site/page, and pick a theme under the theme settings.
3. Look first at these directories, in this order: app/Plugins/ (content modules — what you'll extend most), resources/views/themes/ (presentation), config/ (app-level knobs), and database/migrations/.
4. First real use case: add a content type (news, blog, form, calendar) as a page "frame," then restyle it via a child theme.

Implementation Patterns

Treat upgrades as a first-class workflow, not an afterthought. With ten CVEs landing in a single patch release, pin your version in composer.json/deployment manifest and schedule the upgrade path v2.44.0 → v2.44.1 explicitly. Verify with composer show opensource-workshop/connect-cms (or your deploy tag) and re-run the asset build after upgrading.

Theme customization: never edit a shipped theme in place. Copy it into a child theme directory under resources/views/themes/, register it, and override only the blade views you need. This keeps git pull/composer update upgrades conflict-free — which matters a lot when you're forced to patch quickly for security.

Plugin/module work: follow the existing plugin skeleton in app/Plugins/ rather than inventing a structure. Keep migrations, models, controllers, and views co-located per plugin so a module can be enabled/disabled per site without touching core.

Multi-site and permissions: model your content tree and role assignments early. Connect-CMS's page/content hierarchy and role system are cheap to configure up front and expensive to retrofit; script bulk page creation with an artisan command or seeder rather than clicking through the admin.

Environment discipline: keep .env out of version control, run php artisan config:cache/route:cache only after verifying env parity, and wire storage:link into your deploy script. For CI, run a smoke test that boots the app and hits the login page — a cheap guard against a broken upgrade.

Integrations: prefer Laravel-native hooks (events, scheduled commands, queued jobs) over patching core. If you need to alter core behavior, wrap it in a service provider or a small custom plugin so the diff is auditable at upgrade time.

Gotchas and Tips

• Security release, no changelog detail. The notes list advisory IDs only — no affected endpoints, no migration steps, no breaking-change section. Read the linked GHSAs before upgrading a heavily customized instance, and check whether any patch touches code you've forked. Assume input handling, upload, or auth paths were involved and re-test those surfaces.
• Don't assume "patch release = safe to skip testing." Ten fixes in a x.y.Z bump usually means coordinated backports; a customized instance can still break if you've overridden the affected controllers or views.
• Upgrades clobber edited core/theme files. If you've modified shipped files, git pull will conflict at the worst possible moment — exactly when you're patching a CVE. Always git stash/branch first and diff.
• Caches mask upgrades. After upgrading, run php artisan optimize:clear then rebuild. Stale compiled views and config caches are the most common "the fix didn't apply" cause.
• Asset pipeline: if you customize CSS/JS, re-run the build (npm ci && npm run prod) post-upgrade; mismatched manifest hashes produce blank pages.
• Debugging: set APP_DEBUG=true locally only; in production, check storage/logs/laravel.log and the web server error log. Permission problems on storage/ and bootstrap/cache/ look like application bugs but aren't.
• Extension points to prefer: child themes, plugin directories, service providers, and Laravel events. Avoid editing vendor/ or core app/ files — those are the first things an upgrade overwrites.
• Watch for follow-up advisories. A cluster of ten fixes sometimes precedes a v2.44.2 for incomplete patches; subscribe to the repo's security advisories and keep a fast rollback (DB snapshot + previous release tag) ready.