Web Designs Done Right!

Short answer: yes. Longer answer: also yes, but with a plan. When I say "stop building for the internet," I don't mean burn your router and move to a cabin. I mean stop pretending the desktop browser is the default customer experience. Most people find your business on a phone — in a parking lot, on a couch, in line at the grocery store, squinting through screen glare like they're decoding ancient hieroglyphs.

"The internet" in web-design brain usually means wide layouts, hover states, giant hero banners, and navigation with enough dropdowns to qualify as a filing system. That world still exists. It's just not where your customers live anymore. Building desktop-first in 2026 is like printing a beautiful full-page newspaper ad and then wondering why nobody reads it while they're walking the dog.

The Phone Is the Front Door Now

Mobile traffic isn't a trend line on a chart you check once a quarter. It's the front door. If your site only feels good on a 27-inch monitor, you've built a lovely waiting room that most visitors never enter. They hit your homepage on a five-inch screen and immediately know whether you respect their time.

• Tap targets big enough for actual human thumbs, not pencil erasers
• Text that reads without pinch-zoom archaeology
• Navigation that works one-handed — not a hamburger menu hiding a desktop menu that was never designed for touch
• Pages that load before your visitor's patience files for divorce
• Contact info and calls-to-action where thumbs naturally reach

This isn't radical. It's manners. You're greeting guests at the entrance they actually use.

Desktop Isn't Dead — It's Just Not in Charge

Stopping desktop-first design doesn't mean abandoning desktop. It means flipping the order. Design for the phone first. Make it excellent. Then ask what larger screens can add without wrecking the clarity you earned. Desktop gets bonus real estate — use it for richer visuals and breathing room, not for dumping every link you've ever considered into one horizontal navbar.

I reworked my own site header because the title kept invading the navbar on small screens like an overfriendly houseguest. That's what phone-first thinking looks like in practice: you notice the friction, you fix the layout, you test on a real device instead of resizing a browser window and calling it responsive.

What to Do About Your Current Site

If your site was built desktop-first — especially on a free builder that "auto-resizes" for mobile — you're probably serving a shrunken version of a layout that was never meant to be held. Retrofitting mobile usability onto that is like adding a ramp by rearranging the stairs. Possible. Expensive. Full of compromises.

Start fresh with mobile as the blueprint, or hire someone who will. Ask how they handle phone layouts. If they say "it adapts automatically," ask follow-up questions with detective energy. Auto-adapting is not a strategy. Intentional mobile design is.

Build for the device in your customer's hand, not the monitor in your office. The internet isn't going away — but it's mostly arriving through a phone screen, and your website should act like it knows that.

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

Every few years, someone declares dropdown menus dead. Usually right after they've fought a broken mega-menu built by a platform that treats navigation like a junk drawer. Then they pivot to hamburger icons on everything — including desktop sites — and wonder why users can't find the "Services" page without a treasure map and a spirit of adventure.

I'm here to defend the humble CSS dropdown. Not every dropdown. Not the ones that require hover precision worthy of a surgical robot. But a clean, semantic, hand-coded dropdown? Still one of the most useful tools in a desktop navigation toolkit. Yes, I said desktop. We'll get to mobile in a minute.

Why CSS Dropdowns Still Earn Their Keep

On a wide screen, dropdown menus solve a real problem: too many destinations, not enough horizontal space to shout about all of them at once. A well-built dropdown groups related links, keeps the navbar scannable, and lets users drill into subsections without a page reload. That's not laziness. That's information architecture.

• Hover and focus support — desktop users still use mice and keyboards; :hover and :focus-within are valid interaction models
• Semantic HTML — a <ul> inside a <li> is exactly what lists are for
• No JavaScript required — pure CSS dropdowns are fast, resilient, and don't break when a script fails to load
• Predictable behavior — users have seen dropdowns for decades; familiarity is a feature, not a flaw
• Clean visual hierarchy — top-level categories stay visible; details tuck underneath like a well-organized filing cabinet

The problem was never dropdowns. The problem was dropdowns implemented badly — tiny hit areas, no keyboard access, menus that vanish the millisecond your cursor twitches, and fourteen nested levels because someone confused "comprehensive" with "hostile."

What a Good Dropdown Looks Like in 2026

A modern CSS dropdown should be boring in the best way. It opens on hover and keyboard focus. It stays open long enough for a human being to move their pointer. It doesn't cover the entire viewport like a pop-up with commitment issues. And on mobile? It shouldn't be a hover menu at all — it should collapse into an accordion or a tap-to-expand pattern that respects touch.

That's the part people miss when they bury the whole nav behind a hamburger on desktop: you're hiding navigation that was already working. Dropdowns aren't the enemy of mobile-first design. They're the desktop enhancement you earn after the phone layout is solid. Different devices, different patterns, same goal — get people where they need to go without friction.

When to Drop the Dropdown (Pun Intended)

Skip dropdowns when you only have four links total. Skip them when the submenu is one item — just link directly. Skip hover-only menus with zero keyboard support, because that's not a dropdown, that's an accessibility violation wearing a bow tie. And definitely skip builder-generated menus you can't style or debug when they inevitably start pointing at pages that don't exist.

But if you have a real site with real sections — services, resources, about, portfolio categories — a hand-coded CSS dropdown is still a professional, lightweight, standards-friendly solution. I'd rather write twenty lines of clean CSS than bolt on a JavaScript menu library that needs three polyfills and a prayer.

Don't drop dropdowns because they're unfashionable. Drop the bad ones. Keep the good ones. And for heaven's sake, test them with a keyboard before declaring your navigation finished.

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

Let's be honest about free website makers. They promise you a gorgeous business site in an afternoon, no coding required, just drag, drop, and become a digital entrepreneur before your coffee gets cold. It sounds amazing. It also sounds like Ikea instructions that end with "and somehow you now own seven extra bolts and a wobbly bookshelf that leans like it's eavesdropping."

I'm not saying those platforms are useless for everyone. If you need a quick placeholder page for a bake sale, go forth and drag your blocks. But if you're building a real business presence — one that loads fast, ranks in search, survives a phone screen, and doesn't break when you sneeze near the settings panel — free builders are a starter kit, not a finished house.

What You're Actually Buying (Even When It's "Free")

Free website makers sell convenience. What they often deliver is a template wearing your logo like a borrowed jacket. You get limited layouts, bloated page weight, generic markup, and branding that whispers "I was assembled at 11 p.m. from a dropdown menu." Search engines notice. Customers notice. You notice when your contact form sends messages into the void like a message in a bottle with no ocean.

• Cookie-cutter structure that looks like every competitor on the same platform
• Code you don't control — and can't fix when something breaks
• Features that mysteriously require a paid plan the moment you need them
• SEO tools that are mostly stickers on a broken windshield

A professional builds your site like a carpenter builds a cabinet: measured, intentional, and meant to last longer than the trend cycle. A free builder gives you pre-cut panels and hopes you don't notice the missing back wall until tax season.

Why Professionals Still Win

I hand-code websites. Yes, I'm biased. I'm also the person clients call after the free-builder experiment develops "personality" — which is code for random layout shifts, broken mobile menus, and contact forms that work only on Tuesdays. A pro handles hosting setup, error correction, semantic HTML, accessibility, and the boring technical stuff that makes a site work instead of merely exist.

Save the DIY energy for painting your guest room. Let someone who dreams in valid markup build the thing customers judge you by in the first three seconds.

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

So you decided to host your own website. Brave. Romantic, even. You pictured yourself as the captain of your digital ship, steering through calm seas of bandwidth while your business logo glows heroically in the moonlight. Then you met Apache. Or Nginx. Or a hosting control panel that looks friendly until you click the wrong toggle and your site starts speaking HTTP 500 like it's possessed.

DIY hosting isn't impossible. Plenty of smart people do it. But "possible" and "wise use of a business owner's Tuesday" are different categories. When your site goes down at 9 p.m. and you're the only IT department, you become customer support, sysadmin, and emotional support animal for yourself.

The Greatest Hits of Self-Hosted Panic

I've lived this on Arch Linux, which means I chose difficulty mode with a smile. Your hosting adventure may include:

• DNS records that point nowhere, like a GPS with commitment issues
• SSL certificates that expire quietly and take your trust badge with them
• File permissions that turn a simple upload into a philosophical crisis
• PHP version mismatches where localhost is PHP 8 and production is PHP 7.4 and nothing is fine
• Error logs that read like passive-aggressive poetry

Professionals set up hosting so it's monitored, backed up, and recoverable. You set up hosting and then Google "why is my website blank" with the desperation of someone who can hear their phone ringing with client calls.

Let Someone Else Carry the Uptime

Your business website should sell your services, not teach you the emotional range of server administration. Hire someone who knows how to configure hosting, fix errors before you notice them, and deploy updates without accidentally uploading your entire site into the contact/ folder. Ask me how I know that last one is possible.

Your job is your business. My job is making sure the internet shows up when people look for you.

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

Free website platforms are like sample trays at the warehouse store. Delicious at first. Encouraging. Then suddenly you're walking out with a forklift pallet of premium widgets you didn't know existed, plus a membership fee, plus an ad campaign upsell, plus the vague feeling you were upsold by a chatbot wearing a smile.

You start on the free plan. You pick a template. You add your logo. Then you need a custom domain. Then you need to remove their branding. Then you need forms that actually email you. Then you need SEO tools that do more than whisper encouragement. Each step is a small toll booth on the road to a "professional" site that still isn't as professional as one built correctly from the start.

The Hidden Invoice Nobody Reads at 2 a.m.

DIY platforms love offering coupons for Google Ads when what you actually need is clean HTML, fast loading pages, and a site structure search engines can understand without deciphering a JavaScript jungle. So you pay monthly for the builder and you pay for ads to compensate for weak organic visibility. Congratulations — you now have recurring billing and a hobby.

• Monthly platform fees that never quite end
• Paid add-ons for basics like forms, analytics, or removing ads
• Migration pain if you ever want to leave
• Time — the most expensive line item, always omitted from the brochure

Hiring a professional often costs more upfront and less forever. You get a site you own, code that isn't held hostage, and a human who answers questions without making you watch a tutorial hosted by a cheerful stranger.

Do the Math Like a Grown-Up Business

If your hourly rate is worth anything, multiply the hours you'll spend fighting templates by that number. Add platform fees for a year. Add the ad spend you'll need because your pages load like they're carrying emotional baggage. Compare that to a hand-coded site built for your audience, your goals, and your sanity.

Free is a marketing word. Professional is a results word. Choose accordingly before your "simple website project" becomes a part-time job you didn't apply for.

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

Designing for desktop first in 2026 is like opening a drive-through and then acting surprised that people keep walking up to the window. Most of your visitors are on phones. They are not carrying mice. They are carrying thumbs — wonderful, clumsy, opinionated thumbs that will not delicately hover over your tiny navigation links like a museum curator.

Mobile-first design means you plan for the small screen first, then expand gracefully for larger ones. Not the reverse. Not "shrink the desktop site until the menu catches fire." You build for real human hands, real glare on screens, and real impatience.

What Mobile-First Actually Looks Like

Mobile-first is not one CSS trick. It's a mindset:

• Navigation that works with one thumb, not a full-hand yoga pose
• Text that reads without pinch-zoom archaeology
• Buttons large enough to tap confidently, not accidentally summon the footer
• Images that load quickly instead of staging a bandwidth protest
• Content hierarchy that makes sense when the screen is taller than it is wide

I reworked my own site header because the title kept invading the navbar like an overfriendly houseguest. Balance matters on mobile. So does humility — your giant desktop hero image does not get to bully the rest of the layout on a phone.

Design for the Device People Actually Use

If you hire someone to build your website, ask how they handle mobile. If they say "it auto-resizes," ask follow-up questions with the intensity of a detective who just found suspicious footprints. Auto-resizing is not a strategy. Intentional mobile design is.

Your customers are not sitting at desks waiting to admire your hover effects. They're on couches, in parking lots, and in line at the grocery store. Meet them where their thumbs are.

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

Some businesses should think phone-only from the jump. Food trucks, personal trainers, mobile groomers, emergency plumbers — if your customer is likely to find you while squinting at a screen between errands, your website is a phone tool first and a desktop experience second. Maybe third. Maybe "we'll get to it after lunch."

Phone-exclusive design doesn't mean you ignore desktop. It means you stop treating mobile like the kid's table at Thanksgiving. You design for the thumb zone — the area at the bottom of the screen where human thumbs naturally camp out — and you build navigation that respects one-handed reality.

The Thumb Zone Is Real Estate, Not Decoration

Put the important stuff where thumbs can reach it:

• Call buttons — obvious, tappable, not hidden behind a philosophical hamburger menu
• Contact actions near the bottom or within easy thumb arc
• Short paragraphs and scannable headings — nobody reads a novel on a bus
• Forms with big inputs and sane autofill support
• Fast load times, because mobile networks love to humble us

Desktop can still look beautiful. But if the phone experience is an afterthought, you're essentially hanging your business sign at the wrong end of the building and wondering why foot traffic is low.

Mobile-Exclusive Thinking Saves Money Later

Retrofitting mobile usability onto a desktop-first site is like adding a wheelchair ramp by rearranging the stairs. Possible. Expensive. Full of compromises. Start with the phone, expand upward, and you'll spend less time fixing layouts that break every time someone rotates their screen.

Design for thumbs. Test on real phones. Assume your visitor is standing in bright sunlight with 14% battery and zero patience. If it works there, it works everywhere.

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

Have you ever opened a website on your phone and immediately felt tired? Like the menu expected you to perform a ceremonial swipe sequence before revealing the phone number? That's desktop-last design wearing a mobile disguise. It looks responsive. It feels punitive.

Desktop-last happens when someone builds a sprawling horizontal layout with twelve navigation items, four dropdowns, and a hero banner the size of a billboard, then "fixes" mobile by hiding everything behind a hamburger icon and hoping for the best. The hamburger is not a strategy. It's a junk drawer.

Signs Your Site Was Desktop's Favorite Child

• Tiny tap targets packed tighter than seats on a budget airline
• Horizontal scrolling — the UX equivalent of a haunted hallway
• Pop-ups that cover the entire screen and refuse to leave politely
• Text over images with contrast so low it qualifies as abstract art
• Contact forms that zoom the page when you tap a field because font sizes were an afterthought

Mobile users don't want the desktop experience in miniature. They want the right experience for the device they're holding. That usually means fewer choices up front, clearer calls to action, and content that loads before their coffee cools.

Flip the Priority Order

Build mobile layout first. Test it. Make it excellent. Then ask what desktop can add without ruining the clarity you earned. Desktop gets bonus space — use it for richer visuals, not for dumping every link you've ever thought of into one navbar.

A professional designs for the phone in your customer's hand, not the monitor in your office. The giant menu can stay on desktop if it behaves. On mobile, simplicity is not minimalism — it's respect.

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

People love asking me for SEO like it's a spray you mist over a finished website. Poof, rankings! In reality, SEO starts while the HTML is being written — not after the site is already a tangled ball of divs, inline styles, and JavaScript that needs three wishes and a sacrifice to load.

Search engines are trying to understand your content and serve relevant results. They are not impressed by a plugin badge if the underlying markup is nonsense. Clean structure helps crawlers. Clear headings help relevance. Fast pages help everyone, including the human beings who were allegedly the point.

What Search Engines Actually Read First

Before backlinks, before keyword campaigns, before you name your blog posts like a courtroom drama, get the foundation right:

• One clear <h1> per page that says what the page is about
• Logical heading hierarchy — not three <h2>s because they looked big
• Descriptive title and meta description tags written for humans, not robots cosplaying as humans
• Semantic elements so crawlers know what's navigation, what's main content, and what's footer
• Clean URLs and internal links that make sense without a treasure map

Free website builders often bury your actual content under layers of generated markup. Hand-coded sites can give search engines exactly what they need — which is why I keep preaching standards even when it's more work upfront.

Plugins Don't Fix Spaghetti

If your site code is a mess, an SEO plugin is like putting a air freshener in a car that's on fire. It smells like progress. It is not progress. Hire someone who builds SEO into the structure from day one, and you'll spend less time chasing rankings and more time answering leads.

Good SEO is good coding with business goals. Wild concept, I know.

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

Search engines don't fall in love with your font choices. They fall for structure. Semantic HTML is how you tell crawlers, browsers, and assistive technology what your content means, not just what it looks like. It's the difference between a labeled filing cabinet and a cardboard box labeled "stuff."

When I fixed my own site, I replaced misused ARIA roles and div fortresses with actual landmarks: <header>, <nav>, <main>, <footer>. Search engines eat that up because they can find your content without wading through hundreds of lines of framework noise.

Semantic HTML Is SEO Infrastructure

• <article> for self-contained content like blog posts — hello, this page
• <section> for grouped topics within a page
• <nav> for navigation, not every list of links on earth
• Real text in headings, not images pretending to be headlines
• Alt text on images that describes the image, not keyword stuffing

Machine-generated sites from free builders often output markup that looks like it was assembled by a blender. You get divs with classes named after internal IDs that mean nothing to Google. Hand-coded semantic pages give crawlers a straight path to your words — which is kind of the whole point of having a business website.

Standards Are a Ranking Advantage, Not Homework

Will semantic HTML alone put you at #1 for every keyword? No. SEO is still a buffet of content quality, relevance, performance, and backlinks. But standards-compliant markup removes self-inflicted obstacles. You stop making search engines guess. You stop hiding your best content behind code they struggle to parse.

Speak the search engine's love language: clear structure, honest headings, and HTML that means what it says.

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

SERPs — Search Engine Results Pages — are where your website either gets invited to the party or left home with a broken layout and a 404 excuse. You can't buy your way into credibility with ads alone if your organic foundation is wobbly. Web standards coding is how you make sure search engines can read, index, and trust your pages without sending a crawler on a three-day expedition through JavaScript soup.

I've seen sites where the visible text is fine and the underlying code is a horror novel. Search engines see both. So do accessibility tools. So do I, when a client asks why their "free website" isn't showing up for anything except the business name spelled wrong.

How Standards Affect Real Search Performance

• Indexability: valid, semantic markup helps crawlers find and understand your content
• Performance: lean HTML/CSS loads faster — and speed influences rankings and human patience
• Accessibility: overlaps with SEO more than people think; clear structure helps everyone
• Mobile usability: a standards-aware responsive site beats a broken shrink-to-fit layout
• Maintainability: clean code makes SEO updates possible without rewriting the whole site

When I ran validators on my own pages and cleaned up over a hundred errors, I wasn't just checking boxes. I was making the site easier for search engines, browsers, and future me to live with. That's the professional difference: we build for results, not just screenshots.

Your Competitor's Secret Weapon Might Be Valid HTML

Wild idea: what if the business ranking above you simply has a faster, cleaner, more intelligible website? No magic. No keyword stuffing. Just standards, solid content, and markup that doesn't require a search engine to solve a puzzle before reading your phone number.

Stop making Google work overtime. Build it right, structure it honestly, and let your content show up where your customers are already looking.

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

Let's talk about web standards. Not the boring conference-room kind where someone reads forty slides about W3C governance while the audience dreams of lunch. I mean the practical stuff: semantic HTML, accessible forms, valid markup, and not treating your homepage like a MySpace page from 2007 that learned React and developed confidence issues.

I sell websites for a living. I preach standards on my services page. Then I ran a validator on my own site and nearly spilled coffee on my keyboard — which, given my header background, would have been a weirdly on-brand disaster. The point stands: standards matter even when you think you're the exception. Especially then.

Semantic HTML Is Not Decoration

A <div> is a perfectly fine element. I have nothing against divs. But when your entire page is seventeen nested divs and a prayer, you haven't built a website — you've built a cardboard fort. Screen readers, search engines, and future-you-at-2-a.m. all need real landmarks: <header>, <nav>, <main>, <footer>.

I once found a page using role="contentinfo" on the main content area. That's like putting a "EXIT" sign on the front door of a restaurant. Technically a door. Semantically a cry for help. Standards exist so machines and humans can agree what things are, not just what color you made them in CSS.

Accessibility: Not Just for "Those Users"

"Nobody uses keyboard navigation." Incorrect. I do. Your privacy-conscious cousin does. Your client with repetitive strain injury does. The judge reviewing a discrimination complaint might not tab through your site personally, but they will care whether you planned for people who don't interact with a mouse the way a hyperactive squirrel does.

• Visible focus styles — so tabbing doesn't feel like navigating by sonar
• Real label elements tied to inputs — placeholders are hints, not identities
• Buttons that are <button>s, not divs wearing a fake mustache
• Dialogs that trap focus and close with Escape — like civilized software

Accessibility isn't charity. It's quality control. Also, it keeps you from accidentally building a contact form that only works if you click one exact pixel while the moon is in Aquarius.

Validators Exist Because Hubris Is Free

Browsers are famously forgiving. You can serve HTML that looks like it was typed by a cat walking across a keyboard, and Chrome will still render something. Usually. Maybe. On Tuesdays. That tolerance is a trap. It trains developers to believe their code is fine because nothing exploded in their face immediately.

Run a validator. Run Lighthouse. Run an accessibility checker. Yes, you will get feedback. Some of it will sting. I went from 111 errors to zero on my main pages, and the experience was humbling in the way stepping on a bathroom scale after the holidays is humbling — informative, necessary, and slightly personal.

Standards-compliant markup ages better. It survives CMS changes, redesigns, and that intern who "just tweaks one thing" and accidentally rewrites the footer in Comic Sans inline styles.

Mobile Is Not a Cute Little Extra Screen

Over half your visitors are probably on phones. If your layout only sings on a 27-inch monitor, congratulations — you've built a desktop screensaver with SEO ambitions. Responsive design isn't "make it narrower until it fits." It's structure, typography, touch targets, and not making people pinch-zoom to read a sentence that should wrap like a normal paragraph.

I recently reworked my own mobile header because the title was either invading the navbar like an overfriendly houseguest or shrinking to microscopic size like it owed the layout money. Balance matters. Standards matter there too: readable text, usable navigation, content that doesn't require archaeological skills to find.

Why This Still Matters in 2026

AI can generate a website in seconds now. Great. It can also generate a beautiful, standards-violating pile of div soup with the confidence of a golden retriever holding a live grenade. Tools get faster; fundamentals stay the same. Browsers change. Frameworks come and go. Semantic, accessible, valid markup is still how you build sites that work for real people on real devices in the real world.

If you hire someone to build your business site, ask what standards they follow. If they stare blankly and say "it looks fine on my laptop," slowly back away while maintaining eye contact. Then call someone who knows what a <main> element is for.

I'm off to validate another page and pretend I'm doing it for fun, not because I have standards now and they have me. My dog approves of this lifestyle. My validator does not approve of typos, which is why I proofread twice.

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

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?"