The developer changed the code and nothing changed on the site

This one is small, it is not a bug, and it has probably cost more hours of confusion between clients and developers than anything else on this list.

It happened to me last week on my own site, which is the only reason I am confident about how easy it is to miss.

The situation

I wanted to change a paragraph on my About section. I opened the file where that text lives, edited the sentence, saved, reloaded the page.

The old text was still there.

I cleared the cache. Old text. I checked I had edited the right file. I had. I searched the whole codebase for the old sentence to make sure there was not a second copy. There was not — in the code.

There was one in the database.

Why there are two copies

A well-built WordPress theme usually has text in two places by design, and the pattern is deliberate.

In the code there is a default — the text the site ships with, so that a fresh install looks like the finished design rather than a set of empty boxes. Then there is an override: a custom field the owner can edit from the admin. The code says, in effect, use the edited value if there is one, otherwise use the default.

$title = get_field( 'about_title' ) ?: 'You don’t need to know how to build it.';

This is a good pattern. It means the theme works with an empty database, it means no developer is needed for a wording change, and it means nothing on the page is ever blank.

It also means that once a value has been saved in the admin — even once, even by accident — editing the default in the code does nothing at all. The override wins. Forever. Silently.

Why this is so confusing from both sides

From the client’s side: the developer says the change is done and deployed, and the site says otherwise. It is a very short step from there to wondering whether anything is actually being done.

From the developer’s side: the change is done. The code is correct, the deployment succeeded, and if you check the file on the server the new text is right there. Everything you can see is fine.

Both people are looking at different halves of the same site, and both are honestly reporting what they see.

It gets worse in one specific way. On a project handover, somebody often runs a script that copies the code defaults into the admin fields, so the owner opens the editing screen and sees the real text instead of empty boxes. That is a genuinely good thing to do — an owner facing blank fields under a full page of content has no idea what is safe to type. But from that moment on, every code default is dead. The site is entirely driven by the database, and nobody wrote that down.

How to diagnose it in one minute

The question to ask is simply: is there a stored value?

In the admin, go to the screen where that text would be edited and look at the field. If it contains the old text, that is your answer, and the fix is to edit it there rather than in the code.

If you have command-line access, ask directly:

wp option get options_about_title
wp post meta get 42 case_result

Anything other than empty means the code default is not being used.

And when you do change the code default for a field that is already stored, you have to update both — the code so a fresh install is correct, and the stored value so the live site is correct. Changing only the code is the mistake I made, and it is the mistake that produces the whole conversation.

What good handover looks like

The underlying problem is not technical, it is that nobody says which layer is authoritative. A handover should answer three questions in writing.

Which text is editable from the admin, and where exactly? Not “in the customiser somewhere” — the screen, the section, the field label.

Which text is not editable, and why? Some strings genuinely belong in code: button labels, form validation messages, structural copy. The owner should know that changing those requires a developer, so that a request for one is not a surprise to either side.

What happens if a field is emptied? Usually the default reappears, which is a good behaviour and an alarming one if you did not expect it. An owner who clears a field to “remove” a sentence and watches different text appear will reasonably conclude the site is broken.

One page of documentation, written once. It saves the same conversation repeating for years.

The general version

Any time the same information exists in two places, one of them is authoritative and the other is decoration — and the expensive part is not the duplication, it is that nobody said which is which.

Code default and database value. Site content and a spreadsheet somebody keeps. Prices in the CMS and prices in the accounting system. In each case the system works fine right up until the two copies disagree, at which point everyone involved is looking at a different truth and confidently reporting it.

The fix is never clever. It is deciding, on purpose, which copy wins — and writing that down where the next person will find it.