Featured Posts Block Extension Laravel Package

Technical Evaluation

Architecture fit This is not a general-purpose Laravel package — it is a PyroCMS (Anomaly CMS) addon, identifiable from the -extension suffix and the anomaly/* vendor namespace. It plugs into the Blocks module's page-builder system and renders a "featured posts" widget sourced from the Posts module. It is therefore only viable if the target application is already a PyroCMS 3.x/Anomaly deployment; on a plain Laravel or Livewire/Inertia stack it adds no value and cannot be cleanly adopted. Architectural surface is small: a block class, a form/presentation view, and language files. Coupling is to anomaly/blocks-module and anomaly/posts-module internals, which means it inherits their versioning constraints rather than owning them.

Integration feasibility Feasible and low effort if and only if the platform is PyroCMS 3.x. Integration is via Composer plus the addon installer (php artisan addon:install anomaly/featured_posts_block-extension). There is no configuration, no migrations of its own, and no service provider logic worth reviewing. The real feasibility gate is dependency resolution: the addon's composer.json and composer.lock expectations must align with the host's Laravel and anomaly module versions. With zero stars and zero dependents, expect to validate compatibility manually rather than relying on community-confirmed version matrices.

Technical risk

• Abandonment risk (high): no stars, no dependents, and Anomaly Labs' PyroCMS ecosystem has seen limited maintenance activity. Treat this as unmaintained source code, not a supported dependency.
• Version-lock risk (high): tightly coupled to Blocks/Posts module major versions; Laravel 9+ hosts are unlikely to resolve cleanly without patching.
• Security review surface (low-to-moderate): the block renders post content in a public-facing view — confirm escaping behavior and whether it can surface unpublished/draft posts.
• Supply-chain risk (low): small, auditable codebase; vendor-prefixed, no exotic transitive dependencies expected.
• Blast radius (moderate): a block render exception typically propagates to the whole page render, so a failure is user-visible.

Key questions

1. What exact PyroCMS/Anomaly and Laravel versions does this addon declare, and does that intersect our supported matrix?
2. Does it respect post publication status, roles, and localization, or does it query the Posts repository directly and bypass those filters?
3. Is the "featured" selection manual (block form config) or query-driven (flag/tag)? This determines admin UX and whether editors need a data model change.
4. Are there open issues/PRs, and what is the last commit date relative to the Blocks module version we run?
5. Is there caching, and does it invalidate on post save — or will a high-traffic page hammer the database?
6. What is the license, and are we permitted to vendor/fork it internally?

Integration Approach

Stack fit Only fits a PyroCMS 3.x / Anomaly stack on Laravel (historically 5.5–8.x era, with community forks pushing further). If our roadmap is standard Laravel with Blade/Livewire or an API-first front end, this package is out of scope and the equivalent capability should be built as a first-party block or a small "featured posts" query + Blade partial.

Migration path No migration is required — it is a net-new block registration, not a data-bearing addon. Adoption path: (1) confirm platform version, (2) composer require anomaly/featured_posts_block-extension, (3) run addon:install, (4) publish/verify views, (5) register the block in the page builder and smoke-test rendering with published, draft, and missing-post scenarios. Rollback is similarly cheap: addon:uninstall and remove existing block instances from page layouts first, since orphaned block references will error on render.

Compatibility Primary compatibility axis is the Blocks module version (block API/field-type contract) and the Posts module version (repository/query contract). Secondary axis is Laravel and PHP version. Because dependents are zero, we should treat compatibility as unverified and pin exact versions in composer.json with a documented fork if we patch anything.

Sequencing

1. Confirm PyroCMS/Anomaly version and lock it.
2. Audit the addon source (≤ a few hundred lines) for queries, escaping, and caching.
3. Fork to our VCS if any patch is needed — do not rely on upstream.
4. Install in a staging environment; verify the block form, render output, and permission behavior.
5. Add to the block allow-list and document editor usage.
6. Only then promote to production, with a rollback runbook.

Operational Impact

Maintenance Effectively zero upstream maintenance; assume we own the code. Budget a small annual review (dependency bumps against Blocks/Posts module upgrades) and keep the fork pinned. Because it's an extension, upgrades to the Blocks module can break its block registration silently — include it in every PyroCMS upgrade checklist.

Support No vendor support channel and no community base to lean on. Internal documentation should cover: what the block does, how editors configure it, and who owns the fork. Support tickets will route to the platform team, not to the package author.

Scaling Negligible compute cost on its own — one query per block render. The scaling question is caching: if the block runs an uncached Posts query on every page view of a high-traffic layout, it becomes a database hot spot. Recommend wrapping the block output in the platform's fragment/block cache and invalidating on post save. Horizontally, nothing stateful here, so it scales if the host scales.

Failure modes

• Missing dependency: Posts or Blocks module absent/disabled → class-not-found or render exception; mitigate with a guarded class_exists check and a soft-fail empty state.
• Stale block reference: post deleted or unpublished → blank region or error depending on query strictness; require a null-safe presenter.
• Upgrade drift: Blocks module API change breaks block registration, causing the block to disappear from the picker or throw on render.
• Draft leakage: if the query ignores status, unpublished content may be publicly rendered — a content-integrity incident, not just an outage.
• Cache staleness: featured list doesn't refresh after editorial changes, generating "why isn't my post showing" tickets.

Ramp-up Low technical ramp-up (small, idiomatic PyroCMS addon; a Laravel developer can read it in under an hour), but the organizational ramp-up is the real cost: the team must learn the Blocks/Posts module contracts to safely own the fork. If the team has no existing PyroCMS depth, the total cost of ownership for this "free" block exceeds writing a 100-line first-party equivalent — which is the recommended alternative unless the platform is already PyroCMS and the block is needed urgently.