Chapterone Laravel Package

Getting Started

This package is part of the numberninecms Laravel ecosystem and now acts as a thin layer on top of numberninecms/cms (v0.4.1+). Before touching application code, confirm your composer.json pins the matching core version — this release requires numberninecms/cms:^0.4.1, so a stale core install will break resolution.

1. composer require numberninecms/<this-package> and ensure numberninecms/cms resolves to ^0.4.1.
2. Publish config/migrations if not already done: php artisan vendor:publish --provider="NumberNine\...\ServiceProvider" and run php artisan migrate.
3. Register the service provider (Laravel auto-discovery should handle it, but verify in config/app.php if you're on an older skeleton).

If you were coming from a pre-0.4.1 install, your first stop should be the core package docs — the form components that previously lived here are now part of numberninecms/cms. Start by confirming any form markup, Blade views, or component namespaces still resolve after the move.

A good first use case is wiring the package's public-facing feature (e.g. comment display / rendering) into an existing page and verifying it works for both guests and authenticated users — this is exactly the surface the 0.4.1 bug fix touched.

Implementation Patterns

Depend on core, don't duplicate it. After 0.4.1, form components are owned by numberninecms/cms. In your own code, reference the core component namespace directly instead of expecting form partials/classes from this package. Treat this package as a focused feature package (comments, routing glue, etc.), not a general UI bundle.

Version-lock the ecosystem. Add "numberninecms/cms": "^0.4.1" explicitly in your root composer.json (not just rely on transitive resolution). The ecosystem moves in lockstep, and pinning both packages together avoids partial upgrades where, e.g., a comment view references a form component that no longer exists here.

Testing authenticated-but-latent users. The 0.4.1 fix addresses the case where a user is "remembered" via Laravel's remember-token cookie but not fully re-authenticated (Auth::check() is true but the session was re-established). When you write feature tests around comments/pages, cover three states:

• Guest (Auth::guest())
• Remembered-but-latent (Auth::viaRemember() true)
• Fully authenticated (Auth::check() and viaRemember() false)

Use $this->actingAs($user) for the fully-authenticated case and simulate the remembered case by setting the recaller cookie (Auth::guard()->getRecallerName()).

Upgrade workflow from <0.4.1:

1. composer require numberninecms/cms:^0.4.1 numberninecms/<this-package>:^0.4.1
2. Search your app for imports/aliases of form components previously provided here — rewrite to the core namespace.
3. Clear compiled views (php artisan view:clear) and config cache (php artisan config:clear), since component resolution is cached.
4. Re-run any Blade snapshot tests.

Extension points. Prefer binding overrides via the service container or publishing views into resources/views/vendor/... rather than patch files. If you need additional form behaviour, add it in your application layer on top of core form components, not by reintroducing the removed ones.

Gotchas and Tips

• Hard removal = breaking change. Form components were deleted, not deprecated. Any code, config, or Blade templates referencing the old namespace will fatal with a class-not-found error on upgrade. Grep for the old namespace before deploying.
• Dependency drift. The cms:^0.4.1 requirement means composer will happily install 0.4.x or 1.x-incompatible cores only within the caret range. If you're pinning core to a minor for stability, pin both packages to the same patch level to avoid subtle behavioral skew.
• Remembered-user auth edge cases. The fixed bug — an exception on comment pages for remembered-but-not-fully-authenticated users — is easy to reintroduce if you write custom middleware that assumes Auth::user() implies a fully hydrated session. Guard comment rendering with null-safe checks and be aware some user attributes may not be loaded for a remember-restored user.
• Config cache is your first debug lever. After upgrading, if you see "missing component" or stale class errors, run php artisan optimize:clear (config + view + route caches). Component and view namespace registrations are cached and won't hot-reload on a version bump.
• Debugging auth bugs. Reproduce with a persistent cookie: log in with "remember me", close the browser/session, hit a commented page directly. Wrap the request in Telescope or log Auth::viaRemember() to confirm the code path. This is the exact scenario the 0.4.1 patch fixes — if you're on an older version, upgrade rather than patching your own guard.
• Vendor views override published copies. If you previously published this package's views, the moved form components won't update in your local copies. Re-publish with --force (back up your customizations first) so your overrides align with the 0.4.1 layout.
• Extension via events. For behaviour that previously hooked form components, look for events dispatched by the core package or wrap the relevant controller/route in your AppServiceProvider — don't fork the package internals, which will conflict with future core releases.
• Watch the changelog for core, not just this package. Since this package's features increasingly live in numberninecms/cms, most meaningful changes will land there first. Subscribe to core release notes as the primary signal.