Rebuilding Knut-Edvart.com with PHP and a Directory-Based Layout

Knut-Edvart.com began as my personal website in 2002. Its earlier pages included photographs, programming projects and computer-science work. In rebuilding it, I wanted to preserve that personal foundation while giving the site a clearer purpose: explain artificial intelligence, programming and web development through practical examples.

I also wanted to keep a working style that suits me. I prefer creating directories and files rather than managing a content-management system. The rebuild therefore uses PHP for shared page structure and JavaScript for selected interactions. This case study describes the choices in the current project; it does not claim a measured ranking, revenue or performance improvement simply because the design changed.

Start with subjects that connect to real experience

The content plan groups the site around AI, programming and web development. Those areas connect naturally: an algorithm becomes a program, and a program can become an interactive web tool. My 2003 course-scheduling research with Manuel Penaloza gives the AI section a specific historical starting point rather than an anonymous list of technology topics.

The older programming projects also belong in that structure. Revisiting a neural-network experiment or a search algorithm can explain both the original idea and what a modern implementation would look like. Where source files are missing, the article should distinguish the archived description from a new example. That is more useful than pretending every detail survived.

Use real directories for public page addresses

Each main content page lives in a folder containing an index.php. An article such as /programming/php/read-text-file/ can therefore map directly to a directory on the server. The public address communicates the topic and stays readable when someone copies it into an email or bookmark.

This layout also creates responsibilities. Links must work from deeply nested pages, includes must use reliable filesystem paths, and a moved article needs a redirect from its previous address. A clear directory structure helps organization, but it does not automatically prevent broken references. I keep public URLs and server paths separate so a change in one does not silently rewrite the other.

Let each page configure a shared template

The page file supplies its title, description, path, introductory text and body-file location. A shared renderer loads the header, appropriate template and footer. This keeps the unique article near its directory while allowing a site-wide navigation or metadata change to happen in one place.

<?php
$page = [
    'type' => 'article',
    'path' => '/programming/php/example/',
    'title' => 'A Practical PHP Example',
    'description' => 'Explain the problem and the useful result.',
    'intro' => 'A short introduction for the reader.',
    'body' => __DIR__ . '/body.php',
];
require dirname(__DIR__, 3) . '/layout/render.php';

This illustrative page sits three levels below the site root. Its depth determines the parent path used for the renderer. In a real page, verify that depth instead of copying the number mechanically. The configuration is also explicit about its public path, so canonical metadata does not have to be assembled from an untrusted request hostname.

Share components while allowing different page types

The site uses separate templates for homepage, category, article, research, tool and standard information pages. An article emphasizes reading, a category emphasizes discovery, and a tool places an interactive panel beside an explanation. They share the same navigation and visual language without forcing every kind of content into an identical arrangement.

Cards are another shared component. A single card template can display a label, heading, description and destination across several hubs. In this illustrated batch, it can also display a smaller image when one is available. Existing cards without images continue to use their text layout, which lets the content library grow incrementally.

Make yellow part of the identity

Yellow is my favorite color, so the design uses a pale warm background and stronger golden accents. Charcoal typography keeps long explanations readable, while white article surfaces and dark code blocks separate different kinds of information. The aim is a recognizable personal site that remains comfortable for technical reading.

The new illustrations extend that palette with navy, muted teal and ivory. Each one represents the article’s subject without pretending to be an exact architecture drawing or a screenshot of the old project. Explanations and runnable examples carry the technical detail; the artwork provides an inviting visual entry point.

Keep useful content available without JavaScript

PHP renders navigation, article text and ordinary links. JavaScript supports the mobile menu, analytics choice and browser tools. The meta-description counter and URL encoder/decoder are examples of tasks that can happen locally in the browser. Their supporting text explains what they do and how to interpret the result.

That separation makes failures easier to reason about. If an optional enhancement fails, readers should still be able to open an article and follow its links. A tool that necessarily uses JavaScript needs its own clear fallback message. Adding client-side code should solve a specific interaction problem rather than become a prerequisite for reading the whole website.

Treat privacy and metadata as part of the build

The contact page uses a form so I do not need to publish direct contact details. Its server configuration holds the destination inbox and reCAPTCHA settings. The privacy page describes the services used by the build, including the contact workflow and optional analytics. Those disclosures need to stay aligned with any scripts added later.

The preferred public hostname is www.knut-edvart.com. Canonical tags, sharing URLs and sitemaps use that form. A canonical tag describes a preferred address; a server redirect is a separate mechanism for moving visitors to it. Keeping those roles distinct avoids mistaking a metadata change for a complete hostname migration.

Publish in small batches with an exact upload list

A hand-built site benefits from a predictable release process. New articles arrive with their page and body files, category links, homepage features and sitemap updates. A smaller update archive contains only changed files, and a checklist states where they belong. This reduces the chance of replacing unrelated server customizations while uploading a content batch.

Images add another dependency. The article needs its full-size asset, the card needs a smaller version, and metadata should identify the matching picture. Width and height reserve its space, descriptive alternative text conveys its role, and the image sitemap connects the asset to its article. None of those replaces checking the uploaded page itself.

What this rebuild teaches

A simple stack can still support a structured technical website. The important work lies in consistent templates, accurate content, reliable paths and a release process that keeps related files together. As the article count grows, a generated content manifest may reduce manual link maintenance; that is a practical future improvement rather than a reason to introduce a database before one is needed.

Continue with relative and absolute URLs, reading a text file in PHP and the project collection. PHP’s include reference documents shared-file behavior. This case study is the first entry in the website case-study series, which will document the specific work behind other sites over time.