Skip Navigation

[Résolu] CRED Date-Format of Datepicker-fields

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

This topic contains 10 réponses, has 2 voix.

Last updated by Beda Il y a 4 années et 2 mois.

Assigned support staff: Beda.

Auteur
Publications
#434660
05_errorAfterSavin.JPG
04_datesNotSaved.JPG
03b_errorMessagesAfterSaving.JPG
03a_errorAlert.JPG
02_ValidationError.JPG
01_DefaultFormat.JPG

I am trying to customize the CREDs-Datepicker, but there are problems with saving the CRED-form. I assume, that the format of my date-fields causes the problem. Let me explain:

I have two required custom post type date-fields: a from-date (wpcf-anfr-anreise) and a to-date (wpcf-anfr-abreise). Without customizing the datepicker, these fields are showing up in a different time-format (= F d, Y) as my default wp-date-format (= d.m.Y). You can see that in my first screenshot.

But I have to customize the datepicker anyway, so that I can define a minDate and a maxDate based on the selected dates. If I'm calling the datepicker-function manually, then my default wp-date-format appears. But then the validation doesn't work. It always gives me an error, even though a date is selected (see 2nd screenshot).

I already figured out, that there are two different fields for each date-field: One [display-only]- and a hidden [datepicker]-field. I defined an altField [datepicker] in my datepicker-settings with the altFormat "@" (for timecode). The validation-errror-messages are gone - so far so good. Nevertheless after sending the form, there is an error-alert and the error-message on top are displaying. (screenshots 03a and 03b)

Just to mention it: If I don't define the timestamp-format "@" for the altField, then there are no errors. But my posts aren't showing any dates (screenshot 4).

I compared the default timestamp-value with my altField-value and noticed, that the default ones are given in seconds, my datepicker-values with predefined format "@" are in milliseconds. So I wrote an onSelect-handler for my datepicker, that fills in the correct timestamp-seconds in the [datepicker]-fields. That should work, shouldn't it?

No it's not. Now the validation is okay, but sending the form throws errors on top on both fields, and an error for the second date-field (unlike before for both of the fields) > see screenshot 4. Looking at my source-code, I can see, that the onSelect-handler works fine. But after selecting the second date, mysteriously the first hidden datepicker-field is switching back to the milliseconds-timestamp again.

Why is that? Is that a CRED-default setting or something like that? How can I get rid of that? Or do you know, how to define the standard-timestamp-format, so that it would show seconds instead of milliseconds? Or do you know a better way for storing the correct date-format into the database? Please for help!

#434667

And here is my customized datepicker-code:

jQuery(document).ready(function($){
  from = jQuery('input[name="wpcf-anfr-anreise[display-only]"').attr('id');
  to = jQuery('input[name="wpcf-anfr-abreise[display-only]"').attr('id'); 
  fromcopy = jQuery('input[name="wpcf-anfr-anreise[datepicker]"').attr('id');
  tocopy = jQuery('input[name="wpcf-anfr-abreise[datepicker]"').attr('id'); 
  $( "#"+from ).datepicker({
    minDate: 0,
    altField: "#"+fromcopy,
    altFormat: "@",
    onSelect: function(selectedDate) {
      var dOne = new Date(selectedDate),
      msOne = dOne.valueOf(),
	  sOne = msOne / 1000;
      $("#"+fromcopy).val(sOne);
    }, 
    onClose: function( selectedDate ) {
      $("#"+to).datepicker( "option", "minDate", selectedDate );
    }
  });
  $( "#"+to ).datepicker({
    altField: "#"+tocopy,
    altFormat: "@",
    onSelect: function(selectedDate) {
      var dTwo = new Date(selectedDate),
      msTwo = dTwo.valueOf(),
	  sTwo = msTwo / 1000;
      $("#"+tocopy).val(sTwo);
    }, 
    onClose: function( selectedDate ) {
      $( "#"+from ).datepicker( "option", "maxDate", selectedDate );
    }
  }); 
});

#434932

Timestamp can not be in milliseconds.
Timestamp is a standard time amount in seconds froma date on.
hidden link

To manipulate your CRED date Picker the way you want, I suggest this:

jQuery(window).bind("load", function() {
   jQuery( ".js-wpt-date" ).datepicker( "option", "yearRange", "2002:2012" ).datepicker("option", "defaultDate", "01012012");
});

https://toolset.com/forums/topic/change-default-datepicker-date-in-cred/

This as example would set a Default Date to your picker.

To customize it further, CRED form is using Jquery UI date picker to setup the custom date field, I suggest you follow their document to customize the date picker:
hidden link

Here are a few Threads that can point you in the correct direction to achieve this Custom Code Solution:
https://toolset.com/forums/topic/link-2-datetime-fields-so-2nd-date-cant-be-before-1st-date/#post-341198
https://toolset.com/forums/topic/disable-certain-datepicker-dates-depended-on-another-datepicker-value/#post-330580
https://toolset.com/forums/topic/how-to-restrict-date-range-in-cred-date-pickers/#post-254831

#435316
DatepickerTimeFormat.jpg

Dear Beda,
I went through the steps of this thread before: https://toolset.com/forums/topic/disable-certain-datepicker-dates-depended-on-another-datepicker-value/#post-330580 But overlooked the last posts, in which my solution was already mentioned: I hat to convert my dates to unix timestamp via "cred_before_save_data" and strtotime … So now it works. Thanks.

Only one more question: Why does your datepicker not follow my wp-standard-time-format? In my settings the default format is "d. m. Y". But in every place, where a datepicker is shown, the format is "F d, Y" (as in my Screenshot). Is there a way to handle this?

#435516

CRED and Types are a little limited in what it supports for Date Formats.

In WordPress > Settings > General > Date Format you can set (default) the following modes:
September 13, 2016F j, Y > Works with CRED
2016-09-13Y-m-d > Does not work with CRED and falls back to the WordPress native default
09/13/2016m/d/Y > Works with CRED
13/09/2016d/m/Y > Works with CRED
Custom: > Some work, some do not.

We are aware of this and planning to enhance this.
It's a little complex when signs like "-" or "." come in

I will drive the attention of our Developers on this as well.

For now you are able to use these formats:
'F j, Y', //December 23, 2011
'Y/m/d', // 2011/12/23
'm/d/Y', // 12/23/2011
'd/m/Y', // 23/22/2011
'd/m/y', // 23/22/11

#436765

I see, so my dateformat "d. m. Y" doesn't work. Is there a hook, so that I can customize the fallback-dateformat?

I want to stay with my custom-dateformat on my site, but want to display another (lets say d/m/Y) for the fields, which are created by cred or types.

#436890

No, there is no possiblity to add this in a simple way.

The Developers already pushed this to a "major" issue to be fixed in the next release, we will include a whole list of supported formats so it will work similarly to Views ShortCode.

Unfortunately for now the only supported methods are the ones abovementioned.

I say this is not easily possible because it would need a relatively complex Custom Code approach and given the fact that this will be handled soon, I can not provide a whole Custom Solution right now.

If you need a solution right now, I would suggest you consider contacting one of our certified partners from this link:
https://toolset.com/consultant/

You will get the custom assistance you need to get on with your project.

But if you have any chance to wait with this, I would wait for our Updates.

You can still change that format later, this should not create any issues, as long you do not harcode any formats somewhere, you could develop this now with the "undesired" format and then simply switch later on when it's implemented in CRED.

#436894

Oh, okay. If it's on your list, I will wait …
Could you please mark this thread as "will be solved in next release"?
Thanks for now, Beda!

#436902

Sure, I will do that.

Please let me know if you need any other help or assistance, perhaps (if it's off topic) in another Thread.

I'll be happy to help.

#446000

Types 2.3 will include this new feature (Yes, it is not considered a BUG, as it never was intended to work otherwise in the Code)

I will keep this ticket in the current state, and update you once 2.3 is released.

#555581

This is finally fixed.

Please let us know in new tickets, if you have any other issue with Toolset.