<p>The simple answer is: no, error handling templates don’t have access to the variables that would be available to the template when the request resolves normally. And we won’t be making it possible.</p>

<p>Technically you could get access to them by creating a plugin that has a <a href="http://buildwithcraft.com/classreference/services/TemplatesService#hook-detail" rel="nofollow">template hook</a> which is capable of adding those variables:</p>

<pre class="lang-php prettyprint-override"><code>craft()-&gt;templates-&gt;hook('mergeRouteVariables', function(&amp;$context)
{
    $routeParams = craft()-&gt;urlManager-&gt;getRouteParams();

    if (isset($routeParams['variables']))
    {
        $context = array_merge($context, $routeParams['variables']);
    }
}
</code></pre>

<p>404.html:</p>

<pre class="lang-twig prettyprint-override"><code>{% hook "mergeRouteVariables" %}
{# ... #}
</code></pre>

<blockquote>
  <p>It's probably worth noting that the reason I'm trying to do this is because I want to include a form on the 404 page (that I also include in other areas, so it's setup as a partial) and I'm having trouble passing error validation back and forth with setRouteVariables, but only for 404 pages. I know I could do this with a session and that is my current work around, but I wanted to see if there was a better way.</p>
</blockquote>

<p>While I understand your use case, it's pretty weird that you would have a form that intentionally submits to a 404 page (even though it’s the same page).</p>

<p>Here are a couple alternatives you might want to consider:</p>

<ul>
<li><p>You could create a dedicated page for the form, and have the form submit to that page’s URL in the event that it’s coming from a 404.</p></li>
<li><p>You could handle the form submission and validation with Javascript/Ajax.</p></li>
</ul>

CC BY-SA 3.0
2014-10-15T19:46:14.330Z
Sounds good, thanks for the info Brandon. I've actually gone exactly that route: Posting to a dedicated form instead which obviously makes more sense. I knew the use case was odd and not great, but then it opened up the question which is good to have a definitive answer for should something similar come up in the future.
Peter Tell
CC BY-SA 3.0
2014-10-15T19:44:31.863Z
2014-10-15T19:44:31.863Z
Brandon Kelly
<p>I have a plugin with nothing but the following in the init() method other than the basics (just for testing purposes):</p>

<pre><code>craft()-&gt;urlManager-&gt;setRouteVariables(array(
    'foo' =&gt; array('bar' =&gt; 'baz')
));
</code></pre>

<p>From all of my routes I can access this just fine. It's working for static templates, dynamic entries, etc. To access it I'm using the following code in my main base template <code>/_layouts/base.twig</code>:</p>

<pre><code>{{ foo.bar }}
</code></pre>

<p>The output is as expected: <code>baz</code></p>

<p>However, I cannot access this from a page that does not exist, i.e., a 404. If I go to <code>my-site.com/doesnt-exist</code> I receive the following:</p>

<pre><code>Twig_Error_Runtime

Variable "foo" does not exist in "_layouts/base" at line 1
</code></pre>

<p>My 404 template is extending base as well.</p>

<p>What am I doing wrong?</p>

<p>It's probably worth noting that the reason I'm trying to do this is because I want to include a form on the 404 page (that I also include in other areas, so it's setup as a partial) and I'm having trouble passing error validation back and forth with <code>setRouteVariables</code>, but only for 404 pages. I know I could do this with a session and that is my current work around, but I wanted to see if there was a better way.</p>

<plugin-development>
Do 404s get access to variables set with setRouteVariables?
# Do 404s get access to variables set with setRouteVariables?

(Asked by: username_0 on 2014-10-15)

I have a plugin with nothing but the following in the init() method other than the basics (just for testing purposes):
craft()->urlManager->setRouteVariables(array(
    'foo' => array('bar' => 'baz')
));

From all of my routes I can access this just fine. It's working for static templates, dynamic entries, etc. To access it I'm using the following code in my main base template /_layouts/base.twig:
{{ foo.bar }}

The output is as expected: baz
However, I cannot access this from a page that does not exist, i.e., a 404. If I go to my-site.com/doesnt-exist I receive the following:
Twig_Error_Runtime

Variable "foo" does not exist in "_layouts/base" at line 1

My 404 template is extending base as well.
What am I doing wrong?
It's probably worth noting that the reason I'm trying to do this is because I want to include a form on the 404 page (that I also include in other areas, so it's setup as a partial) and I'm having trouble passing error validation back and forth with setRouteVariables, but only for 404 pages. I know I could do this with a session and that is my current work around, but I wanted to see if there was a better way.

**Tags:** plugin-development

---

## 1 answers

### Answer by username_1 on 2014-10-15. Score: 2 | Accepted answer

The simple answer is: no, error handling templates don’t have access to the variables that would be available to the template when the request resolves normally. And we won’t be making it possible.
Technically you could get access to them by creating a plugin that has a template hook which is capable of adding those variables:
craft()->templates->hook('mergeRouteVariables', function(&$context)
{
    $routeParams = craft()->urlManager->getRouteParams();

    if (isset($routeParams['variables']))
    {
        $context = array_merge($context, $routeParams['variables']);
    }
}

404.html:
{% hook "mergeRouteVariables" %}
{# ... #}


It's probably worth noting that the reason I'm trying to do this is because I want to include a form on the 404 page (that I also include in other areas, so it's setup as a partial) and I'm having trouble passing error validation back and forth with setRouteVariables, but only for 404 pages. I know I could do this with a session and that is my current work around, but I wanted to see if there was a better way.

While I understand your use case, it's pretty weird that you would have a form that intentionally submits to a 404 page (even though it’s the same page).
Here are a couple alternatives you might want to consider:

You could create a dedicated page for the form, and have the form submit to that page’s URL in the event that it’s coming from a 404.
You could handle the form submission and validation with Javascript/Ajax.

> **Comments:**
> **username_0**: Sounds good, thanks for the info Brandon. I've actually gone exactly that route: Posting to a dedicated form instead which obviously makes more sense. I knew the use case was odd and not great, but then it opened up the question which is good to have a definitive answer for should something similar come up in the future.  

---

