can I know where is this and do you have sample link for us to see? btw, it seems to be working fine on my test site?
Thanks for the reply. We have this in our test site. Unfortunately can’t link there. Trying to make things act upon the change of start or end date. When date is changed manually, works for both fields. When changed with timepicker, works only for the end date.
Have tried with all other plugins disabed. Only the above JS was loaded on top of EM defaults. Used default template for event-editor.php and when-with-recurring.php.
As the issue is only with timepicker on start-date field, I am inclined to believe something might be off with how timepicker is set to behave. It’s as if it triggers the change only for the end field.
we hook into the change events too in our js, maybe you can get some ideas there. chances are you’re not hooking in correctly for jQuery datepickers, although I’d think the above would work…
In my recollection the above worked in the Spring. I don’t think there should be any special need to hook into anything, as long as the datepicker triggers the changes correctly. Of course there could be a conflict of one sort or another on our site only, but having tried without any other plugins or JS code it seems possible that the cause may have been a change in EM or its datePicker during the last half a year.
Angelo, did you try the above on a test site with EM 5.5.2? Did both of them trigger?
yes, am using EM 5.5.2 – (if possible) maybe you can provide us a screenshot of what you are seeing just to make sure that we are doing the same thing?
The difference is simple enough. With the following code, changing start/end date field values manually/with datepicker:
– start, manually: triggers alert
– start, datepicker: doesn’t trigger alert
– end, manually: triggers alert
– end, datepicker: triggers alert
If I enter anything directly into either field, alert is triggered, so the above code seems to be in order. When I enter a date by clicking the datepicker, the alert is triggered only when setting end date, but not when setting the start date.
I can’t think of any other reason for this except from datepicker not triggering the change when setting the start-date value.
I tried it again and I get this too, am going to let Marcus know about this.
hi again,
we’ve checked on this and as per Marcus advise this seems not a bug because we are using events from datepicker at http://api.jqueryui.com/datepicker/
If it behaves unexpectedly and unintentionally, it seems like a bug to me 🙂 As per what is the cause, that’s where the money is.
Based on your comment, looking into EM 5.5.2’s events-manager.js prompted me to try commenting out lines 692-700:
dateInput.datepicker('option','onSelect', function( selectedDate ) {
//get corresponding end date input, we expect ranges to be contained in .em-date-range with a start/end input element
var startDate = jQuery(this);
var endDate = startDate.parents('.em-date-range').find('.em-date-end').first();
if( startDate.val() > endDate.val() && endDate.val() != '' ){
endDate.datepicker( "setDate" , selectedDate );
}
endDate.datepicker( "option", 'minDate', selectedDate );
});
This resolved the issue. It appears that when you hook into onSelect, you override the default actions, thus getting to decide whether or not to trigger the change.
The issue can be resolved by adding the triggers manually by changing the above code to:
dateInput.datepicker('option','onSelect', function( selectedDate ) {
//get corresponding end date input, we expect ranges to be contained in .em-date-range with a start/end input element
var startDate = jQuery(this);
jQuery(startDate).change();
var endDate = startDate.parents('.em-date-range').find('.em-date-end').first();
if( startDate.val() > endDate.val() && endDate.val() != '' ){
endDate.datepicker( "setDate" , selectedDate );
jQuery(endDate).change();
}
endDate.datepicker( "option", 'minDate', selectedDate );
});
This bug still exists in 5.5.2.1 (dev). The fix is above and requires only adding that one line above: jQuery(startDate).change();
thanks, will let Marcus know about this.
I’ve looked into this and you’re right, but the problem with your fix is that it’s ‘fixing’ a bug which should be fixed at datepicker’s core code. If/once they fix the problem in datepicker, this will throw an infinite loop of change events.
There’s a few debates flying around on this – http://bugs.jqueryui.com/ticket/7654
Maybe you could use the onChange event of the datepicker?
One interesting point here is that I think endate should be fired if startdate changes alter the value of enddate
Thanks for the info. First the conclusion: it would seem to me that as EM fires endDate.change() when endDate is changed programmatically, for consistency’s sake the same should be done with startDate. JQuery UI bugs related to this have been wontfix with no activity for over a year now, so the infinite loop issue doesn’t seem likely to occur any time soon.
If you think it’s good to fire an endDate.change() without firing the equivalent startDate.change(), I’ll look into the alternatives like autocompletechange and onChange you mentioned.
General thoughts
Almost all of our use cases are about having a single event to monitor for changes to a value regardless of the cause. Whether user typed a new date or set it by clicking a widget, our only interest is that the value was changed. We can foresee that in some circumstances it would be interesting to be able to specify between typed and programmatic changes, but they would be a minority.
An ‘enhanced widget’ not firing a change event kills the option of monitoring for all changes and forces developers to specifically monitor for autocompletechanges. JQuery UI doing this breaks how .change() is supposed to work: “The change event is sent to an element when its value changes.”
Whether jQuery UI is breaking the purpose or the documentation is outdated, I don’t know. If the purpose of .change() has changed to refer only to changes caused by user without any programmatics, we and countless others have a need for an alternative that will monitor for any and all changes irrespective of their origin.
Background
That jQuery UI bug 7654 links to http://bugs.jqueryui.com/ticket/8878 for the reasoning, which is “We don’t guarantee that the native change event is useful for enhanced widgets. Change events do not occur when the value is set programmatically, so it’s always possible that the native change event isn’t fired for any given input-based widget.” and “The change event is not useful on an enhanced widget. If you care about knowing when the value has actually changed, use the autocompletechange event.”
I don’t agree with this reasoning. “We can’t guarantee” and “is not useful” seem to me to be completely up to their decisions. They could fire change events in their core widgets and make that a recommendation. “It’s always possible that the native change event isn’t fired” isn’t true: it fires when it is set to fire.
JQuery UI bug 8878 links to https://github.com/jquery/api.jqueryui.com/issues/63, which is about improving the documentation of this behavior.
We’ve tried hooking to the datepicker from our own .js, but haven’t been able to do it so far. Tried the following with no success:
$('.em-date-start, .em-date-end').datepicker( 'option', 'onChange', function( selectedDate ) {
alert( 'Date selection detected' );
});
How to detect when a date has been selected in Events Manager’s datepicker?
