Web Designs Done Right!

So I finally sat down to make my own website practice what it preaches. Accessibility, semantic HTML, SEO-friendly markup — I talk about all of that on my services page. But when I actually ran a standards check on my local Apache setup? Oh boy. It was like hiring a building inspector for a house you built yourself and hearing them tap the walls going, "Hmm. Interesting choices."

The good news: my PHP include setup — header.php, navbar.php, content.php, footer.php — is a solid pattern. One shell, swap the middle. Very "reusable template files," very hand-coded, very me. The bad news: the HTML inside those includes had issues. Wrong ARIA roles, duplicate <h1> tags, inline styles everywhere, and a contact modal that only worked on the homepage because the JavaScript lived in one file instead of a shared script. Classic spaghetti — except the noodles were spread across four PHP files.

Apache Had Its Own Opinion

Before I could even validate anything, Apache decided to throw a 403 at me. Why? Because my DocumentRoot still pointed at a testing/ folder I had already deleted. So localhost was basically serving an error page while my real site sat in /srv/http like a patient dog waiting to be let inside.

Arch Linux, as always, was helpful in the most unhelpful way: technically correct, emotionally devastating. One line in httpd.conf, one systemctl reload httpd, and suddenly the site loaded. I celebrated for approximately eleven seconds before the HTML validator reported 111 errors.

Fixing the Markup (Without Crying)

We cleaned up a lot. Swapped a misused role="contentinfo" for a proper <main> landmark. Moved inline styles into styles.css. Fixed form fields to use type="email" and type="tel" instead of plain text inputs pretending to be fancy. Pulled the contact slideout into its own contact-modal.php include and shared the open/close logic in scripts.js so the nav "contact us" link works on every page.

• Semantic landmarks: <header>, <nav>, <main>, <footer>
• Keyboard focus styles for people who tab through links (like civilized humans)
• A shared contact modal with role="dialog" and Escape-to-close
• Zero validator errors across the main pages when we were done locally

I also set up restic backups and a sync workflow between ~/Websites and /srv/http, because I have learned — painfully — that "I'll remember where everything is" is not a backup strategy.

FileZilla: My Other Arch Nemesis

Feeling confident, I opened FileZilla to upload the fixed files to my live host. Everything went great until I realized I had accidentally moved the entire site into the contact/ folder. Not a contact page. Not the contact form. The whole dang website, nested like a matryoshka doll that nobody asked for.

Locally, /srv/http/ was empty except for a contact/ directory containing... well, everything. index.php, blog/, css/, the works. It was like putting your entire house inside the mailbox and wondering why mail stopped arriving.

A quick restore from ~/Websites, an FTP deploy script, and we were back in business. Moral of the story: left pane is local, right pane is remote, and the FTP root is / — not /contact/. Write that on a sticky note. Tattoo it on your arm. Whatever it takes.

The PHP 7.4 Plot Twist

Localhost worked beautifully. The contact slideout slid. The form appeared. Life was good. Then I checked the live site and — button only. No overlay. No form. Just a button staring back at me like a prop on a movie set with no wall behind it.

The culprit? I used str_starts_with() in contact-modal.php to skip the modal on the contact and services pages. That function exists in PHP 8+. My live host runs PHP 7.4. So the footer include fatally errored, the modal HTML never rendered, and the button had nothing to open.

One line change — strpos($requestUri, '/contact') === 0 — and it worked everywhere. Local dev on PHP 8.5, production on PHP 7.4. Same files, different universe. I now respect the phrase "works on my machine" on a spiritual level.

What I'm Taking Away From This

The PHP include pattern is staying. It's simple, maintainable, and very much in the spirit of hand-coded sites. But standards compliance is not a one-time chore — it's part of the craft. And deploying to a live server adds a whole other layer: PHP version differences, FTP paths, and the eternal question of "wait, which folder am I in?"

Next time I'll test the live site immediately after upload, keep my working copy in ~/Websites for FTP convenience, and maybe — maybe — double-check the remote directory before clicking upload. But where's the fun in that?

Now if you'll excuse me, I'm going to go pet my dog and pretend I never saw a validator report with triple-digit errors. The site works. The modal slides. The backups run. That's a Tuesday well spent on Arch Linux.

Photos in this post are from Unsplash (free to use).

Ah, the thrill of web development on Arch Linux. It's like running a marathon in a maze, blindfolded, and occasionally being chased by a bear. And that bear is Apache Web Server.

When I first installed Arch Linux, I knew I was signing up for a bit of a challenge. But hey, it’s Arch! It’s lightweight, fast, and endlessly customizable! That’s what I kept telling myself as I dove into the deep end of the Linux pool. Little did I know that getting a web development environment running on this thing would be like trying to teach a cat to swim.

Step 1: Installing Apache – Piece of Cake, Right?

Arch Linux: You want to install Apache? No problem, just run sudo pacman -S apache.

Me: "Wow, this is going so smoothly. I wonder why people say Arch is hard?"

Five minutes later...

Apache: "Ah, you installed me? Good. Now spend the next two hours configuring me."

Step 2: Configuring Apache – The Real Fun Begins

Now, if you thought the installation was easy, you're in for a treat! The real "joy" starts when you try to configure Apache. Oh, you want to change the default document root to your project folder? Of course, it's just a simple change in the /etc/httpd/conf/httpd.conf file. Except...

• You miss one semicolon, and Apache throws a tantrum.
• You change one directory path, and suddenly it refuses to start.
• You forget to enable the service at boot, and it plays hide-and-seek after every restart.

It’s like a highly temperamental artist – "You don’t understand my vision!" – while you just want to serve some HTML.

Step 3: Permissions – Welcome to Your New Nightmare

Ah, permissions. If there’s one thing I’ve learned, it’s that Arch Linux and Apache are both very particular about who’s allowed to do what. After setting up my development environment, I quickly realized that getting permissions right is more confusing than trying to explain recursion to a toddler.

"Why can’t Apache read my files?"

"Oh, because they’re in a folder owned by root? Sure, let me just—oh, wait, now nobody can read them."

At this point, I've chanted sudo chown so many times that I feel like I'm summoning some kind of permissions demon. And then there's chmod, which I'm pretty sure is short for "Choose How Much Of Despair."

Step 4: The Firewall – Apache's Bouncer

Let’s not forget the firewall. Arch Linux is very protective. You’ll try to load your site in the browser, only to be greeted by a very polite error message: "This site can't be reached."

Apache is running, I’ve configured it, I’ve set up my virtual hosts – but the firewall is like, "Nope, not on my watch!" It’s like Apache is the VIP guest, but the firewall forgot to check the list. So, after a good hour of opening ports, reloading services, and running ufw allow 80/tcp, I finally get it working.

Only to realize I blocked all my other services. Good job, me.

Step 5: Virtual Hosts – Let’s Make This Interesting

By the time I got to virtual hosts, I thought I was a pro. "How hard can it be?"