Jquery Bundle Laravel Package

Getting Started

This is a thin Zikula asset bundle whose only job is to make jQuery (and historically jQuery UI / select plugins) available to Zikula modules and themes through Zikula’s page-variable system. It is not a general-purpose jQuery wrapper — think of it as a versioned, server-side CDN substitute for a Zikula install.

Minimal steps in a Zikula 1.4/1.5 application:

1. composer require zikula/jquery-bundle (the package is archived; pin the exact version you get).
2. Register/enable the bundle as a Zikula module (php bin/console zikula:mod:install ZikulaJQueryBundle or via the Modules admin screen). If your app uses Symfony bundle registration, ensure it is listed in app/AppKernel.php / bundles.php.
3. Publish assets so the bundle’s Resources/public files land in public/ (php bin/console assets:install --symlink in a modern layout, or the Zikula asset workflow for your version).
4. In a module template, request jQuery via the page-variable API:

{{ pageAddVar('javascript', 'jquery') }}

or in PHP:

PageUtil::addVar('javascript', 'jquery');

5. Load your own script after it:

{{ pageAddVar('javascript', 'jquery') }}
{{ pageAddVar('javascript', 'modules/mymodule/js/app.js') }}

Where to look first: Resources/public/js (what jQuery version is actually shipped), the bundle class and DependencyInjection/ (for config keys), and any Resources/config/ service definitions that register the jquery asset alias. That alias is the public contract you will actually use.

First real use case: a legacy Zikula module that already calls PageUtil::addVar('javascript', 'jquery') — install this bundle, publish assets, and those calls resolve instead of 404-ing. Confirm by loading a page and grepping the rendered <head> for the jQuery <script> tag.

Implementation Patterns

Template-level inclusion (most common). Treat 'jquery' as a named asset. Add it once per page, ideally in the base layout, then let modules add their own scripts after it. Zikula’s page variable collector de-duplicates repeated adds, so a module can safely request jquery even if the theme already did.

Order-sensitive stacking. Because Zikula renders page vars in insertion order, jQuery must be added before plugins and before your own scripts. The reliable pattern is a base template that adds jquery first, then a module template that appends plugin scripts:

{# layout.html.twig #}
{{ pageAddVar('javascript', 'jquery') }}
{% blockjavascripts %}{% endblock %}

{# MyModule/Resources/views/foo.html.twig #}
{% block javascripts %}
    {{ pageAddVar('javascript', 'modules/mymodule/js/plugin.js') }}
{% endblock %}

Configuring what gets bundled. Depending on the release, the bundle exposes options for including jQuery UI, choosing a UI theme, and enabling plugins. Set these in app/config/config.yml (or the Zikula module config UI) rather than editing files in Resources/public — vendor files are overwritten on composer update / assets:install.

# illustrative; verify keys against your installed version's Configuration.php
zikula_jquery:
    ui: true
    theme: smoothness

Serving from a CDN or a newer jQuery. The intended extension point is to override the asset alias in your own bundle/config so 'jquery' points at a CDN URL or a locally vendored newer build. This is the cleanest way to keep legacy PageUtil::addVar('javascript', 'jquery') calls working while shipping a patched jQuery.

Module-to-module integration. Any bundle that wants jQuery without depending on this one should declare a soft dependency (suggest, not require) and add the page var defensively. Consumers that hard-require zikula/jquery-bundle are rare (zero dependents on Packagist), so expect to be the one wiring it up.

Day-to-day workflow. In practice this bundle shows up in three places: theme base layouts, module admin templates, and AJAX-heavy legacy forms (jQuery Form/Validation). Keep a single "jquery owner" template and never sprinkle addVar('jquery') throughout partials — makes it trivial to later swap to Webpack Encore without chasing every file.

Gotchas and Tips

• Archived and unmaintained (last release 2018). Treat it as legacy-compatibility glue, not a forward-looking choice. The shipped jQuery version is old and will not receive security patches; if you expose user input to it, audit the version in Resources/public/js immediately and consider overriding the asset alias to a current jQuery build.
• Assets not published = 404s. The single most common failure is forgetting assets:install. The template renders the <script> tag but the browser gets a 404, and every jQuery-dependent script silently fails. Check the network tab first when "jQuery is not defined."
• $ vs jQuery / noConflict. Zikula themes and other bundles sometimes load their own jQuery or Bootstrap. Double-inclusion causes plugin re-registration warnings and $ clobbering. If the bundle or a sibling sets jQuery.noConflict(), wrap your code in (function($){ ... })(jQuery);.
• Load-order bugs are layout bugs. If a plugin reports "jQuery is undefined" only on some pages, the page var was added in a partial that renders before the layout’s jQuery include, or the plugin was added from a block that runs earlier. Fix in the template hierarchy, not by adding jQuery twice.
• Cache invalidation. Zikula caches page vars and asset lists in some configurations. After toggling bundle config (e.g., enabling jQuery UI) clear the cache (php bin/console cache:clear) or you will debug a config change that never took effect.
• Upgrade fragility. Zikula 1.3-era code used System module helpers (JQuery::addJQuery()), while 1.4+ uses page vars / Twig. If you are porting old modules, the API name changes between Zikula majors; verify against the Zikula version you actually run before copy-pasting snippets from old docs.
• Extension point is the asset alias, not the bundle. Do not fork the bundle to change the jQuery version — override the jquery asset mapping or point the page var at your own path. Forking an archived bundle means owning a dead copy.
• No test surface to lean on. With one star and no dependents, there is no community test suite or issue history to consult. When something breaks, verify by inspecting rendered HTML and the browser console rather than searching for known issues.
• Migration exit ramp. For new work, skip this bundle and use Symfony Webpack Encore / AssetMapper (or a direct <script> to a pinned, SRI-checked CDN). Keep this bundle only in the pages that still call the legacy 'jquery' page var, and shrink that set over time.