From WordPress
to Laravel.

The concept

// This class belongs to the app/Models part of our project.
namespace App\Models;

// Import Laravel's base database model.
use Illuminate\Database\Eloquent\Model;

// Give Project model features, such as finding and saving records.
class Project extends Model
{
    // These fields may be filled when a Project is created or updated.
    protected $fillable = [
        'title',
        'summary',
        'published',
    ];
}

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    public function up(): void
    {
        // Create the projects table and its actual database columns.
        Schema::create('projects', function (Blueprint $table) {
            $table->id();
            $table->string('title');
            $table->text('summary')->nullable();
            $table->boolean('published')->default(false);
            $table->timestamps();
        });
    }

    public function down(): void
    {
        // Remove the table if this migration is rolled back.
        Schema::dropIfExists('projects');
    }
};

A worked example

A colleague is asking for something like a portfolio page. Each Project is one portfolio entry, such as a website, campaign or case study. Visitors can browse these entries on the public website, while the team uses a private admin screen to add and edit them. In WordPress terms, imagine a Project custom post type with a public archive and editing screens in wp-admin.

Laravel separates this familiar WordPress feature into three parts. A model and migration store the Projects, a Filament resource provides the editor, and a public route with a Blade view displays the portfolio to visitors.

Project model + migration → stored data
ProjectResource → editing workflow
Public route + Blade view → visitor experience

What can go wrong

A shared rule, such as which projects are visible, must not exist only in a button callback. An import or another endpoint could bypass it. Put reusable rules in a model scope or service and invoke them where needed.

Try it yourself

Open Pages in the admin and the public Playground in separate tabs. Edit the Playground hero heading, save it, then reload the public tab.

The heading value is stored in the local SQLite database. The migration is the readable code that defines its storage structure: database/migrations/2026_09_08_000001_create_demo_content.php defines the pages.sections JSON column.

A schema component is PHP configuration that tells Filament which admin input to show and how it maps to saved data. app/Filament/Resources/Pages/Schemas/PageForm.php defines Builder::make('sections') and the hero block's TextInput::make('title') .

resources/views/section.blade.php reads the saved title and renders it as the public hero heading. Follow these three landmarks to trace the value from storage, through the admin input, to the public page.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

use App\Cms\Collection;

// In filament-demo/collections.php
Collection::register('projects', [
    'label' => 'Projects',
    'public' => true,
    'fields' => [
        'client' => ['type' => 'text', 'required' => true],
        'description' => ['type' => 'textarea'],
    ],
]);

<h1>{{ $entry->title }}</h1>
<p>Client: {{ $entry->data['client'] ?? '' }}</p>

use Filament\Schemas\Schema;
use Filament\Forms\Components\{TextInput, Builder};
use Filament\Forms\Components\Builder\Block;

// Inside a form-schema class: returns the editor's configuration.
public static function configure(Schema $schema): Schema
{
    return $schema->components([
        // 'title' names the saved field/state path; it creates no column.
        TextInput::make('title')->required(),
        Builder::make('sections')->blocks([
            Block::make('text')->schema([
                TextInput::make('title')->required(),
            ]),
        ]),
    ]);
}
// Separately: migrate title + sections JSON storage and cast sections to array.

A worked example

Collection::register defines a collection and its fields once. The shared entry model stores custom fields in JSON, and the admin builds its form from the definition.

Public pages are enabled explicitly with public => true. Only published entries appear. The generic template displays titles; project Blade templates choose which custom fields to expose.

Collection translations, relationships, media uploads and revisions are not implemented yet. Existing Page and Post capabilities remain separate.

use App\Cms\Collection;

// In filament-demo/collections.php
Collection::register('projects', [
    'label' => 'Projects',
    'public' => true,
    'fields' => [
        'client' => ['type' => 'text', 'required' => true],
        'description' => ['type' => 'textarea'],
    ],
]);

What can go wrong

Do not copy WordPress hooks mechanically into model events. An event is useful for reacting to persistence, but a multi-step workflow with validation and external calls may belong in an explicit service that can be tested directly.

Keep collection and field keys stable: renaming a key does not move existing data. Removing a definition hides its content without deleting entries. Adding a required field does not backfill existing records; it is enforced when an entry is next saved. The admin shows a persistent review notice for saved field keys no longer defined. Changing an entry slug automatically redirects its earlier URLs to the latest slug; renaming collection or field keys still requires an explicit migration.

Try it yourself

Register a team collection in a disposable local CMS, with name information in the built-in title and an optional job_title text field. Create a draft and check that it is absent from the public list.

Publish the entry as an Author or Editor and confirm the public page works. Switch public to false and verify that the list and detail page return 404. These changes belong in your local code, not the temporary public demo.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

For a public article, the address selects a language and slug. The query must enforce publication and active-language rules before a cached result can be shown. Blade receives the allowed record and produces HTML. A guessed draft URL must fail even if someone once cached that record.

For a save, begin at the server boundary: identify the user, authorize the operation, validate input, perform the change and return feedback. The browser is helpful for interaction, but its hidden inputs and disabled buttons are not a source of trust.

GET /en/blog/example
→ route and middleware
→ language + publication checks
→ query / allowed cached data
→ Blade
→ HTML response

What can go wrong

A 404 does not always mean the template is absent. It can be the intended outcome for an unpublished or wrong-language record. Check the route and query before editing the view.

Try it yourself

Find the public article route in the project. Follow the call into PublicContentCache and locate the checks that can prevent a response.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

Consider Projects that belong to Clients. Store clients separately because they have their own identity and are reused. Put client_id on projects and define both sides of the relationship. A short list of decorative cards used only inside one page can reasonably remain block JSON.

If old Projects have no client, adding a required foreign key immediately may fail or force fabricated values. A safer release can add a nullable column, backfill genuine relationships, then enforce the constraint after checking the data. The exact sequence depends on the database and deployment.

// Illustrative migration fragment
$table->foreignId("client_id")->nullable()->constrained();

// Inside Project
public function client(): BelongsTo {
    return $this->belongsTo(Client::class);
}

What can go wrong

Choose deletion behavior deliberately. Deleting a Client should not silently erase published Projects unless that is the actual domain rule. Decide between preventing deletion, retaining the association or clearing a nullable reference.

Try it yourself

Sketch Projects, Clients and Languages. Mark primary keys, foreign keys and which relationships are one-to-many.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

A Projects resource needs a form for editing, a table for finding records, and resource pages for the workflow. A Publish action may be convenient, but the action still needs authorization and should use the same publication rules as any other entry point.

For relationship-heavy lists, decide which related data the table displays and load it intentionally. Showing a client name on every row can otherwise produce an extra query per row. Test with realistic record counts rather than only three demo rows.

ProjectResource
├─ form: title, client, summary, published
├─ table: title, client, status, updated date
├─ pages: list, create, edit
└─ actions: workflow entry points

What can go wrong

A hidden action is not a permission check. A user may invoke the server action directly. Keep authorization at the operation boundary and test it with a user who must be denied.

Try it yourself

Inspect PageResource and its schema/table files. Find the public View page action and compare it with Save changes.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

Imagine an optional card link. has_link changes which fields appear, but it does not decide automatically whether an old URL should be retained, discarded or written. Make that decision deliberately and verify it after toggling the switch off and on.

A field is filled from a record, edited in component state, validated and then dehydrated into data for persistence. Live interaction and persistence are different stages. A default helps a new form; it is not a migration for existing records.

Toggle::make("has_link")->live();
TextInput::make("link_url")
    ->visible(fn (Get $get) => $get("has_link"))
    ->required(fn (Get $get) => $get("has_link"));

// Also decide how hidden state should be dehydrated.

What can go wrong

Disabled, hidden and read-only have different purposes. None is authorization. Review server validation and state handling instead of assuming that invisible values cannot be submitted or that a disabled field must always be saved.

Try it yourself

In the playground card editor, add a link, hide it and re-enable it before saving. Then save and reopen. Compare the two state transitions.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

A block has a type and data. A Text section and a Quote section need different fields, so Builder is a good fit. A list of FAQ questions has the same question/answer structure repeated, so it belongs in a Repeater inside that block.

Our picker now renders samples from the real block views and current stylesheet. This removes manual screenshot maintenance. The samples still use example content: they do not claim to render an editor’s unsaved values.

{
  "type": "quote",
  "data": {"quote": "A sample", "author": "Team"}
}

Builder → varied blocks
Repeater → repeated items with one schema

What can go wrong

Changing a stored block type or renaming data keys can break existing pages. Add compatible fallbacks or migrate old data. A beautiful new sample is not proof that old records still render.

Try it yourself

Add a Quote block to the playground, move it between existing sections and open its sample preview. Save and compare with View page.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

An article editor describes rich content; the server renderer turns supported content into public HTML. Our shared article stylesheet also styles the editing surface, so a heading or coloured section can be checked in context while writing.

For images, save a managed storage path, derive its public URL through the shared helper and keep meaningful alternative text. A filename extension alone is not proof of the actual media type. Upload validation and safe rendering solve different problems.

Editor document
→ supported rich-content renderer
→ public HTML

Shared Tailwind article-rules.css
→ editor typography
→ public article typography

What can go wrong

Raw HTML from an editor should not be treated as automatically safe. Keep the approved renderer or sanitizer in the path. Also test highlighted sections: a dark theme can make dark text or inherited colours unreadable on some backgrounds.

Try it yourself

Open the sample article editor. Compare a heading and a coloured section with the public article, then inspect the shared stylesheet.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

A page title is translated by editing a language version of that page. The Submit button is a shared interface string. These are different workflows: record translation creates an independently editable draft; String translations changes a reusable label or message.

When a visitor changes language, resolve the matching published version rather than substituting a prefix into any URL. The destination might have a different slug or might not be published. Our forms also resolve the matching language version of an embedded form.

Page in Estonian ── translation group ── Page in English
       │                                  │
  own title/body                     own title/body

forms.submit → shared interface string per language

What can go wrong

Linked versions do not synchronize their text. Blank string overrides use file defaults, with English fallback for languages without files. Keep placeholders such as :max when editing messages that need values inserted.

Try it yourself

Open a language version of the playground and inspect Translate. Then open String translations and find forms.submit. Compare what each changes.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

The form record owns its field definitions. On submission, the server loads that trusted schema and validates the incoming values. A visitor cannot make a field optional by removing the required attribute from the HTML.

When validation fails, our form shows a summary containing field names, concise explanations beneath fields, and red borders. Ordinary values are restored; file inputs cannot be repopulated by the browser. Error messages use the form’s language and can be edited in String translations.

Browser values + challenge
→ published form and language check
→ trusted field schema
→ server validation
→ transaction and private file storage
→ redirect with success or error feedback

What can go wrong

CSRF protection, rate limits, a honeypot and a timed challenge address different risks. None replaces validation or authorization for private attachment downloads. A successful local submission also does not imply that email delivery has been configured.

Try it yourself

Submit the demo form empty, follow an error-summary link, then enter sample values. If you send it successfully, find the stored submission in the admin.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

This demo currently admits only the configured demo admin email to its panel. That is a narrow demo policy, not a complete editor/reviewer role system. Adding roles requires a deliberate permission model and checks for relevant operations.

A public attachment URL would bypass the private download controller entirely. Store sensitive files on the private disk and check permissions before streaming them. Similarly, a public query must enforce publication rules even if admin controls already look correct.

Authentication: Who is making this request?
Authorization: May this user perform this operation?
Validation: Is this submitted data acceptable?
Visibility: May this content be served publicly?

What can go wrong

CSRF tokens are not authorization tokens. A signed-in user can still be forbidden from an operation. Test direct requests, not only whether the action is visible in the browser.

Try it yourself

Inspect User::canAccessPanel and the private submission download route. List the checks each performs and the checks it does not perform.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

The public cache stores model data, while each response still renders the current session and form challenge. Caching the final HTML would risk sharing another visitor’s token or feedback. Publication checks still happen before using cached data.

Model observers invalidate public content after supported saves. A direct SQL import can bypass those observers. Treat cache invalidation as part of the import workflow and verify both freshly requested and previously visited pages.

Request A ─┐
           ├─ shared published model data
Request B ─┘

Request A → own session, CSRF and form feedback
Request B → own session, CSRF and form feedback

What can go wrong

Caching can conceal an expensive query during a demonstration. Measure cold requests too. When a list uses related models, eager loading may address repeated relationship queries before a broader cache is needed.

Try it yourself

Find PublicContentCache and its observer. Trace a Page save and a Post save. Describe what a bulk import must do differently.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

An import that calls an external service can take longer than a user should wait for a request. A queue job can move that work into a worker process, but only if the queue connection and worker are configured. A synchronous queue still runs in the request.

Retries are normal. If a job runs twice, it should not create two copies of the same imported item. Use a stable external identifier, a database constraint and an update-or-create strategy where appropriate. Do not assume a successful HTTP response proves a side effect happened only once.

External item ID → unique stored external_id
Fetch / validate → upsert by external_id
Retry → update the same record

Queue dispatch ≠ a running worker

What can go wrong

Logs and failure handling are part of the feature. Record enough context to investigate a failed job without logging credentials or private payloads. After deployment, long-running workers must pick up the new code.

Try it yourself

Write a retry scenario for importing one Project twice. State the expected number of records and how you would verify it.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

An HTTP test can prove that a draft URL returns 404 and that invalid form data creates no submission. A Livewire test can prove that changing a field type keeps its label. A browser check is still needed to see whether the type modal opens correctly and returns focus.

Use assertions on outcomes. A test that repeats the same implementation logic can pass while the user workflow is broken. Include an edge case that would have caught a plausible regression, such as editing one language after another was cached.

Unit → a pure rule
Feature → route, database, permissions
Livewire → form and action state transitions
Browser → focus, layout, interaction

One workflow may need more than one layer.

What can go wrong

Passing tests do not prove every browser layout works. State what was checked and what was not. Keep fixture data independent so tests do not quietly depend on a previous test’s records.

Try it yourself

Choose a feature from this demo and write three expected outcomes: successful use, invalid input, and unauthorized or unpublished access.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

A release needs the tested dependency versions, environment configuration, database changes and built or deployed assets. Persistent uploads and the database must survive the release directory being replaced. In this demo, Vite compiles Tailwind assets before deployment; the server serves the resulting static files.

Plan migrations and rollback together. A release that drops a column can make an older code version incompatible with the database. Prefer changes that allow a transition when uninterrupted service matters, and test backup restoration rather than only creating backups.

Tested code + lockfile
→ prepared assets and configuration
→ compatible migration
→ serving processes / worker restart
→ smoke checks

Persistent storage and database stay outside disposable releases.

What can go wrong

Debug output must not expose production configuration. Check permissions and application configuration as part of the release. Review the version-specific deployment guide rather than copying commands from an unrelated project.

Try it yourself

Write a deployment checklist for this demo, marking which steps require a running service and which affect persistent data.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.

The concept

A worked example

Build the smallest complete Projects feature: title, slug, summary, cover, language and publication status. Add a public list and detail view. Reuse the existing image and language patterns, and define how slug uniqueness is scoped.

Demonstrate the whole workflow to a colleague: create a draft, verify it is inaccessible publicly, publish it, edit it, and verify the public result. If you add translated versions, prove that editing one leaves the other unchanged and that missing versions do not produce misleading links.

Data contract → migration + model
Editing contract → resource + shared fields
Public contract → route + query + view
Quality contract → permissions + tests + demo

What can go wrong

Do not declare the feature complete after generating the resource. Public visibility, internal links, old data, uploads and cache behavior all belong in the acceptance criteria. Keep queues or integrations out unless they are part of this specific assignment.

Try it yourself

In a separate development branch, implement Projects and prepare a five-minute walkthrough. This exercise is performed in the codebase; the course does not execute or grade submitted code.

The public admin demo is temporary and cannot save changes. Real editing exercises require an editor account at /admin. Coding exercises belong in a separate development branch.