More Problems with unix timestamps

[exside]

I'm not sure where this is coming from exactly, because I have not seen the combination of a date-tv and a "popup/overlay" (like the migx edit/update window) somewhere else (the quickedit window doesn't provide access to pub_date, forexample), so I cannot see how it's done there.

basically it's a two way problem:

1) Unix timestamps that are saved in the db now render correctly in the migxdb grid (as of commit https://github.com/Bruno17/MIGX/pull/80) but they don't in the update overlay when a field is specified as a date tv (date and time, like pub_date or so)...it just always shows 1.1.1970 12:00am, no matter what I try =/. The timestamp is a correct one and it also displays the right one when I switch to a normal text tv, so it's there and it does get read, but the migx update overlay doesn't seem to understand it, probably because it tries to make a Date.parseDate('Y-m-d H:m:i') or so and not read the time as a unix timestamp (I think same problem as with the grid rendering)

I know the problematic part it's located in the templates/mgr/fields.tpl at line 106 where {$tv->get('formElement')}

which creates this in the manager when fetching the form elements of the update overlay, and there lies the problem:

Ext.onReady(function() {
    var fld = MODx.load({

        xtype: 'xdatetime'
        ,applyTo: 'tv1991'
        ,name: 'tv1991'
        ,dateFormat: MODx.config.manager_date_format
        ,timeFormat: MODx.config.manager_time_format

                                ,dateWidth: 120
        ,timeWidth: 120
        ,allowBlank: true        ,value: '1970-01-01 01:00:00'
        ,msgTarget: 'under'

        ,listeners: { 'change': { fn:MODx.fireResourceFormChange, scope:this}}
    });
    Ext.getCmp('modx-panel-resource').getForm().add(fld);
});

which seems to come from /manager/templates/default/element/tv/renders/input/date.tpl, so a native modx thing...= bad = means we have to fix the passed value before that point...

really had to search, but found the right code in core/components/migx/processors/mgr/default/fields.php

at line 60 where

$record = $object->toArray();

// added this ugly thing...but like this it works...but naturally only if the field is called timestamp, so reeeeally ugly, 
// sorry, didn't know better =/
if ( isset($record['timestamp']) ) {
    $record['timestamp'] = strftime('%Y-%m-%d %H:%M:%S', $record['timestamp']);
}

2) The issue also shows it's ugly face when saving a record from the update overlay, so if for example the default value of the date tv is set to "now" (gives the current date/time) I can see in the post that this is sent as a date string in the Y-m-d H:m:i format and not as a unix timestamp (as I have seen in the resource pub_date/unpub_date fields in the normal modx db, date/time values are stored as timestamps), so what happens is, the mgr/default/update.php processor which does a $modx->fromJSON conversion fo the passed POST also only gets a date/time-string as this is what's sent to the script.

When the db field "timestamp" is an integer, the update.php processor cannot write into that field (because it want's to write a string into an int field...), so this is set to default of 0, what causes the 1.1.1970 12:00am...

for this second side of the problem I found a really ugly, hacky workaround by just converting the date/time-string to a unix timestamp in the update.php processor after line 69 at core/components/migx/processors/mgr/default/update.php like this:

if (isset($scriptProperties['data'])) {
    $scriptProperties = array_merge($scriptProperties, $modx->fromJson($scriptProperties['data']));
}
// ugly shit, only works when field is called timestamp
if ( isset($scriptProperties['timestamp']) ) {
    $scriptProperties['timestamp'] = strtotime($scriptProperties['timestamp']);
}

yeah, don't tell me it's ugly =D, I know, but at least, now the right date is SAVED to the DB (if I don't do this, my db timestamps get messed up every time someone edits a record...then its suddenly 0^^)

so I can work now with it btw. with timestamps, but I think this really is a problem...is nobody doing that and occured the same problems, or am I just a moron??? =)

[Bruno17]

you will need to create some custom-processors for getlist.php, update.php and fields.php to handle dates which are in unixtime-format. copy them from default-processors into your package-folder under processors/mgr/default/ or, if you need it not for all configs in your package: processors/mgr/somecustomname and put 'somecustomname' into the processorspath - configuration

I have all my date-fields normally allways in datetime - format

[exside]

no way to handle both depending on what's passed, I mean one is an integer, the other a string, shouldn't be too hard to differentiate at the right place, just not sure where that place would be =)...not so deep into the inner workings of migx yet, and as soon as smarty and extjs come into play, I'm kinda lost =(

[Bruno17]

sure, this would be possible (and has nothing todo with extjs or smarty, its just a php-thing), but the processor would need to know, which fields to check for dates

[exside]

hm, all of type "date"? Is there a way to differentiate between them?