Bob has no idea.
There's this: https://bobsguides.com/blog.html/2013/09/18/displaying-modx-date-fields/. But I'm not sure how that all affects date fields in ClassExtender when they're shown in the Manager.
In the DB are you seeing human-readable dates or just a large number?
It occurs to me that ClassExtender may be using str_replace() to replace the placeholders. If that's true, using output modifiers would lead to no output.
Do you get any output if you leave off the output modifier?
FWIW, the snippets and plugins in CE are sort of "suggestions" to get you started with the class. They were never meant to do everything you might want, and I suspect that date fields might require some extra code in the snippet.
userdata_id checkin checkout 13 2016-11-11 2016-11-11 11 0000-00-00 0000-00-00 11 2018-03-10 2018-04-10 11 2017-05-20 2017-05-21
<field key="userdata_id" dbtype="int" precision="11" phptype="integer" null="false" index="unique" attributes="unsigned"/>
I just checked, and you're right. PHP's strtoTime() function will not handle 15/03/1979 (though it will handle an incredibly wide variety of date and time formats). It will handle 03/15/1978, or 1978/03/15. It will also handle 'March 15, 1979' -- The day always has to come before the month. It makes sense since with dates below 13, it has no way of knowing which is the date and which is the month.
On the duplicates, I'm not sure why that's happening.
You might try adding index="unique" to the userdata_id field:
<field key="userdata_id" dbtype="int" precision="11" phptype="integer" null="false" index="unique" attributes="unsigned">
You'll have to regenerate the class and map files after making the change. Let me know if it works.</field>
<?xml version="1.0" encoding="UTF-8"?>
<model package="extendeduser" baseClass="xPDOObject" platform="mysql" defaultEngine="MyISAM" tablePrefix="ext_" version="1.0.0">
<!-- extend the modUser class -->
<object class="extUser" extends="modUser">
<composite alias="Data" local="id" class="userData" foreign="userdata_id" cardinality="one" owner="local"/>
</object>
<object class="userData" table="user_data" extends="xPDOSimpleObject">
<field key="userdata_id" dbtype="int" precision="11" phptype="integer" null="false" index="unique" attributes="unsigned"/>
<field key="checkin" dbtype="date" precision="100" phptype="date" null="true"/>
<field key="checkout" dbtype="date" precision="100" phptype="date" null="true"/>
<index alias="userdata_id" name="userdata_id" primary="false" unique="true" type="BTREE">
<column key="userdata_id" length="" collation="A" null="false"/>
</index>
<aggregate alias="User" class= "modUser" local="userdata_id" foreign="id" cardinality="one" owner="foreign"/>
<aggregate alias="Profile" class="modUserProfile" local="userdata_id" foreign="internalKey" cardinality="one" owner="foreign"/>
</object>
</model>
>One thing i think about this issue, forgive me if I am out of line or plain wrong, but it seems to me you are trying to use a value within Modx along with values outside of Modx (CE), and this is a source of great trouble and also somehow not aligned well.
Your CE system presumably has a bunch of values for users in it, let's call them values 1-5, but let's recognize that your User system (user values) is/are the real focus. From that angle your user data system looks weird:
UserValue 1 - In CE DB
UserValue 2 - In CE DB
UserValue 3 - In CE DB
UserValue 4 - In Modx>Users>Profile>Path DB
UserValue N - In CE DB
This is the true source of the problem IMHO and can be remedied extremely easily by using a CE value for this data.
I have a tool from my forum days which gets the user creation date and can output, so this task isn't hard (happy to post that if you need), the problem is the intricacies of how Modx parses and manages that string.
<field key="dob" dbtype="int" precision="10" phptype="integer" null="false" default="0" /> <field key="createdon" dbtype="int" precision="20" phptype="timestamp" null="false" default="0" /> <field key="editedon" dbtype="timestamp" phptype="timestamp" null="true" default="NULL" /> <field key="createdon" dbtype="datetime" phptype="datetime" />
I think the problem with your schema is the dbtype and phptype specification of the date fields. Otherwise, I don't see anything wrong with it.
These are the examples I found in the MODX schema:
<field key="dob" dbtype="int" precision="10" phptype="integer" null="false" default="0"> <field key="createdon" dbtype="int" precision="20" phptype="timestamp" null="false" default="0"> <field key="editedon" dbtype="timestamp" phptype="timestamp" null="true" default="NULL"> <field key="createdon" dbtype="datetime" phptype="datetime">
I don't know which would work best for your use case. I'd try the first one first since it's for the modUserProfile object.</field></field></field></field>