Sortable Behavior Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony2/SonataAdminBundle Dependency: The package is tightly coupled with SonataAdminBundle, a legacy Symfony2 admin generator. If the project uses Symfony 5/6/7 or API Platform, EasyAdmin, or Adminer, integration may require significant abstraction or custom development.
• Doctrine ORM/MongoDB Support: Works with Doctrine ORM (default) or MongoDB, but lacks native support for Doctrine DBAL, Elasticsearch, or CouchDB, which could be a limitation for non-relational projects.
• Admin-Only Scope: Designed exclusively for admin/listing UIs—not suitable for frontend sorting (e.g., React/Vue drag-and-drop) without custom bridging.

Integration Feasibility

• SonataAdminBundle Required: If not already in use, adopting this bundle would add ~50MB+ of dependencies (SonataAdmin + Doctrine extensions), increasing complexity.
• Template Overrides: Custom templates (e.g., _sort_drag_drop.html.twig) may clash with existing themes or require CSS/JS overrides.
• Position Field Flexibility: Supports custom field names (order, rang, etc.), but schema migrations would be needed for existing tables.

Technical Risk

• Abandoned Maintenance: Last release in 2017—risks include:
  • Compatibility with Symfony 5+ (deprecated features like AppCache).
  • Security vulnerabilities in transitive dependencies (e.g., old Symfony components).
  • No PHP 8.x support (potential deprecation warnings).
• Drag-and-Drop Limitations: The drag-drop feature relies on jQuery UI Sortable, which may conflict with modern SPAs or require polyfills.
• No API Endpoints: Sorting is UI-driven; backend logic (e.g., bulk reordering) must be manually implemented.

Key Questions

1. Is SonataAdminBundle already in use? If not, is the overhead justified?
2. What’s the current sorting UX? Does it need drag-and-drop, or are up/down buttons sufficient?
3. Database Schema: Are position/order fields already defined, or will migrations be required?
4. Symfony Version: Will this work with Symfony 5+ without forks or patches?
5. Alternatives: Could Vue Draggable + custom API endpoints (e.g., using API Platform) achieve the same result with less technical debt?
6. Performance: How will sorting scale for large datasets (e.g., 10K+ records)?

Integration Approach

Stack Fit

• Best Fit: Symfony2 projects using SonataAdminBundle with Doctrine ORM/MongoDB.
• Partial Fit:
  • Symfony 5/6/7 projects could integrate it via legacy bridges (e.g., symfony/legacy-bundle), but this is not recommended due to maintenance risks.
  • Projects using EasyAdmin, Adminer, or Filament would need custom adapters to replicate functionality.
• Unfit:
  • Headless APIs (e.g., API Platform, NestJS).
  • Modern SPAs without server-side admin panels.

Migration Path

1. Assess Current State:
   • Audit existing sorting logic (e.g., manual SQL ORDER BY, custom JS).
   • Check if position/order fields exist in the schema.
2. Dependency Setup:
   • Install via Composer:

     composer require pixassociates/sortable-behavior-bundle
     

   • Add to AppKernel.php (Symfony2) or bundles.php (Symfony Flex).
3. Configuration:
   • Define pix_sortable_behavior in config.yml (see README).
   • Override templates if drag-and-drop is needed.
4. Admin Class Integration:
   • Extend SonataAdmin classes to include sortable fields:

     protected function configureListFields(ListMapper $listMapper) {
         $listMapper->add('_action', 'actions', [
             'actions' => ['move' => ['template' => 'PixSortableBehaviorBundle:Default:_sort_drag_drop.html.twig']]
         ]);
     }
     

5. Testing:
   • Verify sorting works in dev/staging.
   • Test edge cases (e.g., concurrent edits, large datasets).

Compatibility

• Symfony2: Native support (targeted version).
• Symfony 3/4: May work with minor tweaks (e.g., Twig syntax).
• Symfony 5+: High risk—requires:
  • Replacing deprecated services (e.g., security.context).
  • Updating Twig templates to Symfony 5’s stricter sandboxing.
• Doctrine: Works with ORM/MongoDB; no support for other DBALs.
• Frontend: Relies on jQuery UI Sortable—ensure no conflicts with existing JS.

Sequencing

1. Phase 1: Implement basic up/down buttons (lowest risk).
2. Phase 2: Add drag-and-drop (requires template overrides + JS).
3. Phase 3: Extend to custom entities (if using sortable_groups).
4. Phase 4: (If needed) Build API endpoints for frontend sorting.

Operational Impact

Maintenance

• High Ongoing Risk:
  • No active maintenance means security patches must be backported manually.
  • Symfony upgrades may break compatibility (e.g., Twig, Doctrine).
• Workarounds:
  • Fork the repo and maintain it internally.
  • Replace with a modern alternative (e.g., Vue Draggable + custom API).
• Dependency Bloat: SonataAdminBundle adds ~50+ dependencies, increasing attack surface.

Support

• Community: Limited to 47 stars and no open issues—suggests low adoption.
• Documentation: Outdated (last updated 2017); SonataAdminBundle’s cookbook may not align with current Symfony.
• Debugging:
  • Vague error messages if integration fails.
  • No official support channel (MIT license = "use at your own risk").

Scaling

• Performance:
  • ORM: Sorting via ORDER BY position is efficient for small-to-medium datasets (<50K records).
  • MongoDB: Similar performance, but indexing position is critical.
  • Large Datasets: May require database-level optimizations (e.g., indexed fields, batch updates).
• Concurrency: No built-in locking—race conditions possible if multiple users sort simultaneously.
• Caching: SonataAdmin’s cache may need tuning for frequent sorts.

Failure Modes

Ramp-Up

• Developer Onboarding:
  • 1–2 days to integrate into existing SonataAdmin classes.
  • Additional 1–3 days for drag-and-drop customization.
• Key Learning Curve:
  • SonataAdmin’s ListMapper and action system.
  • Twig template inheritance for overrides.
• Testing Overhead:
  • Manual testing of sorting UX (no built-in test helpers).
  • Performance testing for large datasets.