Category: Security

The Day I Learned DNS Has Feelings (and My MacBook Needed Therapy)

Posted on by Alma Vujasinovic

A WordPress Migration Story About DNS Propagation, Missing Images, and Database/File Mismatches

WordPress migrations look simple – until they aren’t.

If you’re a web designer, developer, agency owner, or business owner dealing with a broken website, this story will feel uncomfortably familiar.

Every web professional has that migration story.

This one involved DNS propagation, WordPress media files, partial restores, and a MacBook that sounded like it was preparing for liftoff.

It Started as a “Simple” WordPress Migration

The task was routine:

  • Database export and import
  • WordPress files moved
  • Admin access confirmed
  • Local preview tested

The site loaded. Images appeared. Confidence was dangerously high. This is usually the exact moment the internet decides to humble you.

The Website That Only Worked Sometimes

Once the site went live, it existed in two parallel realities:

  • In one version, everything worked perfectly
  • In the other, every image had vanished

Same database. Same URLs. Same WordPress install. Completely different results.

This is where browser tabs multiply, terminal windows reopen, and you start wondering whether DNS is a technical system or an emotional one.

The Hosts File Lie (Also Known as False Hope)

Eventually, I did what developers do when logic fails: I edited my hosts file. Instant success.

  • Images were back
  • Pages rendered perfectly
  • Everything looked fixed

Except for one small detail:

It only worked on my computer.

The rest of the world was still staring at broken images. At this point, my MacBook was at peak memory usage and quietly drafting a resignation letter.

The Part No One Explains Well About WordPress

Here’s the detail that causes most WordPress migration disasters:

WordPress stores content in two separate places:

  1. Image references live in the database
  2. Actual image files live on the server filesystem

If you restore:

  • the database from one point in time, and
  • the uploads directory from another point in time

You get a site that:

  • Remembers images perfectly
  • Cannot physically find them

No fatal errors. No warnings. Just empty image containers and quiet judgment.

Why Were NO Errors Showing?

This is what makes these issues so brutal:

  • WordPress does not verify file existence on load
  • Browsers don’t throw errors for missing media paths
  • Hosting dashboards often show everything as “healthy”

To a business owner, it looks random. To junior developers, it looks cursed. To experienced developers, it smells like a partial restore.

The Fix Wasn’t Code (And That’s the Point)

The solution was not:

  • Installing another plugin
  • Reinstalling WordPress
  • Clearing cache for the 30th time
  • Touching a single line of PHP

The fix was restoring the correct filesystem snapshot that matched the database. Sometimes the problem isn’t development.

It’s infrastructure alignment.

Lessons Learned the Hard Way

  • DNS is not instant and never will be
  • “It worked locally” proves nothing
  • Multisite history lingers longer than expected
  • WordPress will happily run without media files
  • If your laptop slows down, close tabs… or buy a new one

Why This Matters for Clients and Agencies

Most website disasters aren’t caused by bad code – sometimes.

They’re caused by:

  • Partial backups
  • Mismatched restores
  • Invisible hosting layers
  • Assumptions made under time pressure

This is exactly how:

  • Business owners lose trust in their site
  • Agencies inherit “mystery problems”
  • Developers burn hours chasing ghosts

My Takeaway Here

These problems are fixable.

But they require:

  • Experience with WordPress internals
  • Understanding of hosting infrastructure
  • Patience
  • And occasionally, a very calm support ticket

Need Help With a WordPress Migration or Cleanup?

If you’re:

  • Planning a WordPress migration
  • Moving hosting providers
  • Dealing with broken images or missing files
  • Inheriting a site that someone else partially restored

This is exactly the kind of issue that experienced planning prevents.

If you want it done cleanly, without surprises, downtime, or laptop trauma, feel free to reach out.

Your website (and your future self) will thank you.

Does my website need HTTPS?

Posted on by Alma Vujasinovic

YES, your website needs HTTPS .

“But my website doesn’t have any forms and it doesn’t collect information from users.”

It does not matter what kind of information is being collected. HTTPS protects more than just form data! HTTPS keeps the headers, URLs, and contents of all transferred pages confidential.

“There’s nothing sensitive on my site anyway.”

Just because your website is hosted safely in your account doesn’t mean it won’t travel through boxes and cables controlled by who knows how many corporate and state owned entities. Do you really want someone injecting images, scripts, or ad content onto your page so that it looks like you put them there? Or changing the words on your pages? Or using your website to attack other sites?  HTTPS prevents all of it. It guarantees content integrity and the ability to detect tampering. If we encrypt only secret content, then we automatically paint a target on those transmissions. Keep which of your transmissions contain secrets secret by encrypting everything.

“The site is HTTP, but our forms are submitted over HTTPS.”

This is as bad as not using any HTTPS at all! All the attacker has to do is change the link or form action to a URL on his/her own server. There’s no way to detect this because it happens over the wire with plain HTTP. Encrypt the WHOLE site and redirect HTTP to HTTPS.

“I can’t afford a certificate.”

They’re free.

“HTTPS is difficult to set up and maintain.”

It just works if Caddy is your web server. Yes, including certificate renewals. No thought required. For everyone else, HTTPS can still be automated by using a Let’s Encrypt client of your choice.

“Attackers can still impersonate my site, even if I use HTTPS.”

As long as your private key stays private, browsers will show warnings if attackers present a mismatched or invalid TLS certificate. And if the attacker does not use HTTPS at all, browsers should mark the impostor page as insecure. To this end, HTTPS guarantees authenticity.

“It works over HTTP just fine.”

Until browsers start flagging HTTP pages as insecure. Effective July 2018, Google’s Chrome browser marks non-HTTPS sites as ‘not secure’.

“HTTPS impacts SEO.”

You’re right—HTTPS improves it! Switching site URLs improperly may impact your search rankings, but HTTPS actually improves them. Just do the switch properly according to the search engine you’re optimizing for, and everything will be fine.

— HOW TO GET ON HTTPS —

The easiest way is through Let’s Encrypt and the Caddy web server, which enables HTTPS for all your sites automatically. There are plenty of other ways to get your site on HTTPS without much trouble.

Click here if you’re still stuck and need help with HTTPS or any other website related problems.