telesforox

I hit the same issue (“Abr 2026” showing as “Ene 2026”) and tracked it to a small JS sync block in events-manager.js. The original intention of the code was trying to sync Flatpickr’s internal date with the month/year already rendered by WordPress, to avoid mismatches when WP localization and Flatpickr localization/formatting differ, I suppose. But the mistake is that it builds a Date from the localized display value:

let month_real_value = monthpicker.val() + '-01';
fp.setDate(new Date(month_real_value));

But monthpicker.val() can be something like “Abr 2026”, so it becomes “Abr 2026-01″, which new Date() can’t reliably parse. Some browsers then fall back to an incorrect month (e.g. January), and Flatpickr overwrites the input value. My pragmatic fix: keep the sync, but parse a stable numeric value instead of localized text. The input already has a stable attribute like value=”YYYY-MM” coming from the server, so:

let month_real_value = monthpicker.attr('value') + '-01';
fp.setDate(new Date(month_real_value), false);

(added false prevents triggering onChange/AJAX reload during initialization.)

This preserves the intended “sync” behavior without relying on parsing localized month names.
Hope this helps someone else!