sdoss

but wait. I can map the ca-wp.com/giant subsite to https://www.giant.com, change my host file to have https://www.giant.com point to the multisite install and pull up the home page. Problem is getting to other pages on the site. Why wouldn’t it work if I changed the links that currently read
www-ca-wp.com/giant/contact-us to https://www.giant.com/contact-us
???

<sigh> so that means, I can’t truly test domain mapping until I go live??

Ah. well.

(don’t you just love it when someone starts like that?)

We’re currently using our hosts file in lieu of pointing the A record, as, once we get the domains mapped, the whole thing is being picked up and moved to another server. The domains I need to map are wnr.com, giant.com, and myexpressrewards.com. wnr.com is a live domain currently pointing to a live site. myexpressrewards.com appears to have been registered through godaddy, but I’m unsure on that, as someone outside of my realm is responsible for that. And giant.com is registered, but currently pointing to wnr.com.

But, entering the domain name (www.giant.com) in our hosts file, and pointing to our server, allows us to access OUR development instead of the live sites.

I know. Convoluted. But it’s the world I live in :\

Andrea, thanks…

Otto’s tutorial works great, for the first page. That was a snap.

The pages all work beautifully when accessed by the maindomain/subsite.

We’re hosting our own. It’s a Linux debian, apache2, mysql and php server. I’ve tried both the current version and the trunk version of the plug-in. I’ve currently disabled the mapping (removed the mu-plugins directory and the sunrise.php, and commented the define statement for sunrise in wp-config) and put the multisite back to where it was.

The site’s url is https://www.ca-wp.com
Sub-sites are /wnr, /giant, /rewards

As for parking the domain – this is a registered domain that points to our server; on our server, there is a virtual host defined that points to the document root for apache.

ok. Went back to step 1. Removed the plugin, the sunrise.php, commented the define statement for ‘sunrise, on’ in wp-config. Went back to Otto’s tutorial https://ottopress.com/2010/wordpress-3-0-multisite-domain-mapping-tutorial and started all over. Pulled the ‘trunk’ version from Otto’s site. Created the mu-plugins directory under wp-content and placed the domain_mapping.php file in that directory. Placed sunrise.php in wp-content. Uncommented the define statement for sunrise in wp-config. Signed onto the main domain’s admin page, logged in as super admin, went to Domain Mapping under Super Admin. Placed my server’s ip address in the appropriate slot. Checked permanent redirect and user domain mapping checkboxes and hit save. Then, signed on to wp-admin under the subsite that I want to map. Went to Tools->Domain mapping, put the new domain name in, set it as primary, and updated. Then, in a new browser window, pulled up the site by the mapped name. The home page came up, with all images intact. Even the widgets were present.

Now, I’m in the sub-sites admin (using domainname.com/wp-admin), and in the widget to adjust url’s there. The widget is a text widget, with links to other pages on this site. Previously, the links read https://www.mainsite.com/sub-site/page-name. I’ve changed them to https://www.mappedsite.com/page-name. And get a 404 not found.

I tried editing my sub-site to change the domain name to the new mapped name, and the widget disappeared. So, the domain name on the edit page of my sub-site is still mainsite.com with a path of /sub-site/. Tried changing the site url to mappedsite.com, still getting 404 not found on my subsequent pages.

I’ve tried updating on the permalinks page (per a post in this forum; my apologies, but I’ve read so many of them I can’t remember which one it was).

So now, I’m totally lost. So here are a few questions, if someone would be so kind as to respond:

1) Do I still need to use the trunk version of the plug-in? Or is the current downloadable version useable?

2) Otto’s tutorial says nothing at all about activating the plugin through the plugins page under admin. Does it need to be activated?

3) After mapping the domain under Tools>Domain Mapping, what else needs to change in regard to the subsite itself? (As in, going to the subsite, editing and changing domain name/home/url/download path/etc

4) If you map mainsite.com/subsite to subsite.com, do you also have to map https://www.subsite.com?

5) In lieu of answering the above, if someone can post a link to complete directions (and I know this is hard to do as alot probably hinges on the server that WordPress is installed on), I’d appreciate it.

Have not found the cause for this yet. I have 3 sites in a multi-site network (directory) using WordPress 3.0.4 on a lamp system. I’ve downloaded the most current version of WordPress MU Domain Mapping (0.5.4), moved the sunrise.php program to the wp-content directory. Edited wp-config to add the define statement for sunrise to turn it on. Easy-peasy.

When I activate the plugin, either a network activation, or a single site activation, I lose all widgets. Not some. All. On all sites. Before I’ve even mapped. The only thing visible is content-area. So I think, ok, I have to map the domain to be able to see the entire page. So I map the domain. And the mapping works, that is, I plug in the wanted domain and get to the site. But the widgets are still gone. I’ve tried going in and updating a page. And going in and saving the widget. And still nothing.

I can understand having to change any theme-related url’s. I don’t understand what to look for, or where to look, to fix this issue.

Anyone who can help?

Sorry – we tried numerous things, but the one thing that seemed to clear it up for us, is, we added the site as a host under Networking/Host addresses. It seems that we were redirecting, and redirecting, and ultimately, the url would resolve to the appropriate place. Once we told the server that, by the way, this url is indeed a host on this server, it seems to have cleared it up. (We use WEBMIN for administrative software; under Networking, under Network Configuration, under Host Addresses – added the internal ip address and the url as host name)

I’m with jzahlaway. Thanks, Alex.

Ok. Well, we’re happy, so this is marked as resolve. Thanks for your responses.

donncha, thank you. It appears to be working as it should, now.
Was it the introduction of google maps that corrupted the wp-cache-config.php? As that was the only thing that changed on the site, I’m thinking so.

Thanks

Ok, restored the database, un-installed wp super cache per the readme.txt instructions. Re-uploaded the plugin, re-installed, re-configured.

Went to test, and got the following error:

Test your cached website by clicking the test button below.

Fetching https://www.ca-wp.com/wnr/ to prime cache: OK

Fetching first copy of https://www.ca-wp.com/wnr/:
Fatal error: Cannot use object of type WP_Error as array in /private-set-1/wwwroot/apache2/wp-content/plugins/wp-super-cache/wp-cache.php on line 900

Suggestions?

You’re a peach ?? Thanks much

huh. Only other thing I did was to enable the multisite support from the WP SuperCache page (as I got the pretty pink message telling me to do so..) So….

I deactivated the domain mapping plugin. I’ve deleted the plug-in folder, deleted the sunrise.php file, put wp-config.php back (no reference to sunrise), and it appears that we’ve got it all back.

When the plug-in is activated, what changes in the database? I know that two tables were new, wp_domain_mapping and wp_domain_mapping_logins, but after mapping the first domain, I only saw a record in the wp_domain_mapping (accurately referencing the appropriate site-id and url).

As I did NOT restore my database to before the plugin was activated, I’m thinking this was all that actually changed. Suggestions on where I can look to determine what caused this?

After a couple of weeks of monitoring multiple things – system resources, various logs in various stages of debug modes, load times for my WordPress pages vs non-WordPress pages in an attempt to determine what was causing my WordPress pages to be excruciatingly slow in loading, I hit upon an Apache directive that seems to have been a big part of the problem.

The directive is a part of mod_access. Allow, Deny, and Order seem to work together to determine which hosts can (or cannot) have access to the directory for which you’ve set the directives. I don’t know what the default settings are, but I noticed in the virtual host for my WordPress domain, it was set to Allow from all. This may have been turned on in conjunction with the AllowOverride all (but I’m unsure at this point).

Anyway, I changed that setting to do neither allow nor deny – and viola! Load times immediately went down to anywhere from 2.1 to 42 seconds, as opposed to the 1.5 to 4 minutes (MINUTES!!) I’d been seeing.

Of course, 42 seconds is still way too long for a page to load, but, at least now I can look more closely at the components of my page, instead of tearing my hair out trying to figure out where the hamster was falling off the wheel!

Also, in this process, I’ve found FireBug for Firefox to be an extremely informative tool, in conjunction with YSlow (although YSlow is more general in it’s info).

So, until I find other things that may be causing the speed issues in my site, we’ll call this one resolved. Thanks for all your help.

Found the issue in wp-options, rewrite_rules. Lots of references to Job Manager in there; cleaned it out and all is well.