Pn Press Laravel Package

Getting Started

pn-press targets PHP 8.4+, so confirm your runtime and CI images before anything else. Install per the README (which now documents the MySQL steps explicitly), run migrations, and look for any publishable config/migrations the package exposes.

The first thing to read is the README section on the demo seed vs. a clean install — this is the distinction that caused the 1.1.0 pain:

• If you ran the demo seed, a demo admin exists and you can sign in immediately.
• If you installed without the demo seed, you have no way in until you run:

php artisan press:admin [email protected]
# password is prompted and never echoed

That gives you an admin account (no --role) or, for an existing user, assigns a role:

php artisan press:admin [email protected] --role=editor

First real use case: provision your own admin, log into the admin panel, then create a page and a menu to confirm content models, routing, and admin UI all wire up before you invest in configuration.

Implementation Patterns

Provisioning users. Treat press:admin as the canonical bootstrap step for non-seeded installs and as the role-assignment tool afterwards. A workable pattern:

• One super admin created without --role.
• Editors created with --role=editor — either at creation time or by re-running the command against an already-registered user.
• Keep a note in your deploy docs that this command must be run manually after a fresh production install, because it is interactive.

Seed vs. no-seed environments. Local/demo environments can use the demo seed for instant access; staging and production should install clean and use press:admin. Documenting this split prevents the "credentials don't work in prod" confusion entirely.

Language planning up front. Because rolling back the 1.1 language migration is now refused while translated content exists, treat language setup as a design-time decision, not something you toggle while building. Add your locales early, before creating pages/posts/categories/menus in secondary languages, so you never need that rollback.

Content modelling. Pages, posts, categories and menus are first-class concepts — build your Blade/navigation layer against them and let the admin panel handle authoring. Use categories and menus as the join points between editorial content and site structure rather than hardcoding navigation.

Deployment. Run migrations as part of deploy, and make "do not roll back the language migration" an explicit line in your runbook. On MySQL, the guard now fails fast before touching schema — but you still don't want to be in that situation on a live database.

Gotchas and Tips

• press:admin is interactive. The password is prompted and never displayed, so it does not fit cleanly into unattended deploy scripts or CI. Use it as a manual post-deploy step; for automated fixtures, seed users through your own seeders/factories instead.
• Don't assume the demo admin exists. This was the exact 1.1.0 install trap. If you skipped the demo seed, there are no credentials until you run the command.
• The rollback guard is a safety net, not a green light. It refuses the language-migration rollback before changing anything when translated content is present — that's strictly better than the previous MySQL half-failure, but it means you must remove or translate back all foreign-language pages, posts, categories and menus if you genuinely need to unwind the migration.
• Bypassing the guard is on you. Manually truncating those tables or forcing migrations defeats the check and can still leave you with an inconsistent schema; the protection only works through the normal migration path.
• Verify command registration if press:admin is "not defined" — check package discovery / your service provider cache, and run php artisan list to confirm.
• Exact email matching. Assigning a role to an existing user requires that user to already exist with the email you pass; create the user first, then re-run with --role.
• PHP 8.4 requirement trips older container images and CI matrices — pin it in composer.json and your Docker base image together.
• Read the 1.1.0 release notes alongside 1.1.1; the patch only fixes install/rollback edges, so the feature and configuration changes live in the 1.1.0 notes.