Simptom izgleda kao pokvarena baza: spremite negdje u WordPressu tekst s crticom „—” ili slovom poput š, a sljedeći put kad ga pogledate stoji doslovni tekst „u2014” ili „u0161” umjesto znaka. Baza je u redu — uzrok je uži i puno češći nego što djeluje.
Simptom
Najčešće se prvi put vidi ondje gdje netko ručno upiše poseban znak — placeholder u kontakt formi, naslov proizvoda, uvezeni sadržaj. Dok se sprema, u administraciji sve izgleda ispravno; nakon osvježavanja stranice znak je nestao, a ostao je goli hex kod.
Dva mehanizma koja se ne slažu
json_encode() — pa tako i WordPressov omotač wp_json_encode() — po defaultu zapisuje svaki znak izvan ASCII skupa kao \u escape: crtica postaje \u2014, š postaje \u0161. To je ispravan, standardan JSON.
Problem nastaje korak kasnije. add_post_meta(), update_post_meta() i update_option() interno pozivaju wp_unslash() na vrijednost prije spremanja — mehanizam koji poništava WordPressovo automatsko escapiranje $_POST podataka. wp_unslash() ne razlikuje kosu crtu koju je dodao WordPress od one koja je dio vašeg JSON-a: briše obje. Rezultat je da \u2014 postane doslovno u2014.
Popravak
Ispravka je jedna linija, ne restrukturiranje: json_encode($podaci, JSON_UNESCAPED_UNICODE), da znak ostane pravi znak umjesto escapea, plus wp_slash() oko cijelog poziva prije predaje u update_post_meta(), da unslash ima nešto bezopasno za skinuti umjesto vašeg sadržaja.
Gdje se to još krije
Svaki dio koda koji JSON enkodira podatke prije spremanja u meta polje ili opciju je kandidat — form builderi, uvoznici sadržaja, prilagođena polja. Bug prolazi kroz testove neopažen jer testni podaci rijetko sadrže dijakritike ili crticu, pa se prvi put pojavi tek kad netko stvarno napiše hrvatski ili njemački tekst.
Bug koji englesko govorno tržište gotovo nikad ne otkrije — dovoljan je jedan š ili jedna crtica da postane vidljiv.