The Django admin: managing data without building a UI for it

Every Django project gets a full CRUD admin interface for free — no HTML, no forms, no views written by hand. It's what this series uses to create test posts through part 9, before there's a public-facing form to do it with (that arrives in part 13).

Creating a superuser

python manage.py createsuperuser

Answer the username/email/password prompts, then visit http://127.0.0.1:8000/admin/ and log in. The admin app has been in INSTALLED_APPS and wired into blogsite/urls.py since part 1 — it's ready before you've registered a single model of your own.

Registering the Post model

# blog/admin.py
from django.contrib import admin
from .models import Post

admin.site.register(Post)

Reload /admin/ and "Posts" now appears, with a working list view, an add form generated from every field on the model, and edit/delete for each row — from three lines of code.

Customizing it with ModelAdmin

# blog/admin.py
from django.contrib import admin
from .models import Post

@admin.register(Post)
class PostAdmin(admin.ModelAdmin):
    list_display = ["title", "author", "published", "created_at"]
    list_filter = ["published", "created_at"]
    search_fields = ["title", "content"]
    prepopulated_fields = {"slug": ("title",)}

@admin.register(Post) is equivalent to admin.site.register(Post, PostAdmin), just as a decorator — both are common, this one reads slightly cleaner once there's a real ModelAdmin class. list_display controls which columns show in the list view (the default is just __str__); list_filter adds a sidebar for narrowing by those fields; search_fields adds a search box. prepopulated_fields auto-fills slug from title as you type it in the add form — client-side JavaScript the admin ships with, not something written by hand.

FAQ

Should the admin stay at /admin/ in production? Changing it to a less guessable path (path("secret-staff-panel/", admin.site.urls)) is a common, low-effort hardening step, since /admin/ is the first path any automated scanner tries. It's not a substitute for a strong password and, ideally, two-factor auth on staff accounts — just one more layer.

Can more than one person have superuser access? Yes — createsuperuser can be run again with a different username for each real staff member who needs full access. For someone who only needs to manage posts, not every model, is_staff=True with specific per-model permissions (set on a regular User, not a superuser) is the more scoped option.

Does registering a model in the admin expose it publicly? No — the admin is only reachable by a logged-in staff user (is_staff=True) at the /admin/ path itself; registering a model there has no effect on the public-facing views and templates the rest of this series builds.

Use the admin now to create two or three test posts with published=True — the next part queries them.