Broken after latest ACF Pro version

There is a fix for this in github that has not been merged into the plugin:

https://github.com/soderlind/acf-field-date-time-picker/pull/102

Hi,

I finally had time (ie summer vacation) to work on the plugin.

As you might have noticed, ACF PRO 5.0+ is no longer supported, ACF PRO has its own date and time picker.

br,
Per

Hi Per – ACF Pro does indeed have it’s own picker, but it doesn’t save in timestamp format and there is no option to do so.

Is there any way to make your picker work with the updated ACF Pro without conflict? reading and writing timestamps is crucial to our application and your plugin was working wonderfully till their update broke it!

Any advice would be appreciated, thanks.

If I could I would make it work together with ACF Pro, but when their core date-time picker was added they decided to use the same name and variables that I used.

in ACF PRO core/compatibility.php there’s a helper function – get_valid_date_time_picker_field – that will convert data saved by my plugin to a format that ACF PRO understand.

If you, in ACF PRO, set the return format to: U, the date+ time picker should return timestamps.

btw, users reports that moving from my plugin to the native works fine (but you should test on a non-production environment first):
https://github.com/soderlind/acf-field-date-time-picker/issues/103

Hope this helps ??

Thanks for the reply. I think ACF said they updated their code to avoid the name conflicts?

The problem, for us, is that we need to keep reading AND writing timestamps, as a considerable amount of the front-end code relies on direct, complex, SQL queries.

i can confirm that their native plugin does NOT work fine!

@ljxdm, Considering that this is now functionality provided by the PRO plugin, you may want to file a support ticket on ACF’s issue tracker as well: https://support.advancedcustomfields.com/new-ticket/

@lelandrd i have, they’re basically passing the buck. we’re left in a position where functionality has been removed but neither side is completely to blame.

Please see and continue the discussion at https://github.com/soderlind/acf-field-date-time-picker/issues/106

I’ve added a beta plugin there.

@ljxdm: The best long-term solution here is for you to update your code, even if it is a considerable amount. ACF’s solution will be maintained in the foreseeable future and there might be more plugins and other code that will rely on it. You become very vulnerable if you continue to rely on Per’s plugin. As all the functionality now is implemented in ACF, I doubt it will be very well maintained in the future (feel free to correct me here, Per).

Of course, I have no idea how much work it would be for you to update your code, but even with a lot of queries, fixing it might be quick. Not fixing your code, will only bring you into technical debt.

For selects it might be to just wrap the instances of meta_key with UNIX_TIMESTAMP() e.g. SELECT * FROM wp_postmeta WHERE UNIX_TIMESTAMP(meta_key) < 1472083200 AND […]orSELECT meta_id, UNIX_TIMESTAMP(meta_value) as meta_value FROM wp_postmeta WHERE […]`

For writes you’ll use DATE_FORMAT() , like UPDATE wp_postmeta SET meta_value = DATE_FORMAT("%Y-%m-%d %H-%i-%s", 1472083200)

(Also please note that the date/time format ACF saves in the DB changed in version 5.3.9, when time was added).

@bj?rn Thank you ?? .. and I agree. If you’re using ACF PRO you should convert your code and use the native functionality.

@bjorn of course, i agree and i fully understand the technical debt of not updating. it just puts me in a very poor position with my client, as you can imagine. that’s why i’m hoping we can resolve by restoring features (either side) rather than re-writing a fairly substantial chunk of the application at their cost. we’ve already considered UNIX_TIMESTAMP() and it may well be the solution – we’re still scoping it.

breaking changes are not ideal, but hey, it’s free software so we can’t complain too much! oh wait, ACF pro isn’t free…