Direct Mail

what is your setting? include media in Newsletter? please attach screenshot

I downgraded to direct_mail version 2.7.0 and it works again. The URL it can't read is hardcoded in the HTML of the template with:

<img src="/fileadmin/images/newsletter/header.jpg" width="630" height="170" alt="" border="0" />

[x] "Include images and other media in HTML content:" is activated yes. But I think that doesn't matter.

In direct_mail Configuration in "Set default values for mail content fetching options:" / "Domain of internal links:" I chose none. But then when I create a new newsletter I get the error "Domain of internal links:" [ INVALID VALUE ("7") ] although I didn't choose any URL and the site record with ID 7 exists. This error occurs with version 2.7.0 and 3.0.1 and 3.0.2 so it doesn't seem to be the cause of the problem.

after debug session with Philipp, it seems that allow_url_fopen must be turned on.

I stumbled upon the same error again - the last time was 11.10.09 and I filed this bug report then: http://bugs.typo3.org/view.php?id=12199

it would be very nice of direct_mail or the Typo3 Core if it would tell the user why files cannot be read. If you forget to activate allow_url_fopen for instance PHP returns:

Warning: fopen() [function.fopen]: URL file-access is disabled in the server configuration in XYZ on line 3

So this error could be presented to the user for example instead of just displaying: "Unable to open file for reading"

filed a new ticket for swiftmailer here: http://forge.typo3.org/issues/38915

Hi Ivan. Have a look at the Solr Report. We have there a test for the fopen stuff. maybe add a directmail report too.

TYPO3 does not rely on allow_url_fopen but it can handle things using cURL. There is a setting in the install tool for that ($TYPO3_CONF_VARS['SYS']['curlUse'] = '1';). Swiftmailer should respect that, too.

Markus Kappe wrote:

TYPO3 does not rely on allow_url_fopen but it can handle things using cURL. There is a setting in the install tool for that ($TYPO3_CONF_VARS['SYS']['curlUse'] = '1';). Swiftmailer should respect that, too.

I guess you have to report this to swiftmailer. since in swiftmailer only fopen is used.
If you are asking that swiftmailer has to support curl too (just like t3lib_div::getURL), then I guess we have to patch swiftmailer library only for TYPO3...

Hello, i have the same problem, allow_url_open is set in PHP.ini, but it doesn´t work. I tested these in 3 TYPO3-Versions, on all this error message is being displayed.

Any solution?
Best regard´s

Quadronet wrote:

Hello, i have the same problem, allow_url_open is set in PHP.ini, but it doesn´t work. I tested these in 3 TYPO3-Versions, on all this error message is being displayed.

Any solution?

are you sure? any error log?

I had the same problem with TYPO3 4.7.1
Enable curlUse in your install tool. Make sure allow_url_fopen is on your php config. And you should use direct mail 3.0.2. After an upgrade everything worked fine for me.

Same Problem: TYPO3 4.5.17, Direct Mail 3.0.2, allow_url_fopen is on, curlUse is 1
"Include images and other media in HTML content:" activated and does not make a difference.

Domain entries can be defined in the topmost page in the page tree and are listed in direct mail configuration under in direct_mail Configuration in "Set default values for mail content fetching options:" / "Domain of internal links:", but INVALID VALUE is shown in the configuration of the newsletter.

The backend uses ssl, the frontend doesn't. Without any configuration all links are generated with https and don't work. There seems to be no possibility to set the correct ssl option for the newsletter without this option working.

Same problem for me Typo3 4.5.20, direct_mail 3.0.2.
curlUse is 1, allow_url_fopen is set to on via ph.ini, which on this server I have to put in each directory that shall be affected. Don't think I missed one though.

I can send simple test mails and I can invoke the sending manually. But when calling via cron/shell it fails with the Unable to open file for reading error. (makes no difference if it is via scheduler typo3/cli_dispatch.phpsh scheduler where I have set the direct_mail task or old fashioned way typo3/cli_dispatch.phpsh direct_mail masssend)

Include images and other media in HTML content does make the following difference for me: If not clicked, the Newsletter is sent but images will not show up. Image src in the mail source code seem to start with typo3temp/GB/, no domain included (although set in configuration of direct mail).
If clicked, the newsletter is not sent and the Unable to open file for reading exeption is thrown.

Thanks for your work – please tell me if I can help by further testing!

Hello,

has someone solve the problem completely? So thats works all fine?

We use TYPO3 4.5.20 and DirectMail 3.02, only the plaintext will be sent.

curlUse is 1, allow_url_fopen is set to on via php.ini

Thanks for your help.

@Max Kirsch If you have just plain text, you should activate html mails in direct mails. Or do you habe any other errors?

@Christian Oettinger: enabling allow_url_fopen on directory basis (htaccess) will only affect Apache but not PHP in CLI mode.

Ivan Dharma Kartolo wrote:

@Christian Oettinger: enabling allow_url_fopen on directory basis (htaccess) will only affect Apache but not PHP in CLI mode.

Yes, I understand, but in my case it is not htaccess, but php.ini files per directory (1und1 managed server setting), so it should affect php?

After having the same problem on TYPO3 4.7.10 I now tried the attached t3x (T3X_direct_mail-3_0_2-z-201211111702.t3x). Solves the issue for me. So far everything good. Thanks a lot(!!) Ivan, and sorry that it took me so long to test...

Hi Christian,

actually the patch is released in the latest TER version (3.0.4).
do you experience any slowness using this version? see #46443

cheers,

ivan

Yes, I did experience the slowness (using not 3.0.4 but the attached t3x "T3X_direct_mail-3_0_2-z-201211111702.t3x").
Theres a Bug #46224 (Unlinking temporary files) describing the problem I experienced. I'll tried the Patch there and it solved the slowness-issue.
At the Moment everything looks fine...
Thanks for your quick work!