Datetime Helper (Doesn't Save to DB)
Permalink 1 user found helpful
Hey all, quick Helper question. I am using the datetime helper function in my Block, but it does not update the DB. The JS pop-up calendar works perfectly, but the resulting value isn't stored in the DB.
Wondering what I'm doing wrong.
<?=$dt->datetime('startmin', '12:00 AM', true, true)?>
p.s. This line was copied from C5 core block and startmin is my DB field name.
--djn
Wondering what I'm doing wrong.
<?=$dt->datetime('startmin', '12:00 AM', true, true)?>
p.s. This line was copied from C5 core block and startmin is my DB field name.
--djn
Anyone know how to solve this?
Do you have a publicly accessible URL of where you are trying to do this?
www.breatheintorecovery.com
Is that the HTML response produced by the DateTime Helper (or, more specifically, the Javascript control) is not a valid format for MySQL to store (returns m/d/Y and needs to be Y-m-d).
There are various solutions to this depending on what you prefer (enter raw text in the correct format, transform the response, etc.)
Just thought I'd post in case anyone else ran into this issue.
There are various solutions to this depending on what you prefer (enter raw text in the correct format, transform the response, etc.)
Just thought I'd post in case anyone else ran into this issue.
Is that the HTML response produced by the DateTime Helper (or, more specifically, the Javascript control) is not a valid format for MySQL to store (returns m/d/Y and needs to be Y-m-d).
There are various solutions to this depending on what you prefer (enter raw text in the correct format, transform the response, etc.)
Just thought I'd post in case anyone else ran into this issue.
There are various solutions to this depending on what you prefer (enter raw text in the correct format, transform the response, etc.)
Just thought I'd post in case anyone else ran into this issue.
Is that the HTML response produced by the DateTime Helper (or, more specifically, the Javascript control) is not a valid format for MySQL to store (returns m/d/Y and needs to be Y-m-d).
There are various solutions to this depending on what you prefer (enter raw text in the correct format, transform the response, etc.)
Just thought I'd post in case anyone else ran into this issue.
There are various solutions to this depending on what you prefer (enter raw text in the correct format, transform the response, etc.)
Just thought I'd post in case anyone else ran into this issue.
can you post this in bugs?
isn't there going to be a calendar in the core of C5 or at least a ad on with the launch of the 3.0 version?
I like that calendar a lot though! Are you going to make that a block?
I like that calendar a lot though! Are you going to make that a block?
calendar form helper, datetime. you can see it in concrete5 right now by going to a page, edit mode, hit properties, then click public date/time box and it pops up(might only be in 5.3)
He is saying that the form helper (the helper loaded to create forms for blocks and anywhere else you want an input) doesn't save to the db correctly.
He is saying that the form helper (the helper loaded to create forms for blocks and anywhere else you want an input) doesn't save to the db correctly.
is a bug, per say. Andrew can speak to this in more detail, but he also included a "translate" function (also in the datetime form Helper) and is using this in the upcoming calendar to adjust the selected date value returned from the JQuery Date Selector when inserting events.
I think the question is, if it truly is a "form helper" then it should probably save to the DB correctly without any tweaks ... like all the other Form Helpers do.
In that sense, I suppose it could be a bug.
I think the question is, if it truly is a "form helper" then it should probably save to the DB correctly without any tweaks ... like all the other Form Helpers do.
In that sense, I suppose it could be a bug.
I would say it's a bug since it doesn't behave the way the user (in this case, the developer using the helper) expects. I came across this same issue and have been scratching my head for a bit on it.
What exactly do I have to do to get this working? Use the translate() function somewhere? Edit some Javascript file somewhere? I guess I'm having trouble seeing how to approach this problem. Any help would be appreciated.
What exactly do I have to do to get this working? Use the translate() function somewhere? Edit some Javascript file somewhere? I guess I'm having trouble seeing how to approach this problem. Any help would be appreciated.
Found the translate function in the datetime helper, but I'm having trouble puzzling through how and where to invoke it. Been through a couple of different iterations here and could use an example. Anyone using this successfully?
The datetime function outputs a calendar datepicker form element and the translate function converts those post vars into a format that's compatible with the mysql datetime format.
This would go where you want the form element to display:
And this would be the code you'd need in your controller to "translate" the form post into a datetime format
One thing to consider is that the easiest way to use this is with the post form submissions, not get.
This would go where you want the form element to display:
<?= $dt->datetime('fieldname', '12:00 AM', true, true)?>
And this would be the code you'd need in your controller to "translate" the form post into a datetime format
<? $datetimevalue = $dt->translate('fieldname'); // insert $datetimevalue into the db ?>
One thing to consider is that the easiest way to use this is with the post form submissions, not get.
I'm having problems with this is my own custom block.
I get that you have to call the translate() method in the controller, but it's not recognising my date field.
I have a date field called 'date_start', but looking at the code for the translate() method, it's expecting a field called 'date_start_d' (note the appended '_d'). There's no such field in the POST data.
I assume this is supposed to be appended by the system somewhere, but the only way I can get it to work is by manually creating a 'dummy' entry in the POST data called 'date_start_d' and copying the value of date_start into it.
Am I doing something wrong, or is something amiss?
BTW I'm using 5.4, a manual upgrade from 5.3.3.1.
//EDIT: OK it occurs to me that I can call the field 'date_start_d' in my block's edit.php, but this still seems rather clumsy. At the very least it should be documented.
I get that you have to call the translate() method in the controller, but it's not recognising my date field.
I have a date field called 'date_start', but looking at the code for the translate() method, it's expecting a field called 'date_start_d' (note the appended '_d'). There's no such field in the POST data.
I assume this is supposed to be appended by the system somewhere, but the only way I can get it to work is by manually creating a 'dummy' entry in the POST data called 'date_start_d' and copying the value of date_start into it.
Am I doing something wrong, or is something amiss?
BTW I'm using 5.4, a manual upgrade from 5.3.3.1.
//EDIT: OK it occurs to me that I can call the field 'date_start_d' in my block's edit.php, but this still seems rather clumsy. At the very least it should be documented.
Hmm, this could be a bug, or at the very least some insufficiently documented examples. translate() may only have to be called when you're dealing with datetime() rather than date().
if you just print out the $_POST is the field name of your date field just present in post?
if you just print out the $_POST is the field name of your date field just present in post?
Yeah, $_POST has the 'original' name, i.e. no '_d' suffix. And translate() is necessary with date -- if you don't run it, it tries to insert the unformatted value (in m/d/y format), which of course fails.
Ah. Yes. This is a bug. In the meantime instead of using translate() when using date() just do date('Y-m-d', $_POST['yourfield']));
But we will fix this.
But we will fix this.
I do of course mean date('Y-m-d', strtotime($_POST['yourfield']));
Thanks...glad it wasn't just me being stupid!
How active is work on the datetime helper? There are some things that would be useful for me that it doesn't seem to support (e.g. the ability to change the date format), is this likely to appear in a future version or is it worth thinking about doing the work myself?
How active is work on the datetime helper? There are some things that would be useful for me that it doesn't seem to support (e.g. the ability to change the date format), is this likely to appear in a future version or is it worth thinking about doing the work myself?
I am using concrete's automatic population of database fields from form fields with the same id as the database fields in the add/edit functionality of the block. In other words, the date is selected in the add/edit pop-up, not in the block itself. Am I then to be accessing the $db object in the add/edit.php files and running another mysql query to put the date in the field in the proper format? This seems counterintuitive to me. Right now it seems to me to be better to just accept the date as a plain text string and then do any conversion in the controller afterwards when that date is actually going to be sent elsewhere. Or should I abandon the formhelper entirely and just redirect the target of the form to a translate function in the controller with a hidden element and the action() method?
