- Can I install jims/editor-hub-bundle in Laravel 10 or 11?
- Not as a native Laravel package. The bundle targets Symfony 2/3/4 and pins PHP to >=5.5 || ^7.x with symfony/framework-bundle ~2.8|~3.0|~4.0, while Laravel 10/11 requires PHP 8.1+. Composer will likely fail outright, and forcing it with --ignore-platform-reqs leaves you patching unsupported framework code before writing any product code.
- Is Editor Hub Bundle compatible with Laravel at all?
- No, not natively. It ships a Symfony Bundle class, a DependencyInjection/Extension, and YAML/XML service wiring under Resources/config, with Twig template helpers. There is no ServiceProvider, no publishable config/editor-hub.php, no facade, and no Blade views. The editor-hub abstraction is built entirely on Symfony's DI container and Twig, so none of that value transfers without a ground-up reimplementation.
- How do I install and configure jims/editor-hub-bundle?
- In its intended stack you register the bundle in the Symfony kernel and wire services through the YAML/XML files under Resources/config. There is no documented Laravel installation path, config publishing step, or facade to call. Treat the README as a reference for the concept rather than an integration guide for a Laravel app.
- What does Editor Hub Bundle actually do?
- It advertises a central registry for registering and resolving editors by name, reusable presets for shared toolbar and plugin configuration, pluggable adapters, and template helpers for rendering editors in views. That surface is implemented on Symfony's DI container and Twig. Stripping the Symfony packaging, the transferable content is roughly a catch-all UEditor server endpoint, a config blob, and the JS/CSS assets for Baidu UEditor/UMEditor.
- Is jims/editor-hub-bundle safe for production use?
- Technical risk is high. UEditor's historical upload handlers validated by file extension rather than content type, and stored-HTML XSS is a known class of issue in this editor family. There are no advisories, no CVE process, and no maintainer response for this fork, so a public-facing authoring surface would be a standing risk with no mitigation path. An internal-only admin with authenticated authors materially lowers the exposure.
- What are the alternatives to Editor Hub Bundle for Laravel?
- Tiptap, CKEditor 5, and TinyMCE are the maintained options for general WYSIWYG authoring in Laravel. If CJK-heavy authoring with Word-paste fidelity is the real requirement, UEditor is genuinely differentiated but discontinued, so verify the need survives a migration. If byte-compatible rendering of an existing UEditor content corpus is the goal, treat it as a content audit first and an editor decision second. Rebuilding the small UEditor protocol surface natively in Laravel using file validation, the filesystem abstraction, and routing is roughly an engineer-week or less.
- Does Editor Hub Bundle support PHP 8.1 or newer?
- The package constraints pin PHP to >=5.5 || ^7.x and Symfony framework-bundle to ~2.8|~3.0|~4.0, so PHP 8.1+ is not supported. Symfony 4.4 went EOL in November 2023, and branches 2 and 3 long before that. Adopting it pins your team to an unsupported framework branch either way.
- Can I reuse Editor Hub Bundle's editor registry inside a Laravel service provider?
- The registry is a tagged-service registry built on Symfony's DI container, and no Laravel ServiceProvider equivalent ships with the package. You would have to reimplement the registry concept natively, which removes most of the reason to depend on it. The honest leverage position is to use the package as a reference implementation of the UEditor server protocol, not as a dependency.
- How do I test and maintain a Laravel app that depends on Editor Hub Bundle?
- You would effectively be testing unsupported Symfony code against a Laravel runtime, with no Laravel test suite or maintenance commitment behind it. The editor is iframe-based, relies on deprecated DOM APIs, and its last meaningful releases predate 2018, so behavior on current Chrome and Safari is untested by anyone. There is no funded exit path, which makes long-term maintenance a real cost rather than a hypothetical.
- What should I verify before adopting jims/editor-hub-bundle?
- Confirm the package identity first: the repo name askuiop/JimsEditorHubBundle does not obviously match the jims/ vendor namespace, and with 10 stars and zero dependents the metadata could be stale, so check that the Composer package name resolves. Then answer what requirement is actually driving this, since general WYSIWYG, CJK-heavy Word-paste fidelity, and byte-compatible rendering of an existing UEditor corpus each lead somewhere different. Sample any existing authored content to size the sanitization and rendering-compatibility work, and decide whether the surface is internal or public. Have a funded exit plan stating what you know you will replace it with.