Opened 15 years ago
Closed 15 years ago
#13104 closed defect (bug) (fixed)
Forced /index.php and stripping of www
Reported by: | bloggus | Owned by: | |
---|---|---|---|
Milestone: | 3.0 | Priority: | high |
Severity: | major | Version: | 3.0 |
Component: | Multisite | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
Hi,
I have been using WP and WPMU with IIS6 and compatibility with mod_rewrite for years. No problem.
Also have been testing out laterst beta1 and today I decided to make a clean install of nightly build of the code.
This are the issues I discovered, divided in three section:
(dd32: Issue 1 has been split to #13106)
- - Single Site
I also noticed immidiately, that the wite is stripped with "www", which is not that case with 2.9.2 . I don't see why this is done in asible site install at all? I think it is a bug in the single site install.
www.site1.com --> site1.com Work, but should not happen in single site mode.
--
- - Multi Site
After that I installed the network to see what is happening there. Immidiately I see that after setting up new htaccess rules and adding a few lines to config, as I should, and I know how to do, the www is not stripped but gives an 404-error in the browser.
site1.com works!
www.site1.com --> 404-error in the browser. Something is broken. I see in chrome that it redirects me to http://site1.com/wp-signup.php?new=www which gives this 404 error.
I go further creating a site (a new blog), testblog, and even here I see a error:
testblog.site1.com works
www.testblog.site1.com --> This should be stripp with www at least, but instead taking me to the signup-page with "www.testblog" as a new blog suggestion.
--
So I see something happened the last days, since an install was working just fine, just like current WPMU 2.9.2, but something has changed the whole setup suddenly.
Change History (13)
#2
@
15 years ago
- Priority changed from highest omg bbq to high
- Severity changed from critical to major
#3
@
15 years ago
- Cc bloggus added
nacin
Yes, but www.subdomain.domain.com and www.domain.com have always been redirected to subdomain.domain.com and domain.com , but now there are giving errors - that have never happended before.
www.domain.com ->> 404 error
www.subdomain.domain.com --> redirect to signup with new subdomain "www.subdomain"
This is not the usual behaviour of multi site.
#4
@
15 years ago
I'm going to split this ticket into 2, One related to the www's, and one for index.php/ permalinks. Its best to have a single issue per ticket to allow for both to be independently fixed.
#9
follow-up:
↓ 12
@
15 years ago
- Cc gazouteast added
Quote bloggus - "www.site1.com --> 404-error in the browser. Something is broken. I see in chrome that it redirects me to http://site1.com/wp-signup.php?new=www which gives this 404 error. "
WPMU did this in 2.8x as well and is still doing it in 2.9.2 in FireFox.
Quote Nacin - "WWW has never been allowed in multisite."
WRONG!!! Sub-directory installs has always had the ability to use it, whether in WP or WPMU - I always print business stationary with the www on it, and when linking back on external sites, I always include it, and it always gets the visitor to my sites. On subdomain WPMU installs, it does not work unless site admin has created a sub-blog (or subdomain) called "www" for redirecting back to the site home blog.
However, if it is a sub-directory install and not a sub-domain install, then the choice of having www.site.com or site.com should be at the site admin's preference and not forced onto them by WordPress.
If WordPress is going to force www removal then installation default MUST include the htaccess mod_rewrite to redirect it correctly.
The ability to set up a sub-blog with the name "www" should be a default banned name from installation in sub-domain installs (so that only site admin can blag the name). (It's a pet gripe of mine).
Gaz
#10
@
15 years ago
The other factor here is that it seems WordPress has forgotten the purpose of the host element of the FQDN ...
If I want a user to go to my FTP server I'll tell them to go to ftp.domain.com
If I want them to go to the mail server, I'll tell them to go to mail.domain.com
If I want them to go to the adverts server, I'll send them to ads.domain.com
If I want them to go direct to blog, I'll send them to blog.domain.com
... and if I want them to land at the website portal, I'll send them to WWW.domain.com
If I want them to see the site in spanish I'll send them to www.es.domain.com, or www.timbuktoo.domain.com if I want to get rid of them.
Why is WordPress trying so hard to remove this self-determining HIERARCHICAL and SEMANTIC form of domain management from their users?
#11
@
15 years ago
Seriously, it simply comes down to structural limitations of MU. (This is definitely not the only one.)
I am not aware of a change or regression in www subdomain handling between MU 2.9.x and WP 3.0 running multisite. You said so yourself, this is how it works in WPMU. If there is a change between MU and MS, we need to address that. Otherwise, we are not making any enhancements to multisite at this point for 3.0.
#12
in reply to:
↑ 9
@
15 years ago
Replying to gazouteast:
Quote bloggus - "www.site1.com --> 404-error in the browser. Something is broken. I see in chrome that it redirects me to http://site1.com/wp-signup.php?new=www which gives this 404 error. "
Bloggus was reporting a bug which was fixed in the three changesets 6 days prior to your comment.
Replying to gazouteast:
If WordPress is going to force www removal then installation default MUST include the htaccess mod_rewrite to redirect it correctly.
Please try the latest version before commenting on tickets (particularly where the ticket shows that patches have been applied that relate to that ticket).
Thanks,
Ron
WWW has never been allowed in multisite.
I agree we probably should adjust index.php handling, but note that MU never handled PATHINFO links properly it seems.