Project Setup & the Current Laravel Baseline

Website Rebuild with Laravel

Chapter 1 · Project Setup & the Current Laravel Baseline

Website Rebuild with Next.js and Website Rebuild with Django both had to be honest about something: neither one was evolving the site's own actual, currently-live stack — both meant replacing PHP/Apache with something else entirely, language and all. This course doesn't have to make that same trade. The live site is already PHP. Laravel isn't a replacement for what's running today; it's what that same PHP could become if it grew up into a real, modern framework — the same arbitrary-depth routing requirement, solved in the language already sitting on the server.

composer create-project: Laravel's Own Install Step

composer create-project laravel/laravel osztromok-site cd osztromok-site php artisan serve

Composer is PHP's own package manager — the direct equivalent of npm (Next.js) or pip (Django) — and artisan is Laravel's own command-line tool, the same job manage.py does for Django. php artisan serve starts a local dev server exactly the way runserver or next dev would.

The Generated Structure: One App, Not a Project-Plus-App Split

osztromok-site/ ├── app/ │ ├── Http/ │ │ └── Controllers/ # request-handling logic │ └── Models/ # Eloquent models — Chapter 2's own Page model lands here ├── routes/ │ └── web.php # the project's own route definitions — Chapter 3's own territory ├── resources/ │ └── views/ # Blade templates — Chapter 4 ├── database/ │ └── migrations/ ├── .env └── artisan
A three-way structural difference, not just two
Django Rebuild 1 named its own project-vs-app split as a structural distinction Next.js has no equivalent for. Laravel doesn't have that split either — like Next.js, there's just one application, one directory tree, no separate outer "project" container wrapping independent "apps" inside it. What Laravel does keep from Django's own philosophy is heavy, deliberate internal organization by convention — app/Models, app/Http/Controllers, routes/web.php, resources/views are all fixed, meaningful locations, not just folders you happened to create. It's a genuine third shape: no project/app split like Next.js, but far more prescriptive internal structure than Next.js imposes on its own single app.

Batteries-Included, Like Django — Not Like Next.js

Laravel ships an ORM (Eloquent), a templating engine (Blade), routing, validation, and authentication scaffolding all together, out of the box — much closer to Django's own "one framework, everything included" philosophy than to Next.js's more compositional style, which needed Prisma and NextAuth.js added as separate, deliberate choices. Chapter 9's own admin authentication work leans directly on this — no separate package required there either, echoing Django Rebuild 9's own advantage for a genuinely similar reason.

.env & APP_KEY: A Forward Reference

# .env APP_NAME=Osztromok APP_ENV=local APP_KEY= # empty until generated DB_CONNECTION=mysql DB_DATABASE=osztromok_site php artisan key:generate # APP_KEY=base64:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=

php artisan key:generate creates a real, random APP_KEY — Laravel's own direct equivalent of Django's SECRET_KEY, used to sign sessions and encrypted data. It matters now for exactly the same reason Django Rebuild 1 flagged INSTALLED_APPS ahead of its own Chapter 9: nothing about it needs solving yet, but Chapter 11's own deployment work will come back to it directly.

Where This Course Is Headed

Designing the same flexible, arbitrary-depth content model as an Eloquent self-relationship, Laravel's own routing mechanism for catching a deep path, Blade templates, Vite-based styling, the database via Eloquent (including the same N+1 query problem, solved Laravel's own way), rendering content and the kanji edge case (with a genuinely new Laravel-specific wrinkle), dynamic content and forms through Controllers, admin authentication (this course's own standout "modernize in place" payoff), a hand-built admin CRUD interface, deployment onto the site's own already-live Apache, and a capstone building a genuinely five-level-deep chain live.

Hands-On Exercises

Exercise 1

Explain why this course can honestly frame itself as "evolving the existing stack" in a way the Next.js and Django rebuilds genuinely couldn't, referencing what the current live site is already built in.

📄 View solution
Exercise 2

Explain why Laravel has no equivalent to Django's own project-vs-app split, even though Laravel is otherwise much closer to Django's "batteries-included" philosophy than to Next.js's more minimal one.

📄 View solution
Exercise 3

Explain what php artisan key:generate actually does, and why this chapter treats it as a forward reference rather than something needing to be solved right now.

📄 View solution

Chapter 1 Quick Reference

  • This course's own real advantage: the live site is already PHP — genuinely evolving the existing stack, not replacing it
  • composer create-project laravel/laravel — Laravel's install step; artisan — its own CLI, the same job as manage.py
  • No project-vs-app split — one application, one directory tree, like Next.js — but far more prescriptive internal structure (app/Models, app/Http/Controllers, routes/, resources/views)
  • Batteries-included — Eloquent, Blade, routing, validation, auth all ship together, closer to Django's philosophy than Next.js's own compositional style
  • APP_KEY / php artisan key:generate — Laravel's own direct equivalent of Django's SECRET_KEY; a forward reference to Chapter 11
  • Next chapter: Designing a Flexible URL & Content Model