<p>You must be running Apache on staging, but not on dev, and the <code>p</code> param is getting added by the mod_rewrite rule in <code>.htaccess</code>.</p>
<p><code>p</code> is the default <a href="https://craftcms.com/docs/4.x/config/general.html#pathparam" rel="nofollow noreferrer">pathParam</a> config setting value. When present, it will be used to define the requested URI path.</p>

CC BY-SA 4.0
2023-01-23T16:18:39.270Z
Thanks. Staging is Apache and I am running Nitro on dev (haven't got with the DDEV program yet.) So is it the case that when `entry` remains unset there is kind of a soft 404 that persists?
Jonathan Schofield
CC BY-SA 4.0
2023-01-23T17:00:30.770Z
You lost me there. `entry` will only be set if the template was loaded via a section’s Entry URI Format setting. If the template is assuming `entry` is set then you might get a 500 error, but not a 404.
Brandon Kelly
CC BY-SA 4.0
2023-01-23T17:06:14.903Z
No worries. I should probably provide more template context to make it clear what _seems_ to be happening in my environment, but it’s not high priority. So thanks for your time today on this and my other thread.
Jonathan Schofield
CC BY-SA 4.0
2023-01-23T12:45:54.670Z
2023-01-23T12:45:54.670Z
Brandon Kelly
<h2>The context</h2>
<p>I have a URL schema that is either doing something new, via a custom Route (no entry set):</p>
<pre><code>bookings/new/*
</code></pre>
<p>…or reviewing an existing entry:</p>
<pre><code>bookings/{slug}
</code></pre>
<p>My custom route is working fine in that it's routing to the correct template logic when  no entry is set.</p>
<p>I have some development in progress which will get converted to working with the PHP session – and therefore a properly integrated action URL – but for now I'm just invoking a template-derived action URL on a hard-coded <code>&lt;form&gt;</code> tag to test front-end behaviours.</p>
<h2>The problem</h2>
<p>The template renders fine and the front end behaves fine <em>in all respects in my <strong>local</strong> dev environment</em>, but…</p>
<p><em>In the <strong>staging</strong> environment only</em>, something like the following is getting auto-added after my opening form tag (not by any code I have written):</p>
<pre><code>&lt;input type=&quot;hidden&quot; name=&quot;p&quot; value=&quot;bookings/new/accommodation&quot;&gt;
</code></pre>
<p>…and the form will not submit to the next stage of the booking path that's invoked by the action URL.</p>
<p>I infer this is because it is determined to be a 404, even though the path matches the custom route and the expected template is being invoked.</p>
<p>As far as I can see the local and staging environments are near identical:</p>
<ul>
<li>Both are running 4.3.6, albeit with:
<ul>
<li>Minor differences in host PHP</li>
<li>My local dev is Nitro and therefore using <code>mariadb</code></li>
</ul>
</li>
<li>Both have the same plugins and modules</li>
</ul>
<p>Any clues as to what is going on?</p>
<hr />
<ul>
<li>My bookings channel section has a URI format of <code>bookings/{slug}</code> and calls <code>bookings/_entry</code></li>
<li>My custom route is <code>bookings/new/*</code> and calls <code>bookings/_entry</code></li>
</ul>
<hr />
<h2>Update</h2>
<p>This feels like a work-around, not really a fix:</p>
<ul>
<li>It seems that when a custom route is registering as a 404 (still don't know why that's the case here), there is a <code>p</code> parameter in <code>craft.app.request.queryParams</code> even when it is not explicitly in the URL.</li>
<li>And it was getting rendered because I had…</li>
</ul>
<pre><code>{% set qParams = craft.app.request.queryParams ?? null %}

…

&lt;form …&gt;
    {# Pass params along in the URL but 
       exclude ones that have fields submitted in this page
    #}
    {% set excludes = ['array', 'of', 'names'] %}

    {% for key, val in qParams %}
        {% if key not in excludes %}
            &lt;input type=&quot;hidden&quot; name=&quot;{{ key }}&quot; value=&quot;{{ val }}&quot;&gt;
        {% endif %}
    {% endfor %}
</code></pre>
<p>…so I have tweaked that with:</p>
<pre><code>{% for key, val in qParams %}
    {% if key not in excludes and key != 'p' %}
        &lt;input type=&quot;hidden&quot; name=&quot;{{ key }}&quot; value=&quot;{{ val }}&quot;&gt;
    {% endif %}
{% endfor %}

</code></pre>
<p>…which works.</p>
<h2>Revised framing of the question</h2>
<p>I would still like to know why there is a 404 registering in the first place.</p>
<p>Is it perhaps that when <code>entry</code> is not defined that <em>equates to a 404</em> even if a custom route picks it up?</p>

<form><routes><404>
Why is my custom route registering as a 404?
# Why is my custom route registering as a 404?

(Asked by: username_0 on 2023-01-13)

The context
I have a URL schema that is either doing something new, via a custom Route (no entry set):
bookings/new/*

…or reviewing an existing entry:
bookings/{slug}

My custom route is working fine in that it's routing to the correct template logic when  no entry is set.
I have some development in progress which will get converted to working with the PHP session – and therefore a properly integrated action URL – but for now I'm just invoking a template-derived action URL on a hard-coded  tag to test front-end behaviours.
The problem
The template renders fine and the front end behaves fine in all respects in my local dev environment, but…
In the staging environment only, something like the following is getting auto-added after my opening form tag (not by any code I have written):


…and the form will not submit to the next stage of the booking path that's invoked by the action URL.
I infer this is because it is determined to be a 404, even though the path matches the custom route and the expected template is being invoked.
As far as I can see the local and staging environments are near identical:

Both are running 4.3.6, albeit with:

Minor differences in host PHP
My local dev is Nitro and therefore using mariadb


Both have the same plugins and modules

Any clues as to what is going on?


My bookings channel section has a URI format of bookings/{slug} and calls bookings/_entry
My custom route is bookings/new/* and calls bookings/_entry


Update
This feels like a work-around, not really a fix:

It seems that when a custom route is registering as a 404 (still don't know why that's the case here), there is a p parameter in craft.app.request.queryParams even when it is not explicitly in the URL.
And it was getting rendered because I had…

{% set qParams = craft.app.request.queryParams ?? null %}

…


    {# Pass params along in the URL but 
       exclude ones that have fields submitted in this page
    #}
    {% set excludes = ['array', 'of', 'names'] %}

    {% for key, val in qParams %}
        {% if key not in excludes %}
            
        {% endif %}
    {% endfor %}

…so I have tweaked that with:
{% for key, val in qParams %}
    {% if key not in excludes and key != 'p' %}
        
    {% endif %}
{% endfor %}


…which works.
Revised framing of the question
I would still like to know why there is a 404 registering in the first place.
Is it perhaps that when entry is not defined that equates to a 404 even if a custom route picks it up?

**Tags:** form, routes, 404


---

## 1 answers

### Answer by username_1 on 2023-01-23. Score: 1

You must be running Apache on staging, but not on dev, and the `p` param is getting added by the mod\_rewrite rule in `.htaccess`.

`p` is the default [pathParam](https://craftcms.com/docs/4.x/config/general.html#pathparam) config setting value. When present, it will be used to define the requested URI path.

> **Comments:**
> **username_0**: Thanks. Staging is Apache and I am running Nitro on dev (haven't got with the DDEV program yet.) So is it the case that when `entry` remains unset there is kind of a soft 404 that persists?  
> **username_1**: You lost me there. `entry` will only be set if the template was loaded via a section’s Entry URI Format setting. If the template is assuming `entry` is set then you might get a 500 error, but not a 404.  
> **username_0**: No worries. I should probably provide more template context to make it clear what _seems_ to be happening in my environment, but it’s not high priority. So thanks for your time today on this and my other thread.  

---

