Wink Laravel Package

Technical Evaluation

Architecture fit. Wink is a Laravel package, not a standalone application. It registers its own service provider, routes, views, migrations, and config into a host Laravel app, mounting an admin SPA under a /wink route prefix. Content lands in wink_-prefixed tables and is surfaced as Eloquent models (Wink\Post, Wink\Page, Wink\Tag) that the host app consumes and renders through its own controllers and templates. That is a strong fit only when two conditions hold: the product already runs Laravel, and the content model is genuinely blog-shaped — posts, pages, tags, a small author set. It is a poor fit for editorial workflows, approvals, localization, multi-tenancy, or any content type that isn't a document.

Integration feasibility. Composer install, vendor:publish, php artisan migrate, configure the wink auth guard and storage disk in config/wink.php. A working admin is typically under a day of effort. The real cost is the read side: Wink ships no public-facing site. Every route, template, sitemap, RSS feed, and SEO tag is ours to build. Budget the frontend as the actual project and the package as a small dependency inside it.

Technical risk.

• Maintenance signal is weak: last release May 2023, and the package has been in caretaker status since. Every Laravel major upgrade becomes a bet on whether it still boots.
• The admin UI is Vue 2, which is past end-of-life. Compiled assets ship in the package, so we don't build them — but any UI customization pulls us into an EOL toolchain.
• Authentication is a parallel guard with users defined in config or a dedicated table. No SSO, no reuse of host-app users or roles without custom wrapping.
• Content is a single markdown body column with minimal structure — no block editor, no revision history surface, no approval states.
• Media goes to a configured disk with no transformation or CDN pipeline out of the box.

Key questions. Which Laravel version is the host on, and is it on a supported track? Does the roadmap require editorial workflow, multi-author permissions, or localization? Who owns the public frontend? Will the Vue 2 asset bundle clear security review? Is the TCO of a hosted CMS, or a maintained alternative like Statamic or a Filament-based admin over our own models, actually lower?

Integration Approach

Stack fit. Laravel 8–10 era PHP applications, MySQL/Postgres/SQLite, Blade or Inertia frontends. On Laravel 11/12, validate package boot before committing — this is the first and cheapest gate.

Migration path. From WordPress or a hand-rolled CMS: export to markdown, import into wink_posts via a one-off artisan command, map slugs, tags, and publish dates, and pre-plan redirects for every changed URL. Greenfield: install first, lock the content schema second, build the read side third.

Compatibility. Pin both the Wink version and the Laravel version in composer.json, and run a CI job that exercises the host test suite against that pinned pair so a framework bump fails in the pipeline rather than at deploy.

Sequencing.

1. Spike — install on a throwaway branch, publish config and migrations, confirm the admin boots and login works.
2. Content model — lock the mapping of post fields, tag taxonomy, and page hierarchy before any frontend code exists.
3. Read side — routes, controllers, caching layer, sitemap/RSS, structured metadata.
4. Media and storage — pick the disk, set upload limits, add derivatives if the design needs them.
5. Auth decision — keep config-driven Wink users or wrap the guard to defer to application users. Decide early; it touches every admin route.
6. Cutover — content import, redirects, DNS, and a written rollback plan.

Operational Impact

Maintenance. Effectively vendor-less. Budget a named owner who can read the package source and patch it, plus a fork strategy — mirror the repository internally so security and framework-compatibility fixes can be applied when upstream doesn't ship them.

Support. Community only via GitHub issues, no SLA, no escalation path beyond "we fix it." That is acceptable for an internal or marketing surface; it is not acceptable for revenue-critical publishing.

Scaling. Read traffic scales fine — it's ordinary Eloquent queries, so cache rendered output and the query layer. The admin is intrinsically low-traffic and single-node. The genuine bottleneck is media: local-disk uploads break under horizontal scaling, so S3 plus a CDN should be the day-one configuration. Markdown rendering on every request is a CPU trap — pre-render and store HTML.

Failure modes.

• Laravel upgrade breaks package boot → site-wide 500.
• Auth guard misconfiguration locks editors out of the admin.
• Upload disk misconfigured → silent media loss during a deploy.
• Vue 2 bundle flagged by a security or dependency scanner.
• Abandonware drift: PHP deprecations accumulate until a forced rewrite.

Ramp-up. Low for a Laravel developer — roughly a day to admin proficiency and a week to own the read side comfortably. Higher for stakeholders expecting WordPress parity, because Wink deliberately stops at content storage and leaves the product surface entirely to us.

Positioning. Wink is a solid accelerator for an internal blog or marketing site sitting on an existing Laravel app where engineering already owns the frontend. It is not a platform to standardize a content organization on. Treat it as a scaffold we may outgrow: content lives in plain tables, which keeps exit cost low and makes a later migration to a maintained CMS or first-party models a contained piece of work rather than a rewrite.