Ckeditor Lineutils Bundle Laravel Package

Getting Started

This bundle wires the CKEditor lineutils plugin (a helper library used by widget/widgetselection) into a Symfony 2-era application. With one star and zero dependents, treat it as a thin asset shim rather than a maintained integration.

Minimal steps:

composer require stinger/ckeditor-lineutils-bundle

Register the bundle in app/AppKernel.php:

$bundles = [
    // ...
    new Stinger\CKEditorLineUtilsBundle\StingerCKEditorLineUtilsBundle(),
];

Then publish assets so CKEditor can resolve the plugin path:

php app/console assets:install --symlink

First use case: enabling line-based selection helpers required by widget. In a config.yml-driven CKEditor setup (e.g. stfalcon/tinymce-bundle-style or a global ckeditor service), add:

# config.yml
ckeditor:
    extra_plugins: ['lineutils', 'widget', 'widgetselection']

Where to look first: composer.json (Symfony version constraints, the type: symfony-bundle block), the root StingerCKEditorLineUtilsBundle.php class (getContainerExtension, getPath), and Resources/public/ — that folder contains the upstream LineUtils plugin JS and is the only thing actually shipped. If the JS isn't in Resources/public/js/plugins/lineutils/plugin.js, the bundle is inert.

Implementation Patterns

1. Pair it with Widget, never alone. LineUtils is not user-facing. It registers CKEDITOR.plugins.lineutils and provides findLine, decorate, isLineEmpty, etc. that widget and drag/drop plugins consume. Enabling lineutils on its own does literally nothing visible — always enable it in a plugin group alongside widget:

CKEDITOR.replace('editor1', {
    extraPlugins: 'lineutils,widget,widgetselection',
    removePlugins: 'elementspath'
});

2. Bundle-as-asset-provider, config-as-CKEditor-config. The bundle does not call CKEditor's replace() for you. Typical flow: Twig template renders a <textarea data-ckeditor> and a small JS init reads an extraPlugins string from a Twig global or a Symfony parameter:

// AcmeBundle/Resources/views/editor.html.twig
<script src="{{ asset('bundles/stingerckeditorlineutils/plugins/lineutils/plugin.js') }}"></script>

Adjust the path to match whatever the bundle actually publishes (inspect Resources/public/ after assets:install before wiring this).

3. Symfony 2/3 lifecycle. assets:install (Symfony 2) or bin/console assets:install (Symfony 3) must be run on every deploy after composer updates; --symlink is fine for dev but brittle on ephemeral containers. In CI, use assets:install web --relative and commit the resulting web/bundles/ output if you can't guarantee a writable webroot.

4. Alternative when the bundle is overkill (recommended for any greenfield work). Modern Symfony (4+) apps should skip the bundle entirely:

npm i ckeditor4 ckeditor-lineutils   # or vendor the plugin JS directly

import 'ckeditor4/plugins/lineutils/plugin.js';
// configure extraPlugins: 'lineutils,widget'

Or pull from CDN with CKEDITOR.plugins.addExternal('lineutils', '/vendor/lineutils/plugin.js'). This removes the Symfony-version coupling entirely.

Gotchas and Tips

• Symfony 2 is EOL. The bundle's composer.json almost certainly pins symfony/symfony: ~2.x or ~3.x. Composer 2 will refuse to install on Symfony 4/5/6 without --ignore-platform-reqs-style workarounds, and even then the bundle class API (bundle command, assets:install target) is gone. Budget for a migration, not a drop-in.
• Zero dependents, one star = no upstream safety net. Read Resources/public/*/plugin.js against the upstream CKEditor LineUtils source (ckeditor/ckeditor4) to verify the version. LineUtils had API drift between CKEditor 4.4 and 4.5+; a stale vendored copy silently breaks widget drag handles.
• lineutils requires widget — in that order. If widgetselection or widget is listed before lineutils in extraPlugins, you'll see CKEDITOR.plugins.lineutils is undefined in the console when a widget initializes. Order: lineutils,widget,widgetselection.
• Asset path drift. Bundle short names in Symfony 2 are auto-lowercased and underscored. StingerCKEditorLineUtilsBundle publishes to web/bundles/stingerckeditorlineutils/. Confirm with bin/console debug:asset or by listing the directory — this is the #1 source of "plugin works in dev, 404s in prod" reports.
• MPL-2.0 is file-level copyleft. Modifying plugin.js (e.g., patching a LineUtils bug yourself) means you must publish your modified file under MPL-2.0. Simply loading it from a Symfony app is fine; bundling it into your build is also fine. Keeping the unmodified file in vendor/ and vendoring via npm is the cleanest compliance path.
• Debugging CKEditor plugin load failures. In the browser console, log CKEDITOR.plugins.registered — if lineutils is absent, the script tag or extraPlugins config is wrong. If it's present but widgets still break, check CKEDITOR.plugins.lineutils.finder initialization in config.widget (the widget plugin sets it).
• Extension point to prefer: rather than relying on this bundle to expose the JS, override the publish path via getPath() or, more simply, register your own Twig function pointing at vendor/ckeditor-lineutils/plugin.js. You retain full control of version and won't inherit the bundle's release cadence (which is likely zero).
• Don't add this to a new project. Given 1 star, 0 dependents, an MPL-2.0 wrapper whose actual content is a 20 KB JS file from CKEditor, and a dead framework target — the correct "day-two" move is to remove the dependency and vendor the plugin directly or via npm.