Pn Press Laravel Package

Product Decisions This Supports

• Build vs. buy for content surfaces. pn-press bundles the parts of a CMS teams usually rebuild from scratch — pages, posts, categories, menus, roles, and multilingual content — as a Laravel package. This makes "build a lightweight CMS on our own stack" a credible alternative to a SaaS CMS subscription or a headless CMS + custom admin build.
• Roadmap sequencing for a content-driven launch. A marketing site, blog, docs hub, or multilingual brochure site can ship without a dedicated CMS workstream, freeing engineering capacity for the actual product differentiator.
• Localization as a product decision, not a later migration. The package's language layer plus the 1.1.1 rollback guard means "we'll add French/German later" becomes a low-risk roadmap item rather than a schema migration project.
• Access model decisions. press:admin --role=editor puts role assignment in the deployment/onboarding path, which supports decisions about who gets editorial vs. admin access, and makes "one seat per environment" provisioning a settled question.
• Production-readiness gating. 1.1.1 exists specifically because a 1.1.0 install test failed: a fresh install without the demo seed produced no way to sign in. If your adoption decision was blocked on "can we actually get into the admin on a clean production install," that blocker is now closed — this is the version to evaluate against.
• Operational risk posture for multilingual sites. 1.1.1 refuses the 1.1 language-migration rollback before mutating anything when translated content exists, replacing a MySQL half-applied failure that left schema broken. That converts a potential production incident into a clean, explainable error — a meaningful input to a go/no-go on multilingual rollout and to your rollback runbook.

When to Consider This Package

Adopt when most of the following hold:

• You are already on Laravel with PHP 8.4+, and content is a supporting capability rather than the core product.
• You need an admin UI out of the box — editorial screens for pages/posts/categories/menus — and don't want to staff a CMS build.
• Multilingual content is on the roadmap or already required; the 1.1.1 rollback guard materially lowers the cost of getting this wrong.
• You want content to live in your own database and repo, under your existing auth, backup, and hosting/security review — no third-party CMS in the data path.
• You are comfortable pinning a young (1.1.x) package and reviewing release notes on upgrade; the 1.1.0 → 1.1.1 sequence shows the maintainer is running real install tests, which is the signal you want at this maturity.
• Team size is small enough that a role-based, editor/admin split covers your permission needs.

Look elsewhere when:

• You need e-commerce, complex content modeling, custom post types with field-level schema, or a page-builder with arbitrary layout components.
• You require enterprise governance — SSO/SAML, granular per-field permissions, editorial approval chains, full audit logging, scheduled publishing SLAs.
• Non-technical editors are the primary users at scale; a mature commercial CMS or a hosted headless option will have better authoring ergonomics and support contracts.
• You are not on Laravel, or are pinned below PHP 8.4.
• You need a long-term support commitment or vendor SLA — this is a small, single-maintainer project; treat upgrade risk and bus-factor as part of the decision.
• Traffic/scale profile demands a decoupled, cache-first content API rather than an in-app CMS.

How to Pitch It (Stakeholders)

To executives: We can put a real, multilingual content site into production on the stack we already run, without a per-seat CMS licence, a new vendor in our security review, or a multi-sprint admin build. The 1.1.1 release removes the two things that made this risky to commit to — a clean production install now has a supported way to create the first admin account (press:admin), and a multilingual schema rollback can no longer fail halfway and corrupt the database. The remaining risk is maturity, not capability: we should pin the version, budget a small amount of upgrade maintenance, and keep an exit path (content lives in our own database, so switching is a data migration, not a re-platform).

To engineering: It's a Composer package with artisan-driven install and migrations, so it slots into our existing deploy pipeline and CI rather than introducing a separate service. The 1.1.1 changes are narrow and addressable: a new press:admin [email protected] [--role=editor] command for first-account creation and role assignment (password prompted, never echoed), a pre-flight guard that blocks the 1.1 language-migration rollback while translated pages/posts/categories/menus exist, and README corrections covering MySQL setup and the demo-admin question. Note the PHP 8.4 floor and that the install path without demo seed data is now the supported production path. Recommended actions before adoption: run the install test in a staging environment with MySQL, confirm the rollback guard fires as described, and verify seedless-install admin login end to end.