Eloquent Publishing Laravel Package

Product Decisions This Supports

• Modernization of Legacy Systems: Justifies upgrading Laravel 10/PHP 8.1 projects to Laravel 11+ and PHP 8.2+ by providing a critical dependency that now enforces these requirements. Aligns with infrastructure roadmaps for security/compliance (e.g., EOL support).
• Strategic Dependency Management: Supports a dependency hygiene initiative by dropping outdated Laravel/PHP versions, reducing long-term maintenance risk. Can be framed as a "force upgrade" opportunity for technical debt reduction.
• Roadmap for "Time-Based Visibility": Reinforces the case for scheduled publishing by ensuring the package remains actively maintained (e.g., Dependabot updates, Laravel 11+ support). Use as a blocker for delaying scheduled publishing features if the app isn’t yet on L11+.
• Use Cases (Updated):
  • Legacy Migration: Accelerates moving older Laravel apps to L11+ by offering a drop-in replacement for publishing logic.
  • Security Compliance: Enables compliance with modern PHP/Laravel security patches (e.g., PHP 8.1 EOL in Nov 2023).
  • New Feature Enablement: Unlocks Laravel 11 features (e.g., improved query builder, performance optimizations) that may interact with publishing logic.

When to Consider This Package

• Adopt if:

  • Your Laravel app is upgrading to Laravel 11+ and PHP 8.2+ (now a hard requirement).
  • You need time-sensitive visibility (e.g., publishing dates) and want to avoid reinventing the wheel.
  • Your team prioritizes reducing technical debt by standardizing on a maintained package.
  • You’re using Eloquent models and want built-in query scopes/events for publishing workflows.
  • You’re evaluating dependency hygiene and want to drop EOL Laravel/PHP versions.

• Look elsewhere if:

  • You’re stuck on Laravel 10 or PHP 8.1 (this package is no longer supported on those versions).
  • You need hard deletion (use Laravel’s SoftDeletes instead).
  • Your publishing logic requires complex approval workflows (consider a dedicated CMS like Strapi or Craft CMS).
  • You’re using non-Eloquent models (e.g., raw SQL or other ORMs).
  • You need multi-tenancy support (this package doesn’t natively handle tenant-specific publishing).
  • Your team prefers zero dependencies (this adds a small but now mandatory modern stack dependency).

How to Pitch It (Stakeholders)

For Executives:

*"This update to the publishing package is a critical opportunity to modernize our Laravel stack. By adopting it, we’ll:

1. Force an upgrade to Laravel 11+ and PHP 8.2+, aligning with security best practices and enabling future-proof features.
2. Eliminate technical debt from custom publishing logic, saving dev time and reducing bugs.
3. Future-proof our content workflows with a maintained package that supports scheduled posts, soft unpublishing, and event-driven integrations.

Example: If we’re planning to launch a new feature announcement on [date], this package ensures we can schedule it without manual database updates—while also pushing us toward a more secure, scalable stack. The upgrade is low-risk: it’s a one-time migration to L11+, with clear ROI in developer productivity and security."

ROI:

• Security: Drops EOL PHP/Laravel versions, reducing vulnerability risks.
• Time Saved: Avoids 2–4 weeks of custom development for publishing logic + upgrade effort.
• Scalability: Supports future features like bulk publishing or API-driven scheduling in a modern stack.

For Engineering:

*"This 4.0.0 release drops Laravel 10/PHP 8.1 support, so we have two options:

1. Upgrade to L11+/PHP 8.2+ and adopt the package: This is the recommended path. The package now includes:

   • Migration helpers for published_at columns (e.g., $table->publishes()).
   • Query scopes (onlyPublished(), latestPlanned()) and events (published, unpublished) for workflows.
   • Dependabot-managed dependencies for long-term stability.
   • Laravel 11 optimizations (e.g., improved query performance).

2. Stay on 3.x: Not viable long-term due to EOL Laravel/PHP risks and lack of updates.

Proposal: Let’s use this as a blocker for our L11+ upgrade. We’ll:

• Schedule the upgrade alongside [Project Y]’s timeline.
• Replace our current publishing logic with this package in 1–2 days.
• Gain immediate benefits: standardized workflows, security compliance, and future scalability.

Trade-offs:

• Upgrade effort: ~1–2 weeks for L11+ migration (but aligns with other roadmap items).
• Dependency: Adds a single, well-maintained package to the stack.

Demo: I’ll show how the package integrates with our models and how the L11+ upgrade enables new features like [specific use case]."