Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-01-23T16:18:39.270Z
Answers.Text: 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?
Answers.UserDisplayName: Jonathan Schofield
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-01-23T17:00:30.770Z
Answers.Text: 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.
Answers.UserDisplayName: Brandon Kelly
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-01-23T17:06:14.903Z
Answers.Text: 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.
Answers.UserDisplayName: Jonathan Schofield
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-01-23T12:45:54.670Z
Answers.LastActivityDate: 2023-01-23T12:45:54.670Z
Answers.UserDisplayName: Brandon Kelly
Body: <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>
  
Tags: <form><routes><404>
Title: Why is my custom route registering as a 404?
ThreadText: # 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 `<form>` 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):
  
  ```
  <input type="hidden" name="p" value="bookings/new/accommodation">
  
  ```
  
  …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 %}
  
  …
  
  <form …>
      {# 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 %}
              <input type="hidden" name="{{ key }}" value="{{ val }}">
          {% endif %}
      {% endfor %}
  
  ```
  
  …so I have tweaked that with:
  
  ```
  {% for key, val in qParams %}
      {% if key not in excludes and key != 'p' %}
          <input type="hidden" name="{{ key }}" value="{{ val }}">
      {% 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.  
  
  ---
  
  