Symphony.

I'm building a pretty simple Symphony site but am running into difficulties managing the URLs. There are a few instances in which valid pages are being served when I don't want them to.

1. My 'index' page has a URL handle of 'home' which means that the homepage can be reached from http://example.com and http://example.com/home. I'd rather not have the homepage available at two different URLs like that. Can I set up Symphony to 404 in the second case?

2. My site features episodic data, with each episode reachable at /episode/N (where N is the episode number). I'm using the Number Field extension to store the episode numbers but am finding data source filtering on the field problematic. For example, not only does /episode/2 return a result but so do /episode/002, /episode/+2, and /episode/2+2 (anything that can be evaluated as a number I guess). I've tried a few regex expressions but haven't come up with anything that only permits an episode number. Has anyone else run into something similar and solved it?

3. The site allows episode drafts. Check the draft flag and the episode will not appear in the listings but it will be available at /drafts/N (where N is the episode number). I'd like to restrict this further to logged-in users and serve everyone else a 404 page. Is there a way to do this?

Thanks in advance. I have some other issues but I'll save those for another thread.

Generally, have a look at the URL Router-extension to design your URLs the way you like independent from the actual page structure.

I'd rather not have the homepage available at two different URLs like that. Can I set up Symphony to 404 in the second case?

Wouldn't bother with that. If you're worried about Google and duplicate content, just define a canonical URL in your frontend HTML.

If you really need to prevent people from accessing a page from a specific URL, you could overwrite that URL with URL Router and route it directly to your 404 page. But again, why even bother?

Same applies to your second question.

I'd like to restrict this further to logged-in users and serve everyone else a 404 page.

You can do this by setting the page type of your drafts page to admin. However, people currently not logged-in will be redirected to your 403 Forbidden instead of your 404 Not Found page, which is the more correct server response in that case.

Thanks. The admin page type takes care of the third issue.

I'll look into the URL Router extension. I definitely do not want URLs like /episode/00000002 or /episode/+++++++++1 to return content, regardless of SEO.

I also noticed that the designated 403/404 pages don't actually return 403/404 statuses - they return 301. Is there a way around that?

I definitely do not want URLs like /episode/00000002 or /episode/+++++++++1 to return content, regardless of SEO.

I currently can't think of a use case where this might cause problems in practice. Maybe you can give a good example where this might be harmful, so we can decide if it should be reported on the issue tracker.

I also noticed that the designated 403/404 pages don't actually return 403/404 statuses - they return 301. Is there a way around that?

They should return the correct status codes.

My guess is that you forgot the trailing slash at the end of the URL. Symphony redirects these to URLs with trailing slash in the .htaccess so it always has a canonical URL. URLs with and without trailing slash are considered two different URLs, so it would be bad for SEO and other stuff if it wouldn't do this.

I currently can't think of a use case where this might cause problems in practice. Maybe you can give a good example where this might be harmful

Not really. I just dislike the idea of garbage URLs returning content. It's an aesthetic objection rather than a technical one. And although the chances of a user stumbling across those URLs are low, I will know that they exist.

They should return the correct status codes. My guess is that you forgot the trailing slash at the end of the URL.

That is indeed what was happening! That's one less thing to worry about. Thanks.

And although the chances of a user stumbling across those URLs are low, I will know that they exist.

Actually, they don't exist. It's just a parameter.

I've tried a few regex expressions but haven't come up with anything that only permits an episode number.

I still think you shouldn't really care about this, but for piece of mind, the following filter should serve you well... ;)

regexp: {$episode}[0-9]*

regexp: {$episode}[0-9]*

This will still let plus signs through. Cutting out leading zeroes is the best I've been able to achieve.

I think the better solution would be to abandon the number field here and just use a plain text field. The number field is intended for all types of numerical data and is really just there to help with filtering/output/templating based on numerical operations along with some validation in the section entry pages.

What you seem to want in this case is a method of identifying a particular episode, so your episode numbers are more like names. Something like the unique or bog standard text field with validation applied would suit this just fine and would be easier to filter on. If you do need to perform any evaluations in XSL later on you can still use the data as numbers.

This will still let plus signs through.

Tested it, didn't do this for me.

Cutting out leading zeroes is the best I've been able to achieve.

Yeah, but to be honest, I don't fully understand why the regex is cutting out leading zeros. I mean, that's totally what we wanted to achieve, but from my understanding, it really shouldn't.

I think the better solution would be to abandon the number field here and just use a plain text field.

From what I remember, sorting by episode would be a problem with a text field if you don't want to add leading zeros.

Tested it, didn't do this for me.

Odd that it didn't work for me. It also returned spurious results for single digit numbers. For example, /episode/4 returned episodes 34, 24, 14 and 4.

The filter I'm currently using is:

regexp: ^{$episode-number}$

That takes care of the leading zeroes. There's still a little oddness with plus signs but I can live with that, especially as the other issues have been resolved.

From what I remember, sorting by episode would be a problem with a text field if you don't want to add leading zeros.

Good point.