Statamic Backlinks Laravel Package

Technical Evaluation

Architecture fit

• The presence of Antlers tags, a control-panel dashboard widget, and an entry sidebar identifies this as a Statamic addon (Statamic is a Laravel package), not a framework-agnostic Laravel library. Fit should be assessed against the Statamic version, not Laravel alone.
• The feature set implies four architectural layers: (1) a content parser for [[Page Title]] / [[Page Title|Display Text]], (2) a persisted link-graph index with reverse lookups, (3) write-path behavior (creating pages from missing links, missing-link styling), and (4) CP presentation (widget, sidebar) plus read-path templating (backlinks tag, wiki_links modifier).
• The backlinks:rebuild command is the strongest architectural signal: the link graph is a derived index stored outside the content source. That is the correct design for query performance, but it introduces a second source of truth that can drift.

Integration feasibility

• Greenfield install is low-friction: Composer require, publish config, enable per-collection via collections config, optional CSS class overrides. No data migration of existing content is required beyond running backlinks:rebuild.
• Configurable collections/fields keeps blast radius small — we can pilot on one collection rather than site-wide.
• The main unknown is where the index lives (custom Eloquent table vs. cache driver) and whether it is scoped per-site.

Technical risk

• v1.0.0 with no prior release history. No track record on upgrade discipline, security response, or breaking-change policy. Treat as unproven despite a coherent feature set.
• Index staleness is the dominant risk: bulk imports, content restores, entry renames/slug changes, and multi-site propagation may not all fire the events the index listens to.
• Parser ambiguity: [[...]] is not Markdown-standard; risk of collision with existing shortcode/Bard/Replicator content or literal bracket usage in code samples.
• Write-path exposure: "page creation from missing wiki-links" is a content-author-triggered write. If it runs under the requesting user's permissions rather than a scoped system context, it becomes an authorization surface.
• Missing-link "visual styling" implies runtime resolution of potentially unbounded link targets on render — a per-request cost that needs measuring.

Key questions

1. Where is the backlink index stored, and is it scoped per site in multi-site installs?
2. Are links extracted on entry save, on render, or both — and which events trigger reindexing (save, publish, rename, delete, revision restore, import)?
3. What happens to backlinks when a target entry's title or slug changes — are they auto-retargeted, or silently orphaned?
4. Does missing-link page creation inherit the acting user's permissions, and what collection/default field values does it assign?
5. Does the parser operate on Markdown fields, Bard/Replicator sets, or both?
6. What are published performance characteristics at 10k / 100k entries for backlinks:rebuild and for entry-sidebar rendering?
7. Licensing, support model, and stated backward-compatibility policy for 1.x.
8. Is there an upgrade path if we later adopt a different wiki-link implementation?

Integration Approach

Stack fit

• Requires a Laravel + Statamic stack (PHP 8.1+ class). Confirm the exact Statamic major supported; addons commonly pin to one major.
• No additional infrastructure assumed — the rebuild command suggests storage reuses the existing database (or cache), so no new service to operate.
• CSS classes being configurable is a good sign of non-invasive theming; it should integrate with our existing asset pipeline rather than forcing a stylesheet.

Migration path

• We have no existing wiki-link content, so this is a greenfield adoption, not a migration. The reverse case — extracting ourselves later — is the real migration risk, since [[...]] syntax would be embedded in author-written content.
• Pre-adoption, run a scan for existing literal [[ occurrences in Markdown/Bard fields to size the false-positive surface before enabling parsing.
• Backfill is a single backlinks:rebuild; this must be scripted, timed, and repeatable in our deploy runbook, not left as a manual step.

Compatibility

• Verify against our Statamic version, our Eloquent-vs-flat-file content driver, and our multi-site configuration (if multi-site, confirm per-site backlink scoping before pilot).
• Check for namespace/tag collisions with any existing shortcode or Markdown extension already registered.
• Confirm the CP widget and sidebar assets build cleanly under our CSP and admin asset pipeline.

Sequencing

1. Install in a staging environment; run the literal-[[ scan; measure backlinks:rebuild duration against a production-sized content copy.
2. Enable on one non-critical collection with a small author group.
3. Validate: backlink accuracy after edit, rename, delete, and restore; missing-link styling; permission behavior on page creation.
4. Add backlinks:rebuild to the deploy/restore runbook before any content restore or bulk import.
5. Expand to remaining collections; only then enable the dashboard widget, which is the most visible and most query-heavy surface.

Operational Impact

Maintenance

• Single-maintainer, v1.0.0-class dependency: pin to an exact minor, review the changelog before every bump, and keep the config file in version control for drift detection.
• Our team owns the rebuild runbook and the post-restore/post-import reindex step — that is permanent operational overhead regardless of how stable the addon becomes.
• Budget a modest, ongoing allowance for upstream lag on Statamic major upgrades.

Support

• Presumably community/author-supported with no SLA. Escalation path is the upstream repo, which is thin for a 1.0.0.
• Internal mitigation: fork-and-patch contingency is realistic for a small addon, but only if the code stays small — worth a one-time review of codebase size and complexity.
• Editors will need a short runbook on syntax and on what "missing link" means; there is no autocomplete mentioned, so authoring errors will be common early.

Scaling

• Index size grows linearly with link count; query cost depends on indexing of the backlink table. Confirm indexes on target and source columns.
• backlinks:rebuild is linear in entry count and will be the long pole during large restores — plan for it to run outside request handling, with a maintenance window or queue job.
• Entry-sidebar and dashboard-widget rendering add per-admin-page cost; the dashboard widget in particular can aggregate across all content and should be load-tested before wide release.

Failure modes

• Index drift after imports, restores, rename/slug changes, or multi-site propagation — surfaces as wrong or missing backlinks, typically noticed by authors rather than monitoring. Mitigation: scheduled backlinks:rebuild and a post-restore hook.
• Silent orphaning on title change: backlinks pointing at the old title may become "missing links," potentially triggering well-meaning authors to recreate duplicate pages.
• Duplicate page creation from missing links — needs a guard rail (naming convention, review step, or restricted to editors) before enabling for all authors.
• Authorization gap if page creation bypasses normal collection permissions.
• Render-time parsing cost on high-traffic front-end pages using the wiki_links modifier; cache rendered output where feasible.
• False-positive parsing of literal [[ in code blocks or technical entries.

Ramp-up

• Author training is light but non-zero: syntax, display-text variant, and the meaning of missing-link styling — roughly a single short doc plus a demo in the pilot collection.
• Developer ramp-up is low (standard addon install and config), but the on-call runbook entry for backlinks:rebuild needs to exist before launch, not after the first incident.
• Recommend a 2–3 week pilot on one collection before site-wide enablement, gated on passing the rename/delete/restore accuracy checks and a production-scale rebuild timing test.