Download the PHP package pvtl/dynamic-content without Composer

pvtl/dynamic-content

Dynamic content management with configurable sections for Laravel Livewire and Flux UI applications. Define section types in a config file, manage content through an admin UI, and render sections on the frontend using Blade components.

Requirements

• PHP ^8.4
• Laravel ^13.0
• Livewire ^4.0
• Flux UI ^2.0 (Pro)

Installation

Add this to your application's main Tailwind stylesheet, usually resources/css/app.css, so Tailwind generates the utilities used by the package views:

Publish resources and run migrations:

What Gets Published

pvtl-dynamic-content:publish installs:

To also publish the section field Blade components for customisation:

This copies the field input components to resources/views/components/sections/. Once published, the package uses your copies instead of its own defaults.

Configuration

config/dynamic_content.php

Routes

The published routes/dynamic_content.php contains the admin CRUD routes. Customise them as needed — add middleware, change URIs, or wrap them in a route group to suit your application's auth setup.

Helpers

The package ships a global helpers file (src/helpers.php, autoloaded via Composer) with small utility functions for working with stored field values in your frontend section components:

• dcGetFileUrl(string|TemporaryUploadedFile|null $file): ?string — Resolves a stored file path or temporary preview upload to a public URL using the configured dynamic_content.disk, or null if no file is set.

Defining Sections

Edit the published config/sections.php to define the section types available in the admin panel. The homepage-hero example is included and ready to use:

Refer to the schema comment at the top of config/sections.php for the full list of available field types and options.

Dynamic (database-backed) options

For Select, Multiselect, RadioButton, and CheckboxGroup fields, options is normally a static value => label array. If you need the list to come from the database (e.g. a dropdown of Meal records), you cannot just query the database directly inside config/sections.php:

Config files are required by Laravel's LoadConfiguration bootstrapper very early in the request lifecycle — before any service providers (including the database provider) have booted. Querying the database at this point fails, and Laravel's own attempt to render that error also fails (the view binding isn't registered yet either), which surfaces as a confusing Target class [view] does not exist error instead of the real cause.

Instead, set options to a static callable array — [Class::class, 'method'] — pointing at a method that returns the options. It's resolved lazily, only when the field is actually rendered:

Do not use a Closure for this (e.g. fn () => Meal::all()->pluck(...)) — closures cannot be serialized by php artisan config:cache and will break config caching for the entire application. A [Class::class, 'method'] array is just two strings, so it caches fine and is resolved with call_user_func() only when needed.

Creating Frontend Section Components

Each section type needs a Blade component that renders it on the frontend. Components live in resources/views/components/{component_directory}/ (default: resources/views/components/dynamic/).

How it works

When the DynamicContentRenderer outputs a section, it calls:

Your component receives all stored field values as the $attrs array. Components must never query the database — all data is passed via $attrs.

Example: homepage-hero

Create resources/views/components/dynamic/homepage-hero.blade.php:

Key rules for section components

• Always declare @props(['attrs' => []]).
• Access fields via $attrs['field_slug'] — use ?? null for optional fields.

Rendering Dynamic Content

Use DynamicContentRenderer anywhere in your Blade views:

The component loads the DynamicContent record by slug (creating it if it does not exist), loops through its sections ordered by the order column, and renders each one using its configured Blade component.