Make WordPress Core

Opened 16 years ago

Last modified 5 years ago

#6778 reopened enhancement

Detect when the config will cause infinite loop

Reported by: analogpoint's profile Analogpoint Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 2.5
Component: Permalinks Keywords: needs-patch dev-feedback
Focuses: Cc:

Description (last modified by westi)

Behavior:

If you put in http://www.domain.com in the "Wordpress Address" setting, then Wordpress will automatically do a redirect from http://domain.com to http://www.domain.com. Many hosting packages allow the user to deal with www and non-www versions of their domain. This will cause an infinite redirect loop if, for example, the "Wordpress Address" is set to http://www.domain.com and the hosting setting is set remove the www from the domain address-- to redirect http://www.domain.com to http://domain.com.

Expected behavior:

When setting the "Wordpress Address" setting, it should detect if the canocical code will cause an infinite redirect loop and warn/correct the mistake

Attachments (4)

6778.diff (2.0 KB) - added by caesarsgrunt 16 years ago.
6778.2.diff (2.1 KB) - added by caesarsgrunt 16 years ago.
6778.3.diff (2.1 KB) - added by caesarsgrunt 16 years ago.
test.php (5.0 KB) - added by dd32 15 years ago.
relies upon patch from #10624

Download all attachments as: .zip

Change History (31)

#1 @Viper007Bond
16 years ago

  • Component changed from General to Administration

Yeah, wouldn't hurt to put a note there saying that the www/no-www preference will be enforced.

#2 @JohnLamansky
16 years ago

  • Keywords 2nd-opinion added
  • Milestone changed from 2.7 to 2.5.2
  • Priority changed from normal to low
  • Summary changed from Redirect from domain.com to www.domain.com causes redirect loop to Add notice about www preference enforcement

#3 @thee17
16 years ago

  • Milestone changed from 2.5.2 to 2.7

#4 @caesarsgrunt
16 years ago

Well actually, it's not just www/no-www, but it could do with a better explanation.

WordPress address (URL) is actually the absolute url to the directory in which the WordPress files live.

The value entered in the Blog address (URL) filed is the canonical url for the blog. Any other url pointing to WordPress install file, with any domain or subdomain, will be redirected to the value entered here.

@caesarsgrunt
16 years ago

#5 @caesarsgrunt
16 years ago

  • Keywords has-patch added

Here's a first try - someone else have a look and see if it's correct and clear enough!

#6 @Viper007Bond
16 years ago

-1 to "unusual". Don't want to scare users off from that wonder, wonder feature (I do it on every single blog I install).

@caesarsgrunt
16 years ago

#8 @Viper007Bond
16 years ago

Yes, but more nitpicking:

  • I think "incorrectly" should be used instead of "wrongly" (is that even a word? not sure)
  • I think it should be "Other URLs pointing to your blog" to be clear what "it" is.

@caesarsgrunt
16 years ago

#9 follow-up: @caesarsgrunt
16 years ago

How's that then?

  • I've changed it to incorrectly - yes, wrongly is a word. It's in the Oxford American Dictionary on my Mac. I'm British, and I prefer wrongly to incorrectly, but I'm comfortable with either...
  • Yes, you're right of course. I've changed it to 'your blog'.

#10 @caesarsgrunt
16 years ago

Of course actually, entering the wrong value in either filed will prevent access to the blog. But the description under the second one is already a bit long...

Another thought - what does anyone else think of the idea of moving the URL fields to the permalink page? (And possibly renaming the page...) I think that's a far more sensible place.

#11 in reply to: ↑ 9 ; follow-up: @Viper007Bond
16 years ago

Replying to caesarsgrunt:

I'm British, and I prefer wrongly to incorrectly

Ah, I wasn't aware you Brits used "wrongly". Sounds very wrong to me being an American, no pun intended, heh.

#12 in reply to: ↑ 11 @caesarsgrunt
16 years ago

Ah, but it's in the American dictionary! Mind you, so are wronger and wrongness, neither of which I'd dream of using... :)

Anyhow, I think incorrectly is fine.

#13 @matt
15 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

I think this is not needed.

#14 @jacobsantos
15 years ago

  • Keywords has-patch 2nd-opinion removed
  • Milestone 2.7 deleted

#15 @caesarsgrunt
15 years ago

  • Keywords has-patch added
  • Milestone set to 2.7
  • Resolution wontfix deleted
  • Status changed from closed to reopened

@matt :
I think it is needed! :) Please reconsider...
So do other people, evidently, or the ticket wouldn't have been opened in the first place.

Anyhow; "Enter the address here if you want your blog homepage to be different from the directory you installed WordPress" is just plain bad English. The directory you installed WordPress? WTF???

#16 follow-up: @DD32
15 years ago

Alternate thought:

Use the HTTP API to request the new URL, and check to see if it gets redirected back to the current URL? (That'd require setting an extra param to tell the canonical redirection code from kicking in again possibly?)

But that's extra protection a different ticket might be better suited for, The actual "fault" in this ticket is really not an issue, People need to learn to enter the correct URL :) - But something does need to happen to stop the site from becoming completely unaccessable.

#17 in reply to: ↑ 16 @caesarsgrunt
15 years ago

Replying to DD32:

Use the HTTP API to request the new URL, and check to see if it gets redirected back to the current URL? (That'd require setting an extra param to tell the canonical redirection code from kicking in again possibly?)

Yes, I like that idea. But as you say, it's a different ticket - the description needs clarifying as well.

Also, I can't see that getting into 2.7, whereas there's no reason why the string change shouldn't.

#18 @matt
15 years ago

  • Milestone changed from 2.7 to 2.9

Removing from the 2.7 milestone, please do not add back. DD32's idea is cool.

#19 @westi
15 years ago

  • Description modified (diff)
  • Keywords needs-patch added; has-patch removed
  • Priority changed from low to normal
  • Summary changed from Add notice about www preference enforcement to Detect when the config will cause infinite loop

#20 @caesarsgrunt
15 years ago

What, so the string change isn't going to get into 2.7? Even though there's a patch? Why not, may I ask?

#21 @Denis-de-Bernardy
15 years ago

  • Component changed from Administration to Permalinks

on a related note, there is a much gorier issue when the host enforces nothing and the cookie path ends up being incorrect. this can happen on sites with inconsistent www prefs between the home and siteurl options.

#22 @Denis-de-Bernardy
15 years ago

  • Keywords dup added

#23 @Denis-de-Bernardy
15 years ago

  • Keywords dup removed
  • Milestone changed from 2.9 to Future Release

@dd32
15 years ago

relies upon patch from #10624

#24 @dd32
15 years ago

  • Keywords 2nd-opinion added

Use the HTTP API to request the new URL, and check to see if it gets redirected back to the current URL? (That'd require setting an extra param to tell the canonical redirection code from kicking in again possibly?)

attachment test.php added

  • relies upon patch from #10624
  • Sample implementation of the above idea, Probably contains a few extra cases that dont need to be included
    • Just the ok/redirect/error items maybe.
  • The spinner on an unsupported attempt could confuse people to think that WordPress just auto-saved the field.
    • unsupported = no HTTP transports available which can support redirection and report back issues.

#25 @chriscct7
9 years ago

  • Keywords dev-feedback added; 2nd-opinion removed

While the number of people who've run into this issue since it was first reported 6 years ago is small (I only found about 20 to 30 people on Google) comparative to WordPress's userbase, there are people with the issue.

#26 @chriscct7
9 years ago

This patch might solve #29708 actually.

#27 @chriscct7
8 years ago

#29708 has been fixed in 4.0

Note: See TracTickets for help on using tickets.