Blocks

13.6 Partial Templates vs Blocks: When to Use Each

Right, let’s settle this. You’ve hit that point where you’re copying and pasting the same chunk of HTML across ten templates and the mere thought of changing it in all ten places makes you want to become a beekeeper instead. Django offers you two primary escape routes: {% include %} with partial templates, and {% block %} with template inheritance. They seem similar on the surface, but using the wrong one for the job is like using a screwdriver to hammer a nail—it might eventually work, but you’re gonna have a bad time and leave some ugly dents.

13.5 The block Function vs define

Right, let’s settle this. You’ve probably seen block and define all over the place in your templates and wondered, “Aren’t these the same thing?” I’m here to tell you they are absolutely not, and confusing them is a one-way ticket to a night of head-scratching and template debugging. Think of it this way: define is the architect who draws the blueprints, and block is the contractor who can make on-the-fly modifications when they find a load-bearing wall where the architect promised a skylight.

13.4 Multiple Base Templates for Different Content Types

Right, so you’ve got your base template set up. It’s beautiful. It’s got your <head>, your <footer>, your nav bar that finally works right. You’re feeling like a web development wizard. And then your PM walks over and says, “This is great! Now, can we make the blog post pages look totally different? And the landing pages need a unique layout. Oh, and the admin panel should be a completely separate experience.”

13.3 Overriding Blocks in Child Templates

Right, so you’ve got a base template. It’s a beautiful, well-structured piece of art, full of {% block %} tags like little marked-up landing zones. But you don’t want what the base template serves by default. You want your content in its structure. This is where you stop merely inheriting and start overriding. It’s the core of Jinja’s power, and frankly, it’s where most people first get themselves into a proper muddle. Let’s untangle it.

13.2 Defining Blocks in the Base Template

Right, so you’ve built a base template. It’s a beautiful thing, full of your site’s <head> boilerplate, a <header> with your logo, a <footer> with your copyright (which you’ll forget to update next year). But how do you get unique content from your child templates into that rigid, beautiful frame? You yell “Hey, base template, over here!” and you throw it a block. Think of a block as a named placeholder. You’re telling your base template, “I’m reserving this spot. Later, a child template is going to swoop in and fill it with its own specific content.” It’s the designated area where the child gets to be its own person.

13.1 baseof.html: The Master Layout

Alright, let’s talk about baseof.html. This is it. The big one. The master layout file. If your Hugo site were a stage play, this file would be the stage, the curtains, the lighting rig, and the seating plan. The actual page templates? Those are just the actors who walk on, deliver their lines into the main spotlight, and walk off. They don’t have to worry about the HTML scaffolding, the <head>, the meta tags, the footer—that’s all handled backstage by the master layout.