Sortable Columns Laravel Package

Technical Evaluation

Architecture fit

Poor. zikula/sortable-columns is a micro-component from the Zikula CMS ecosystem, not a general-purpose PHP library. Its job is narrow: produce clickable table column headers that toggle sort direction and carry the correct query parameters. In practice that means it is coupled to Zikula's conventions — module variables, the Zikula service container, legacy request/session helpers, and the Zikula translation layer — rather than to PSR-7/PSR-15 abstractions or plain Symfony components. A Laravel application shares almost no surface area with those assumptions, so adopting the package means importing Zikula's idioms into a Laravel codebase rather than fitting a library to our stack.

Integration feasibility

Low, and not worth the effort. Realistic options:

• Install as-is — blocked. The package's runtime dependencies pull in Zikula core/legacy packages that are themselves end-of-life and will not install cleanly on PHP 8.2+ alongside Laravel 10/11 (Symfony 6+). composer require would likely fail or produce an unresolvable conflict.
• Fork and patch — technically possible but means owning a fork of a 1-star, zero-dependent, archived package. We would be maintaining a shim layer to emulate Zikula request/session semantics purely for table headers.
• Reimplement — the only sane path. The behavioural surface is small and well understood: track a sort and direction parameter, whitelist against allowed columns, render <a> elements with preserved query string, and render an asc/desc indicator. That is a Blade component plus a small query-scope helper — a day or two of work, fully owned and tested.

Technical risk

• Abandonment: last release January 2020, repository archived. No security response, no PHP 8 compatibility work, no Symfony/Laravel alignment.
• Ecosystem dead-end: Zikula Core is effectively dormant; adopting this ties a table-rendering concern to a framework we will never run.
• Low signal: 1 star and 0 dependents means no community validation, no third-party bug reports, and no documented usage patterns beyond whatever the Zikula modules happened to do.
• Injection surface (if reimplemented carelessly): the entire value of this component is passing a column name into a query's ORDER BY. Any implementation must whitelist columns server-side; the package's era of PHP makes it unlikely to model that defensively, and copying its approach verbatim would be risky.
• The scores are not a green light: the composite score of 0.0025 is the meaningful number. The 17.3 "opportunity" figure almost certainly reflects how common the problem is (every data table needs sortable headers), not the merit of this solution.

Key questions

1. Do we have any existing Zikula modules in the estate that already consume this, or is this a greenfield consideration? (If greenfield, stop here.)
2. What is the actual requirement — header link generation only, or also sort-state persistence across pagination, filters, and sessions?
3. Does our design system already specify sort indicators and accessible aria-sort semantics? If so, the package's markup is a liability, not an asset.
4. Are we prepared to own a fork indefinitely, including PHP upgrades, with zero upstream support?
5. Which columns need sorting, and are they all safe to sort (indexed, non-computed, non-user-controlled)?

Integration Approach

Stack fit

Conceptually compatible, technically incompatible. Laravel's request object, URL::current()/request()->fullUrlWithQuery(), Blade components, and Eloquent/query-builder scopes cover every capability this package offers, with first-class sorting-parameter handling and no framework crossover.

Migration path

There is no data migration — the package holds no state of its own beyond request parameters. The path is behavioural parity, not porting:

1. Inventory existing sortable tables and the exact parameter names and defaults in use (sort, direction, or legacy Zikula variants).
2. Build an internal primitive: a SortableColumn value object or Blade component that takes column key, label, current sort, current direction, and base URL; emits a link with toggled direction and preserved query string, plus aria-sort and an icon slot.
3. Add a server-side guard: a Sortable trait or applySort() macro on the query builder that whitelists columns and directions before orderBy.
4. Wire it in to index controllers/resources, replacing any Zikula-era helper calls.
5. Retire the dependency — do not vendor or fork the package.

Compatibility

• PHP: target 8.2/8.3; the package predates these and is untested on them.
• Laravel: 10/11 Blade and query builder; no conflicts because nothing is actually shared.
• Markup/accessibility: the 2020-era output will not meet current aria-sort expectations; the reimplementation is an accessibility upgrade, not a regression.

Sequencing

Ship the internal component behind a feature flag on one table first, confirm sort state survives pagination and filter changes, then roll out. Treat the archived package as documentation of intent, not as a dependency to install.

Operational Impact

Maintenance

Adopting this package converts a two-day build into an indefinite fork-maintenance obligation on an archived, single-star project. Reimplementing keeps the code inside our normal upgrade cadence (PHP and Laravel majors) and inside our test suite.

Support

None available. No maintainer, no issue triage, no security advisories. Any defect becomes an internal ticket with no upstream escalation path.

Scaling

Performance is a non-issue — it is presentation-layer link generation. The scaling concern is the query side: sorting on unindexed or computed columns at volume is a database problem the package does nothing to address. Enforce a whitelist of indexed sortable columns and consider capping sortable sets on large tables.

Failure modes

• SQL injection via ORDER BY if column names are passed through from the request without whitelisting — the highest-severity risk in this whole area.
• Parameter loss on pagination or filter changes, causing the sort to silently reset.
• State desync between the rendered icon and the actual query order when defaults and request values diverge.
• Composer resolution failure at install time on modern PHP, surfacing as a blocked build rather than a runtime bug.
• Silent abandonment: the package installs today and quietly stops receiving fixes, leaving an unaudited surface in the dependency tree.

Ramp-up

Low either way — the API surface is tiny. The difference is what the team learns: with the package, engineers must learn Zikula's module/request/session idioms that have no reuse elsewhere in our stack; with a reimplementation, they learn our own Blade component and query-scope conventions, which pay off across every table in the product.