Propel Publishable Behavior Laravel Package

Product Decisions This Supports

• Soft Delete Alternative: Enables a publish/unpublish workflow instead of hard deletes, preserving data while controlling visibility (e.g., for drafts, archived content, or seasonal promotions).
• Content Moderation: Supports staged rollouts (e.g., A/B testing, regional releases) by tracking publication start/end dates via hasPublicationStarted()/hasPublicationEnded().
• Compliance/Regulatory Use Cases: Facilitates audit trails or temporary data suppression (e.g., GDPR "right to be forgotten" without permanent deletion).
• Roadmap Efficiency: Build vs. Buy—avoids reinventing publish workflows if Propel ORM is already in use; integrates seamlessly with existing Laravel/Propel projects.
• Multi-Tenant Data: Enables tenant-specific visibility (e.g., unpublished content for other tenants remains accessible via includeUnpublished()).
• Performance Optimization: Reduces database bloat by avoiding hard deletes while maintaining query flexibility (e.g., filterPublished() for public-facing APIs).

When to Consider This Package

• Avoid if:
  • Using Eloquent (not Propel ORM)—this package is Propel-specific.
  • Needing hard deletes or time-based expiration (e.g., auto-deleting after X days); this requires custom logic.
  • Requiring granular permissions (e.g., role-based publish access); pair with Laravel’s Policies or Gate system.
  • Seeking highly active maintenance—package is archived (last commit: 2013); evaluate risk for long-term projects.
  • Using modern Laravel features like Scout (for search) or Model Events (for hooks); this package lacks integration.
• Consider alternatives:
  • Laravel Scout + Soft Deletes: For searchable, soft-deleted content.
  • Spatie Laravel Activity Log: For audit trails with publish/unpublish events.
  • Custom Trait: If Propel isn’t a constraint, build a reusable trait for Eloquent.

How to Pitch It (Stakeholders)

For Executives: "This package lets us toggle content visibility (publish/unpublish) without deleting data—critical for compliance, A/B testing, or seasonal campaigns. It’s a lightweight, Propel-specific solution that integrates with our existing stack, reducing dev time for moderation workflows. Trade-off: It’s archived (low maintenance risk for short-term needs), but we can mitigate this by wrapping it in a custom service layer."

For Engineers: *"If we’re using Propel ORM, this gives us OOTB publish/unpublish methods (publish(), unpublish()) with query filters (filterPublished()). Key benefits:

• No SQL migrations needed—just configure propel.ini.
• ActiveQuery support: Filter unpublished content in APIs (e.g., /admin vs. /public).
• Extensible: Hook into hasPublicationStarted() for time-based logic. Downside: Propel-only; if we’re Eloquent-heavy, we’d need a custom solution. Also, the package is stale, so we’d add tests/updates to a fork."*

For Design/UX: *"This enables ‘soft visibility’ for content—think drafts, hidden promotions, or region-locked features. For example:

• Editors can unpublish a blog post without losing it.
• Marketing can schedule a campaign to ‘publish at’ a future date. Pair with a UI toggle (e.g., ‘Published?’ checkbox) for seamless workflows."*