TYPO3 : no updated newsletter with direct_mail and scheduler - typo3

This is my 1st question on this forum... So, please, be indulgent !
I'm using TYPO3 4.7.11 (PHP 5.3.3) with extension direct_mail 3.1.1 for the intranet site of a non-profit firm.
My problem (maybe connected to Bug #51583 : http://forge.typo3.org/issues/51583) is that, after numerous tests and attempts, it seems impossible to have an updated version of a page saved as draft for newsletter in an automatic scheduler driven way : the same newsletter is produced with the same informations that were already there on the day it was first created and saved.
The specific page used for newsletter includes a content element 'Menu/Sitemap' with 'Recently updated pages' as 'Menu type'. It has been saved as 'draft (for recurring sendings)' in Direct Mail.
The scheduler contains these 2 tasks with recurring type :
- Direct Mail: Create Mail from Draft (direct_mail)
- Direct Mail: Mailing Queue (direct_mail)
Note : the manual way is fully functional and the newsletter produced is really updated. Same with option "Testmail - Simple" !
So, my problem seems to be linked to the automatic scheduled mailing ! It looks as if the newsletter draft has turned into a freezed snapshot of a specific moment and that Typo3 is unable to update/recalculate this page when invoked in scheduler mode.
On the web, I saw reported problems that could be related like "When mails get sent via the scheduler the same subject is used for all sendings ( https://review.typo3.org/21313 )" and "Adding hooks when sending direct mails via scheduler ( forge.typo3.org/issues/48994 )", but these issues seem to be fixed with direct_mail 3.1.1 version.
I made these observations and, in my opinion, there is some relevancy :
1.There is no domain proposed in the 'Domain of internal links' drop-down list in 'Set default values for mail content fetching options' in Direct Mailer, and yet I have a single record in sys_domain table with a domain name (with no protocol and no final slash). Is there a reason why this record is not considered good, or isn't it the right table ? (uid=3, pid, tstamp, crdate, cruser_id, hidden, sorting, prepend_params and forced=0, redirectHttpStatusCode=301, domain_name=site.subdomain.domain, redirectTo=)
2.In the Typo 3 Log, I get this systematic error message for user _cli_scheduler#LIVE :
Core: Error handler (BE): PHP Warning: Invalid argument supplied for
foreach() in
...typo3conf/ext/direct_mail/Classes/Scheduler/MailFromDraft.php line
125.
The concerned part of MailFromDraft.php is this function : initializeHookObjects
...
/*
* Initializes hook objects for this class
*
* #return void
*/
function initializeHookObjects() {
foreach ($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] as $hookObj) {
$hookObjectInstance = t3lib_div::getUserObj($hookObj);
if (is_object($hookObjectInstance) && ($hookObjectInstance instanceof x_directmail_Scheduler_MailFromDraftHook)) {
$this->hookObjects[] = $hookObjectInstance;
}
}
}
...
I'm not sure of understanding very clearly the origin and the use of the hook Object... (in spite of this interesting article by Robert Lemke : typo3.org/documentation/article/how-to-use-existing-hooks-in-your-own-extension/ )
3.Nothing like the apparently requested GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] seems to exist in TYPO3_CONF_VARS (Global configuration).
Can anybody give me an advice or a clue about what's going on and why I can't get a weekly updated newsletter with the scheduler ? I feel a bit confused !
Thanks in advance for any suggestion or solution (if a miracle is possible).
Greetings.
P-H SILLIAU

I've read about this issue before, but couldn't remember where.
Googling "direct_mail draft (for recurring sendings)" helped.
Try this bug: http://forge.typo3.org/issues/4421
User Markus says:
Things work fine, when you set a domain-record in your system and
select it in the direct_mail settings!
If you don't have a domain-record and specify it in the direct_mail
setup you're able to send normal newsletters, but if you try the
draft-functionality it won't work because the getUrlBase function in
class.tx_directmail_static.php returns an unsuable URL to the System
so it can't use the fetchHTML($file) and quits - therefore not
replacing the old draft contents created when starting the first time.
I don't really get why this works the first time you set up the draft
though....
So setting up the domain-record is a work-around that works.
I hope it does!
Probably, you will find more related topics.
Else, workarounds would be
re-considering the task. As it's a NPO intranet, maybe requirements are not that required suddenly, if asked again :-)
setting up a custom notification tool that only does that precise job.

To put an end to this problem, after many attempts (and informations gleaned from the internet), here is the solution we finally used in our specific case to make the newsletter work :
1st. We created a record in table sys_domain. This was a recurrent instruction in the manual and the forums, and it was IMHO legitimate.
Important : note that the redirectTo field had to remain empty, due to global malfunction of the site if filled (whatever we put in it like /, /var/www/sitename, ...)
2nd. All images, CSS, JS included in template had to be hardcoded (i.e. http ://site/fileamin/images/xxx.png for instance). If we didn't do that, the result would have been an abort in the production of the newletter : Not Found... Maybe, by digging a bit deeper, should we be able to find a parameter we forgot or neglected in some way to solve this issue...
3rd. In the newsletter template TS setup, we added these 2 parameters :
mod.web_modules.dmail.use_domain=[uid of sys-domain]
config.absRefPrefix = / (in order to get rid of PHP DOCUMENT_ROOT (or TYPO3_DOCUMENT_ROOT ?) otherwise wrongly present in all generated links.)
The result is now a well dynamically-generated newsletter, the date is OK, all links are correct and realUrl-compliant (no ../index.php?id=nnn) .... and you know what ?... We're happy ! :-)
Hope it will help !
Many thanks to everybody who answered (Markus, Urs...) or even thought of a possible solution...
P-H Silliau

Related

Tiki: Unexpected return from trackerlib -> get_item_creators

I upgraded my tiki from 15.4 to 16.2. Everything runs fine. The problem is the site registration does not work. I have a tracker to extend my user information. In the tracker, I created a field called "Network" that allows the users to choose a group that them want to be in. Hence, they won't see each other content due to different group permission. This registration broke. The error message showed:
Cannot add nonexistent user xxx to group students
I found out the problem was that there is a change in trackerlib.php line 3671. Instead of returning "null", it now returns an empty array().
else {
return array();
}
In GroupSelector.php, line 124, the condition check
if (empty ($creators))) $creators=array($user);
This if will never be executed since the function now return an array not null. Hence causing the problem that no one can be registered if they choose a group in the registration form.
Propose solution, change the if condition in line 124 to:
if (empty($creators[0]))
My fix has now been improved by our colleague kroky6 (thanks!) and is now in the 16.x branch, so you can test it by using the 16.x nightly tarball from here tomorrow and will be in 16.3 (and 17.0 onwards) coming soon...
Did you check the actual 16.x version (dev branch) of this file (lib/core/Tracker/Field/GroupSelector.php) ?
https://sourceforge.net/p/tikiwiki/code/HEAD/tree/branches/16.x/lib/core/Tracker/Field/GroupSelector.php
Chances are, this is fixed already. :)
Bernard

Automatically send email about editing google spreadsheet

I'm working on a rather simple script which should handle new values in the spreadsheet and then send emails to specified addresses. And I faced with the problem. My code is listed below:
function onEdit(e) {
//part of the code for checking e.range to process only updated values
sendEmail();
}
function sendEmail() {
// arguments are missed only for demo
GmailApp.sendEmail();
}
While I'm using "simple trigger", my function "sendEmail()" works only if I start it from script editor. I allowed sending emails on behalf of my at first time and then function works fine. But if I'm changing the value in the spreadsheet - function "onEdit(e)" processes new data but function "sendEmail()" does nothing.
I partly solved this problem by using project's triggers from "current project's triggers" menu. In that case, function "sendEmail()" works properly, but I have no access to the information about update.
For my purposes I could use just second way and find new values "manually" every time, but I wish to optimize this work.
So, my questions are:
Is the process I described above proper or I made a mistake
anywhere?
If process proper, is where a way to combine both cases?
Thanks!
You correctly understood that (as the docs say) simple triggers cannot send an email, because they run without authorization. An installable trigger, created via Resources menu, can: it has the same rights as the user who created the trigger. If it is set to fire on edit, it will get the same type of event object as a simple trigger does.
So, a minimal example would be like this, set to run "on edit":
function sendMail(e) {
MailApp.sendEmail('user#gmail.com', 'sheet edited', JSON.stringify(e));
}
It emails the whole event object in JSON format.
Aside: if your script only needs to send email but not read it, use MailApp instead of GmailApp to keep the scope of permissions more narrow.

Why would LayoutObjectNames return an empty string in FileMaker 14?

I'm seeing some very strange behavior with FileMaker 14. I'm using LayoutObjectNames for some required functionality. On the development system it's working fine. It returns the list of named objects on the layout.
I close the file, zip it up and send it to the client, and that required functionality isn't working. He sends the file back and I open it and get a data viewer up. The function returns nothing. I go into layout mode and confirm that there are named objects on the layout.
The first time this happened and I tried recovering the file. In the recovered file it worked, so I assumed some corruption had happened on his end. I told him to trash the file I had given him and work with a new version I supplied. The problem came up again.
This morning he sent me the oldest version that the problem manifested in. I confirmed the problem, tried recovering it again, but this time it didn't fix the problem.
I'm at a loss. It works in the version I send him, doesn't on his system. We're both using FileMaker 14, although I'm using Advanced. My next step will be to work from a served file instead of a local one, but I have never seen this type of behavior in FileMaker. Has anyone seen anything similar? Any ideas on a fix? I'm almost ready to just scrap the file and build it again from scratch since we're not too far into the project.
Thanks, Chuck
There is a known issue with the Get (FileName) function when the file name contains dots (other that the one before the extension). I will amend my answer later with more details and a possible solution (I have to look it up).
Here's a quote from 2008:
This is a known issue. It affects not only the ValueListItems()
function, but any function that requires the file name. The solution
is to include the file extension explicitly in the file name. This
works even if you use Get (FileName) to return the file name
dynamically:
ValueListItems ( Get ( FileName ) & ".fp7" ; "MyValueList" )
Of course, this is not required if you take care not to use period
when naming your files.
http://fmforums.com/forums/topic/60368-fm-bug-with-valuelistitems-function/?do=findComment&comment=285448
Apparently the issue is still with us - I wonder if the solution is still the same (I cannot test this at the moment).

Magento Automatically send tracking email

OK, been searching this everywhere, and can't come up with anything... we are externally populating tracking numbers in Magento Community 1.7.0.2 via a sync program from Dydacomp's Mail order Manager software... - it closes the order in Magento and adds a tracking number, but does not trigger the send tracking email function in mage. - I have researched, and seen that there are observers, etc. which appear maybe to be able to do this, but after 20 hours scouring every blog I can find, etc. cannot come up with anything that works!
This link seems to be REALLY in the right direction... but where to put this block of code? I've tried putting it in all kinds of places and none works:
Programmaticly send email when shipping tracking number is set
Any help would be tremendously appreciated.
I developed something similar. I created a module activated by cron (once a day) that checks the last orders that have 'delivered' (complete status).
To run a function in your cron magento module, add to your config.xml
<crontab>
<jobs>
<myModule_myFunction>
<schedule><cron_expr>*/60 * * * *</cron_expr></schedule>
<run><model>emailtracker/cron::myFunction</model></run>
</myModule_myFunction>
</jobs>
</crontab>
For the order to have supplies you can use the following code snippet
$orders = Mage::getModel('sales/order')->getCollection()
->addFieldToFilter('status', 'complete')
->addAttributeToFilter('created_at', array('gteq' => $dataForFilter));
Note that the collection of orders that I created, I make filter by date to avoid retrieving all orders already made​​.
With my collection of recent and complete orders that are possible candidates to receive a tracking email delivery, I can actually work with the orders that are important.
I created a foreach to run in my collection and within that loop, retrieve the tracking number.
foreach($orders as $order) {
$trackings = Mage::getResourceModel('sales/order_shipment_track_collection')
->setOrderFilter($order)
->getData();
for($i=0;$i<count($trackings);$i++) {
$trackingNumber = $trackings[$i]['track_number'];
//Make your php magic here
}
}
From this point, you can work this information the way you want. You can create a function that checks the status of tracking number via API and its delivery service sends an email, or you can imagine.
Important: Remember to check if your magento cron is active.
Note: I did it in Magento 1.6.1.0

Sugar CRM SOAP API - Problems with Auto Incrementing Key and set_entry

I've tried the SugarCRM forums for this problem as well, but I was wondering if anyone here has run into a similar issue and would be willing to share the solution.
We are working with the SOAP API for Sugar CRM via the Sugar On Demand system and their appears to be a problem - which at the moment looks very much like a bug.
The Module we trying to work with is the case module. We are running the set_entry action on the case module. It worked the first time we did this, but now it refuses to allow us to enter any more modules. I've checked the log files and made sure that we are submitting anything in the case_number field to over ride this, but whenever we try to add a new case we get the following error showing up in the log:
Query Failed: INSERT into cases set id='bb53030e-0f2f-5787-f403-4dde57cde36e', name='New RMA Request Test', date_entered='2011-05-26 13:37:15', date_modified='2011-05-26 13:37:15', modified_user_id='b1256ced-011d-7c1a-e1f3-4d4004ea4e9a', created_by='b1256ced-011d-7c1a-e1f3-4d4004ea4e9a', description='fjdlkas', deleted='0', assigned_user_id=null, team_id=null, team_set_id='ded0fbb0-c5dc-74ee-0622-4d22eb653a80', type=null, status=null, priority=null, resolution=null, system_id=1, work_log=null, account_id=null: MySQL error 1062: Duplicate entry '2147483647' for key 2
This is a bit odd for a few reasons:
I've confirmed that the corresponding key is auto-incrementing.
I am not submitting that number anywhere.
The next auto-increment value when I check the setting in the Studio is actually 2147483648.
Can someone explain what I need to do with the SOAP API to stop it from overriding the auto-increment value on my table?
Edit: I get the same error if I try to add a case via the interface, so I suspect this could be a problem with the CRM configuration itself rather than a SOAP related issue like I originally thought.
I would try to increase the size of the case_number field from an int(11) to something bigger and see if that fixes the issue.