Hey Brian, You can view the test file here.
Both future and past times are forced correctly, down to the second.
Let me know if you need further help testing.
Thanks
Brian,
This extension rocks! Thanks for taking the time to keep it updated!
I have three suggestions to make: - An option to require that a date field (eg, expiration_date) be filled in, which throws an error otherwise. - An option which enforces date1 < date2. - Options per-weblog. Otherwise you’re trapping, eg, entry_date everywhere.
Brian, This extension rocks! Thanks for taking the time to keep it updated!
😊
I have three suggestions to make: - An option to require that a date field (eg, expiration_date) be filled in, which throws an error otherwise.
This would only apply to expiration date, yes? Entry date is automagically filled in, and everything else you can just set as required in the custom fields setup, correct?
- An option which enforces date1 < date2.
That sounds like a good option - a bit tricky to put a GUI to, but it might be a good place to start using jQuery in the CP for me.
- Options per-weblog. Otherwise you’re trapping, eg, entry_date everywhere.
So for example you might want to force entry_date into the future for one weblog, but not for another? Once again gets a bit tricky setting up the control panel, but it is doable.
An option to require that a date field (eg, expiration_date) be filled in, which throws an error otherwise.This would only apply to expiration date, yes? Entry date is automagically filled in, and everything else you can just set as required in the custom fields setup, correct?
That’s a good point. So yes, this would be for expiration_date only.
- An option which enforces date1 < date2.That sounds like a good option - a bit tricky to put a GUI to, but it might be a good place to start using jQuery in the CP for me.
The GUI for date1 < date2 could be as simple as an extra line in your plugin’s settings, which takes pairs of dates. Eg: date1|date2, date3|date4, date5|date6.
JQuery is great - I just started using it to display hover tooltips, and it seems very easy to work with.
- Options per-weblog. Otherwise you’re trapping, eg, entry_date everywhere.So for example you might want to force entry_date into the future for one weblog, but not for another? Once again gets a bit tricky setting up the control panel, but it is doable.
That’s exactly right. I think I lost an hour of my life to disappearing entries before realizing that your plugin was affecting all of my weblogs.
Hi
Sweaty palms is set to YES and it is not working for me. When I leave the expiration date blank, it stays blank when I review the entry in the cpanel after publishing in the SAEF form.
I have the expiration_date in the “disastrously late field”. Could that be why it is not working?
Thanks!
Love this extension, solves many client troubles.
I would like to second the request to be able to set BD per weblog. I had the same disappearing entries not thinking after I turned on sweaty palms thinking it would only add the expiration date to the weblog I magically was thinking of in my head. Not sure why I thought that.
In fact that would be my one request to make this a top-notch, must have extension (which it already is but I’m trying to bribe you via your ego!)
Thanks Phil.
My ego is an easy target, it’s my free time that is a bit harder to get a hold of 😉 In all honesty EE 2.0 has a say in whether this gets developed much more than it is now - if 2.0 includes this functionality out of the box it will be a bit harder to justify the time involved…
Happy holidays!
Hi Brian,
Any chance you can help me out? I’m getting some very weird behaviour when using Blind Date. It looks to be just what I’m looking for too if I can get it to play nice…
In essence my problems is that if I have the extension installed (plain vanilla - no extra settings etc) I find that every time I edit an entry and quick save or update, the entry and expiration times get decremented by 1 hour - ie 23:00 gets saved as 22:00.
This then happens every subsequent time I edit that entry, knocking off an extra hour off whatever the entry and expires times are.
I’m rocking 1.6.6 and the bug still occurs when all other xtns are disabled.
Many thanks for your time,
meta
Hi metadaptive - any luck figuring out your issue (figured I’d ask since it’s been 5 days).
I’ve run into similar situations and I thought I had corrected the issue with the plug-in.
Here’s a response I posted on page 3 of this thread for someone else who was having issues - does any of this help?
I had a similar situation with the time shift on a server I tested on. The thing about dates/times entered into the system is that it interacts with settings in many different places. The server date/time, the localization settings for EE as well as per user, , as well as daylight savings time. Unfortunately I don’t have an exact, “Do this and your problem will be solved,” answer because all blind date does is take the date supplied and apply the PHP function strtotime to that string. After that happens it is entered into the system, and that is when EE does it’s magic and applies all the localization, daylight savings, etc. What I did when I encountered the problem was to check the server date/time to make sure it was correct, the daylight saving setting to make sure that was correct, then individually the localization options for EE, for the user making the post. I think I ended up having to use the localization override in the localization preferences - the option “Honor the Daylight Saving Time setting associated with each section entry?” - set that to “no”. Let me know if that helps - if not we can figure something else out.
Hi Brian,
Cheers for your reply. I’m afraid I haven’t solved this issue just yet.
I did recently have a weird time zone bug on the same install that was fixed by upgrading to 1.6.6, but that was cleared up before I started playing with Blind Date.
I’m pretty confident I’ve got my localisation settings sorted as result of tinkering while trying to fix the earlier problem, and looking at your earlier post I’ve basically got everything set up as you suggest.
I’m on the road at the moment but when I get some time I’ll try this with a clean install and then add settings gradually to see if I can replicate it.
I’m in no vast rush but if you’ve got any ideas they’d be much appreciated. If you like I could sort you out with a temp log-in to my CP…
cheers again for your time!
meta
My current settings are as follows:
My local time zone is GMT/UTC and my hosting (enginehosting) is CST/ UTC -6.00.
My site-wide localisation settings are as follows:
server time zone: UTC -6.00 server offset: 0 default time format: european DST: no Honor DST per entry: no
In my account → personal settings → localisation settings my time zone is set to UTC
and in
Member administration → Member Preferences for the same account “Use this member’s localization settings as the master site default?” is checked.
I’m outputting a my current server time as reported by php and my timezone prefs here:
Blah I was writing a response and then closed the window.
I’m glad you’re not in a rush because I don’t have much free time these days! I have to admit that I wrote this extension because I was annoyed with the date format you had to use in the CP, but I don’t really know much about date/time system in EE (and also have to admit I find it very confusing). I hadn’t even seen most of these options until I started trying to debug this extension. I’ve had times shifting myself, and it can be really hard to figure out what is happening, and when/where it takes place.
Can you use this version of the extension (turn on debug mode in the settings) and let me know the results?
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.