Make WordPress Core

Opened 8 years ago

Last modified 16 months ago

#36507 reopened defect (bug)

Invalid URLs in network admin when WP Core is in custom subdirectory

Reported by: flixos90's profile flixos90 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Networks and Sites Keywords: has-patch 2nd-opinion
Focuses: multisite Cc:

Description

In my setup, I have WordPress Core in a custom subdirectory, so my home URL for a site is like http://example.com while my site URL is like http://example.com/core.

In the network admin area, this results in invalid links since the network_site_url() function does not check whether WordPress is installed in a custom subdirectory. The links have a path like /wp-admin/network/... although they should have a path like /core/wp-admin/network/....

Attachments (2)

36507.diff (651 bytes) - added by flixos90 8 years ago.
a possible solution to fix the links
ms.png (12.8 KB) - added by Latz 8 years ago.
Screenshot

Download all attachments as: .zip

Change History (13)

@flixos90
8 years ago

a possible solution to fix the links

#1 @flixos90
8 years ago

  • Keywords has-patch added

36507.diff has a possible solution to the problem. It checks whether the site URL is different from the home URL and then appends the difference to the base URL.

#2 follow-up: @Latz
8 years ago

Can't confirm this error. On my local server I have a multisite installation called "ms" and the network screen looks correct (see attached image).

@Latz
8 years ago

Screenshot

#3 @dd32
8 years ago

FWIW, WordPress with Multisite expects that URL Rewriting is enabled, which as a result makes the wp-admin folder exist at many different locations, such as example.com/site1/wp-admin/ and example.com/site3/wp-admin will both be loading the files from /path/to/wp-admin/ (Whether you're using subdirectory or subdomain shouldn't matter here, they both expect the URL Rewriting will paper over the cracks).

I suspect that's where the confusion is here. Further, I don't think multisite is even designed to operate with WordPress in a subdirectory at present, I think the configuration/network enabler will baulk at that and abort.

#4 in reply to: ↑ 2 ; follow-up: @flixos90
8 years ago

Replying to Latz:

Can't confirm this error. On my local server I have a multisite installation called "ms" and the network screen looks correct (see attached image).

I see on your screenshot that your whole sites are actually in a subdirectory. The problem I'm talking about is concerning setups where the home URL is different from the site URL. This is causing the above problems because the network_site_url() function does not consider these possible differences at all. It only works properly for sites where the site URL matches the home URL.

@dd32:

FWIW, WordPress with Multisite expects that URL Rewriting is enabled, which as a result makes the wp-admin folder exist at many different locations, such as example.com/site1/wp-admin/ and example.com/site3/wp-admin will both be loading the files from /path/to/wp-admin/ (Whether you're using subdirectory or subdomain shouldn't matter here, they both expect the URL Rewriting will paper over the cracks).

I didn't see any notices preventing me from setting up multisite under these circumstances. I would say that some areas in multisite not considering the possibility that WordPress is installed in a subdirectory different from where the actual index.php is located should be fixed since it works on non-multisite environments without any problems as well.

#5 in reply to: ↑ 4 ; follow-up: @DrewAPicture
8 years ago

Replying to flixos90:

@dd32:

FWIW, WordPress with Multisite expects that URL Rewriting is enabled, which as a result makes the wp-admin folder exist at many different locations, such as example.com/site1/wp-admin/ and example.com/site3/wp-admin will both be loading the files from /path/to/wp-admin/ (Whether you're using subdirectory or subdomain shouldn't matter here, they both expect the URL Rewriting will paper over the cracks).

I didn't see any notices preventing me from setting up multisite under these circumstances. I would say that some areas in multisite not considering the possibility that WordPress is installed in a subdirectory different from where the actual index.php is located should be fixed since it works on non-multisite environments without any problems as well.

To be fair, while WordPress is defensively coded in most places, we should never assume that because something doesn't throw errors that it's supported functionality by default. If it's working as designed, we should have corresponding documentation.

#6 in reply to: ↑ 5 @flixos90
8 years ago

Replying to DrewAPicture:

To be fair, while WordPress is defensively coded in most places, we should never assume that because something doesn't throw errors that it's supported functionality by default. If it's working as designed, we should have corresponding documentation.

That makes sense, thanks for clarifying. In this case though, I would like to propose actually adding support for this. WordPress supports this behavior on non-multisite setups (using home and siteurl options) and I think it would be straightforward to support that behavior on multisite as well - basically let's think about this as an enhancement (which would go beyond this ticket)! :)

I would gladly dig into this to find a solution. Maybe we can talk about this in the next multisite chat. #27287 is another ticket related to this issue. The main problem seems to be that in a multisite (especially in network context) only the domain and path of a site are honored while their individual settings home and siteurl are ignored. I would expect that domain and path of a site are similar to its home option - however it's siteurl option is not considered in these areas. That doesn't matter for a default setup, but it causes problems with a custom directory structure.

Another problem that results from this lack of parity is the scheme of the URL. While home and siteurl are full URLs with http or https in front of them, this setting is not available from domain and path of a site in a multisite. While WordPress detects this scheme on a regular site and redirects, it doesn't do that on a multisite (when some sites are HTTPS and others aren't).

I think we would need to determine these issues more precisely and where they appear before starting to think about eventual fixes. But I think it's worth to tackle this.

This ticket was mentioned in Slack in #core-multisite by flixos90. View the logs.


8 years ago

This ticket was mentioned in Slack in #core-multisite by flixos90. View the logs.


7 years ago

#9 @flixos90
7 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

There is clearly a lack of interest here, and those setups that use multisite with a custom subdirectory can easily fix it. Leaving a link here for a possible fix: https://github.com/felixarntz/multisite-fixes/blob/master/mu-plugins/wpms-site-url-fixer.php

Let's close for now.

#10 @flixos90
6 years ago

#42453 was marked as a duplicate.

#11 @iandunn
16 months ago

  • Keywords 2nd-opinion added
  • Milestone set to Awaiting Review
  • Resolution maybelater deleted
  • Status changed from closed to reopened

I ran into this again today. I have several Multisites configured with WP installed in a subdirectory (and also with a custom content dir). Other than this issue, I can't remember having any problems with that.

I think it's reasonable to expect that this works, and folks shouldn't have to setup workarounds. Installing WP into a subdirectory is a best practice IMO, and should be fully supported in Multisite.

Note: See TracTickets for help on using tickets.