Shtumi Useful Bundle Laravel Package

Getting Started

Reality check first: this is not a Laravel package. It's a Symfony 2 bundle, last touched in 2018, with 1 star and zero dependents. composer require keyopstech/shtumi-useful-bundle will happily resolve inside a Laravel app and then do absolutely nothing — there is no service provider, no extra.laravel block, no facade, no config publish tag. All the wiring lives in Symfony-land: AppKernel::registerBundles(), a DependencyInjection/*Extension, and service tags for Form types, Twig extensions, and Doctrine DQL functions.

So before you write a line of code, read these in order:

1. composer.json — the require block is the gatekeeper. Expect symfony/symfony ~2.x and a PHP constraint that blocks installation on PHP 8, which means it won't coexist with any current Laravel version.
2. README.md — usually lists the form types, DQL functions, and Twig filters with usage snippets. This is the best documentation you'll get; there's no docs site.
3. DependencyInjection/ — shows what's registered by default and what config keys exist. This is the map for everything else.
4. The three feature folders, in this order: Form/Type/ (custom form types), Doctrine/ (DQL function classes), Twig/ (extension classes). These are the actual value.

Your first concrete use case is almost certainly pattern mining, not installation. Skim the Twig extensions and DQL functions — those are the two things that map cleanly onto Laravel primitives, and you can reimplement each one in under twenty lines. The only scenario where you actually install this is if you're maintaining a legacy Symfony 2/3 app in parallel; in that case register the bundle in AppKernel, import its config, and start by using a single form type in one controller rather than adopting the whole bundle at once.

Implementation Patterns

Treat the bundle as a reference implementation and port features one at a time. The mapping is straightforward:

Porting a Twig filter to Blade. Find the extension class, note the method body, then register a directive in a service provider:

Blade::directive('truncate', function ($expression) {
    return "<?php echo e(\\Illuminate\\Support\\Str::limit($expression)); ?>";
});

Keep the directive name identical to the Twig filter name if you're migrating templates — it makes a grep-and-replace migration possible instead of a manual rewrite.

Porting a DQL function. The bundle's DQL functions exist because Doctrine couldn't express date math portably. In Laravel you don't need a function class, just raw SQL:

Order::selectRaw('DATE(created_at) as day, COUNT(*) as total')
    ->groupBy('day')
    ->get();

If you repeat it often, register a Builder macro in a service provider rather than scattering selectRaw calls.

Porting a custom form type. In Symfony the form type encapsulates rendering + validation. In Laravel that splits into three pieces: a FormRequest rule, a Blade component for the markup, and a controller that composes them. A date-range form type becomes a <x-date-range> component plus a array $dates validation rule.

Coexistence pattern. If you genuinely must run both apps, vendor the bundle into a Legacy\ namespace and never reference its classes from Laravel code directly — wrap each call behind a small adapter. This keeps your Laravel side free of Symfony's Component\Form dependency graph.

Gotchas and Tips

• It is abandoned. Last release November 2018, no dependents, no downstream users to find bugs. Zero security patches. Do not put this on a production request path.
• Symfony 2 is end-of-life. Symfony 2.8's support ended in 2018. The bundle's PHP constraint will block installation on any modern PHP, so composer require on a Laravel 10/11 app fails or, worse, resolves an ancient transitive set. Check composer why-not before assuming it's a code problem.
• Nothing auto-wires. No package discovery. Any ported class must be registered manually in a service provider; form types, Twig extensions, and DQL functions are all tagged services in Symfony, and those tags are exactly the metadata you need to capture when reimplementing.
• DQL functions must be registered. In Symfony this happens under the Doctrine ORM dql: config key. If you copy a function class and it "doesn't exist" at query time, the registration is what's missing — not the class.
• Config quirks. Bundle defaults live inside the DI extension's load(), not in a YAML file. If you're mirroring config behavior, read the extension rather than the docs.
• Twig ≠ Blade, Doctrine ≠ Eloquent. No amount of glue makes {{ my_filter(x) }} or a DQL DATE() work inside Blade/Eloquent. Reimplement, don't shim.
• Pulling in symfony/form is a trap. It drags a half-dozen Symfony components and an event dispatcher you'll never use. The form type you wanted was probably 40 lines of HTML.
• Check the license before copying. If you lift code into a commercial app, confirm the header on each file permits it — this repo predates widespread SPDX headers.
• The high-value parts are tiny. Truncation, date formatting, and date-math SQL are each trivial to rewrite and you lose nothing. The genuinely non-trivial piece is the autocomplete form type, and by 2018 standards it's still a thin wrapper around a JSON endpoint you'd write yourself anyway.
• Fork, don't depend. If you must use it, vendor it into your own repo under your own namespace. Upstream is not coming back, and pinning to a GitHub URL for a dead repo will bite you the first time a transitive constraint shifts.

Bottom line for a Laravel developer: don't install it. Spend thirty minutes reading Twig/, Doctrine/, and Form/Type/, port the two or three helpers that actually save you time, and move on.