Symphony.

Is it possible to hide the template section so that it cannot be accessed directly in the browser?

Sounds like the same bug I’ve been having with sending emails, but my allow_url_fopen is on and safe mode is off. It’s a bit peculiar that it sends the rest but not the body!

I had the same issue! I ended up using the Symphony 1.7 mail code for several projects.

hey rowan, the tutorial you posted doesn’t seem to be there anymore

Pretty sure he moved it to his new site: http://rowanlewis.com/journal/getting-started-with-email-template-filters/

Is it possible to hide the template section so that it cannot be accessed directly in the browser?

Has anybody a solution for this problem?

I have setup a page that sends invoices (e. g. /send/invoice/123). It contains addresses, orders etc - things that should not be accessible to anybody but the recipient of the mail.

How do I prevent users to browse to /send/invoice/, guess an invoice number (e. g. 123) and see the email with all the details in their browser?

It seems like these lines in sendEmail() are fetching the content of the mail via a front-end call:

$email['generator'] = "{$generator}/{$params}/";
// Add values:
$email['message'] = (string)file_get_contents($email['generator']);

Is there a way to not use the front-end in this context and generate the output internally?

This way it would be possible to set up the data source for the mail page like this:

System-ID: {$etf-entry-id:0}
[checked] Redirect to 404 page when no results are found

It will then output the email content if called using $etf-entry-id but will send a 404 page if called via the front-end.

Any fix for body not being sent yet?

moonoo

@moonoo2 Do you have the maintenance mode extension running?

@nils Does the 404 technique work?

Right now I don’t believe it’s possible to create a second Symphony instance to generate a page - perhaps in the future however this won’t be a problem.

Yes, I got the 404 technique running. I changed the code in extension.driver.php:

// Generate xsl file name:
$page = $this->getPage($email['page']); 
if ($page->path) $xsl = $page->path . '_';
$xsl .= $page->handle . '.xsl';

// Generate output
require_once(TOOLKIT . '/class.xsltpage.php');
$proc = new XSLTPage;
$proc->setXML($data->saveXML());
$proc->setXSL(PAGES . '/' . $xsl, true);
$proc->setRuntimeParam(self::$params);
$result = $proc->generate();

// Add values:
$email['message'] = $result;
$email['condition_id'] = $email['id'];
$email['entry_id'] = $entry_id;

and added a filter for the data source like this (with 404 redirection enabled):

{$etf-entry-id:0}

It’s working just fine (even in maintenance mode). The only things yet to be solved are paths of imported stylesheets that are currently misinterpreted.

@Nils, thanks for figuring that out, will look at integrating it tomorrow.

Just went round and round and round and round in circles trying to solve this “bug”. An old Symphony bug whereby a Textarea will not correctly encode ampersands in free-text input. We had a contact form and some emails got through, others were logged but never sent. The problematic emails contained ampersands, causing the page that’s used as the email body to barf, splutter and fail.

The workaround is to add a Markdown formatter to the textfield which will encode the ampersands correctly. If you’re sending an HTML email, naturally.

Nils do I need to edit any other parts of symphony bar the 404 method above in order to get the body of my email sending correctly?

Besides of not using <xsl:import /> it should work with just these lines (remember that you have to edit the core to get this extension working at all, see the readme file).

Incidentally, the getting started tutorial link referenced in the opening post no longer seems to work:

There’s also a new getting started tutorial that’ll guide you through using this extension.

I started trying to learn this extension and got it set up via Rowan’s helpful tutorial. However, I’m getting this Fatal Error:

Fatal error: Call to private method FrontendPage::__processDatasources() from context 'Extension_EmailTemplateFilter' in C:xampphtdocsheirloomarthouse.compublicextensionsemailtemplatefilterextension.driver.php on line 328

Line 328 in the extension.driver.php file looks like this: self::$page->__processDatasources($template[‘datasources’], $data, array( ‘etf-entry-id’ => $entry_id ));

class.frontendpage.php on about line 450 has the private method:

private function __processDatasources($datasources, &$wrapper){...}

Is there a public/protected way that this process could be accessed?

You need to update that file as per the README.

Sheesh! You think Rowan could make the file in all-caps or something so that we’d see those things. :-) Maybe he could make that the first step in the README file or something. (Oh, he did…)

@makenosound Thanks Max for your iterative help!

I think this is a case of being at work for 16 hours straight. Gotta get some sleep. Sorry for the oversight, I’ll check the README file out in the morning (US CST).

Hah, I’m going to rewrite the readme ASAP, the only changes you need to make are:

1. Edit symphony/lib/toolkit/class.frontendpage.php
2. Replace private function __processDatasources... with public function __processDatasources($datasources, &$wrapper, $params = array()) {
3. Change the first $this->_env['pool'] = array(); into $this->_env['pool'] = $params;.
4. Change the first $pool = array(); into $pool = $params;.
5. Save. You’re done.

I will try my best to make sure these updates are in the next stable.

http://github.com/rowan-lewis/emailtemplatefilter/issues#issue/1

I suggested that these changes go into the core to prevent customising builds. I’m aware of a couple of other extensions that also require the same change.