Opened 15 years ago
Closed 11 years ago
#12405 closed enhancement (wontfix)
Query String based Permalinks
Reported by: | mdawaffe | Owned by: | ryan |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.0 |
Component: | Permalinks | Keywords: | has-patch |
Focuses: | Cc: |
Description
Here's a 80% working patch to implement query string based permalinks (/?%year%/%monthnum%/%postname%/
) mentioned in #12404.
Try
- http://example.com/ (home URL)
- http://example.com/?nothing (query string with args that don't have anything to do with the permalink structure)
- http://example.com/?2010/02/hello-world/ (a post)
I'm not sure if this is the best implementation. It's also hacked together (fixing the $match
es on the fly instead of generating the real rewrite rules, for example). Call it a proof of concept.
Canonical redirects don't work correctly when using query string permalinks with this patch (?p=1 doesn't redirect).
Attachments (2)
Change History (12)
#1
@
13 years ago
- Cc mike@… added
It looks like this was posted before Google's "crawlable AJAX" proposal had gotten much traffic, http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html.
That presented the idea of a URL hash-bang, like Twitter uses now: twitter.com/#!/username. I think these are a better idea than using querystrings, since Google went live with hash-bangs but still suggests that querystring pages limit their parameters (here, http://www.google.com/support/webmasters/bin/answer.py?answer=35769&hl=en#1)
Basically, the original suggestion:
- /?%year%/%monthnum%/%postname%/
...might be better as:
- /#!/%year%/%monthnum%/%postname%/
(The preceding slash is my own preference. In the event the querystring is used, I think it should stay [like "/?/$year%..."] The added slash would make an explicitly matchable pattern [the "?/"] & make it easy for default querystring permalinks to be preserved.)
#2
follow-up:
↓ 3
@
13 years ago
Hashbangs are terrible. I'd probably go on strike if we introduced these, and I bet MarkJaquith would walk out with me. :-)
For more, see http://www.tbray.org/ongoing/When/201x/2011/02/09/Hash-Blecch and http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs.
Twitter would have launched using HTML5 History if it were not for a webkit bug. See http://www.adequatelygood.com/2011/2/Thoughts-on-the-Hashbang, https://bugs.webkit.org/show_bug.cgi?id=42940.
#3
in reply to:
↑ 2
@
13 years ago
- Cc mikeschinkel@… added
Replying to nacin:
Hashbangs are terrible. I'd probably go on strike if we introduced these, and I bet MarkJaquith would walk out with me. :-)
Totally agree! if either of this ideas went mainstream in WP I'd probably switch back to Drupal, and by now I hate Drupal.
Or just fork WP...
#4
follow-up:
↓ 5
@
13 years ago
Good points @nacin, I hadn't considered how fragile this might be. Also, one your links shows the hashbang is un-crawlable by anyone except Google, and that's really a bad idea (from: http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs):
"All non-browser user-agents (crawlers, aggregators, spiders, indexers) that completely support both HTTP/1.1 and the URL specification (RFC 2396, for example) cannot crawl any Lifehacker or Gawker content. Except Googlebot."
Mike, what do you mean by "either of these ideas"? Obviously the hashbangs, but do you dislike query string permalinks in-general or my minor suggestion on preceding slash?
#5
in reply to:
↑ 4
@
13 years ago
Replying to mbijon:
Mike, what do you mean by "either of these ideas"? Obviously the hashbangs, but do you dislike query string permalinks in-general or my minor suggestion on preceding slash?
All of it. I'd really hate to see any movement away from standard permalinks for many reasons.
Reasons:
- The inclusion of a question mark makes URLs more cryptic and makes less technical people discount them as being understandable.
- It makes them longer and more characters to type.
http://example.com/foo/
vs.http://example.com/?/foo/
- It gives people less reason to actually fix their permalinks.
- Worst of all, given that WordPress addresses 65 millions sites, it sets a precedent just like Twitter did. People who don't think through the ramifications think "Oh, that's now the cool way to build websites" and they mimic it. With great power comes great responsibility.
Much better IMO to put a big Akismet style notice that says:
"YOU REALLY NEED TO CHANGE YOUR PERMALINKS, OR GOOGLE WILL FORESAKE YOU.
HERE'S HOW!"
I also think if we put our heads together we could come up with a better way to enable hosts to make this work. But that's a much longer discussion that I doubt anyone wants to tackle this close to 3.3 release...
Anyway, in general I really dislike ideology or zealotry, but I'll admit to being an ideologue and a zealot when it comes to URLs...
#6
follow-up:
↓ 7
@
13 years ago
Mike, I understand your objection now. My understanding of this ticket is different.
I thought this was only to change non-redirect permalinks from "?id=123" into some form of "?friendly-worded-title". In the event a user doesn't have mod_rewrite/.htaccess (and *only* then) I think the form of links suggested here are better than "?id=123".
What are your thoughts of the suggestion in this ticket being enabled only for that sub-set of users?
Details & Related:
Query string containing permalinks are the defaults now. It's likely that everyone who can change them does so immediately after setting up WP (see the discussion of that here, #16416). Unless we can do perfect mod-rewrite detection things should stay that way -- which is where I thought this tasks "better defaults" came into play.
This should stay "Future Release". I had just added a semi-related bug and dragged-up a few non-3.3 tickets that I thought were related to mine, #18841
#7
in reply to:
↑ 6
@
13 years ago
Replying to mbijon:
Mike, I understand your objection now. My understanding of this ticket is different.
I thought this was only to change non-redirect permalinks from "?id=123" into some form of "?friendly-worded-title". In the event a user doesn't have mod_rewrite/.htaccess (and *only* then) I think the form of links suggested here are better than "?id=123".
Doing that will IMO cause many fewer people to go to the trouble to set URLs that don't require the '?'. I'd rather see us encourage people to fix them, encourage web hosts to make it easier, etc. than to give people a crutch that many would consider "good enough." Just my opinion, of course.
Query string containing permalinks are the defaults now. It's likely that everyone who can change them does so immediately after setting up WP (see the discussion of that here, #16416). Unless we can do perfect mod-rewrite detection things should stay that way
Exactly.
#8
@
13 years ago
What do devs out there think about allowing the query string "?" as a token in custom structure permalinks?
That would allow a fallback for users who don't have .htaccess, but won't change the existing defaults nor break anyone's current usage of custom.
#9
follow-up:
↓ 10
@
11 years ago
I'd like to chime in with a big fat -1 on this ticket too. If you enable this kind of url, it might become extra tricky to toss in extra $_GET
arguments into urls, and turn the whole thing into a wretched, bloody ocean of bugs.
Picture the scenario:
example.com/?foo # $_GET['foo'] = '' — easy enough example.com/?foo&foo=bar # $_GET['foo'] = 'bar' — how do we get the WP url now? example.com/?foo&bar # $_GET['foo'] = '', $_GET['bar'] = '' — which is the WP url?
Maybe, just *maybe*, the following would make more sense:
example.com/?u=foo # u for url
But in that case, we might as well use /index.php/foo
links, which already work…
In the end, terrible, terrible idea. I predict a never ending avalanche of bugs and support requests ahead if we actually implement this.
#10
in reply to:
↑ 9
@
11 years ago
- Milestone Future Release deleted
- Resolution set to wontfix
- Status changed from new to closed
Replying to Denis-de-Bernardy:
it might become extra tricky to toss in extra
$_GET
arguments into urls
We'd look at $_SERVER['QUERY_STRING']
, not $_GET
. I don't think there's a technical problem.
Looks to me like this idea is going nowhere, though. I also don't remember the initial impetus for opening this ticket.
Closing.
First patch was missing a file.