Birthday element - Can it show years in the future?

[kouwearie]

Im asking this because i/clients have difficulties with the date element(it jumps a day sometimes), and doesnt work well with all browsers.
I want to use it for a reservations form, so the birthday element is pretty useless, since i also need reservation possibility for 2013 and 2014, and i like the way it looks, no graphical stuff, just 'basic'..

 

[Jaanus]

But the date element? You may want to use this instead of birthday.

BD is created only for birthdays, decease days, dates of different historical events etc. Specially for the past.

 

[kouwearie]

The date element keeps on bugging me. It wants to post date and time to the database, whatever i do, it wants to change the field type in Mysql to datetime, even if i turn alter field types off, and, for example, when clients fill in a reservation form for a period from 2012-05-16 till 2012-05-25, when its saved to the database, it saves both dates one day later, so from 2012-05-17 to 2012-05-26, which is pretty annoying, but probably caused by the friggin time selector..

 

[Jaanus]

ah, sry, i didn't read your post enough carefully. So the date element is the big problem. Perhaps there are some timezone issues.
Yeah, in some cases I dislike the "datetime" field type as well.
Theoretically it should be possible to give the bd element even more power than it has yet. As I made there some improvements I'll try to think what more could be done. Or will it be done by someone else who get ideas faster.

 

[Jaanus]

Huh, it was too easy, LOL

See this pull request:
https://github.com/Fabrik/fabrik/pull/257

Until they approve you can do as a temporary solution this little thing:

plugins/fabrik_element/birthday/birthday.php around line 171 you should see
$date = date('Y');

If you want e.g 10 years forward, add +10 after the date('Y'), that means replace this line with
$date = date('Y') + 10;

That's all

 

[cheesegrits]

Merged.

-- hugh

 

[Jaanus]

If you want e.g 10 years forward, add +10 after the date('Y')

@kouwearie - Now, as my commit is merged (thanks, Hugh), you just have to update your site from github, go to element admin and write the needed number into the new field 'Years forward/backward' in element admin!
+ sign is not needed there.

 

[kouwearie]

Great work guys, big thanks!

 

[kouwearie]

Only thing i miss is formatting how it goes into Mysql

 

[Jaanus]

Only thing i miss is formatting how it goes into Mysql

What do you mean? Into MySQL it goes always as e.g '2012-05-20' or '0001-03-02', not in any other format.
Important is how it comes to you from MySQL. This is what you can set in element admin.

 

[kouwearie]

yup your right, i was mixing it up, and didnt had cache cleared so there was a slight failure in the element admin because of it.. works great

 

[kouwearie]

There seem to be some bugs in formatting dates and saving to Mysql. Please, have a look at it. People filled in a form, i got a confirmation through mail, ( Formatting failures like 2012,10,3 showed in there), and, it aint saved to database then...

 

[kouwearie]

Its bugging as hell...jeez... I'v got 5 birthday elements in a form, all the same settings, and only 2 of them are saving in MySQL...

 

[kouwearie]

One thing: The ones saving are in a different group, the ones not saving correct are in repeated groups

 

[Jaanus]

One thing: The ones saving are in a different group, the ones not saving correct are in repeated groups

Indeed - see and test
http://j25.nurmoja.net.ee/test-birthday-groups-see-also-vol-2

For now, there are 2 known bugs:
1) birthday element doesn't work correctly when list plugin inline edit is on.
Editing whatever field using inline edit removes the bd element data/sets it to 0 (and bd element itself is not editable). I talked about this somewhere else, I think in github
2) birthday element data is not submitted in db table when the element is in joined group.
We see '0000-00-00' in db field instead. Wrong formatting during submission?
+ something e-mail related that could be one part of the 2-nd bug or something independent.

Can anyone help?

 

[cheesegrits]

Working on this. Found one of the issues, still working on another.

-- hugh

 

[Jaanus]

perhaps I should correct to be exact: when inline edit is on = when inline edit is set for this list (the plugin is always on)

But I still believe you understood me right
Posted via Mobile Device

 

[felixkat]

There does appear to be a third issue, so I'll highjack the post as it's related to the birthday plugin.

We have the Birthday plugin in a repeat group with some other elements.

If you click the + to repeat the group all is well.

If you click the 2nd plus, i,e the one on the repeated group the page scrolls up to the top.

In addition if you load the form with the ?layout=bluesky the page will scroll to the top and refresh removing the ?layout=bluesk syntax.

 

[cheesegrits]

OK, I've committed some changes.

I think the + button issue was down to duplicateGroup banging out, because the birthday element doesn't have an 'input' field. I've added some defensive coding in duplicateGroup to avoid that, but we should probably modify the birthday element to work the same way other elements with sub-elements work. Which is ... using a hidden "input" field, with the main element's name, which the JS for the element writes the formatted value to whenever the element is changed. The date element is a good example of this in action. Oh, and a getValue() and an update() method might be nice as well.

Anyway ... the other fix, of the repeated values not saving to the table properly, was in the main element PHP, in storeDatabaseFormat(), which was still using the old 2.x treatment for repeat groups.

-- hugh

 

[cheesegrits]

Oh, PS ... that first issue, in form.js, was a little more serious than just messing up the birthday element ...

If you had an existing repeat row (i.e. you were editing an existing record with one or more repeated groups), and hit +, the duplicateGroup method would bang out BEFORE we got to the part where we clear all the existing values from the cloned elements. Which included the PK value (typically a hidden 'internalid' element). So when you submitted that form, it would overwrite the first group (the one the repeat was cloned from) with the new repeat data, as two repeat instances were being submitted with the same PK value.

-- hugh