Webtrees Laravel Package

Technical Evaluation

Classification mismatch is the first finding. Despite the description's phrasing, fisharebest/webtrees is not a Laravel package — it is a standalone, server-rendered PHP application that consumes a few Laravel components (illuminate/database for query building, Blade for templating) as independently versioned Composer dependencies. There is no service provider, no publishable config, no facade, no package-style extension contract. composer require fisharebest/webtrees inside an existing Laravel app is not a supported integration path; the project ships its own bootstrap, container/registry, routing, session handling, authentication, migration runner, and theme layer.

Architecture fit: low. webtrees is a monolith with global/static state, its own module registry, and opinionated conventions (GEDCOM-record-backed Eloquent-style models keyed by xref IDs, not auto-increment primary keys). Dropping it beside a Laravel application means two competing auth systems, two session stores, two migration timelines, and two view layers. There is meaningful conceptual overlap and almost no compositional overlap.

Integration feasibility: constrained by the absence of an API. The core application is HTML-in/HTML-out; there is no first-party REST/JSON API. Machine integration must go through one of: (a) GEDCOM 5.5.1 file import/export, (b) direct database reads against an internal schema with no stability guarantee, or (c) an in-process module that registers routes against webtrees' own router. Only (a) is a defensible contract.

Technical risk: high, concentrated in three areas.

Key questions before committing engineering time:

1. What is the actual latest tagged release, and what is the commit cadence over the trailing 12 months?
2. Is the "Laravel components" claim load-bearing for our use case, or is it incidental to the original author's refactor? Which illuminate/* constraints does it pin, and do they collide with our framework version?
3. Which illuminate/* and PHP minor versions are supported, and what is the stated EOL policy?
4. Does GPL-3.0 contamination apply to our intended usage — sidecar deployment with no linking, versus code extraction?
5. What is the real requirement? "Genealogy data model + GEDCOM interop" is a narrow, extractable need; "a collaborative genealogy product" is a different, much larger bet.
6. Are there commercial alternatives (enterprise genealogy platforms, hosted APIs) whose licensing and support terms we can actually procure?

Bottom line: treat this as a reference implementation and a possible sidecar appliance, not as a dependency. The score of ~34.9 with an opportunity score of ~26.25 is consistent with that read: a mature artifact with limited leverage against our roadmap.

Integration Approach

Stack fit is runtime-compatible but framework-incompatible. PHP 8.x + MySQL/MariaDB/PostgreSQL/SQLite satisfies our infrastructure, but the shared-dependency axis is the problem: webtrees' pinned illuminate/* and Blade versions must coexist with ours in a monorepo or be isolated entirely. Do not attempt to co-resolve them in one composer.json; isolate at the process boundary.

Four viable paths, ranked:

1. Reference-only (recommended default). Read the codebase; do not run it. Harvest domain knowledge: GEDCOM 5.5.1 edge cases, the privacy-rule evaluation model, the person/family xref linkage scheme, the chart-rendering approach. Zero licensing exposure if we write our own implementation from the spec and from observed behavior, not from copied source. Lowest cost, lowest ceiling.
2. Sidecar appliance. Deploy webtrees as a separately versioned service on its own subdomain and database, reverse-proxied. No shared sessions, no shared DB. GEDCOM files (or a thin custom module endpoint) are the only data channel. GPL obligations are contained because we distribute/host it unmodified as an independent program. This is the correct shape if the requirement is "give users real genealogy editing now."
3. Extract-and-reimplement. Pull the GEDCOM parser semantics and privacy evaluator into our own Laravel-native services, written clean-room against the spec. Highest long-term value, 4–8 engineer-weeks minimum, and requires legal review of how closely derived code mirrors GPL source.
4. Fork as the primary application. Do not do this unless genealogy is the product. It converts a TPM problem into a maintenance-treadmill problem.

Migration path: GEDCOM is the contract boundary, and only GEDCOM. Any inbound data migration uses GEDCOM 5.5.1 export from the source system, import into webtrees, and round-trip validation. Build a fixture suite before the spike: a handful of real trees with blended families, adoptions, multiple marriages, unknown parents, source citations, and multimedia pointers. Assert record counts, xref stability, and that privacy flags survive export→import→export unchanged. Media files are a separate problem — they are filesystem/URL references inside GEDCOM, so they need a mapping table and object-storage strategy, and this is where most migrations silently lose data.

Compatibility: SSO is not native. Authentication into a sidecar requires an OIDC/SAML module or proxy-level identity injection, and that module becomes a pinned, upgrade-blocking fork. Budget for it explicitly rather than assuming it is configuration.

Sequencing, with decision gates:

1. Data-quality fix (1 day). Resolve the 2016 release-date conflict. If genuinely stale → stop. If mis-scraped → correct the record and continue.
2. License review (parallel, 2–3 days). Legal opinion on paths 1–3 specifically. Gate: written sign-off.
3. Timeboxed spike (10 working days). Docker deploy, fixture round-trip, one chart, one privacy scenario, one SSO attempt. Gate: spike report with measured effort, not estimates.
4. Path decision. Choose 1/2/3 based on the spike, with an explicit cost of the sidecar's ongoing operational burden.
5. Build. If path 2: sidecar in staging, SSO, GEDCOM sync job, runbook. If path 3: extract services behind our own interfaces and keep webtrees out of production entirely.

Operational Impact

Maintenance. No vendor, no LTS, no support contract. GPL-3.0 means we own every bug we hit and every security patch we backport. If we operate a sidecar, we inherit a PHP application with its own upgrade treadmill, and major-version upgrades are documented data migrations rather than drop-in bumps — plan one engineer-quarter of risk per major upgrade. Pinning is mandatory; auto-updates are not acceptable given the PII surface.

Support. Community forum and issue tracker only. Response times are volunteer-shaped. There is no SLA to inherit and no escalation path. For an internal tool that is tolerable; for anything user-facing with uptime expectations it must be explicit in the risk register.

Scaling. The read/write profile is favorable: heavily read-dominant, PHP-FPM stateless per request, horizontally scalable behind a load balancer with a shared database. The database is the bottleneck, not the application tier. Media should move to object storage with a CDN rather than local disk, since multimedia is first-class. Cron is required for scheduled jobs; there is no queue-worker model to lean on, so anything long-running (large GEDCOM imports, report generation) blocks a request unless we wrap it. Large imports need explicit progress tracking and resumability, which the core does not give us.

Failure modes to design for, in priority order:

• Privacy leak (P1). A misconfigured tree-visibility rule or a module bypass exposes living-person data. Requires a pre-deployment test matrix per role, an auditable change history check, and a documented kill-switch (take the tree offline) in the runbook.
• Silent GEDCOM corruption (P1). Partial imports, dropped multimedia references, or broken xref linkage that appears successful. Mitigation: checksum and record-count validation on every import, plus a retained pre-import snapshot.
• Module breakage on upgrade (P2). Custom modules register against internal extension points with no stability guarantee; an upgrade can disable them without a clear error.
• PHP/framework drift (P2). The pinned illuminate/* set will age out of security support before our own framework does, forcing a coupled upgrade.
• Translation gaps (P3). 100+ languages are claimed at the UI layer; domain-specific strings in custom modules will not be covered, and genealogy terminology mistranslates easily.

Ramp-up. Two distinct learning curves, and they compound. First, genealogy domain literacy: GEDCOM 5.5.1 is a dense specification with genuinely ambiguous corners (pedigree linkage, adoption events, source citations, confidence levels) and practitioners are unforgiving about data fidelity. Second, the codebase: legacy-flavored PHP with global state and internal registries that does not match the "modern Laravel" framing in the description. A new engineer should be assumed to need two to three weeks before they can safely touch the privacy layer, and that estimate should not be compressed.

Recommendation. Cap investment at the timeboxed spike plus a legal opinion. Default to the reference-only path and, if a genealogy feature is genuinely on the roadmap, to a sidecar deployment with GEDCOM as the sole integration contract. Do not make this a dependency of the main application.