Project Setup & the Current Django Baseline

Website Rebuild with Django

Chapter 1 · Project Setup & the Current Django Baseline

Website Rebuild with Next.js rebuilt this same real site — Philip's own learning blog, currently served as HTML fragments out of a MySQL database via PHP/Apache — specifically to support genuinely arbitrary-depth content nesting: programming/general-purpose-languages/java/fundamentals/chapter-1, five levels deep, rather than the site's current fixed three-level subject/subtopic/page model. This course rebuilds the exact same site, with the exact same requirement, in Django instead — not to declare one framework "better," but because Django solves the identical arbitrary-depth problem through a genuinely different mechanism: its own URL dispatcher paired with a self-referencing database model, rather than Next.js's file-based catch-all routes. Chapter 2 gets to that model directly; this chapter is about standing up a real, working Django baseline first.

django-admin startproject: Project vs. App

# Creates the overall project — settings, URL config, WSGI/ASGI entry points django-admin startproject osztromok_site cd osztromok_site # Creates an APP — a self-contained, reusable unit of functionality inside the project python manage.py startapp content
A structural split Next.js simply doesn't have
Django's project (the settings/configuration container — osztromok_site, here) and app (a focused, in-principle-reusable piece of functionality — content, here) are two genuinely different things, both required, related but not interchangeable. Next.js has no equivalent split at all: there's just "the app," full stop, with routing and configuration living directly inside it rather than in a separate outer container. A Django project routinely hosts several independent apps side by side (this course's own content app, plus django.contrib.admin and the other built-in apps introduced below); a Next.js project has no comparable notion of several separately pluggable "apps" cooperating inside one project.

The Generated Skeleton

osztromok_site/ ├── manage.py # the command-line entry point for everything — runserver, migrate, etc. ├── content/ # the app just created — will hold the Page model starting Chapter 2 │ ├── migrations/ │ ├── models.py │ ├── views.py │ └── apps.py └── osztromok_site/ ├── settings.py # INSTALLED_APPS, DATABASES, middleware — the project-wide configuration ├── urls.py # the project's own root URL configuration ├── wsgi.py └── asgi.py

settings.py and the project-level urls.py are the two files this course returns to most — the first for configuration, the second for wiring the flexible URL dispatch Chapter 3 builds.

Batteries-Included, Visible From the First Run

# settings.py — already present, nothing added by hand yet INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', ]

A real admin interface (django.contrib.admin) and a full authentication system (django.contrib.auth) are already listed — before a single line of this course's own code has been written. Website Rebuild with Next.js needed to install and wire up NextAuth.js separately, starting only at its own Chapter 9. This course reaches the identical admin-login requirement in its own Chapter 9 too — but largely by using what startproject already generated, not by adding a third-party package first. Worth remembering now; it becomes a genuinely concrete payoff later.

Confirming the Baseline Actually Runs

# Applies the migrations the built-in apps above already define (auth, sessions, etc.) python manage.py migrate python manage.py runserver # Starting development server at http://127.0.0.1:8000/

Nothing about this site's own actual content exists yet — this step exists purely to confirm the project itself is sound before Chapter 2 starts modeling real data on top of it.

A first practical habit
Run python manage.py migrate before runserver on a genuinely fresh project, every time — the built-in apps in INSTALLED_APPS already define real database tables (for sessions, users, and more), and skipping this step is a common source of a confusing first-run error that has nothing to do with anything this course will actually build.

Where This Course Is Headed

Designing the same flexible, arbitrary-depth URL and content model Next.js Rebuild 2 designed — now as a self-referencing Django model — then Django's own URL dispatch mechanism, the MVT view/template model, dark-theme styling, the database via Django's ORM, rendering content (including the same kanji edge case Next.js Rebuild 7 resolved), dynamic content and forms, admin authentication, a custom admin CRUD interface for the tree structure, deployment, and a capstone building a genuinely five-level-deep chain live.

Hands-On Exercises

Exercise 1

Explain, in your own words, what a Django "project" is and what a Django "app" is, and why Next.js has no real equivalent to that specific two-level split.

📄 View solution
Exercise 2

This chapter lists django.contrib.admin and django.contrib.auth as already present in INSTALLED_APPS immediately after startproject. Explain why this is called out as a genuine advantage over the Next.js rebuild's own starting point, specifically regarding Chapter 9's admin authentication work.

📄 View solution
Exercise 3

Explain why python manage.py migrate is run before runserver on a fresh project, even though this course hasn't defined a single model of its own yet.

📄 View solution

Chapter 1 Quick Reference

  • The rebuild's own real requirement — arbitrary-depth content nesting, the same one Website Rebuild with Next.js was built around
  • django-admin startproject — creates the project (settings, root URL config); manage.py startapp — creates an app inside it
  • Project vs. app — a genuine structural distinction with no real Next.js equivalent
  • settings.py / urls.py — the two files this course returns to most
  • INSTALLED_APPS — admin and auth are already present out of the box, unlike Next.js's own NextAuth.js add-on requirement
  • manage.py migrate before runserver — applies the built-in apps' own tables even before this course defines any of its own
  • Next chapter: Designing a Flexible URL & Content Model