#24833 closed enhancement (fixed)
Multisite site search for subdomain install with mapped domains
Reported by: | Surbma | Owned by: | jeremyfelt |
---|---|---|---|
Milestone: | 4.6 | Priority: | normal |
Severity: | normal | Version: | 3.5.2 |
Component: | Networks and Sites | Keywords: | has-patch has-unit-tests |
Focuses: | multisite | Cc: |
Description
Site search is not working in a Multisite with subdomain install, when a sub site's domain is changed and not using the main site's domain in its own domain. It means it is not a subdomain of the main site.
Mainly it affects sub sites with domain mapping.
In the file: /wp-admin/includes/class-wp-ms-sites-list-table.php there is the search query, which has the main site's domain hardcoded in the query ($current_site->domain). So it needs to be changed to search for all kind of domains.
I don't know much about this code, but I have found a fix and it is working, so I add it here.
This code needs to be put in the /wp-admin/includes/class-wp-ms-sites-list-table.php file after the 73rd line in WP 3.5.2:
$blog_s = '$wild' . $like_s . '$wild'; // fix
Attachments (1)
Change History (29)
#2
@
12 years ago
WordPress Multisite has the feature to change the domain of a subsite without any plugin, so it is indeed an issue with WordPress core.
The best way to use custom domains is with domain mapping, but it is not mandatory. So the WordPress core needs to be fixed to search for other domains, than the main site's subdomains.
It is not my code, I don't know much about database query, I just know, that I put this code to the file and now the domain search function is working fine.
So this fix needs a developer, who understands how it works and change the code accordingly.
#4
follow-up:
↓ 5
@
12 years ago
I looked into it and I'm mixed. I think simplifying $blog_s
would be cool but that would also mean searching on the network domain name will always show everything.
I think in this situation a filter maybe makes more sense then changing $blog_s
. So you change only that small part of the query.
#5
in reply to:
↑ 4
@
12 years ago
Replying to markoheijnen:
searching on the network domain name will always show everything
Not for me. ;) I use almost only custom domains in my network. So it makes sense for me to search for the network domain as it will show me all the blogs without any custom domains.
For others without any custom domains, what is the problem if it shows all subdomains, if somebody search for the network domain? Main site is always the first in the list, there is no need to search for it.
#6
@
12 years ago
So a filter will work for you ;) I just mentioning the possible negative impact of it. The key is that the search only shows real results and not because the main domain is in the domain name
#7
@
12 years ago
Ok, I believe you. Every solution is good for me, what works for everybody, in every case. :)
I just told you a situation, where searching for the network domain makes sense if it really shows all blogs with that domain.
So just to understand your solution, what if I search for the network domain in your case? What will it show? If it doesn't show all blogs, just the main site, how can I search for all blogs without custom domains?
#9
@
11 years ago
I have tried it with every new version of WordPress since 3.5.2, but the search function is still not working with sub sites, that has a changed domain.
Is there any chance to have a fix for this? Is it only me, who has a Multisite with a lot of sub sites having all their own domains?
I don't know database queries, but is it really a difficult thing to get a search for a domain name?
I would pay for this solution if somebody can fix it and push this fix into WordPress core.
#10
@
10 years ago
- Keywords needs-patch added
- Milestone changed from Awaiting Review to 4.3
The current search is built with this:
$blog_s = str_replace( '.' . $current_site->domain, '', $s ); $blog_s = $wpdb->esc_like( $blog_s ) . $wild . $wpdb->esc_like( '.' . $current_site->domain ); $query .= $wpdb->prepare( " AND ( {$wpdb->blogs}.domain LIKE %s ) ", $blog_s );
With the improvements we're working toward in #22383 and #31240, this should be updated to search all paths/domains in a subdomain configuration. See also #31148, which should become WP_Site_Query
.
#12
@
10 years ago
- Milestone changed from 4.3 to Future Release
No movement, let's circle back in another release.
#13
@
9 years ago
We have the same issue on dotorg: The network for the localized sites has the domain global.wordpress.org
and each "sub-site" has the domain $locale.wordpress.org
. Because of the lines mentioned in comment:10 WordPress searches for $locale.wordpress.org.global.wordpress.org
or $locale.global.wordpress.org
which of course doesn't exist.
I tried to make a test for this behavior similar to ticket:33185:33185.tests.patch but it seems like our test suite only supports sub-directory installs. :(
This ticket was mentioned in Slack in #core-multisite by ocean90. View the logs.
9 years ago
#16
@
9 years ago
Wow! I can't believe it. I opened this ticket almost 3 years ago. Can't wait for the 4.6 version.
Thank you for all developers, who contributed in this!
#17
@
9 years ago
See #36675 for where WP_MS_Sites_List_Table
is being adapted to use WP_Site_Query
.
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
9 years ago
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
9 years ago
#23
@
9 years ago
The fix for this will be part of the work on #36675 to adapt WP_MS_Sites_List_Tables
to WP_Site_Query
#24
@
9 years ago
- Keywords has-patch has-unit-tests added; needs-patch removed
- Owner changed from ocean90 to jeremyfelt
If the issue is only with mapped domains then it's not really an issue in WordPress because you need a plugin for that but you do have a point about having it hardcoded. Maybe a filter on the query would make sense.
I don't think your fix is a real fix but I can be wrong about the issue you are having. When you want the ability to search on mapped domains then you need to look into another table. So a like query will not fix that.