views:

59

answers:

2

I did some looking around at how other sites might handle this and didn't really see anything that jumped out at me. I'm working on a project where you can create pages that get linked to from every other page. Here is where the issue is coming up for me.

I'm not sure how I should go about linking to these pages. I've only really thought of two ideas, them being:

  1. website.com/page/My-Page-Name
  2. website.com/My-Page-Name

To note, I'm using mod_rewrite to redirect them to a file that takes the page name as a parameter and grabs all the relevant info from the DB and displays it. This is where an issue develops for idea #2.

Idea #1 works and is solid, but I think it's kind of ugly and you don't see a lot of websites that link to other pages of the site with other information padded in the URL.

EDIT for a bit of clarity. The intention of said pages are to be static in the sense they will only ever display what the user sets them to display. They will never except any sort of data in which case pages formatted like in this example would be more appropriate. I'd compare these page more so towards SO's faqs or about page which don't have URLs formatted in this manner.

Idea #2 looks cleaner but runs into some issues when using mod_rewrite and creating said pages.

There are other parts of the site that are linked to that could be mimicked and cause conflicts if you named the page the same. For example, website.com/page1/ points to page1 which already exists, but a conflict would arise if someone wanted to create a page called page1.

So implementing this idea I'd have to filter and limit the user in what page names they could use and at the same time this could make the feature a bit unintuitive and leave them scratching their head. As well as it seems a bit ugly coding it, having an array of unacceptable page names and having to check against it.

The last bit dealing with mod_rewrite to redirect to something like that: RewriteRule ^([A-Za-z0-9-]+)$ getPage.php?p=$1 gets a bit ugly as it gets a bit greedy even while limiting what it'll except.

So does anyone have any insight on any other possible methods to tackle this issue with or how the implementation of one of the two mentioned could be different / better?

Thanks.

A: 

I would go with #1, it's a fairly common convention and avoids potential problems. You said you haven't seen any sites do this, apparently you havent glanced upwards

  (look up)
      ^
      |
http://stackoverflow.com/questions/2121720/dynamic-pages-and-clean-url-conflicts
                         ^^^^^^^^^

other examples:

http://dsc.discovery.com/videos/mythbusters-raw-kari-goes-macgirlver.html
                         ^^^^^^

http://www.hulu.com/watch/115500/the-colbert-report-alicia-keys-and-stephen-perform
                    ^^^^^

Another alternative is to pad the built-in pages and have user generated content be in the url root. And example is the Tcler's wiki:

http://wiki.tcl.tk/_/recent        <-- special page padded with _
http://wiki.tcl.tk/coroutine       <-- user generated content
slebetman
I guess I should have described the intention of the pages better. They are simple static pages in the sense they won't take any data and will only ever display what the user sets them to display. So in that sense they are more akin to SO's faq or about pages which don't have URLs formatted in such a manner.
anomareh
The discovery.com example is a static page. I'd recommend not only padding it but also create a directory called "pages" where users can upload their content. It's much easier and less confusing to explain to users to use the "pages" directory rather than give them a list or regexp pattern of acceptable or unacceptable file names.
slebetman
+1  A: 

I have to agree that Idea #1 (website.com/page/My-Page-Name) is better. It avoids aliasing, and make the rest of the code cleaner (e.g. the rewrite rule simply looks at /page/.*). Among popular sites that use this technique are Wikipedia (http://en.wikipedia.org /wiki/ C), Everything2 (http://everything2.com /title/ Cool+Archive) and Answers.com (http://www.answers.com /topic/ exquisite).

EDIT: Idea #2 could work if you distinguish user pages from built-in pages by case. the path part of a URL is case sensitive, and a rewrite rule can easily check that. Example:

http://example.com/faq <- the website's built-in faq page.

http://example.com/Faq <- a user's page.

http://example.com/Frequently-asked-questions <- another user page.

I'd still go with #1 for simplicity and user-friendliness, but this avoid aliasing at least.

Max Shawabkeh
Refer to my edit and comment on slebetman's answer about URL formatting.
anomareh
I don't think that changes anything.
Max Shawabkeh
@Max Well in general URLs tend to be padded only when the rest of URL contains parameters used to determine what's going to be on the page. The wikipedia example is pretty moot because just about ever link is padded with __wiki__ to the point you could almost concider it part of the base URL. For your other examples the URLs are padded because the rest of the URL is needed to determine what's going to be on the page. There's no sense in padding a link to an faq or about page because for the most part those pages are static which is the intent of the pages users will be able to create.
anomareh
Ok, I thought "user" meant a visitor to the site, rather than its owner. From your edit it seems to be the latter. In that case, you could probably avoid conflicts by doing the opposite of Idea #2, prefixing built-in pages with a single prefix, which would make only one page name unavailable, or you could go ahead and stick built-in pages into a subdomain.
Max Shawabkeh
You're wrong in saying that there is no sense in padding. There is sense in padding - to avoid name collisions between user generated content and default site content. The padding is less confusing to the user than seemingly arbitrary rules about acceptable page names.
slebetman