Same issue here. I had to fix it by editing /wp-content/plugins/events-manager/includes/js/events-manager.js and removing the following two lines (ironically, it was supposed to be a fix):
// this bit fixes issues if the supplied text value has a mismatch with the real text value due to localization differences between WP and flatpickr
let month_real_value = monthpicker.val() + '-01';
fp.setDate( new Date( month_real_value ) );
And also had to rename events-manager.js.map into something like events-manager.js.map.bak to make the frontend use the non-minified version.
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!
