🚀 Django Day 28 — Custom 404 Page & Dynamic Post Details ⚙️📄 Yesterday, I worked on setting up the index page, and today I focused on making sure each post’s page displays exactly what it’s supposed to 🧠✨. I started by updating the views.py file, where I made changes to the post_detail function. This function now handles displaying the correct post content whenever a user clicks on a specific post. Then, I implemented it in the post_details.html file to show the title, image, and content dynamically. After that, I created a custom 404 error page 🚫 — this is the page users see when they try to access a post or link that doesn’t exist. To do this, I made a new HTML file named 404.html and configured it so Django automatically renders it when a page isn’t found. This makes the site feel more polished and user-friendly 😎. Now, whenever someone enters the wrong URL, instead of a boring technical error message, they’ll see a custom-designed 404 page that fits the look and feel of the project, but it cannot be implemented now due to the fact that the website has not yet been deployed🎨💡. There’s a video below showing how everything looks now 🙌 #Django #Python #WebDevelopment #ErrorHandling #Frontend #100DaysOfCode #LearningInPublic #LexissLearns 💻🔥

🚀 Django Day 16 — Understanding Template Inheritance Today, I explored one of the core features of Django’s template system — Template Inheritance. 💡 Template inheritance allows me to create a base structure that other pages can reuse. Instead of repeating the same HTML layout across multiple files, I can define it once and simply extend it wherever it’s needed. This makes my code cleaner, more organized, and easier to maintain. 🧩✨ To implement this, I created a new folder named “templates”, but this time it’s located inside my main project folder — not inside my app folder. Inside this main templates folder, I created a new file called base.html, which acts as the foundation for all my other pages. Then I made my existing templates — index.html and challenge.html — inherit from this base file using the {% extends %} tag. This tag tells Django that the template should use everything from the base.html file unless it overrides specific sections. 🏗️ Inside the base.html, I used the {% block %} and {% endblock %} tags to define placeholder sections that other templates can fill with their unique content. For example, I wrote something like: {% block content %} Page-specific content goes here {% endblock %} In my index.html and challenge.html, I simply added: {% extends "base.html" %} {% block content %} Page content unique to this template {% endblock %} This setup allows both templates to share the same general layout — like the navigation bar, footer, or styling — while still keeping their unique content. 🌐 I also had to make a small adjustment in the settings.py file to let Django recognize my new templates folder. I did this by adding the path of the folder under the TEMPLATES setting. Once that was done, Django immediately picked up my base structure. ⚙️ It feels amazing to see how much cleaner and scalable my project is becoming and Happy last Sunday of the Month. 💪🔥 #Django #Python #WebDevelopment #CodeJourney #LearningInPublic #TechJourney #lexisslearns 🚀💻

🚀 Django Day 17 — Include Tags Today, I explored another exciting template feature in Django — the {% include %} tag. 💡 This tag allows me to reuse smaller parts of HTML (called snippets or partials) across multiple pages without rewriting the same code again and again. It’s somewhat similar to template inheritance, but instead of having one big base.html file that everything extends from, I can create small, reusable pieces of HTML and include them wherever I need. 🧩 For example, I wanted to create a simple header link that appears both on my index page and details page, which lets users easily go back to the “All Challenges” page instead of clicking the browser’s back button. 🔗 To do this, I created a new folder inside my templates folder called includes, and then added a new file named header.html. This file holds the HTML snippet for my header link — something like: <header> <a href="/challenges/">All Challenges</a> </header> Once that was done, I included this snippet inside my index.html and challenge.html files using the {% include "includes/header.html" %} tag. That single line of code pulled in the header snippet and displayed it on both pages. ⚙️ This makes my project more structured and easier to maintain. If I ever want to update or style the header later, I’ll only need to edit it once — and the changes will reflect everywhere it’s included. ✨ Little improvements like this make a big difference in the coding world. 💻🔥 #Django #Python #WebDevelopment #CodeJourney #LearningInPublic #TechJourney #lexisslearns 🚀

🚀 Django Day 24 – Adding Images to the Project 🖼️ In yesterday’s video 🎥, I showed how the website looked like — it was coming together nicely, but there were no images on it yet 😅. So today, I decided to work on that and bring more life and visual appeal to the blog page 🌄. In Django, images are considered static files, which means they are implemented and attached in the same way CSS files are. For example, when linking a CSS file, I make use of the {% load static %} tag at the top of the HTML file, and then reference the file path like this: <link rel="stylesheet" href="{% static 'blog/styles.css' %}"> The same concept applies to images 🖼️ — for instance, if I want to add a blog banner or thumbnail, I can do something like this: <img src="{% static 'blog/images/blog-banner.jpg' %}" alt="Blog Banner"> This tells Django to look for the image in the static folder and display it properly on the page. Today’s focus was all about understanding how static files (especially images) are handled and how to properly link them within the templates. I also made sure the images directory was correctly structured inside the static folder and that my settings were configured to recognize them ✅. Now the blog page looks way more engaging and visually balanced 💻✨ There’s a video below 🎬 showing how the website looks now with images added 🩵 #Django #Python #WebDevelopment #CSS #Frontend #LearningInPublic #100DaysOfCode #LexissLearns 🚀

🚀 Django Day 9 — Reverse Function & Named URLs Every new day in Django comes with another discovery, and today I explored something that makes our projects cleaner and smarter — the reverse() function and Named URLs. 💡 The reverse function helps make Django projects more maintainable and less error-prone. Instead of manually typing out URLs in different parts of the code, we can use the reverse function to automatically fetch the correct URL by its name. This way, even if a URL changes later, Django automatically adapts — saving us time and avoiding broken links. 🧭 To use it, we simply import reverse from Django and reference the name of the URL we want to point to — simple, efficient, and reliable. ⚙️ I also began learning how to integrate HTML code directly into Django views using curly brackets and f-strings, like this: f"<h1>{ challenge_text }</h1>" It’s a simple concept, but it felt exciting to see how Django logic and HTML can work together to display meaningful output — a small but powerful connection between backend and frontend. 🌍 And below is an exercise I did under URLs and VIEWs Looking back, I can’t help but feel proud of how far this journey has come — from setting up my first Django project to understanding how everything links together. Each day truly builds on the last. 💪 💭 Question for you: When you’re coding, do you prefer handling things manually or do you rely more on built-in functions to keep your code clean and efficient? #Django #Python #WebDevelopment #LearningInPublic #CodeJourney #TechJourney #lexisslearns

🚀 Django Day 11 – The Index Page Today, we focused on building the index page of our Django project — the page that displays all the months as clickable links leading to their respective challenge activity views. To achieve this, we created a new path inside the urls.py file of the challenges app, which handles the logic for our monthly challenges. In order to make the page interactive, we used some basic HTML tags such as <ul>, <li>, and <a href="..">. Here’s how they work together 👇 🧩 <ul> creates an unordered list that serves as the container for all the months. 🔹 <li> represents each month as a list item within that list. 🔗 <a href=".."> makes each month name clickable, linking it directly to that month’s challenge activity page. By combining these, we created a dynamic list of all the months, where clicking on any of them takes the user straight to its respective challenge activity view. After writing the code, we started the development server (as explained back in Day 3) before saving the file. This allowed Django to automatically preview our work and point out any issues. Once everything was set, we navigated to the browser and entered: 🌐 localhost:8000/challenges/ That URL now leads to our index page, displaying all the months neatly listed and fully clickable. This marks an exciting point in the journey — my very first working website with Django. It’s simple, but it represents the foundation of web development with Django. From here, it’s all about consistency, understanding, and steady improvement. 🎥 A short video below shows how everything looks so far. #Django #Python #WebDevelopment #LearningInPublic #CodeJourney #TechJourney #lexisslearns

🚀 Django Day 14 — Exploring Template Tags and Dynamic Pages After diving into Django Template Language (DTL) and template filters yesterday, today I moved one step further — learning about Django Template Tags. ⚙️✨ Template tags are another powerful feature built into DTL that make Django templates truly dynamic. Unlike filters that modify data, tags control the logic and structure of what gets displayed on a page. They are written using curly-brace and percentage symbols like this — {% ... %} — which tell Django to perform specific actions within the HTML file. Some common examples I explored include: 💠 {% for %} — used to loop through lists or query sets. 💠 {% if %} — used for conditional statements, to display content only when certain conditions are met.(to learn later on) 💠 {% include %} — allows reusing smaller template parts (like a navbar or footer) across multiple pages.(to learn later on) 💠 {% block %} and {% extends %} — help in template inheritance, making it easy to build large websites with shared layouts.(to learn later on) To put this into practice, I created a new template file named index.html, which displays all the months dynamically on the index page. Instead of hardcoding each month one by one, I used the for tag to loop through the list of months — making the process cleaner, faster, and easier to maintain. 🧠💻 I had already worked with basic HTML list strings in Day 11, where I made the months appear vertically as clickable links — but this time, it’s all automated through Django logic inside the template. Seeing it come together in the browser felt like a real upgrade! 🚀 Every new feature I learn reminds me that Django isn’t just about coding — it’s about writing smarter, more efficient, and dynamic web structures. 💪 #Django #Python #WebDevelopment #CodeJourney #LearningInPublic #TechJourney #lexisslearns 💻🔥

🚀 Django Day 18 — Wrapping Up Templates & Error Handling Today I wrapped up work on templates by checking my project for any remaining hardcoded HTML and converting those parts into reusable template files 🧩. I also created a custom 404.html template to handle wrong or non-existent URLs, so users see a friendly error page instead of the default debug message ⚠️. To display a custom 404 page I first experimented with render_to_string, which renders a template into an HTML string. For example, I used something like response = HttpResponseNotFound(render_to_string("404.html")) to return the rendered HTML as a 404 response. Then I learned about the Http404 exception. Instead of manually rendering and returning a 404 response, I can raise Http404("Page not found"), and Django will automatically use my 404.html template (if it exists) to show the error page. I found this approach cleaner and more idiomatic because: ✅ Less code — raising Http404 is shorter than building and returning a full response. ✅ Built-in behavior — Django’s error handling pipeline already knows how to find and render 404.html, so I don’t need to duplicate logic. ✅ Better separation — raising an exception keeps view logic focused on business rules; the rendering of error pages stays in Django’s standard flow. After switching to Http404, my error handling looks neater and follows Django best practices — and the custom 404 page now appears automatically when I test an invalid URL. It’s a small improvement, but it makes the app feel more polished. ✨ #Django #Python #WebDevelopment #LearningInPublic #100DaysOfCode #PythonJourney #lexisslearns 🚀

🚀 Django Day 27 — Structuring the Blog Homepage & Displaying Dynamic Posts 🧩📰 Today, I focused on making my blog homepage look more structured and realistic 🎯. I started with the index page, which is basically the first thing users see — so it has to look clean and organized 😎. To make it more dynamic, I added data to my views.py file to represent the blog posts that would appear on the homepage. For now, I’m hardcoding the data (since I haven’t started working with databases yet 🧠). This allowed me to simulate how real posts would display. After adding the data to views.py, I configured it inside post.html and index.html using Django for loops and a few template concepts to display each post nicely. I also implemented logic to make the homepage automatically show only the top three latest posts 🕒✨. So, today’s main changes were done in these three files: 📄 views.py — for adding and structuring post data 📄 index.html — for displaying the top three posts 📄 post.html — for formatting how posts appear on the page There’s a video below showing how the index page looks now — and you’ll notice that instead of repeating the same default post, there are now three unique posts displayed beautifully 🙌 #Django #Python #WebDevelopment #BlogApp #Frontend #100DaysOfCode #LearningInPublic #LexissLearns 💻🔥