"Search sites" doesn't work

I have several MS installs with Pro Sites, all version 3.3.1 on an Nginx server.

On install #1, I am using a custom DB prefix and Hyper DB. On install #2, I am using the standard DB prefix and no Hyper DB. I have tested both with only 2 network activated plugins: Pro Sites and WordPress MU Domain Mapping.

On install #2, the "search sites" function (either on Sites or Pro Sites->Manage SItes) works fine. On install #1, neither works. (Since some threads here don't acknowledge this, since WP 3.1, search in network admin requires explicit use of wildcards, as in entering abc* to find a site that starts with abc; you can't just enter abc without the asterix.)

I can't find any differences between these 2 installs except that 1 uses a custom prefix and Hyper DB (and site search doesn't work), while another works fine. So, my questions are:

a) does Pro Sites impact site search?
b) would the custom prefix or Hyper DB break site search?
c) If I deactivate Pro Sites to test, and then reactivate, will my sites be impacted or will all of their Pro Sites settings (plugins, themes, etc) come back?
d) if not Pro Sites, any suggestions on how I can debug this?

Thanks in advance.

  • Arun Basil Lal
    • New Recruit

    Hey there,

    To start with, I like the way you have raised the question, well explained and then the points.

    since WP 3.1, search in network admin requires explicit use of wildcards, as in entering abc* to find a site that starts with abc; you can't just enter abc without the asterix.

    I hadn't noticed this before, but when I tried just now without the asterix, it didn't get through.

    a) does Pro Sites impact site search?

    It works for me and I doubt it. Had to use the asterix though like you said.

    b) would the custom prefix or Hyper DB break site search?

    Having a custom prefix shouldn't be a concern as long as you have the database prefix in your wp-config.php . That's where WordPress reads it from anyway as far as I know.

    c) If I deactivate Pro Sites to test, and then reactivate, will my sites be impacted or will all of their Pro Sites settings (plugins, themes, etc) come back?

    Interesting, I just tried this out. I tried deactivating and then reactivated. everything seem to be in place. It should be just fine.

    d) if not Pro Sites, any suggestions on how I can debug this?

    Let me pass this onto Aaron, he might have some ideas. I am pretty positive this isn't Pro Sites though, but lets see.

  • johnm63
    • WPMU DEV Initiate

    Thanks. Since I saw an update to Pro Sites that I had to install, I ended up having to deactivate the plugin before I saw this reply.

    So, I did deactivate and ran a test, and on this WP MS install, with a custom prefix (yes, it's in wp-config.php, because WP is otherwise working),

    With a custom prefix and Pro Sites deactivated, site search doesn't work. So that rules out Pro Sites. I'm going to set up a new WP install with just a custom prefix and see if it works. Meanwhile, maybe Aaron has something to suggest.

  • Aaron
    • CTO

    This isn't part of pro sites at all really. That form field is just a copy of the field on the network dashboard page, it posts the the same sites form. My guess is that the core form on the network dashboard page probably doesn't work for you too?

    No ideas why that would be though. I did'nt know you could use wildcards, very cool!

  • johnm63
    • WPMU DEV Initiate

    No, it is not just wildcards. If I search for the entire site name, it fails. Basically, every search on the site with a custom table prefix and Hyper DB fails. It fails when accessed on the Sites menu choice and the Pro Sites menu choice.

    Once I set up a clean install and test, if it's still happening I'll open a ticket and see what WP says.

    But I am pretty sure at this point that it is not a Pro Sites issue.

    Btw, when I was looking through the Pro Sites code to see if it impacted this, I noticed most (all?) of the files had closing PHP tags. Are those necessary?

  • johnm63
    • WPMU DEV Initiate

    After further research, I've identified the problem.

    On WP MS, if your primary domain (as set by DOMAIN_CURRENT_SITE in wp-config.php) contains 'www', then WP performs a SQL query that will always fail. If you search for xy* in site search, the SQL query will look for xy%.www.mydomain.com, when the domains are stored in the blogs table without the www, as xyzabc.mydomain.com.

    It seems to me that WP should either strongly advise against choosing www (and inform that it breaks site search) or strip the www if one's site includes it.

    The problem had nothing to do with custom prefixes or HyperDB.

  • BlueSea
    • WPMU DEV Initiate

    My WP Network set up does not have a "www" as the prefix to the domain (as set by DOMAIN_CURRENT_SITE in wp-config.php) i.e. it has:

    define( 'DOMAIN_CURRENT_SITE', 'mynetwork.com' );

    How ever when I "search sites" I get no results no matter what I try (full site name or various combinations using wild cards). Everything is upgraded to use the latest version as of the time of this post (including Wordpress 3.4.2) but this has been a long standing problem that I have never been able to resolve.

    Any other suggestions?

    Thank you.
    Andy

    P.S. Perhaps I should also point out that I am using the domain mapping plugin and the domains field are not set to be the sub domains (they are set to be a full custom domain e.g. http://www.myblogname.com and not myblogname.mynetwork.com). What specific field does "site search' actually search on? I am reting to search on "www.myblogname.com"

  • johnm63
    • WPMU DEV Initiate

    I don't think domain mapping has anything to do with site search.

    For a network of subdomains, site search is looking at the "subdomain" in subdomain.domain.com.

    Can you give an example of a subdomain that exists on your network and how you attempted to search for it using wildcards?

  • aecnu
    • WP Unicorn

    Greetings everyone,

    I am marking this ticket as resolved being that our lead developer indicated that this should be put on the WordPress bug tracking system due to it being troubleshooted by johnm63 to be a certain WordPress core issue.

    Thank you all for your patience and for being WPMU Dev Community Members!

    Cheers, Joe

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.