Does it work if you change
$modx->mail->set(modMail::MAIL_SENDER,'Test');
to...
$modx->mail->set(modMail::MAIL_SENDER,'[email protected]');
Thanks that did the trick! It is now working
]]>FWIW, I send all emails through Mailgun, which is free for several thousand emails per month and greatly improves deliverability, though it takes some effort to set up.]]>
$modx->mail->set(modMail::MAIL_SENDER,'Test');
to...
$modx->mail->set(modMail::MAIL_SENDER,'[email protected]');
Thanks for reporting back.
Are you saving timestamps or human-readable dates there? If it's the latter, it will be difficult (but not impossible) to do date arithmetic on them (e.g., "you've been a member for 2 years and 3 months").
I should have remembered that the modUser object already has a createdon field (added somewhat recently), but not an editedon field. Since you're extending modUser, that could have caused your troubles. Using a different name for that field might have made it work as a date field.
Hi thanks Bob, well I thought everything was working now, but for some reason there is another issue.
I set up the postHooks field in register so it would email the Admin when a new user registers. I just called it like this:
&postHooks=`notifyAdmin`
and then my snippet is the standard example:
<?php
$message = 'Hi, a new User has registered on your site: '.$hook->getValue('username')
. ' with email '.$hook->getValue('email').'.';
$modx->getService('mail', 'mail.modPHPMailer');
$modx->mail->set(modMail::MAIL_BODY,$message);
$modx->mail->set(modMail::MAIL_FROM,'[email protected]');
$modx->mail->set(modMail::MAIL_FROM_NAME,'Test');
$modx->mail->set(modMail::MAIL_SENDER,'Test');
$modx->mail->set(modMail::MAIL_SUBJECT,'New App User Registration');
$modx->mail->address('to','[email protected]');
$modx->mail->setHTML(true);
if (!$modx->mail->send()) {
$modx->log(modX::LOG_LEVEL_ERROR,'An error occurred while trying to send the email: '.$err);
}
$modx->mail->reset();
/* tell our snippet we're good and can continue */
return true;(obviously with [email protected] changed in both places to my actual email address - which may I add is an email that uses the same domain so shouldn't get blocked or rejected etc)
But the modx Log just gives me this:
[2018-09-17 14:53:02] (ERROR @ /public_html/core/cache/includes/elements/modsnippet/33.include.cache.php : 13) An error occurred while trying to send the email:
Has something changed with the newer versions of PHP that I need to alter the snippet, or can anyone else spot what is wrong. Not sure how to diagnose this further really. I've checked the email logs on the server and such and can't find anything there either.
Thanks for any help.]]>
Are you saving timestamps or human-readable dates there? If it's the latter, it will be difficult (but not impossible) to do date arithmetic on them (e.g., "you've been a member for 2 years and 3 months").
I should have remembered that the modUser object already has a createdon field (added somewhat recently), but not an editedon field. Since you're extending modUser, that could have caused your troubles. Using a different name for that field might have made it work as a date field.]]>
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>
Hi Bob, I finally got it working. Thanks it was something going wrong with that schema. So in the end I just set them both to be type="text" phptype="text" and now it works well. Any trying with date or other types and I can't get it working. Also if I add the precision="10" or such it won't work either, so I removed that and "text" seems to do the job so that will be fine!
Thanks again for your help
]]>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.]]>
>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.
Hi thanks also for your reply, but I'm not really sure what you mean. Bob's extension is supposed to extend the user data, that's the whole point of it I believe. So it should work fine??]]>
Ok thanks I changed my table to match your described one (screenshot attached) but now no data will save in it at all when I update a user.
The schema looks ok to me but I'm not really sure if you can take a look for me if you get chance:
<?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>Thanks again for any help]]>
I based the schema and object on the modUserProfile object (modx_user_attributes table) because it's doing the same thing.
For that table, 'id' is the primary key.
The 'id' and 'internalKey' fields are both indexes and both are set to be unique.
I see your table has no id field. I can't look back at your schema right now, but is it possible that your object extends xPDOObject instead of xPDOSimpleObject? The second gets an automatic, autoincrement id field. The first assumes that you will be creating that field yourself if you need it (which you do).
You need an id field that's unique, set to autoincrement, and is the primary key. Extending xPDOSimpleObject and leaving the id field out of the schema will give you all that automatically.
You also need an 'internalKey' field that is unique, not autoincrement, and is an index (but not the primary index).
]]>