ACF blijft “Sync available” tonen? Zo werkt ACF JSON echt

Je klikt op Sync. ACF meldt dat de veldgroep is gesynchroniseerd. Je herlaadt de pagina en daar staat hij weer: Sync available. Je klikt nog een keer. Zelfde verhaal. Ergens na de vierde keer begin je aan jezelf te twijfelen.

Het omgekeerde komt ook voor. Je past een JSON-bestand aan, deployt het, en in de admin gebeurt niets. Geen sync-melding, geen nieuw veld. Beide problemen hebben dezelfde oorzaak, en die zit in één regel onderaan je JSON.

Hoe ACF beslist of er iets te syncen valt

ACF vergelijkt de inhoud van je JSON niet met de database. Geen diff, geen hash. Het kijkt naar twee dingen. Bestaat de veldgroep uit het JSON-bestand nog niet in de database, dan is er een sync beschikbaar. Bestaat hij wel, dan vergelijkt ACF de waarde van modified in het bestand met de wijzigingsdatum van de veldgroep in de database. Is het bestand nieuwer, dan verschijnt de melding.

{
    "key": "group_project_fields",
    "title": "CPT -- Project",
    "fields": [ ... ],
    "modified": 1789563408
}

Dat getal is een Unix-timestamp in seconden. Meer zit er niet achter. En precies daardoor kan het op twee manieren misgaan.

Waarom de melding na het syncen blijft staan

De timestamp in je bestand ligt in de toekomst. Tijdens een sync zet ACF de JSON-opslag bewust even uit, zodat het bestand zelf niet wordt aangeraakt. De database krijgt als wijzigingsdatum het moment van nu. Staat in je JSON een tijdstip van volgende week, dan is het bestand na de sync nog steeds nieuwer dan de database. De vergelijking klopt dus weer, en de melding komt terug. Eindeloos.

Hoe komt zo’n timestamp erin? Bijna altijd door handwerk. Iemand typt een getal dat er ongeveer goed uitziet, een script rondt naar boven af, of een AI-assistent verzint er een. De klassieker is een timestamp in milliseconden, dertien cijfers in plaats van tien. Voor ACF is dat ergens in het jaar 58000. Die haal je met syncen niet meer in.

De oplossing: een echte timestamp

Haal de huidige tijd op in je terminal en zet precies dat getal in het bestand. Niet overtypen uit je hoofd, niet afronden.

date +%s
# of
php -r 'echo time();'

1. Draai het commando en kopieer de uitkomst.
2. Zet die waarde bij modified in het JSON-bestand. Tien cijfers, geen aanhalingstekens.
3. Sla op, ga naar de veldgroepen in de admin en klik nog één keer op Sync.
4. Herlaad. De melding is weg, want de database is nu nieuwer dan het bestand.

Andersom: je wijziging verschijnt niet

Je voegt met de hand een veld toe aan het JSON-bestand en laat modified staan. Voor ACF is er dan niets veranderd, want het bestand is niet nieuwer dan de database. Geen melding, geen veld. Zolang de veldgroep ook in de database staat, wint die versie.

De oplossing is dezelfde. Zet modified op de tijd van nu, dan ziet ACF het bestand als nieuwer en biedt het de sync aan. Maak er een gewoonte van: elke handmatige wijziging aan een JSON-bestand krijgt een verse timestamp.

Wanneer je juist niet wilt syncen

Een veldgroep hoeft niet in de database te staan om te werken. Staat hij alleen als bestand in je map, dan laadt ACF hem gewoon uit de JSON. Dat is sneller en je bestand blijft de enige bron. De melding Sync available blijft dan staan, en dat is prima. Wil je hem kwijt, zet dan "private": true in het bestand. ACF slaat zo’n groep over bij de sync-controle.

Ik houd grote veldgroepen met veel clone-velden bewust alleen in JSON. Bij een sync maakt ACF er een kopie van in de database, en ik heb meegemaakt dat die kopie de clones platslaat tot losse velden. Daarna wint de databaseversie, en een veld dat je later in de JSON toevoegt verschijnt niet meer. Dat zoek je niet snel terug.

Controleer je save- en loadpad

Dit alles werkt alleen als ACF weet waar de bestanden staan, en er mag schrijven. Zonder savepad worden wijzigingen uit de admin niet naar een bestand geschreven, en daar merk je niets van tot je een veld mist op een andere omgeving.

add_filter( 'acf/settings/save_json', function ( $path ) {
	return get_stylesheet_directory() . '/acf-json';
} );

add_filter( 'acf/settings/load_json', function ( $paths ) {
	unset( $paths[0] );
	$paths[] = get_stylesheet_directory() . '/acf-json';

	return $paths;
} );

Waar het meestal misgaat

• Een timestamp in milliseconden. JavaScript geeft met Date.now() dertien cijfers. ACF verwacht seconden. Tel de cijfers: het moeten er tien zijn.
• Een toekomstige timestamp om een sync af te dwingen. Het werkt één keer, en daarna blijft de melding voor altijd staan. Gebruik de tijd van nu, dat is genoeg.
• Denken dat het de tijdzone is. Dat is het niet. Een Unix-timestamp is overal ter wereld hetzelfde getal, en ACF vergelijkt met de GMT-tijd van de veldgroep.
• Een merge in git die een oude waarde terugzet. Twee mensen bewerken dezelfde veldgroep, de merge kiest de oudste modified, en op live verschijnt geen sync. Zet na zo’n merge de timestamp opnieuw.
• Deployen en vergeten te syncen. Staat de veldgroep op live in de database, dan zie je je nieuwe veld pas na een klik op Sync. Het bestand alleen is dan niet genoeg.
• Een map die niet schrijfbaar is. ACF slaat dan stil niets op. Controleer de rechten op acf-json als een wijziging uit de admin niet in je bestand belandt.

Tot slot

ACF JSON is geen magie. Het is één getal dat zegt welke kant nieuwer is. Staat dat getal goed, dan doet de sync wat je verwacht. Blijft de melding terugkomen, open dan het bestand en kijk naar de laatste regel. Negen van de tien keer staat daar een datum die nog moet komen.