Easy Admin Pretty Urls Laravel Package

Getting Started

Check whether you need this package at all. If you're on EasyAdmin >= 4.14, stop — native Pretty URLs are built in and this package is now obsolete. If you're on an older EasyAdmin, this is the bridge package you'd install, but understand you're adopting an unmaintained dependency.

Minimal steps:

1. composer require marcin-jozwikowski/easy-admin-pretty-urls — this will pull EasyAdmin pinned below 4.14 (v2.9.3 adds an upper bound in composer.json). If you're already on 4.14+, Composer will fail to resolve; that's the package intentionally stepping aside.
2. Look first at the package README.md in the repo (marcin-jozwikowski/easy-admin-pretty-urls) for the config key names and the entity-level slug setup — there is no Laravel-style config file; configuration is done in your EasyAdmin dashboard/entity code.
3. Read the EasyAdmin 4.14 native Pretty URLs release notes before you write any code. Any time spent learning this package's API should be treated as throwaway work.
4. First real use case: a ProductCrudController (or similar) where you want /admin/products/red-sneakers instead of /admin/products/42.

// Typical shape (verify exact option names against the README)
yield MenuItem::linkToCrud('Products', 'fa fa-box', Product::class);
// ...and set the slug/source field on the CRUD or entity as documented.

Implementation Patterns

Treat this as a transition shim, not a foundation. The only workflows worth documenting are ones you can delete in a single PR.

• Greenfield / upgrading: skip the package entirely. Upgrade EasyAdmin to >= 4.14 and use the native feature. Do not build new CRUDs around this package's API in 2024+.
• Legacy admin currently on this package: it will keep working, but pin your EasyAdmin to whatever < 4.14 version you run today and treat that pin as a project-level decision. Add "easycorp/easyadmin-bundle": "4.13.*" explicitly in composer.json so a composer update doesn't produce a confusing conflict error from the transitive constraint.
• Incremental migration pattern: run both URL schemes for a release. Keep the native (ID-based) CRUD routes live while you build a parallel set of pretty routes via EasyAdmin 4.14, then flip the links and add 301s from the old pretty URLs to the new native ones. This avoids a hard cutover on a Friday.
• Preserve URL stability at the app level, not the package level. Whatever slug logic the package applies, replicate it in your own entity listener/prePersist/preUpdate or Doctrine lifecycle callbacks so that when you uninstall the package, slugs in the database are already correct and unchanged. This is the single most important integration tip: the data should outlive the package.
• Testing: add feature tests that assert your admin URLs resolve and that old URLs redirect. Do this before removing the package, not after. These tests are your safety net for the migration.
• Composer hygiene: if you keep it temporarily, mark it in composer.json as an internal fork or add a replace/inline comment in your team docs so the next developer doesn't assume it's an actively maintained vendor dependency.

Gotchas and Tips

• v2.9.3 is a terminal release. There will be no security patches, no PHP 8.x compatibility fixes, no EasyAdmin 5 support. Any vulnerability or deprecation notice in this package is yours to fix. Plan removal rather than pinning and hoping.
• The version constraint is a hard wall. v2.9.3 explicitly caps EasyAdmin before 4.14. composer require easycorp/easyadmin-bundle:^4.14 and this package cannot coexist. If a composer update suddenly reports an unrelated-looking conflict, this constraint is the culprit.
• You will not get a runtime warning. The package doesn't emit a deprecation notice on boot — obsolescence is only communicated in the release notes. Add a note to your own UPGRADING.md or a tracking issue so the knowledge isn't lost.
• Route cache is the classic debugging trap. After changing slug configuration, run bin/console cache:clear (Symfony) / php artisan route:clear and route:cache in your host app; stale cached admin routes are the usual cause of "my change did nothing."
• Slug collisions. Two entities with the same title will generate the same pretty URL. If the package's built-in uniqueness handling is insufficient, resolve it in your own slug generator (append an ID or short suffix) — don't rely on an unmaintained package to be patched.
• Changing a slug silently breaks bookmarks and external links. If you rename entities or regenerate slugs during migration, emit redirects from old paths. EasyAdmin's native implementation is where you should invest this effort.
• Extension point of last resort. Because there's no maintainer, if you must keep it alive, vendor it (Composer path repository or a fork) rather than depending on the abandoned upstream. A private fork is cheaper than a surprise breakage on a PHP upgrade.
• Debugging tip: since the docs are now the final docs, snapshot the README and the release-notes migration guidance into your repo now — the project "will no longer be maintained," which historically means the repo may eventually be archived or removed.