Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Xeditable Bundle

Xeditable Bundle Laravel Package

ibrows/xeditable-bundle

Symfony bundle that brings X-editable inline editing to your forms and Twig templates, letting users edit fields in place via popups, tooltips, and AJAX saves. Ships form type extensions, Twig helpers, and asset wiring for fast setup.

View on GitHub
Deep Wiki
Context7

At a glance

Frequently asked questions about Xeditable Bundle
Can I install ibrows/xeditable-bundle in a Laravel application?
No. It is a Symfony2 bundle that depends on Symfony's kernel, dependency injection container, form type extensions, and Twig templates, none of which exist in Laravel. There is no service provider, facade, config file, or Blade directive to wire it up. Composer constraints target PHP 5.x and Symfony 2.3 through 2.8, so it will not install cleanly on a modern Laravel stack running PHP 8. Treat it as a reference implementation, not a dependency.
Is ibrows/xeditable-bundle still maintained and safe to use?
It shows no maintenance signal at all: zero stars, zero dependents, Symfony2-era code, and no PHP 8 compatibility. There is no security response process, no CVE history, and no community reviewing releases, which makes it a supply-chain question even under the MIT license. The underlying jQuery x-editable library it wraps is itself unmaintained. Do not add it to a production Laravel application.
What is the x-editable client/server contract for inline editing?
Fields are rendered with data-* attributes such as data-pk, data-name, data-type, data-url, and data-value, which the x-editable jQuery plugin reads. When a user saves, the client sends a request containing a payload of {pk, name, value} to the per-field URL and expects a JSON response back. That protocol, not the Symfony code, is the reusable part you can rebuild in Laravel.
How do I implement inline editing in Laravel without this bundle?
Build a small Blade component that wraps an Alpine.js toggle and PATCHes a value to a per-field route. Pair it with a FormRequest for validation, a policy check for authorization, and a JSON resource returning {success, value, errors}. This is idiomatic Laravel and inherits CSRF protection, validation, and policies for free. Expect roughly two days of work for a vertical slice, far cheaper than porting a dead Symfony bundle.
Does this bundle work with Laravel 10 or 11 and PHP 8.2?
No. The bundle's Composer constraints target PHP 5.x and Symfony 2.x, so it will not even resolve on PHP 8.2, let alone boot. Its Twig form themes and Symfony form type extensions cannot be translated into Blade directives without a rewrite. If you want inline editing on Laravel 10 or 11, implement the pattern yourself or use Livewire.
How should I validate inline edits and return errors to the popover?
Put the rules in a FormRequest per editable field group and return a 422 JSON response with an errors object when validation fails. The Alpine or Livewire component then renders those messages inside the popover next to the input. Old Symfony bundles of this vintage typically returned full HTML error pages that a small inline popover could not display, which is a common source of broken UX.
How do I prevent lost updates when two users edit the same field?
Use optimistic locking: include the row's updated_at timestamp or a version column in the payload the client sends. On the server, compare it against the current value inside a transaction and reject stale writes with a 409 Conflict. The x-editable pattern has no built-in concurrency control, so if you rebuild it in Laravel you must add this yourself.
How do I authorize which fields a user can inline-edit in Laravel?
Use a policy on the underlying model and call the update ability before persisting, then enforce a field allowlist so a request cannot touch columns like email_verified_at or roles. The x-editable payload uses a generic name field, so an unrestricted generic endpoint is an easy mass-assignment hole. Prefer per-resource routes such as PATCH /posts/{post}/{field} with an explicit map of editable fields.
What are the alternatives to x-editable for inline editing in Laravel?
Livewire gives you server-driven inline editing with validation and authorization handled in PHP, and Alpine.js is a good fit for a lightweight Blade component without a full-stack framework. Filament covers inline editing inside admin panels, and Inertia with Vue or React works if you already use that stack. All of these avoid jQuery and the Bootstrap 3 markup that x-editable assumes.
How do I test an inline edit endpoint in Laravel?
Write feature tests that use actingAs to authenticate, send a PATCH or POST with JSON, and assert the database with assertDatabaseHas plus assertJson on the response shape. Cover the failure paths too: 422 for validation errors, 403 for policy denials, and 409 for stale version conflicts. That set of tests is the real replacement for anything the Symfony bundle gave you.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource