I have a template variable that we’re using for an event start and end time. The input type is Date. When editing the resource, the date and time can be entered and saved. However, if we refresh or reopen the resource the time reverts back to 12:00. The date remains what was entered.
This site was recently upgrade from 2.8.6 to 3.0.4. It’s entirely possible this was happening before the upgrade, but the client just mentioned it.
Has anyone seen this behavior?
When you output the raw TV value (or look at the value in the database table modx_site_tmplvar_contentvalues), does the time get saved correctly?
Is the problem, that the time doesn’t get saved, or that the time isn’t displayed correctly (in the manager) after a reload?
Does this TV have any special settings in the “Input Options”?
When I test a “Date” TV in MODX 3.0.4, I don’t see the “am” after the time in the input field (that is shown in your screenshot above) on my installation.
input type = date
default date and time = none
Allow Blank = yes
Start Day = Sunday
Disable days = none checked
All other input options are blank
Output type = default
The am pm appears when you enter a date. If you remove the date the am pm disappears.
It appears the time is not saved.
If I enter this and save the resource.
Putting the tv in the content of the page.
produces this
Try pasting the timestamp saved in the value field of the modx_site_tmplvar_contentvalues table, where the
into the converter here to see if the time is saved to the DB.
If the time is there, it’s a display problem.
IIRC, there’s some interesting code that combines the date and time when saving, and some other interesting code that splits them apart for display in the manager. I had to duplicate their functions in NewsPublisher. The problem could be in either place.
I still can’t reproduce the problem with the posted TV-settings (which all seem to be the default).
What are the values of the system settings manager_time_format and manager_date_format?
Open the developer tools in the browser and go to the “Network” tab. Then save the resource. A new request gets generated with the parameter “action” = “Resource/Update”. What is the value of your Date-TV that gets sent to the server? Does it contain the correct time?
The parameter name is “tv” plus the TV-ID. E.g. if the TV-ID is 11, it should look something like this:
Content-Disposition: form-data; name="tv11"
2023-12-14 10:00:00
Halftrainedharry, this is what I see in the dev tools network tab.
Bob, this is what I see in the DB
This is what I see in the converter
So I browsed through the modx_site_tmplvar_contentvalues table and found a bunch of other records with time stamp of 00:00:00. They are all on recently added resources. This reminded me that we recently upgraded this site and I’m now wondering if the process we used might be a factor in this.
This site has menu index numbers approaching 9000. There aren’t really that number of resources but it is a very big site. So to upgrade the site was cloned to test out the upgrade process and to test for any broken elements–there are some custom functions (not related to these resources or dates).
The old site was 2.8.5 (I think) the new site 3.0.4.
Once the testing was done, the modx_site_content and tmplvar_contentvalues tables were exported from the old site (that the client was continuing to update) and imported into the newly upgraded clone and the site was made live.
As I write this, It occurs to me that perhaps the differences in the DB structure/format might cause this. We have not noticed any other issues like this, but we haven’t actively searched either.
Without analyzing these records, it might be these are those records imported from the old database. They are all recently added resources. However, the resource I referenced above was created yesterday to illustrate this post. So it’s happening on newly created resources as well. All the older resources have time stamps in them. Although I haven’t tried resaving one of those to see if it retains or loses the time stamp data.
Perhaps we should create a new TV and use that going forward and retire the old one?
I know that’s a lot of moving parts here. I appreciate your help and your patience.
Thanks.
Click on the request “index.php” (the first row in the screenshot) and look at the values in the “Payload” tab. What is the value of “tv” + ID?
I don’t think the problem is in the database. Nothing relevant has changed there from MODX 2.x to MODX 3. It’s probably a specific setting that causes the issue in the manager UI.
Can you tell me what the values of the system settings manager_time_format and manager_date_format are?
OK, when I edit the time and save I get this from the payload tab:
tv9: 2023-12-31 02:00:00
If I refresh the page, the time stamp reverts to 00.00 and when refresh the resource, the payload tab shows this:
tv9: 2023-12-31 00:00:00
These are the system settings.
So, the value is correct (with the time) when it’s sent to the server, but then is incorrect (without the time) in the database.
Looking at the code, all that happens to the TV value in between, is calling the function format('Y-m-d H:i:s') on it.
Can you put this code in a snippet and check what the output is?
<?php
$value = '2023-12-31 02:00:00';
$dateTime = new \DateTime($value);
$value = $dateTime->format('Y-m-d H:i:s');
return $value;
(The output should still be 2023-12-31 02:00:00.)
Any idea why the screenshot of the system settings shows -0001 as the year in the “Last Modified” column?
It could also be that the code (somehow) thinks, that the “Hide Time” option is set for the TV. Maybe also run this snippet to check that:
<?php
use MODX\Revolution\modTemplateVar;
$tv_ID = 9;
$tv = $modx->getObject(modTemplateVar::class, $tv_ID);
$tvProperties = $tv->get('input_properties');
if (array_key_exists('hideTime', $tvProperties) && (bool)$tvProperties['hideTime']) {
return "Hide time for TV {$tv_ID}!";
} else {
return "Don't hide time for TV {$tv_ID}.";
}
The snippet out does show the correct time: 02:00
I see more than half the system settings have that date -0001 format. All of them are -0001-11-30.
If I edit a setting with a new value, modified date changes to today’s date and time. Just opening and saving, without changes, does not change the modified date.
So I updated the time setting saved it, the modified date changed to today’s date and time. Then edit it back to the original setting, the modified date updated normally again
I then checked to see if this affected the behavior of the event-date TV. It did not.
I’m going to find out what happened on 11-30. This was about the time of the cloning and upgrading process.
This is most likely not relevant to the issue at hand.
Were you able to test the second snippet I posted above?
What’s the content of the column input_properties in the database table modx_site_tmplvars for this TV?
I didn’t see the 2nd snippet. I just ran it and it says:
Hide time for TV 9!
This is what’s in the input_properties for TV 9.
a:10:{s:10:“allowBlank”;s:4:“true”;s:13:“disabledDates”;s:0:“”;s:12:“disabledDays”;s:0:“”;s:12:“minDateValue”;s:0:“”;s:12:“minTimeValue”;s:0:“”;s:12:“maxDateValue”;s:0:“”;s:12:“maxTimeValue”;s:0:“”;s:8:“startDay”;s:0:“”;s:13:“timeIncrement”;s:0:“”;s:8:“hideTime”;s:5:“false”;}
Here’s the TV input options
Somehow this setting has the value “false”.
When I test it with a newly created Date-TV, it has the value “0” instead.
Maybe active “Hide Time Option”, click save, deactivate it again, save again and check if that helps.
Yes! Thank you!
That seems to fix the problem. How strange. Thank you so much for helping me narrow this down. I would never have made it. I’m going to have the client run it through paces to ensure we’re all good.
My last concern is the 0000-11-30 date on so many of the system settings modified date fields.
Should I be concerned?
These values are probably just used to display if (and when) a system setting was changed. I don’t think the ‘wrong’ value will have any negative consequences.
These values are timestamps in the database table modx_system_settings → column editedon.
Great. I’m not going to worry about it.
This whole thing was strange, but I learned a bunch of new stuff.
Thank you so much!
My bad for wasting your time. I assumed the TV values were stored as timestamps like the resource date fields.
I’m glad you got it sorted.