When updated to recent version of Chronoengine friom 6.0.12 to 6.1.2, calendar picker settings are ignored. Particularly Earliest date/time setting with formula in it, like {date:Y-m-d$+ 10 days} (before update allowed to pick the date not earlier than 10 days since now, after updates shows all dates, any date is pickable)
What is the dumbest is that if I add NEW calendar field and put exactly the same code there, it's going to work.
It means that something is breaking forms upon update. The formula is there, but in old field it doesn't work, while in new one it works.
"How to screw up everything in one update" saga goes on.
ok, so I fiddled a bit more and now I discovered that SOMEHOW Earliest date/time setting {date:Y-m-d$+ 10 days} is related to another setting of calendar, on the same settings tab, named "Real Format". if I use YYYY-MM-DD in Real format, Earliest date +days works. BUT if I use in Real format something like DD.MM.YYYY, then Earliest date doesn't calculated anymore.
It doesn't seem to be the way it intended to work.
ok, so I just tried the dumbest thing I could imagine and it worked: I've changed Earliest time formula to {date:d-m-Y$+ 10 days} (reordered year, month and day accordigly to what I prefer to use in Real format setting), and now it works.
Also curious that Earliest time setting is sensitive to Y, m and d order, but it doesn't care what symbol is between - is it dot or dash.
SO, if you use
Real format DD.MM.YYYY, then Earliest time formula will be {date:d-m-Y$+ <your number here> days}
if you use
Real format YYYY-MM-DD, then Earliest time formula will be {date:Y-m-d$+ <your number here> days}
You get the idea.
I really don't know if this is bug or feature. :twisted:
Yet again unable to upload screenshot, so here it is:
https://www.dropbox.com/s/3rbmfz231yy6hp6/cal-fix.jpg?dl=0
The real format is the actual format you want the field VALUE to have. The other one is just how it LOOKS. So yes, if the actual value you want it to have is a different format, then your earliest date/time will need to match that format.
How the heck inner form data representation is related to mysql {data:} value? That's nonsence. Or fix your (non-existant) documentation to reflect changes in your data representation.
Can you explain that first sentence a bit more for me please
I have to go out now but {date:} and the formats it uses are PHP and don't have anything to do with MySQL.
it also should not any how be related to another setting which formats absolutely other thing.
Of course it should. If you want the real value to be h:m, you try to set the minimum to '2019.08.01', how's that supposed to work exactly?
The format of the field value needing to match the format of the minimum setting seems like a pretty reasonable requirement.
Then why I have to reformat another value, which is not related to this one, and will not be used, and will not be passed with form? This is setting for date-picker display! Why default Y-m-d worked 6 versions before, and SUDDENLY it doesn't work? You think this is normal way to update things, breaking user's forms that worked for years?
Once again - Real format - formats values that passes when form is submitted
Earliest date/time is NOT related to this format. It takes default {date} value and should work with default formats, with no relation to Real format.
Different settings for different things, were NEVER related before.
Or make this relation CLEARLY VISIBLE (comment / write documentation). It's just unfair to make customers spend hours looking for the way to make your product work.
Hi, this just took me some while too... :-/