So, I’ve finally gotten my head around module development for the sake of integrating more complex, CI-based functionality. In one of my controllers, I want to send an email using a standard template. My template parsing code is this:
$this->EE->load->library('Template', NULL, 'TMPL');
$this->EE->TMPL->fetch_and_parse('experience', 'email');
$html_message = $this->EE->TMPL->parse_globals($this->EE->TMPL->final_template);
$html_message = $this->EE->TMPL->parse_variables_row($html_message, $data);However, I really don’t want that template to be publicly available at the URL of experience/email, which it is, so I change the template’s name to email (I have implemented $config[‘hidden_template_indicator’] = ‘’;) and tried switching line 3 above to:
$this->EE->TMPL->fetch_and_parse('experience', '_email');But the controller loads the site’s home page template when I do that. Is it not possible to use a hidden template with the TemplateParser?
But the controller loads the site’s home page template when I do that. Is it not possible to use a hidden template with the TemplateParser?$this->EE->TMPL->fetch_and_parse('experience', '_email');
The fetch_and_parse() function loads the fetch_template() function, which does the checks for hidden templates.
I think these lines are your killer:
$hidden_indicator = ($this->EE->config->item('hidden_template_indicator') === FALSE) ? '.' : $this->EE->config->item('hidden_template_indicator');
if ($this->depth == 0 AND substr($template, 0, 1) == $hidden_indicator)Basically, embedded templates have a depth > 0 and hence pass the hidden templates test. The initial depth (of course) is 0, and the depth is incremented in the process_sub_templates() function.
I can think of 2 ways to handle this.
Firstly, you could try to override $hidden_indicator by temporarily replacing the config variable ‘hidden_template_indicator’, setting it to “FALSE”. That would result in the check above failing and the template being processed.
Alternatively, you could try hacking the base code. If you were to hack to code, you could add a flag to fetch_and_parse() to set a false depth (although this might cause other problems, you’d have to check), or you could add a flag to fetch_and_parse() that gets passed to fetch_template() which overrides that check. That would of course render the module (essentially) undistributable and cause additional administrative headaches of remembering to “fix” the code base when you upgrade it.
Personally, I think overriding ‘hidden_template_indicator’ is the better option.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.