Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#1 2009-01-05 20:21:04
- els
- Moderator
- From: The Netherlands
- Registered: 2004-06-06
- Posts: 7,458
[wiki] Textbook home page URL/duplicate content?
Destry, could you have a look at this post? Don’t know if it matters that there are two different URLs (http://textpattern.net/ and http://textbook.textpattern.net/) for the main page, but you might want to let the devs know which one to link to from the Txp install.
Offline
Re: [wiki] Textbook home page URL/duplicate content?
Yeah, there’s a number of links floating around the web that reflect the two different URLs; or three if you want to add textpattern.net/wiki.
These two:
- textpattern.net
- textpattern.net/wiki
are what might be thought of as the default, with the first one having a redirect to the wiki directory where the install is actually located. The wiki is the only thing on the .net domain, so it’s set-up to point to the wiki directory.
I think (not positive) Patrick sometime in 2006 or 2007 created the alias textbook.textpattern.net (again, with or without the “/wiki”) to provide a more suggestive URL — “textbook” — but in retrospect I think it just added to the mud.
What we should want to do, and this has come up several times before with little feedback, is get back to thinking about the integrated design, specifically the navigation, and setup URLs that support that consistently across all the family domains (.com, .net, .org). So for example this kind of thing (where “docs” is TxB):
- Home (textpattern.com)
- Features (features.textpattern.com)
- Docs (docs.textpattern.com) — or if necessary (docs.textpattern.net)
- Forum (forum.textpattern.com)
- Weblog (blog.textpattern.com)
- Plugins (plugins.textpattern.com) — or if necessary (plugins.textpattern.org)
- etc.
It’s unlikely anything but the wiki will ever be on .net, but whether it’s .com, .net or .org … I don’t think it’s a big deal. It’s more important to have the first part consistent (docs.txp, forum.txp, blog.txt, etc). I think it would be prudent to move the wiki install out of the “wiki” directory and into the root of the .net domain so there’s no fudging with the “/wiki” paths at all (assuming it always stays on .net).
There should also be a clean URL ability for the wiki too (as can be witnessed at WP Codex). For example a link like this: http://textpattern.net/wiki/index.php?title=Textpattern_Release_History
Should really look like this: http://docs.textpattern.net/Textpattern_Release_History
Those are the only changes I want to mess with at this point.
I suppose we could start going with this change now, but what I’ve been hoping to see is some adoption by .com and .org of the same consistency. First clarifying what should be the official URLs for sake of marketing/branding/longevity, and then putting those into effect (with necessary redirects), in parallel fashion, across all domains and in the integrated navigation. The .com redesign is supposedly still on course so now would be the right time to make a vocal decision about that from their camp.
Offline
Re: [wiki] Textbook home page URL/duplicate content?
Yeah everyone wanted textbook.textpattern.net at one point. The wiki subfolder was something that was there since day one, and the root always redirected you to it. It almost had clean urls without the /wiki working at one point but some of the non-english page names caused some problems. If we are starting new pages it wouldn’t be a bad time to try that again.
Now back into the shadows…
Shoving is the answer – pusher robot
Offline
Re: [wiki] Textbook home page URL/duplicate content?
hakjoon wrote:
It almost had clean urls without the /wiki working at one point but some of the non-english page names caused some problems.
Good point. Some testing would be needed and if it didn’t work, then no clean URLs. (Codex is not international, that I can tell.)
Offline
Re: [wiki] Textbook home page URL/duplicate content?
I think as long as the pages are created with the clean URLS it worked fine. From what I remember the problem was that mod_rewrite would encode some characters that the original querystring title didn’t so the page names ended up being different, so there was no way to setup clean redirects from teh old pages to teh new pages.
If we are doing new pages it would be the ideal time to put it in place.
Shoving is the answer – pusher robot
Offline