Php Session Laravel Package

Getting Started

This is a small, framework-agnostic wrapper around PHP's native $_SESSION — not a Laravel package. There is no service provider, no config file to publish, and no Laravel integration of any kind. Before installing anything, be clear about why you're reaching for it: inside a normal Laravel HTTP request, Illuminate\Session already does everything this class does, with encryption, CSRF, flash data, and a tested driver abstraction. This package earns its place in narrow cases: a legacy PHP script being dropped into public/, a standalone endpoint that boots without the framework, or a migration where you're trying to keep an old call site alive while you rewrite it.

The practical first steps:

1. Install from Packagist at the last tagged release (2019-08-21). The repo is archived, so pin the version in composer.json and commit composer.lock — there will be no upstream fixes.
2. Read the single class file under src/ before the README. The entire surface area is a handful of methods (start, set, get, delete, destroy, and usually an exists/clear pair), and the source is short enough to audit in one sitting. Confirm the exact method names and whether they're static or instance methods — the README examples are the only documentation you get, and they may not match the current tag.
3. Call start() before any output, then set()/get() with plain string keys.

Your first use case should be the smallest possible one: a single legacy script that needs to persist a user preference or a cart fragment across two requests. Get that working in isolation, outside the framework, before you try to wire it into a Laravel route.

Implementation Patterns

Legacy bridge inside a Laravel app. The cleanest pattern is to keep the package entirely outside the framework's request lifecycle. Put the legacy entry point in public/legacy/checkout.php, let it require the Composer autoloader directly, and never route it through Laravel's HTTP kernel. Laravel's StartSession middleware will not run, so there is no contention over the session ID and no double session_start().

Adapter behind an interface. If the package is temporary scaffolding, wrap it immediately:

interface SessionStore {
    public function get(string $key, $default = null);
    public function put(string $key, $value): void;
    public function forget(string $key): void;
}

final class LegacySessionStore implements SessionStore { /* delegates to the package */ }

Bind the interface in a service provider and resolve it in your controllers. When you're ready, swap the binding for a thin wrapper over Illuminate\Session\Store and delete the dependency. This is the single highest-value pattern here, because it turns an archived dependency into a one-line change later.

CLI and queue workers. Long-running processes have no HTTP session, and this package is a reasonable lightweight key-value store for them if you treat $_SESSION as a plain array — though Illuminate\Cache's array or file store is usually the better answer. Use it here only if you're already carrying the dependency.

Configuration before start. Whatever cookie name, lifetime, and save path the class exposes must be set before start(). Treat construction-plus-start as one atomic step in a factory method so nobody can call set() on an unstarted session.

Testing. Because state lives in the superglobal, reset it in setUp(): clear $_SESSION, call session_destroy() if a session is active, and reset session_status(). Don't rely on process isolation alone — PHPUnit will leak state between tests otherwise.

Gotchas and Tips

• Archived since 2019. Assume no PHP 8.1+ compatibility work has been done. Watch for dynamic-property deprecations, implicit nullable parameter warnings, and session_start() return values that are ignored. Run it once under your target PHP version with E_ALL before trusting it.
• Double session start is the most common failure. In a Laravel HTTP context, the framework has already started a session and set the cookie. Calling this package's start() will either warn, silently no-op, or — worse — reset the session array. Never use both in the same request.
• Headers already sent. Any output, BOM, or whitespace before start() kills the Set-Cookie header. Laravel's response pipeline has already flushed headers by the time a view renders, so package calls from Blade or a controller action are effectively broken.
• No session fixation protection. These wrappers typically don't call session_regenerate_id() on privilege change. Do it yourself at login, or you've shipped a vulnerability.
• Mixing storage backends. If you write $_SESSION['cart'] via the package and read session('cart') via Laravel for the same key, you'll get inconsistent results depending on driver and cookie encryption. Pick one owner per key.
• ini settings applied after start are no-ops. session_set_cookie_params and session_name must precede session_start(). Check the constructor for anything that sets these too late.
• Autoloading. Verify PSR-4 vs. classmap in composer.json; older packages sometimes ship a class name that doesn't match the filename, which breaks case-sensitive filesystems but works on macOS.
• Debugging checklist: session_status(), headers_sent($file, $line), session_name(), session_save_path(), and whether the cookie actually appears in the browser devtools. Nine times out of ten the problem is one of those five.
• Extension point is subclassing. There's no event system or driver interface. If you need flash data, CSRF tokens, or encryption, you're either subclassing and adding it, or — realistically — using Laravel's session component instead.