fix: offer the home strip through the block registry, not a template directory (2.0.1)
A block resolves as GP247TemplatePath::.blocks., and the template
name is a path segment — so this plugin shipped template/GP247Front/blocks/ and
registered that directory as one more GP247TemplatePath source root. Two things
were wrong with it: the plugin does not publish a template, yet it hardcoded the
name of one (a site running its own template never saw the block at all), and its
root joined TemplateSourceAudit::roots(), so gp247:template-publish,
gp247:template-prune and gp247:doctor counted plugin files as template sources.
gp247/front now carries a registry for exactly this, alongside layout_page,
seo_sitemap_providers and plugin_hooks:
config('gp247-config.front.layout_block_views') // '<block>' => '<view key>'
Provider.php appends its entry there and the template/ directory is gone. The
renderer looks the active template's own blocks/.blade.php up FIRST and only
then the registry, so a site that published the block to edit it still wins, and
the block now reaches every template, needs no writable directory, and leaves
nothing behind when the plugin is removed.
seedLayoutBlock() drops blockAvailableForTemplate(): with no file inside a
template directory to depend on, there is no template the strip cannot render on,
so every store gets the row.
Nothing changes in front_layout_block — the block is still named
product_flash_sale — so installed sites need no migration.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com