Ckeditor Notificationaggregator Bundle Laravel Package

Getting Started

This is a Symfony2-era bundle that ships the CKEditor 4 notificationaggregator plugin as bundle assets and (typically) a small DI extension so you can reference it from templates. There is no Symfony Flex recipe and no maintained release line, so treat it as "vendor a plugin + a thin Symfony wrapper" rather than a framework component.

Minimal setup:

composer require stinger/ckeditor-notificationaggregator-bundle
# pin explicitly, there is only a 2015-era release:
# composer require stinger/ckeditor-notificationaggregator-bundle:1.0.*

Register the bundle in app/AppKernel.php (Symfony 2.x only — it will not autoload cleanly under Symfony 4+/Flex):

public function registerBundles()
{
    $bundles = [
        // ...
        new Stinger\CKEditorNotificationAggregatorBundle\StingerCKEditorNotificationAggregatorBundle(),
    ];
}

Publish the assets so the browser can actually fetch plugin.js:

php app/console assets:install web --symlink

Where to look first, in this order:

1. Resources/public/ — this is the real payload: the CKEditor plugin files (plugin.js, lang/, icons). Everything else is plumbing.
2. Resources/views/ — check for an include/partial you can drop into your base template, or just inline the <script> tag yourself.
3. DependencyInjection/ and Resources/config/ — see whether there is anything configurable (asset path, plugin name) or whether it is a no-op extension.
4. README.md — for the exact CKEditor config key names, if any are prescribed.

First real use case — wire the plugin into an existing editor and show a progress notification:

{# base.html.twig #}
<script src="{{ asset('bundles/stingernotificationaggregator/plugin.js') }}"></script>

CKEDITOR.replace('body', {
    extraPlugins: 'notificationaggregator'
});

var editor = CKEDITOR.instances.body;
var aggregator = editor.plugins.notificationaggregator.create('Uploading attachments');
aggregator.on('finished', function () { /* ... */ });

If that renders a notification and no 404 appears in the network tab, the bundle is doing its job.

Implementation Patterns

Asset-only integration (the common case). Most projects never touch the bundle's PHP; they just need the plugin JS on the page next to CKEditor. Include it once in your admin/base layout, after ckeditor.js and before editor instantiation, then declare extraPlugins: 'notificationaggregator' on each editor instance. Keeping the include in one layout avoids double-registration when multiple editors exist on a page.

IvoryCKEditorBundle / CKEditor bundle integration. If your editors are configured through a bundle config block, add the plugin there instead of per-instance:

# config.yml
ivory_ck_editor:
    default_config: default
    configs:
        default:
            extraPlugins: 'notificationaggregator,notification'

The notification core plugin is the dependency the aggregator drives; confirm it is present in your CKEditor build (it is in standard/full, not in basic).

Task-based aggregation workflow. The plugin's value is grouping N async operations into one UI element. The day-to-day pattern is: create one aggregator per user action, register a task per unit of work, update and finish each task, and listen on finished to reload or redirect.

var agg = editor.plugins.notificationaggregator.create('Saving images');

var task = agg.createTask('image-1');
task.on('updated', function (evt) {
    // evt.data.progress in 0..1
});
task.update(0.4);
task.done();
// when all tasks reported done:
agg.on('finished', function () { editor.fire('saveSnapshot'); });

Wrapping it as a service/helper. Rather than repeating editor.plugins.notificationaggregator lookups across templates, expose a small JS helper (window.ckNotify = function (editor, label) { ... }) in your asset pipeline and call it from page-specific scripts. That is the only "abstraction" worth building here.

Asset override via bundle inheritance (Symfony 2). If you need a newer plugin build, create a child bundle with the same name in your src/, place your plugin.js under its Resources/public/, and register the child instead. Symfony 2 bundle inheritance will shadow the vendor file without you forking the package.

Deployment workflow. In dev use assets:install --symlink so plugin edits are picked up live; in prod run assets:install web --relative and include the generated path in your asset versioning/cache-busting scheme.

Gotchas and Tips

• Symfony 2 only. Last release was December 2015; the bundle predates PSR-4 conventions and Flex. On Symfony 3+ you will likely hit autoload or getContainerExtension issues. If you are on a modern stack, skip the bundle entirely and copy Resources/public/ into public/js/ckeditor/plugins/notificationaggregator/.
• Plugin directory name must match. CKEditor resolves extraPlugins: 'notificationaggregator' by looking for plugins/notificationaggregator/plugin.js under CKEDITOR.basePath. If the bundle publishes it as bundles/stingernotificationaggregator/plugin.js, either set CKEDITOR.plugins.addExternal('notificationaggregator', '/bundles/.../plugin.js') or copy it into the correct subdirectory. A wrongly-pathed plugin fails silently — the editor loads, the feature just never appears.
• assets:install is mandatory. Forgetting it produces 404s on plugin.js that only show up in the browser network panel, not in Symfony logs.
• Order of includes matters. Load ckeditor.js → plugin script → instantiate editor. Loading the plugin script before CKEditor throws CKEDITOR is not defined.
• notification vs notificationaggregator. The aggregator depends on CKEditor's core notification plugin; basic-preset builds omit it. Add both to extraPlugins if you are unsure which preset you use.
• Version pin the dependency. With one 2015 tag and zero dependents, composer update can silently jump to a dev-master from a stale branch. Pin to a tag or a specific commit hash in composer.json.
• Debugging steps that actually work. In the console: CKEDITOR.plugins.get('notificationaggregator') (undefined = not loaded), CKEDITOR.instances.<name>.config.extraPlugins (verify your config merged and was not overwritten by an instance-level config), and check editor.plugins.notificationaggregator exists before calling create(). If create() throws, the plugin loaded but its dependency did not.
• Aggregator lifecycle. An aggregator created and never finished will leave a stuck notification in the editor UI. Always done() tasks in both success and error branches, and call aggregator.finished()/remove on failure so users are not left with a spinner.
• License check. MPL-2.0 applies to the bundled plugin files; if you redistribute a modified plugin.js, keep the license header and note changes. The thin PHP wrapper is trivial, but the CKEditor plugin code is the licensed part.
• Extension points are intentionally thin. There is essentially nothing to configure — no meaningful DI parameters, no events. If you need to change behavior, fork Resources/public/plugin.js via a child bundle rather than trying to bend the bundle config, and consider vendoring the plugin directly to drop the abandoned dependency.