arturrossbach/statamic-linkwise
Linkwise adds link management to Statamic: scan your content for broken or outdated URLs, review results in the control panel, and keep redirects and references tidy so visitors never hit a dead end. A lightweight addon for keeping large Statamic sites healthy.
Architecture fit. The package is a Laravel link-integrity/inventory tool with a bundled admin UI (Overview, Links, Broken Links pages) that tracks entries, orphaned pages, inbound/outbound link coverage, and broken links, with first-class multilingual support. That makes it a content-operations concern rather than a runtime dependency: it sits alongside the CMS/content layer, reads the link graph, and exposes aggregate reporting to editors and SEO stakeholders. It fits a Laravel monolith or a modular Laravel app that owns its content model. It is a poor fit for headless/API-only deployments where editors never see Blade/Livewire admin screens, unless the underlying data is queried programmatically.
Integration feasibility. Low-to-moderate. Typical shape: composer require, publish config and migrations, run migrations, gate the admin routes behind existing authorization, and schedule the crawl/aggregation command. The v1.3.0 work is additive and internal to the UI — a locale filter on Overview stats plus restoration of the per-language entry-count chips — so it does not change the integration surface. Real effort sits in the data-model questions: what the package treats as an "entry," how it resolves a locale, and whether it can see every content type that participates in the link graph.
Technical risk. Moderate, concentrated in two places. First, correctness of locale scoping: the release fixes stats that were previously computed across all languages, which means any pre-1.3.0 numbers used for reporting were blended and are not comparable to post-upgrade numbers. Any dashboard, export, or stakeholder KPI built on those aggregates has a silent discontinuity at upgrade. Second, quality signal: the entry-count chips were invisible from 1.2.0 to 1.3.0 — a user-visible regression that survived a full minor release, which suggests thin UI test coverage and a manual QA gate. Treat future minor bumps as requiring visual verification, not just green CI.
Key questions. Is "locale" derived from the app locale, the entry's translation record, or a per-domain mapping? Does the "All languages" view now issue one aggregate query per locale, and what is the query cost at scale? Are stats precomputed/cached, and if so does the locale filter invalidate or partition the cache correctly? Do orphaned and broken-link detection run per locale, and can an entry be orphaned in one language but linked in another? Is there an API, artisan command, or event surface for consuming stats outside the UI? What is the supported Laravel/PHP version matrix, and is the admin UI Blade, Livewire, or Inertia (which affects upgrade friction on Livewire/Inertia majors)? Does the package have a documented deprecation policy?
Stack fit. Assumes a conventional Laravel app (Laravel 10/11-era, PHP 8.1+) on MySQL or Postgres with a queue worker available for crawl/aggregation jobs. Multilingual capability implies compatibility with a translation strategy — likely per-locale route groups or a translation package — but the release notes do not name a supported localization library, so that must be confirmed before committing. If the admin UI is Livewire or Inertia, pin those majors and check the package's constraints before upgrading the host app.
Migration path. Additive: install into a staging clone, publish and diff config and migrations against existing schema (watch for tables or columns that collide with existing link tables), run migrations, seed/backfill via the crawl command, then verify Overview numbers against a hand-counted sample page set for one locale before enabling "All languages."
Compatibility. The 1.3.0 change is non-breaking for code, but breaking for interpretation: pre-upgrade Overview figures are all-languages aggregates. Snapshot or annotate any dashboards sourced from them and state the cutoff date. Chip visibility restoration is purely cosmetic.
Sequencing.
Maintenance. Minor-version upgrades should be cheap, but budget a visual QA pass on the admin screens each release given the 1.2.0–1.3.0 chip regression. Track the package against the host app's Laravel major; framework majors are the realistic forced-upgrade events. Keep published config and migrations under version control so upgrades can be diffed rather than blindly re-published.
Support. Two recurring ticket classes are predictable: "the numbers changed" (locale scoping discontinuity at upgrade) and "this page is missing from the report" (entry model coverage, not a bug). Publish an internal definition of each Overview metric — especially orphaned and inbound coverage — and note the per-locale basis. Editors will ask why a page orphaned in one language appears fine in another; that answer needs to exist before launch.
Scaling. Cost is dominated by crawl/aggregation over the entry and link tables, not by the UI. Per-locale filtering is an opportunity — a locale-scoped Overview should touch a smaller slice than the all-languages aggregate — but only if the queries are properly indexed on the locale column and stats are not recomputed on every page load. On large multilingual sites, verify the "All languages" page specifically; that is where a naive per-locale loop would surface as slow admin rendering. Schedule crawls off-peak and cap concurrency against the origin.
Failure modes. Stale stats when the scheduled job silently stops — invisible because the UI still renders old numbers; alert on data freshness, not job exit code. Partial crawl coverage producing false "orphaned" or false "broken" flags after a deploy or content migration. Cache/aggregate keyed without locale, reintroducing cross-language blending after an innocuous cache change. Locale rows with no crawled entries rendering empty chip sets, which reads as a bug to editors. Upgrade-time KPI discontinuity in any downstream report that consumed pre-1.3.0 aggregates.
Ramp-up. Low for editors — one filter control plus restored chips, roughly a 15-minute walkthrough, though the team should be told explicitly that "All languages" is unchanged and that per-locale numbers are new rather than corrected historicals. Higher for the implementing engineer: half a day to install and backfill in staging, plus meaningful time on locale-semantics verification and metric reconciliation, which is where the actual risk sits. Assign one owner for the metric definitions and one for the crawl schedule; without both, the tool decays into an unmonitored dashboard people stop trusting.
How can I help you explore Laravel packages today?