<p>You don't want to hardcode an ID (<code>530</code>) in a URI template. This is likely to break if you deploy the site to the production environment, because content and their IDs aren't shared between environments.</p>
<p>Instead, I would look for a way to uniquely identify the <code>Spezialgebiete</code> page. For example, by converting it to a single section, or by adding a relation field to relate the entries in your channel to it.</p>
<blockquote>
<p>The issue / problem is, if entry 'Tierärzte' gets a new slug.<br />
The link to a section item does not recognize the new slug of the parent page.</p>
</blockquote>
<p>Entry URIs are only updated when the entry is saved. So when you change the parent URI, you also need to resave all the other entries that use this entry for their URI in order to update their URIs. You could write a hook that triggers after an entry is saved to enforce that this always happens.</p>
<hr />
<p>From a broader viewpoint: I've mostly stopped making entry URIs depend on the slug of other entries. <a href="https://www.w3.org/Provider/Style/URI" rel="nofollow noreferrer">Cool URIs don't change</a>. I don't want editors to have the ability to invalidate a bunch of page URLs by changing a single slug. This will mess with SEO and saved bookmarks that people may have (this can be addressed by creating redirects, but it's still not ideal).</p>
<p>Instead, I try to define stable URLs. For example, for your areas of expertise (<code>Spezialgebiete</code>), I would just use <code>spezialgebiete/{slug}</code> or maybe <code>tieraerzte/spezialgebiete/{slug}</code> as the URI format, depending on how the site is structured and what other contents they contain.</p>

CC BY-SA 4.0
2024-06-11T12:57:02.167Z
Hmm ... yes, thank you Moritz!

Although it is certainly technically possible, it doesn’t make sense to do so. This simplifies my job; I will now only hide the slug field from editors on the corresponding pages.
Marc 
CC BY-SA 4.0
2024-06-07T15:21:11.877Z
2024-06-07T15:21:11.877Z
MoritzLost
<p>My solution works, but I seem to have some caching issues ... so I'm unsure weather my solution is useful or not?</p>
<p><strong>Entry URI Format</strong> of Section (Channel): <code>{{craft.entries.id(530).one().uri}}/{slug}</code></p>
<ul>
<li>Spezialgebiete =&gt; entries.id = 530</li>
<li>The correct URI shout be: https://[domain]/tieraerzte/spezialgebiete/[slug of section entry]</li>
</ul>
<p>The issue / problem is, if entry 'Tierärzte' gets a new slug.<br />
The link to a section item does not recognize the new slug of the parent page.</p>
<p>Should I look for another solution?</p>
<h2>Twig Template</h2>
<pre><code>{% set spezialgebiete = craft.entries().section('spezialgebiet') %}

&lt;ul&gt;
  {% for item in spezialgebiete %}
    &lt;li&gt;
        {% dump(item.url) %}
        {% include '_ui/objects/link/link' with {
          link: {
              url: item.url,
          },
          text: item.title,
        } only %}
    &lt;/li&gt;
  {% endfor %}
&lt;/ul&gt;
</code></pre>
<h2>Screenshot of Section</h2>
<p><a href="https://i.sstatic.net/7RoIlYeK.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/7RoIlYeK.png" alt="Screenshot" /></a></p>
<h2>Screenshot of Sitemap (sorry for German language)</h2>
<p><a href="https://i.sstatic.net/53Vez9dH.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/53Vez9dH.png" alt="Sitemap" /></a></p>

<craft4><sections><uri>
Section: dynamic Entry URI Format
# Section: dynamic Entry URI Format

(Asked by: username_0 on 2024-06-07)

My solution works, but I seem to have some caching issues ... so I'm unsure weather my solution is useful or not?
Entry URI Format of Section (Channel): {{craft.entries.id(530).one().uri}}/{slug}

Spezialgebiete => entries.id = 530
The correct URI shout be: https://[domain]/tieraerzte/spezialgebiete/[slug of section entry]

The issue / problem is, if entry 'Tierärzte' gets a new slug.
The link to a section item does not recognize the new slug of the parent page.
Should I look for another solution?
Twig Template
{% set spezialgebiete = craft.entries().section('spezialgebiet') %}


  {% for item in spezialgebiete %}
    
        {% dump(item.url) %}
        {% include '_ui/objects/link/link' with {
          link: {
              url: item.url,
          },
          text: item.title,
        } only %}
    
  {% endfor %}


Screenshot of Section

Screenshot of Sitemap (sorry for German language)

**Tags:** craft4, sections, uri


---

## 1 answers

### Answer by username_1 on 2024-06-07. Score: 2 | Accepted answer

You don't want to hardcode an ID (`530`) in a URI template. This is likely to break if you deploy the site to the production environment, because content and their IDs aren't shared between environments.

Instead, I would look for a way to uniquely identify the `Spezialgebiete` page. For example, by converting it to a single section, or by adding a relation field to relate the entries in your channel to it.

> The issue / problem is, if entry 'Tierärzte' gets a new slug.  
> The link to a section item does not recognize the new slug of the parent page.

Entry URIs are only updated when the entry is saved. So when you change the parent URI, you also need to resave all the other entries that use this entry for their URI in order to update their URIs. You could write a hook that triggers after an entry is saved to enforce that this always happens.

---

From a broader viewpoint: I've mostly stopped making entry URIs depend on the slug of other entries. [Cool URIs don't change](https://www.w3.org/Provider/Style/URI). I don't want editors to have the ability to invalidate a bunch of page URLs by changing a single slug. This will mess with SEO and saved bookmarks that people may have (this can be addressed by creating redirects, but it's still not ideal).

Instead, I try to define stable URLs. For example, for your areas of expertise (`Spezialgebiete`), I would just use `spezialgebiete/{slug}` or maybe `tieraerzte/spezialgebiete/{slug}` as the URI format, depending on how the site is structured and what other contents they contain.

> **Comments:**
> **username_0**: Hmm ... yes, thank you Moritz!  Although it is certainly technically possible, it doesn’t make sense to do so. This simplifies my job; I will now only hide the slug field from editors on the corresponding pages.  

---

