WordPress MU

217 queries to SQL? Is this normal? I see people freaking if they get 25+! It may have to do with how I stumbled upon getting domain mapping working, as the default instructions were, um, less than absolute. AND, the only way I could get WPMU to start was to use the modified domain mapping plugin by johnnytee:

http://mu.wordpress.org/forums/topic.php?id=10882

Using Donncha's original gets me a "500 redirect limit exceeded" error when logging in, so looks to be rewrite related somehow.

WPMU 2.7.1

A records on external domains point to IP# of wpmu_example.org

CNAMEs of sub-domains on wpmu_example.org point to wpmu_example.org

.htaccess is standard from dist

Domains mapped within each individual blog's backend using the plugin and all works as expected... except the high query rate.

This WPDB Profiler report tells the story. The output has been truncated a bit at the top, where stuff looked to be pretty normal, only interspersed with these domain mapping lines.

I've tested this on a blog that has zero other plugins loaded, to see if there is an interaction, and it's pretty much the same--only smaller. So, is this normal or should I be looking somewhere for a misconfiguration?

Switch debugging on in your wp-config.php and try to access the site again. It looks like something is going a bit wrong there and the site isn't getting picked up correctly.

Could be a misconfiguration.

http://wpmututorials.com/plugins/donnchas-domain-mapping-plugin/ for details on the install & configure.

I seem to remember this previously but I can't find it right off.

You may want to try caching the site if you haven't yet. 217 does seem high.

edit: Yup, that looks high. One of my mapped sites shows 57 queries.

One bit of added info. Once the 500 error shows when trying Donncha's original version of Domain Mapping, the URL is displayed as:

http://example.com/wp-admin/url/wp-admin/

Whatever may be causing this extra string might also be causing the high SQL queries.

Checked out the above link and that's the way it's set up, with the addition of CNAMES for sub-domains.

Running debug, I get a lot of these on the minimal (no plugins) site:

Notice: Undefined index: HTTPS in /usr/www/users/speed/wpmu/wp-content/mu-plugins/domain_mapping.php on line 128

Notice: Undefined index: count in /usr/www/users/speed/wpmu/wp-includes/widgets.php on line 1082

Notice: Undefined index: hierarchical in /usr/www/users/speed/wpmu/wp-includes/widgets.php on line 1083

Notice: Undefined index: dropdown in /usr/www/users/speed/wpmu/wp-includes/widgets.php on line 1084
My Categories

and these in it's dashboard:

Notice: Undefined offset: 1 in /usr/www/users/speed/wpmu/wp-includes/theme.php on line 212

and these above the dashboard of the site in question:

Notice: Undefined index: comment in /usr/www/users/speed/wpmu/wp-content/mu-plugins/spam-filter.php on line 43

Notice: Undefined index: ec_name in /usr/www/users/speed/wpmu/wp-content/plugins/easy-contact/econtact.php on line 32

Notice: Undefined index: ec_email in /usr/www/users/speed/wpmu/wp-content/plugins/easy-contact/econtact.php on line 33

Notice: Undefined index: ec_url in /usr/www/users/speed/wpmu/wp-content/plugins/easy-contact/econtact.php on line 34

Notice: Undefined index: ec_subject in /usr/www/users/speed/wpmu/wp-content/plugins/easy-contact/econtact.php on line 35

Notice: Undefined index: ec_message in /usr/www/users/speed/wpmu/wp-content/plugins/easy-contact/econtact.php on line 36

Notice: Use of undefined constant GFCI_MEMBER_WIDGET - assumed 'GFCI_MEMBER_WIDGET' in /usr/www/users/speed/wpmu/wp-content/plugins/google-friend-connect-integration/gfcintegration.php on line 26

Notice: Use of undefined constant GFCI_LOGIN_WIDGET - assumed 'GFCI_LOGIN_WIDGET' in /usr/www/users/speed/wpmu/wp-content/plugins/google-friend-connect-integration/gfcintegration.php on line 27

Notice: Undefined property: WPGreetBox::$plugin_domain in /usr/www/users/speed/wpmu/wp-content/plugins/wp-greet-box/wp-greet-box.php on line 65

Notice: Undefined variable: class in /usr/www/users/speed/wpmu/wp-content/plugins/my-link-order/mylinkorder.php on line 259

Notice: Use of undefined constant wp_cumulus_widget - assumed 'wp_cumulus_widget' in /usr/www/users/speed/wpmu/wp-content/plugins/wp-cumulus/wp-cumulus.php on line 362

Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /usr/www/users/speed/wpmu/wp-content/mu-plugins/spam-filter.php:43) in /usr/www/users/speed/wpmu/wp-content/plugins/easy-contact/econtact.php on line 112

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /usr/www/users/speed/wpmu/wp-content/mu-plugins/spam-filter.php:43) in /usr/www/users/speed/wpmu/wp-content/plugins/easy-contact/econtact.php on line 112

Notice: Undefined variable: uid in /usr/www/users/speed/wpmu/wp-content/plugins/google-analyticator/google-analyticator.php on line 606

Notice: Undefined index: page in /usr/www/users/speed/wpmu/wp-content/plugins/post-teaser/post-teaser.php on line 104

Notice: Undefined index: page in /usr/www/users/speed/wpmu/wp-content/plugins/my-link-order/mylinkorder.php on line 20

If I'm unsuccessful in locating the problem, is there another way to map domains that doesn't require a plugin? A little extra work to get the queries down would be worth it. Switch to Multi-site Manager? Do it manually in the DB?

I don't think it's the plugin - I think you've got a whole pile of other issues going on here.

Yes, you need a plugin to properly map domains. Multi SITE is if you want multiple MU sites. Each extra domain has the ability to have blogs under it as well. Overkill if you're just trying to map domains.

Take out the domain mapping, fix all the errors (check your error logs too) And then try again.

Fix all the errorrs...
In all of these plugins--without knowing the background about how they were written. Heck, I've already tested this DM plugin on a blog that has no plugins; hence the section posted above:

Running debug, I get a lot of these on the minimal (no plugins) site:

Notice: Undefined index: HTTPS in /usr/www/users/speed/wpmu/wp-content/mu-plugins/domain_mapping.php on line 128

Notice: Undefined index: count in /usr/www/users/speed/wpmu/wp-includes/widgets.php on line 1082

Notice: Undefined index: hierarchical in /usr/www/users/speed/wpmu/wp-includes/widgets.php on line 1083

Notice: Undefined index: dropdown in /usr/www/users/speed/wpmu/wp-includes/widgets.php on line 1084

and these in it's dashboard:

Notice: Undefined offset: 1 in /usr/www/users/speed/wpmu/wp-includes/theme.php on line 212

...(many of them)...

All are core files. If these undefineds are normal, then what?

Ah, I see you're running debug and not just looking in error logs.

(I'm assuming there's a difference.)

Undefined's you needn't worry about really.
You'll get an undefined with:

if(isset($_GET['page'])) {}

So if you get an undefined notice when you are checking if something is set or not, there isn't much you can do :)

OK, well, that's kinda what I figured. Thanks for clarifying.

So the other question still remains: Does this look normal?

An interesing side note. I went into the DB and tried manually modifying the domain and IDs. The mapped domain worked but only when entering it into the URL box. All links on the generated page stayed as: blogtitle.example.com as opposed to: mappeddomain.com. What was interesting was, with the Domain Mapping plugin deactivated the queries went down from 217 to a nice comfy 28 but the time to serve the page nearly doubled! huh?

Do you have COOKIEDOMAIN defined in your wp-config.php?
If so, what happens if you comment that line out?

Wasn't set. Set it and cleared all cookies for primary, sub and mapped domains to see what happens. No appreciable difference. Same 200 calls to the DB. This was using Domain Mapping plugin. With the page serve time doubling when mapping manually, going through altering the DB again doesn't seem worth it.

Did find that commenting out line #149:
//add_action( 'admin_init', 'redirect_admin_page' );
allowed Donncha's version of the plugin to load WPMu without a 500 redirect loop error. What's up with that, anyway?

You might want to talk to Donncha, the dev of the plugin AND the dev of WPMU?

Donncha is good at checking support topics on his plugin, so maybe ask that way for more exposure:

http://wordpress.org/tags/wordpress-mu-domain-mapping

Will do.

Got a partial fix today. The 500 redirect loop is gone when running DM 0.4.1. While reading another thread on the 0.3 version and its difficulties with uploads, etc., and noting the earlier versions available on the Extend page, I decided to go get them and try 'em out. v0.30 worked. v0.40 looped. Sitting there staring blankly at the screen searching for possibilities, I observed that sunrise.php on the server was 1.14k, where all of the versions on the local box are identical at 911 bytes. Hmmm. This has the ring of truth... Must have been uploaded as binary. Sent the 0.4.1 version up, sent DM 0.4.1 up again and login loop is gone. D'Oh! The double-login when going to a blog backend is there now in its place. :/

DB queries remain at 197+, however, so it's not a total fix.

In reading many threads on how to do domain mapping, some months old, there are references to changing the entries in Edit Blog to the mapped domain. It is unclear as to whether this needs to be done with the plugin or not and whether all 4 should be changed or only the lower 3, with "Update 'siteurl' and 'home' as well" unchecked (someone said leaving it checked causes a redirect loop). Leaving the Domain entry as sub.domain.com and SiteURL, Home and Fileupload URL changed to mappeddomain.com doesn't seem to matter. Changing the Domain entry up at the top, however, causes the backend to become inaccessible, redirecting to http://wp-admin.com/, so that's not right.

THEN, going into the DB and looking at the domain_mapping table, there is 'id' and 'blog_id'. Should they match? Should 'id' match 'site_id'? In a sub-domain install, the 'site_id' should be "1" else the blog doesn't show up in the list of blogs in the site admin panel. At least that's what I *think* I've seen. There are so many perturbations of this that I don't know what is "up" anymore and I'm lucky that the darn thing is still running at all.

There REALLY needs to be an up-to-date definitive guide to doing this.

Other than the instructions with the plugin and the link I posted waaaaay above, those *are* the definitive guides.

I'm convinced there's something wacky with your setup. The blog I mentioned above? wpmututorials? It's a mapped domain on a WPMU install.

"The blog I mentioned above? wpmututorials? It's a mapped domain on a WPMU install."

Not to be obstinate or anything of the sort, because you help a lot of people here, but what is this supposed to tell me? I have mapped domains running. It isn't as if I haven't been able to get this going and, therefore, don't believe you that it is possible.

In the interest of finding out what may or may not be "wacky with my set up", what is the answer to:

THEN, going into the DB and looking at the domain_mapping table, there is 'id' and 'blog_id'. Should they match? Should 'id' match 'site_id'? or Can 'id' be anything--it doesn't matter?

And

Do you change the three (or four) fields (domain, siteURL, home, fileuploadURL) in the blog edit screen or they don't matter if you are running the plugin & only need to be changed if mapping manually.

Answers to these could make all of the difference. Not getting any, I'm right where I started.

As far as the instructions being complete, there could be a clearer way to state:

"If your domain name includes a hostname like "blog" or some other prefix before the actual domain name you will need to add a CNAME for that hostname in your DNS pointing at this blog URL."

The definition of "this blog URL" is ambiguous. Which blog URL? The unmapped sub-domain one? The new mapped one? The one that WPMu is running on? and Where does the CNAME go? On the domain that WPMu is on? On the domain that is pointing to the WPMu IP#? Well, that won't work because you can't have a CNAME and an A for the same domain entry at the same time, so it must go on the domain that WPMu is running on. See what I mean? I went round and round on this for a while before actually doing anything until figuring out what was really meant. At the time, I didn't know that MPMu did rewriting internally. Figured out that this must be how it works, though, because there HAD to be SOME table somewhere with domain equations; because they aren't in .htaccess.

And

The "definitive" guide doesn't take into account not being able to park domains on top of the WPMu domain because that external domain is already in use on another IP#. You can, however, point a sub-domain of it to the WPMu IP# with an A Record then set a CNAME for that sub-domain on the WPMu domain.

And

What may be "wacky with my set up" is that, due to advice from many places, here included, I switched from MSM to DM. I think I backed out of MSM properly but don't know for sure. This is why I am asking the question on the table contents in wp_domain_mapping and/or looking for other cruft that may be left over from MSM. I'd much rather do a surgical alteration than nuke it from orbit, just to be sure.

Thanks for understanding.

Just going down the long list here:

"THEN, going into the DB and looking at the domain_mapping table, there is 'id' and 'blog_id'. Should they match?"

No. ID is the ID number of the db table index. it's only used intenrally to look things up. blog_id is the actual blog id.

" Should 'id' match 'site_id'? or Can 'id' be anything--it doesn't matter?"

Again, no. It's just an index for db use.

"Do you change the three (or four) fields (domain, siteURL, home, fileuploadURL) in the blog edit screen or they don't matter if you are running the plugin & only need to be changed if mapping manually."

It depends. The FIRST field with the home URL of the blog should really be the mapped domain, and the plugin should be changing it. the rest of them for internal use some of us have found need to be changed to get the functionality we want. If all of them are changed to the new mapped domain, it shoudl definitely work.

The fact you're getting 500 errors when you do so says to me it's more a server configuration issue than anything.

This part:

"Changing the Domain entry up at the top, however, causes the backend to become inaccessible, redirecting to http://wp-admin.com/, so that's not right."

I have never seen happen. It's not an issue with the plugin, I don't think. (maybe it is, I rolled my own version)

And in this post, http://mu.wordpress.org/forums/topic.php?id=12351#post-74207 you answered your own question.

btw. I have installed the latest plugin version and my homepage is counting 82 db calls from it, even though there is not a single blog using it at the moment. is that normal? on a category page it shows 182 db calls what exactly does this figure depend on and what to expect if users start using it?

@andrea
"And in this post, http://mu.wordpress.org/forums/topic.php?id=12351#post-74207 you answered your own question."

Huh? It loops bsck to this thread that we're in. At bit of explanation as to where you think I've answered my own question (which one--there are a few) would be helpful.

spherical:
"Do you change the three (or four) fields (domain, siteURL, home, fileuploadURL) in the blog edit screen or they don't matter if you are running the plugin & only need to be changed if mapping manually."

andrea:
It depends. The FIRST field with the home URL of the blog should really be the mapped domain, and the plugin should be changing it. the rest of them for internal use some of us have found need to be changed to get the functionality we want."

You see? Ambiguity. "FIRST field with the 'home URL'...". Here's where people get confused. The FIRST field isn't 'home'.

FIRST is 'Domain'
SECOND is 'Siteurl'
THIRD is 'Home'
FOURTH is 'Fileupload Url'

Which one do you really mean?

spherical:
"Changing the Domain entry up at the top, however, causes the backend to become inaccessible, redirecting to http://wp-admin.com/, so that's not right."

andrea:
"I have never seen happen. It's not an issue with the plugin, I don't think. (maybe it is, I rolled my own version)"

Oh.

andrea:
"It depends. The FIRST field with the home URL of the blog should really be the mapped domain, and the plugin should be changing it."

DM plugin has never changed that (or any of those 4 fields) at all, ever. Seems as if all of the ducks have to be in a row, with their left webbed foot off the ground, while facing NorthEast, to get this to play nice.

andrea:
"And in this post, http://mu.wordpress.org/forums/topic.php?id=12351#post-74207 you answered your own question."

Huh? This loops back into this very thread, only a few posts up. What question, out of all of these (I get that there are apparently too many for people to assimilate in one go--but this IS a complex topic) did I answer?

As they say: "Here's the thing."

What causes so much confusion, and is the crux of my saying that there needs to be a definitive guide to domain mapping--As It Stands Right Now--is that, when one begins to tackle this, one searches through the forums for answers and finds all manner of solutions; some of which no longer apply at all. Sorting out the good from the obsolete is the Big Problem. Those who know aren't telling or don't realize that they aren't. They are too close to the code and it's difficult for them to step back and see what it looks like from another perspective.

We've got miles of php code amassed over years, a lot of it superseded by better methods and plugins. Yet, the history available in the forums, and on external sites, can lead people in the wrong direction. A new direction that now exists and is *way* easier gets muddled up by the simple fact that the person searching didn't find a complete, unambiguous set of instructions at the outset. So, they went searching for answers. Most of them are outdated or don't really apply at all anymore but *look* like they might. Does this ring a bell?

*sigh*

I answer posts from memory, not always with an admin menu open in a new tab.

"FIRST is 'Domain'
SECOND is 'Siteurl'
THIRD is 'Home'
FOURTH is 'Fileupload Url'

Which one do you really mean?"

The FIRST one. Whatever it's called. It's first.

------- next topic -----

me: ""If your domain name includes a hostname like "blog" or some other prefix before the actual domain name you will need to add a CNAME for that hostname in your DNS pointing at this blog URL."

you : The definition of "this blog URL" is ambiguous. Which blog URL? The unmapped sub-domain one? The new mapped one? The one that WPMu is running on? and Where does the CNAME go? On the domain that WPMu is on? On the domain that is pointing to the WPMu IP#? "

the answer:
"You can, however, point a sub-domain of it to the WPMu IP# with an A Record then set a CNAME for that sub-domain on the WPMu domain. "

-----

"Those who know aren't telling or don't realize that they aren't. They are too close to the code and it's difficult for them to step back and see what it looks like from another perspective."

It;s a relatively straightforward process. Some people, when having issues over what really should be a simple thing, take a step back and try again later, after a rest, with a clear mind.

you: *sigh*

me: :\

you: "the answer:
"You can, however, point a sub-domain of it to the WPMu IP# with an A Record then set a CNAME for that sub-domain on the WPMu domain. "

me: I'm saying that what you just pointed out (apparently you were referring to where I answered my own question) should have been said in the instructions in the first place. It was an illustration of the point at hand. Oh, nevermind... Seems that I can't state things clearly enough for you to get what I'm saying either.

you: "It;s a relatively straightforward process. Some people, when having issues over what really should be a simple thing, take a step back and try again later, after a rest, with a clear mind. "

me: Yes, they should be simple. Heh, that's what I did. That's what I always do; especially when things should be straightforward ...and aren't. "Hmmm, maybe this is what is meant... I'll try it, after careful re-consideration, making a DB backup or two, crossing my fingers while hoping I don't blow the whole thing up because I applied yet another meaning to the instructions that no one ever considered."

Sorry for the noise. I'll go take a step back, crawl under a rock and figure out why the plugin isn't changing that first field on my own. Thanks for your help. I learned some of what I need.

Spherical, I did the following:

Commented line 130 of domain mapping.php

// $domain = $wpdb->get_var( "SELECT domain FROM {$wpdb->dmtable} WHERE blog_id = '{$wpdb->blogid}'" );

Magically everything works. Number of queries decreased to reasonable 28. Can someone explain me what I did? :)

You commented out line 130 of domainmapping.php :)

I would figure it was there for a reason, so keep an eye out for something else now not working.

quick eustion relating what spherical said:

A records on external domains point to IP# of wpmu_example.org
CNAMEs of sub-domains on wpmu_example.org point to wpmu_example.org

I thought the CNAME solution was if the redirected domain was using subdomains only?

Yep, but it's a good alternative (well, the only one...) if you can;t point the domain to the IP address.

And http://www.second.domain counts as a "sub" domain.