Diy Page Bundle Laravel Package

Getting Started

• Install via Composer: composer require tourze/diy-page-bundle. This is a 0.0.1 release, so expect a very early, unstable API.
• If Laravel package discovery is supported, the service provider will auto-register. Otherwise, add Tourze\DiyPageBundle\DiyPageBundleServiceProvider::class (verify exact namespace in composer.json / src/) to config/app.php.
• Publish any config and migrations: php artisan vendor:publish --provider="Tourze\DiyPageBundle\DiyPageBundleServiceProvider". Inspect the published files before running migrations—table names and columns are not yet documented.
• Run php artisan migrate and check the created tables. The bundle likely provides entities/models for pages, blocks, or templates, but no admin UI.
• First use case: create a page programmatically via the provided model(s), then render it in a controller. For example, fetch a page by slug and pass its content to a Blade view. You will probably need to write your own CRUD or admin layer.

Implementation Patterns

• Headless CMS approach: Use the bundle’s models (e.g., Page, Block) to store structured content, then expose via API resources or Inertia/Livewire components. Keep rendering logic in your app, not in the bundle.
• Controller rendering: In a PageController@show, resolve a page by slug, eager-load any block relations, and return a view. Cache the rendered HTML with Cache::remember keyed by page ID and updated_at.
• Custom block types: If the bundle defines a block interface or abstract class, implement it for your own content types (e.g., hero, text, gallery). Register via config or service container if an extension point exists—check src/ for tagged services.
• Integration with admin panels: Since no admin is provided, wire the models into Filament, Nova, or Backpack. Use the bundle’s migrations as a base, then add your own fields via separate migrations.
• Route model binding: If the bundle’s page model has a slug column, use Route::get('/{page:slug}', ...) for clean URLs. Add a fallback 404 handler.
• Testing: Write feature tests that create a page via the model, hit the route, and assert the rendered output. Mock any Symfony-specific services if the bundle assumes them.

Gotchas and Tips

• Version 0.0.1 is pre-alpha: APIs, table schemas, and namespaces can change without notice. Pin the exact version in composer.json and avoid using in production until a stable release.
• Symfony bundle heritage: The package name ends in -bundle, suggesting Symfony conventions. Check composer.json for symfony/* dependencies—some may conflict with Laravel’s own Symfony components. Test installation in a fresh Laravel app first.
• No documentation: The release notes are only a changelog link. Read the source code (src/, config/, migrations/) to understand available models and services. Use php artisan list to see if any custom commands are registered.
• Migrations may be incomplete: Inspect published migrations for foreign keys, indexes, and column types. You may need to add your own indexes for slug lookups or updated_at caching.
• Config quirks: If a config file is published, it may contain Symfony-style parameters (e.g., %kernel.debug%) that are invalid in Laravel. Replace with env() calls or Laravel config values.
• Debugging: Enable Laravel Telescope or log queries to see what the bundle does. If pages don’t render, check that the service provider is registered and that the model’s table exists.
• Extension points: Look for events (PageRendered, BlockCreated) or interfaces you can implement. If none exist, consider forking or wrapping the bundle’s services in your own decorators.
• No admin or frontend scaffolding: Expect to build CRUD, routing, and views yourself. Budget time for this—the bundle is likely a data-layer starting point, not a turnkey page builder.