Cms Contact Laravel Package

Getting Started

This is an early alpha (0.2.0-alpha) of a package that explicitly targets only Laravel 4.1 — treat it as a pre-1.0 library with no backwards-compatibility promise. Before anything else, confirm your app is actually on Laravel 4.1 and PHP ≥ 5.3.7; there is no 4.2/5.x support and no auto-discovery.

1. Require with an explicit stability flag. The default minimum-stability is stable, so an alpha will not resolve without one:

   "vendor/package": "0.2.*@alpha"
   

   Then composer update vendor/package.
2. Read the updated docs first. The release notes only say "Updated docs" — the README is the only contract this package currently offers, so snapshot it alongside the pinned version.
3. Register the service provider manually in app/config/app.php (providers array), and add any facade alias to aliases if the docs list one. Laravel 4.1 has no package discovery.
4. Publish config if the package ships one: php artisan config:publish vendor/package. Re-read the published file after every package bump — Laravel will not overwrite it.
5. First use case: resolve the package's main class out of the IoC container (App::make(...)) in a tinker-style route or a single test, rather than wiring it into a controller. On an alpha, prove the binding works before designing around it.

If the docs are thin, run the package's own test suite locally — "tweaked unit tests" in this release usually means the tests are the most accurate description of intended behaviour available.

Implementation Patterns

• Go through the container, never new. Call the provider-registered binding (App::make('package.alias')) so you can substitute a mock in tests and so a later binding-key change is a one-line fix.
• Isolate the package behind your own wrapper. Put all calls into a small repository/service class of your own. Given the alpha status, assume 0.3 will break something; a single seam keeps the blast radius to one file.
• Config-driven usage. Read settings via Config::get('package::key') (Laravel 4.1's namespaced config) instead of hardcoding values, and keep your overrides in app/config/packages/vendor/package/.
• Facade for ergonomics, injection for tests. Use the facade in controllers/blade, but type-hint the underlying class in constructors so tests stay honest.
• Migrations, if present: php artisan migrate --package="vendor/package"; during package development use --bench.
• Pin and lock. Commit composer.lock, and avoid dev-master — an alpha plus a moving branch is two variables at once. If you must track dev, use a branch alias deliberately and re-run the suite on every pull.
• Testing pattern: App::instance(...) swap plus Mockery for the package's collaborators; use the package's own tests as the behaviour spec when docs are ambiguous.

Gotchas and Tips

• "Support only Laravel 4.1" is literal. 4.0 and 4.2 are out of scope. 4.2 is largely BC-compatible so it may work, but it is untested — verify, don't assume. Lumen and 5.x will not work at all.
• PSR-4 is new in this release. If you installed a pre-0.2 version, the namespace-to-path mapping changed: run composer dump-autoload -o, remove stale classmap entries, and check the namespace in your provider registration still matches. This is the most likely silent breakage in this bump.
• Alpha stability bites at install time, not runtime — a missing @alpha flag surfaces as an unhelpful "could not find package" solver error. Add prefer-stable: true if you mix this with other deps.
• Published config is not updated by Composer. After upgrading, diff the package's src/config/ against your app/config/packages/ copy or you will silently run old defaults.
• Debugging: Laravel 4.1 logs to app/storage/logs/laravel.log. If a binding resolves but behaves oddly, php artisan dump-autoload and a fresh config:publish clear most self-inflicted issues.
• Unit tests are "tweaked," which is not the same as green on your stack. Run them locally on your PHP minor version before trusting CI claims from 2014-era tooling.
• Extension points are minimal: the service provider bindings and the config file are the only stable hooks at this stage. Do not subclass package internals — they are the most likely thing to move before 1.0.
• Version-pinning discipline: record the exact installed version (composer show vendor/package) next to the README snapshot. When 0.3 arrives, that pairing is what lets you diff behaviour instead of guessing.