EasyAdmin Pro

Locks that take care of themselves

The lock is acquired when the edit page loads, refreshed by a heartbeat every 30 seconds and released the moment the user submits the form or leaves the page. If the browser crashes, the lock expires on its own after its TTL and the next editor takes it over. Meanwhile, the locked page polls in the background and redirects the waiting user to the form the instant the record is free, with a warning banner if the network drops in between.

Takeovers with rules, not surprises

Sometimes the lock owner went to lunch. A user can take over a lock, after an explicit confirmation, only if they hold every role the owner had when the lock was acquired, checked through Symfony's access decision manager so your custom voters apply. A lock with no recorded roles refuses every override.

The previous editor finds out on their next heartbeat: a banner names who took over, the save buttons are disabled, and any submit that still reaches the server is rejected.

Field-level diffs, recorded automatically

Every create, update, delete and restore of your Doctrine entities is captured by a Doctrine listener, without touching your entities or controllers. Each entry stores the old and new value of every changed property, including owning-side associations, together with the actor (resolved from the security token, the running console command, or the system), the client IP address and any metadata you attach. Soft deletes are recognized (deletedAt by convention, configurable per entity) and recorded as deletes and restores instead of anonymous updates.

Browse the history without leaving your admin

A ready-made interface mounts on any admin route with a controller of two lines. Filter by action, actor type, actor and date range (down to the time of day), search in free text, and click any actor name to filter by that person. Timestamps are displayed in the viewer's local timezone. User names, avatars (custom URL or Gravatar), page size and date formats are configured with a fluent configureAuditLog() method, like everything else in EasyAdmin.

Proof, not just records

Most audit logs are just another table: anyone with database access can edit or delete a row and nobody will ever know. Here, every entry is signed and linked to the one before it, so the whole history forms a chain. Change a single value, delete a row or slip one in the middle, and easyadmin:audit-log:verify points at the entries that were touched; run it on a schedule and alert on its exit code. Signed checkpoints seal the chain at regular intervals: export them to write-once storage (Amazon S3 Object Lock, Azure immutable blobs) and not even your database administrator can rewrite the past.

See the failure, fix it in place

The list opens filtered by what needs attention: failed, retrying and stale messages. Each row opens a side panel with the error, the stack trace, the payload (if you opt in) and every earlier attempt of the same message. Retry sends the message back through its original transport and finds the right failure transport on its own, even if you use several; Remove discards it for good. Both update the list and the panel without reloading the page.

Find the one message you're looking for

The status filter shows how many messages sit in each status before you click anything. Search by message class, error text or transport, narrow it down to the incident window with the date filter, and turn on auto-refresh to watch a retry go through live. Statuses tell the truth: a message stays pending until every transport has accepted it, and wait and handle times are recorded to the millisecond, whatever your database's date precision.

Built for production volume

Two recording modes: minimal (the default) writes one row per message attempt with its outcome, for high-throughput systems; full records the whole lifecycle, in-flight messages included. Sampling is deterministic per message, so a message is either tracked from start to finish or not at all. Include or exclude messages by class or interface, with a PHP attribute, or per dispatch. Per-status retention is enforced by a prune command you schedule.

One field, every page

MarkdownEditorField::new('body') is all it takes. On new and edit pages the field loads the editor; on detail pages the Markdown is rendered inline; on index pages a compact "View content" button opens the rendered document in a modal, so long texts don't break your tables. setNumOfRows(), setLabel(), setHelp(), setColumns() and the rest of the field API work as with any built-in field.

# Release notes
<script>steal(document.cookie)</script>
<img src="logo.png" onerror="alert(1)">
[Read more](javascript:alert(1))
<iframe src="https://evil.example"></iframe>

marked + DOMPurify

<h1>Release notes</h1>
<img src="logo.png">
<a>Read more</a>
<!-- script and iframe removed -->

Sanitized output, unmodified source

Rendering happens in the browser with marked, and the resulting HTML goes through DOMPurify before it's inserted into the DOM: <script> tags, inline event handlers and other dangerous markup are removed. The raw Markdown is stored unchanged in your database, so your public site can render it with any processor you like.