Jquery Bundle Laravel Package

Getting Started

This package only earns its place in an existing legacy Symfony 2.x/3.x application. It is archived and marked deprecated, so treat "getting started" as "safely inheriting," not "adopting."

1. Confirm the Symfony version. composer.json requiring symfony/symfony: ^2.8|^3.4-era constraints is your signal. On Symfony 4+ there is no compelling reason to add this bundle.
2. Require it: composer require sonata-project/jquery-bundle (the composer name differs from the repo name — this trips people up).
3. Register it. On Symfony <4, add new Sonata\jQueryBundle\SonatajQueryBundle() to AppKernel::registerBundles(). On Symfony 4-style config/bundles.php, add the class only if the tag supports it.
4. Publish the assets: php bin/console assets:install --symlink (target web/bundles/sonatajquery on legacy, public/bundles/sonatajquery on newer). Without this step every include 404s and you'll waste an hour blaming the bundle.
5. First use case: in your base layout, include jQuery before any dependent script, and jQuery UI plus one theme CSS when you need widgets (datepicker, dialog, sortable, tabs).

Where to look first: Resources/public/ inside the bundle. It is the only reliable documentation for which jQuery/jQuery UI versions and theme folders actually ship. The README is thin; the vendored files are the contract. Second stop is the bundle's DependencyInjection/Configuration.php to see whether a config block exists in your tag — this has changed across releases.

Implementation Patterns

Template includes via the asset helper. Reference published assets through asset() rather than hardcoding paths, and keep ordering explicit:

• jQuery core first, then jQuery UI, then the theme CSS, then your widget initialisation.
• Use asset('bundles/sonatajquery/jquery/<exact-file>.js') on legacy layouts, or asset('@SonatajQueryBundle/Resources/public/...') with the bundle notation on newer ones. Copy the exact filenames from Resources/public/ — they are version-stamped.

One theme, chosen deliberately. The bundle ships several jQuery UI themes. Pick exactly one directory and include its .css; loading two themes produces subtle cascade chaos (overlapping .ui-* rules) that is painful to debug. If you need brand colours, override specific selectors in your own stylesheet loaded after the theme rather than editing the vendored file.

CDN toggle pattern. Older tags expose a sonata_jquery config block with a use_cdn-style flag that switches resolved URLs to a Google CDN. Verify against Configuration.php before relying on it — the flag is not present in every release, and it does not rewrite script tags you wrote by hand. The clean pattern: decide once (CDN vs. local) and centralise the include in a single Twig block so the switch is a one-line change.

SonataAdminBundle pairing. This bundle's historical reason to exist is feeding jQuery/jQuery UI to SonataAdminBundle. If you maintain an admin panel, keep this bundle's major roughly in step with the admin bundle's expectations; mismatched jQuery UI versions manifest as widgets that render but silently fail to initialise.

Widget initialisation discipline. Put initialisers in a page-specific script block, wrapped in $(function () { ... }), and assume nothing about load order beyond your own includes. For datepickers, bind to an explicit selector and pass dateFormat explicitly — jQuery UI's default format differs from what most backends expect.

Migration pattern (the one most teams actually run). Map each include to an npm package at the same major version ([email protected] or 3.x, [email protected]), install via Yarn/npm, and load through Webpack Encore or AssetMapper. Keeping the same jQuery UI major avoids widget behaviour changes. The diff usually only touches the base template and package.json — much smaller than it looks.

Gotchas and Tips

• Security debt is the headline. The vendored jQuery is 1.8–1.10 era. Several jQuery <3.5 releases have known XSS issues. If this bundle is on a public-facing page, audit and plan the npm migration; if it's internal admin only, document the risk.
• No upstream fixes, ever. Archived means no patches. Any bug you hit is yours to work around in application code; do not expect StackOverflow coverage (41 stars, zero dependents in the listed metadata) — read the source.
• Double-loading jQuery. Themes, other bundles, or a stray <script src="...jquery..."> in a child template can load a second copy. Plugins then attach to whichever instance was last assigned to window.jQuery, and your widget code silently targets the other one. Grep templates for jQuery before adding an include, and check window.jQuery once in the console.
• Stale published assets. After composer update, assets:install must be re-run or the old files linger in web/bundles. Combine with browser caching and you get "it works locally, not in staging." Append a version query string to your asset() calls or clear the asset cache as part of deploy.
• jQuery UI theme images break when CSS moves. Theme CSS references images by relative path. Copying the CSS into your own concatenated stylesheet severs those references and you get missing icons (calendar glyphs, spinner images). Either keep the theme folder intact or rewrite the url(...) paths.
• web/ vs public/ path confusion. Hardcoded bundles/sonatajquery/... paths still resolve if assets:install ran, but the install target moved between Symfony versions. Always go through asset().
• Config node may not exist. Don't write sonata_jquery: into YAML based on a blog post; check the bundle's Configuration.php in your installed tag first, or Symfony will reject the unknown key.
• Debugging checklist, in order: does web/bundles/sonatajquery exist? Does the exact filename in Resources/public/ match your include? Does view-source show the expected tag order? Is window.jQuery.fn.jquery the version you think it is?
• Extension points are essentially nil. This bundle ships static files; there is nothing meaningful to extend or configure. The practical override surface is your own templates — centralise the includes so future changes are single-point edits.