New extension: EEvent Helper

Love EEvent helper. I have a calendar implemented for a church site, but just now realized that for one weblog the start and end TIMES of events are essential.

So count me in as one more request for the setting to not automatically update the expiration date to midnight. (This is different from the Forked version mentioned above, because the Forked version will not clone a custom field to the expiration date.)

So count me in as one more request for the setting to not automatically update the expiration date to midnight.

So, is the request in effect to have the expiration date be left alone completely? Or have it be determined by something else?

As it is, you can still add times to both the start date and end date fields, and they will be respected (provided you have the “remove time” option set to “no”).

Maybe I’m missing the crux of the request?

Okay I double and tripled checked this behavior with the latest version, 1.2. On 1.6.8.

My settings are as follows:

Start Date Field: I have a custom field chosen End Date Field: I have a custom field chosen Clone Start to Entry Date: yes Remove the time from the above date fields: no Remove localization from date fields in this weblog: yes Default Localization settings: fixed.

If I set a time in the my end date custom field, it is overridden to 11:59 pm on save. If I set a time in the Date tab, expiration field, it is overridden to 11:59 pm on save.

I am indeed wanting the times to be honored if entered in the custom end date, or even the expiration date on the date tab.

Does this make sense?

Bizarre. I just tested the exact same settings on my 1.6.8 dev server, and both my start time and time are preserved as I entered them (with the start date inheriting the custom start date (including the time) and the expiration date becoming 23:59:59 on the end date.)

Not being able to manually set the expiration date is expected behaviour - but changing the time entered into custom date fields when the “midnight” setting is not enabled is definitely not. In fact, you shouldn’t even be able to enter a time when that setting is enabled (as some JavaScript should truncate the length of the date fields).

As I look at the screen shot you attached, I too am getting that behavior. Your end time on the custom field is 11:00 PM while the Expiration Date is 11:59 PM.

Humm. I don’t know if we are talking about the same thing. I just want to be able to set the end date and time (via a custom field) and EEvent Helper clone that to the Expiration Date.

I just want to be able to set the end date and time (via a custom field) and EEvent Helper clone that to the Expiration Date.

Gotcha. EEvent Helper will not do this right now. My thinking in designing it this way (where the expiration date is always set to midnight on the last day of the event) is that it’s not often desirable to have an event disappear the second it’s over. 9 times out of 10, you want people to know that there was an event on that day, and have it roll over to “past events” the next day.

I’ll think about adding some configurable options for this though.

Thanks for all your help. Sadly I will turn off EEvent helper for now. ;(

Would be nice if this worked in a SAEF. Without it I have to do all sorts of date manipuluation in PHP in the SAEF in order to calculate the last minute of the date selected and populate the expiration date field that way.

Adam - it was just brought to my attention recently by someone else that Eevent Helper wasn’t working for SAEFs. Turns out they use a different hook to process the entry data. WIll be updating the GitHub repo in the coming days to fix this.

Just pushed version 1.2.2 which is compatible with SAEFs.

Excellent, and quick too!

I haven’t bothered to read through the whole thread, so forgive me if this has already been mentioned, but I ran into a problem today with EEvent Helper and some NBZ Date fields. A bit of digging revealed that, ironically, the jQuery.noconflict(); call was breaking the jQuery calendars that NBZ date uses.

I replaced:

jQuery.noConflict();
jQuery(document).ready(function($)

With:

$(document).ready(function($)

… and everything ran perfectly afterwards. No doubt the noconflict call is there for a reason, but for me it seemed to be doing more harm than good.

That aside everything seems to be working perfectly. Thanks for a very handy plugin. (Any chance of support for the NBZ date fields at some point in the future?)

Hey Dom - you know, I had to remove the noConflict call from another extension of mine recently as well. It seems that jQuery functions can’t be referenced as noConflict and $ on the same page. Oh well - so much for due diligence!

Will revert this shortly, and will look into adding NBZ Date support as well.

That’d be fantastic. Thanks for the speedy reply.