Your script runs too late to change what the app already read

Data handed from PHP to JavaScript is printed inline, immediately before the script that uses it. If your correction runs in the footer, the application read the original minutes ago in machine terms and has already drawn the interface from it.

The symptom

You filter a localised data object in a footer hook. The values are correct when you log them. The interface still shows the old ones. Nothing is cached and nothing is wrong with your filter.

The actual window

There is a gap between the data being printed and the script being loaded, and that gap is where your code has to run. The tag filter that wraps script output lets you inject markup immediately ahead of a specific script, which puts you inside it. Not a footer hook, not a late-priority action — those are both after the application has mounted.

A watcher on the rendered markup can stay in place as a safety net, but treat it as exactly that. Correcting the interface after it has been drawn causes a visible flicker and breaks the first time the markup changes shape.

Knowing you are on the right page

Half of these problems start with detection. Custom endpoints supplied by a plugin are frequently not pages at all, so asking WordPress which page you are on returns nothing useful, and matching on the address breaks the first time somebody changes a slug.

Ask instead whether the thing you want to modify is present: is that script queued for this request? That question is true exactly when your code is relevant and false the rest of the time, it survives a renamed URL, and it cannot accidentally fire on an unrelated page that happens to match a pattern.

The general rule

Before writing code to change a value, establish when the value is read. Most failures of this kind are not logic errors at all — the logic is fine, and it ran after the only moment it could have mattered.