Sfcontextbundle Laravel Package

Getting Started

francisbesset/sfContextBundle reintroduces Symfony 1.x's sfContext singleton into Symfony 2. It exists for one reason: to let code written against sfContext::getInstance()->… keep running after a Symfony 1 → Symfony 2 migration, without rewriting every call site on day one.

Before you install anything, confirm you actually qualify:

• Your application runs on Symfony 2.0/2.1-era APIs. The package is from that generation, targets the old AppKernel/XML-service-definition style, and will not install against Symfony 4/5/6/7 (composer require will fail on version constraints, and the code relies on APIs removed long ago).
• You have real sfContext call sites to port — helpers, legacy bundles, third-party SF1 code. If you don't, this bundle adds nothing.
• Check the exact Composer name in the repo's composer.json / Packagist entry before installing; the repository directory is sfContextBundle but the published package name may be hyphenated.

Minimal wiring:

// app/AppKernel.php
public function registerBundles()
{
    $bundles = [
        // ...
        new FrancisBesset\Bundle\sfContextBundle\sfContextBundle(),
    ];
    return $bundles;
}

First use case — the one this bundle is built for:

// A legacy SF1 helper you have not ported yet
$request  = sfContext::getInstance()->getRequest();
$user     = sfContext::getInstance()->getUser();
$response = sfContext::getInstance()->getResponse();

Look first at the bundle's service definition (usually Resources/config/services.xml) to see which container services are exposed through the context and under which method names. That mapping is the contract you'll be porting against.

Implementation Patterns

1. Thin adapter around the singleton. Don't sprinkle sfContext::getInstance() through new code. Introduce one class that wraps it, then inject that class. When you're ready to drop the bundle, you change one file:

final class LegacyContext
{
    public function request(): Request
    {
        return sfContext::getInstance()->getRequest();
    }
    // ...
}

2. Bridge legacy libraries. If you're pulling in SF1-era code (a mailer helper, an ACL check), wrap the entry point in a Symfony 2 service that constructs the sfContext state once from the request stack, calls the legacy code, and returns a value. Keep the singleton at the boundary, never in the core.

3. Templates. Expose a small Twig global/extension delegating to your adapter rather than calling sfContext directly from templates — templates are exactly where untestable global state rots fastest.

4. Incremental porting order. Port in this sequence: request/response access → user/session → routing → logging/i18n. The first two are trivially replaceable by RequestStack and TokenStorage; routing and i18n are where the bundle buys you the most breathing room.

5. Feature-flag the shim. Put legacy call sites behind a config flag so you can run the app both with and without the bundle and measure how much is left to port.

Gotchas and Tips

• It is a service locator by design. Every problem sfContext had in SF1 comes along: hidden dependencies, untestable units, and initialization-order bugs. Treat it as scaffolding with a demolition date, not architecture.
• No request in CLI. Console commands, queue workers, and cron jobs have no HTTP request. Any getRequest() call in those contexts returns null or throws depending on how the bundle was initialized — guard every non-web entry point.
• Sub-requests and the stack. The bundle predates RequestStack. Under ESI/fragment rendering or forwarded sub-requests, the "current" request the context reports may not be the one you think. Don't trust it inside fragment controllers.
• Circular references. Because the context reaches into the container for many services, injecting the context into services that the context itself depends on produces container cycles. Keep the context at the leaves of your dependency graph.
• Service visibility. On modern-ish Symfony versions a shared sfContext service must be explicitly public: true to be retrievable from $container->get(). Older definitions assume the default was public.
• Abandonment risk. 13 stars, zero dependents, and an effectively unmaintained codebase: you are the maintainer. Pin the exact Symfony version in composer.json, vendor the bundle into your repo if you need to patch it, and expect no upstream fixes.
• Exit strategy is the deliverable. The best day-to-day use of this bundle is to make it unnecessary. Track remaining sfContext::getInstance() occurrences (a grep in CI is enough) as a burn-down metric, and delete the bundle when the count hits zero.