Thread

Lastly, and probably most troubling, I can’t figure out how to make a page like this not render the index page:

http://expressionengine.com/blog/dont_link_to_this_url/

What about

{if segment_1 == "blog" AND segment_3 == ""}
  {redirect="404"}
{/if}

Lastly, and probably most troubling, I can’t figure out how to make a page like this not render the index page:

http://expressionengine.com/blog/dont_link_to_this_url/

What about

{if segment_1 == "blog" AND segment_3 == ""}
  {redirect="404"}
{/if}

In the current version, redirect= is not a valid global variable.

This worked for me but I removed it because it would look at pagination links as 404 pages:

{if segment_2 != ''}

{exp:query sql="SELECT template_id FROM exp_templates WHERE template_name = '{segment_2}' & group_id = '3' "}

{if no_results}
This template doesn't exist
{/if}

{/exp:query}{/if}

I believe the group_id was the template ID..

I definitely think it’s worth waiting for the new version (I really can’t wait) 😊

There are some PHP based solutions you could use if you search the forums, Zuul, but 1.6.5 is coming in days, not weeks, so it may be best to wait for that update.

Excellent, thanks, Derek.  Yes, I preferred not to have to drop into PHP to solve this.

I’d just like to check my understanding of the Strict URLs feature:

<a href="http://www.domain.com">http://www.domain.com</a>
<a href="http://www.domain.com/default_template_group">http://www.domain.com/default_template_group</a>
<a href="http://www.domain.com/default_template_group/default_template">http://www.domain.com/default_template_group/default_template</a>
all of above → /default_template_group/default_template

<a href="http://www.domain.com/article">http://www.domain.com/article</a> → 404
<a href="http://www.domain.com/default_template_group/article">http://www.domain.com/default_template_group/article</a> → 404
<a href="http://www.domain.com/default_template_group/default_template/article">http://www.domain.com/default_template_group/default_template/article</a> → /default_template_group/default_template/article

<a href="http://www.domain.com/template_group">http://www.domain.com/template_group</a> → /template_group/default_template
<a href="http://www.domain.com/template_group/article">http://www.domain.com/template_group/article</a> → 404
<a href="http://www.domain.com/template_group/template">http://www.domain.com/template_group/template</a> → /template_group/template
<a href="http://www.domain.com/template_group/template/article">http://www.domain.com/template_group/template/article</a> → /template_group/template/article

Also am I right in assuming this?

<a href="http://www.domain.com/default_template_group/2008/10/">http://www.domain.com/default_template_group/2008/10/</a> → 404?
<a href="http://www.domain.com/default_template_group/default_template/2008/10/">http://www.domain.com/default_template_group/default_template/2008/10/</a> → /default_template_group/default_template articles for 2008/10
<a href="http://www.domain.com/template_group/2008/10/">http://www.domain.com/template_group/2008/10/</a> → 404?
<a href="http://www.domain.com/template_group/template/2008/10/">http://www.domain.com/template_group/template/2008/10/</a> → /template_group/template articles for 2008/10

(which presumably also applies to other generated URLs such as category)

Did I make any mistakes?

You should always build your template groups based on your site’s desired URL structure; indeed it defines it.

I feel that conflating template naming and URL structure is problematic, due to the inherent inflexibility of requiring template_group/template (I don’t think the typical overloading of for example categories to represent structure in Movable Type is good either). I can’t see how I’d make eg domain.com/2008/10/article_name URLs, and adding two extra levels of hierarchy seems crufty to me. Basically I wish there was a way to combine the benefits of Pages with automatic date-based archives, or something like that.

Of course, if I’m misunderstanding this please let me know!

peace - oli

You’re right that EE doesn’t have a mechanism to natively mimic WordPress URL structure, which incidentally is not an omission, but if you’re wanting that flexibility in your URLs, you simply will be one that chooses to not enabled Strict URLs.  Nothing’s being forced on you, just recommended.

Thanks Derek, I’m glad it seems I didn’t make any mistakes in my understanding of what this does. Also I apologise if that comment came across as whining. It’s great to have the Strict URL feature—the more options the better! It’s just taken me a little while to get a decent understanding of what’s possible using EE (especially re: URLs). I think I’ve figured out how to do get the URL structure I want via path.php and the comments in this thread (especially {redirect=404}).

peace - oli

Correct, with Strict URLs you will not be able to use URL titles in either the first or second URL segments under any circumstances.

What about with the default “index” template? You’re saying that’s never included in the URL, so what about a situation where I have a template group called “news” where the “index” template checks the URL title and displays content accordingly.

The way it is now

<a href="http://www.example.com/news/url-title-for-news-bulletin">http://www.example.com/news/url-title-for-news-bulletin</a>

Are you saying that will not work? Should it be:

<a href="http://www.example.com/news/index/url-title-for-news-bulletin">http://www.example.com/news/index/url-title-for-news-bulletin</a>

or do I need to add an extra, useless, template like:

<a href="http://www.example.com/news/archives/url-title-for-news-bulletin">http://www.example.com/news/archives/url-title-for-news-bulletin</a>

Please see the user guide for the instructions and description of the finalized Strict URLs feature.

Lost Cause, you need to use {redirect="404"} in order for the 404 headers to be sent with your 404 page.

I was going to ask a question about the redire=“404” as well. Currently on my single entry pages I’ve got a weblog:entries tag and using the limit=“1” parameter to only show the single entry. I’m also using the {if no_results}{redirect="404"}{/if} in that weblog entries tag to take the visitor to the 404 page if the URL doesn’t exist.

With Strict URL’s turned on, will I still need the if no_results conditional in there to redirect to a 404 page or will EE do all of that for me?

Yes you will, that has not changed.  Look below the Strict URL feature description for details (404 Page).

Yes you will, that has not changed.  Look below the Strict URL feature description for details (404 Page).

Ah, thanks. Right there in front of me. 😉

So you can’t have the best of both worlds by having strict URL’s enabled, and having the “one-off” pages in your main template group look like:

site.com/about-us/
site.com/privacy/
site.com/submissions/

Those 1st segments would either need to be template groups with only an index page in them, or…Pages? Otherwise that would have to look like (assuming you keep them in the default template group of ‘site’:

site.com/site/about-us/
site.com/site/privacy/
site.com/site/submissions/

Is that correct? I’m assuming Pages is the way to go to make those one-time solo types of…pages…then?

Correct, if you want the first segment to point to templates of a single group instead of different template groups, you would want to disable Strict URLs.  Or just create your groups in the traditional way - if you have some text that you want in the first segment, you create a template group for it.  If you step back and think about it, you aren’t doing any more work, you’re just moving those segments from the right hand side of your template manager to the left hand side of the page.

Thanks for clarifying. I really want to use strict URL’s because they supposedly work better with Leevi’s LG .htaccess Generator - which is a really slick piece of extension work.

Just want to make sure I can still do my one-off type pages right after of the domain - and I can with template groups - and why the heck not? Jst not how I’ve done it in the past.

On another EE 1.6.5 note…thanks for including the CP jQuery Extension. Working great.