chrisv2

AITPro – if looking at the bundled PHPMailer within wp-includes — isn’t that class-pop3.php file vastly different from the similarly named file that ships with PHPMailer? I’m not sure you should be replacing that file. The other two (class-smtp.php and class-phpmailer.php), yes.

Disappointing that nobody could bother to reply to this.

Here’s what I ended up doing. Would appreciate some feedback on this. Also, curious as to why you guys are running your function wpas_single_activate() on EVERY blog (network site) within a multisite network, hooked to the wpmu_new_blog action? If the administrator of the network did not choose to network-enable your plugin, shouldn’t you not be touching anything related to the network sites?

// turn of the action of Awesome Support adding itself to every network site
function chrisv2_wpas_no_network_sites() {
    remove_action( 'wpmu_new_blog', 'wpas_activate_new_site', 10 );
}
add_action( 'wp_login', 'chrisv2_wpas_no_network_sites', 99 );

With this, now PaidMembershipsPro works correctly again…but it feels “weird” to me that I had to do this…am I missing some setting somewhere, where your plugin will not attempt to run an install routine on network sites?

Wanted to share with you guys my experience in overcoming a couple of concerns I had with this setup:

1. I like using www. in front of my domains.
2. I wanted to prove this could be done without a static IP address for the multisite.
3. I wanted to give my clients the easiest possible instructions for modifying their domain registration, and avoid having to maintain A records in the event of a static IP address change (if using a static IP address for multisite).

Amazon Route 53 gave me the path to do this. In your AWS console:

1. In Route 53: Create a hosted zone for the client’s registered domain (foosite.com) with a www CNAME record pointing to your multisite (www.mymultisite.com).

2. In S3 Bucket: Set up an S3 bucket for the (non-www) client’s foosite.com and statically map that to www.foosite.com.

3. In Route 53: In the new hosted zone, create an A record for the (non-www) foosite.com and specify it as an Alias, pointing it to the bucket created in step 2. This assures that both www.foosite.com and foosite.com will end up pointing to www.mymultisite.com.

Now, back in your multisite dashboard you can make the network site URL be www.foosite.com; it will work.

Give your clients the DNS names that AWS Route 53 assigns in the hosted zone, and that’s all they need to do — use those DNS names and don’t even worry about modifying A or CNAME records.

Imagine having a few hundred clients and one day your static IP address changes — it would be like herding cats to get them to go into registrar and make the A record mapping update (!) This solves that dilemma.

To take this to the next level, you can also set up “white label” DNS with AWS, so you can tell your clients just use dns.mymultisite.com or whatever you wish to call them. It’s a very slick solution.

A note for CPANEL: some hosting companies don’t allow the wildcard incoming subdomain to map. You can also use an add-on domain or a parked domain (foosite.com), and point that to public_html or wherever you have WP installed. This effectively creates a virtual host record in Apache config, for the incoming mapped site.

OK. I’ve been on this for 20 hours straight and I think I finally figured it out. My goal was to enable CNAME only mapping, handling both www.foosite.com and foosite.com — with no worry about a dedicated/static IP address and with the goal of the clients to ONLY have to update their nameservers at the registrar, not have them try to deal with CNAME or A records. Oh, and I’m on a CPanel host so I have no access to Apache config, or logs.

I should probably write this up somewhere but the net is:

1. Amazon AWS Route 53 handles the DNS, create a hosted zone for the client’s registered domain (foosite.com) with a www CNAME pointing to www.mymultisite.com

2. Set up an S3 bucket in Amazon AWS for the (non-www) client’s foosite.com and statically map that to www.foosite.com

3. Back in the Route 53 hosted zone, create an A record for the (non-www) foosite.com and specify it as an Alias, pointing it to the bucket created in step 2. This assures that both www.foosite.com and foosite.com will end up pointing to www.mymultisite.com (look mom, no static IP address needed! ?? )

4. In the multisite network, go to the client’s site in network admin and edit the site URL, changing it to www.foosite.com

5. In the CPanel account that hosts mymultisite.com specify an add-on domain called foosite.com and point it to public_html (or wherever you have WP installed). This effectively creates a virtual host record in Apache config, for the incoming mapped site.

I also tried it in Godaddy and got it to work, but not the root TLD (only www), whereas I am confident that Amazon’s Alias mechanism is handling both www and non-www nicely via the bank shot to the S3 bucket.

With this setup, all I have to do is tell my client to change their nameserver designation at their registrar to the AWS nameservers I give them — and BAM, it works.

Upon further reading, the mapping of the root TLD (footsite.com) to another domain is a non-trivial problem. Looks like I am going to end up using Amazon Route 53 as a DNS service since they’ve added an “alias” record type that can handle this. Normal DNS like at GoDaddy will only allow the root TLD to map via an A record to a real IP address.

That’s an “ok” solution but down the road if I were to move to a different hosting service (i.e. different static IP address), I’d have a bunch of unhappy customers who will have to go back into their registrar and change the A record.

Apparently, using Route 53 to handle all DNS services will make the client side of the equation a lot easier. I hope.

Ron, forgive my ignorance here…but when someone new comes to my multisite and they click on “register”, then they are picking a name when they register. BillyBob12 signs up at the site and he is going to get a new site called billybob12.mymultisite.com

So, how can I have a single CNAME that’s used by all subsites?

Also, I tried (hard!) to not add that define('COOKIE_DOMAIN','');
to my wp-config.php but without that line of code I was not able to log into the newly mapped subdomain site. WP login was giving me a “browser does not support cookies” error.

Is there some bad side effect I am going to have by having that define statement in my config file?

It is actually working now! The remaining issue I am having is that www.foosite.com is mapping perfectly to customer.mymultisite.com — but foosite.com will not map; it goes to the default page at the registrar. I tried adding a CNAME record for *.foosite.com to point to customer.mymultisite.com and still no luck.

ok, understood and thank you Ron. So, to summarize:

1. I have WP multisite up and running as the single hosted site in my hosting account, and also with a static IP address.

2. I (think?) I have to also edit wp-config.php and add: define('COOKIE_DOMAIN','');

3. Customer requests and receives a new blog instance in the multisite network: customer.mymultisite.com

4. Customer registers a domain www.foosite.com, and at registrar he sets a CNAME record to point www to customer.mymultisite.com

5. I go into admin for customer.mymultisite.com and set the URL to www.foosite.com

Then, everything works as expected – all URIs using www.foosite.com will work. If this is correct, then I’m home free. I will give it a shot if you don’t think I’m missing anything.

Thanks Ron – is domain parking always a requirement — or *if* I had my multisite sitting at a dedicated/static IP address would it work without parking the domain at my hosting company?

Thanks so much for your time, Ron; marking this question as resolved.

(I think?) that is ok. Let me lay this out, please tell me if it makes sense:

1. Edit the URL settings in the user’s site to state that the URL is https://username.com

2. At the user’s registrar, set the DNS to where my multisite network is hosted. My multisite needs to be on a dedicated IP address.

3. Make sure cookies are handled correctly.

4. Random internet surfers can now put www.username.com into their browser and they will end up at the user’s site correctly, and all URLs will be re-written to domain base username.com

5. (this one I am really not sure about) When user wants to log into their WP back-end at their site, they’d still use the link username.foonetwork.com/wp-login.php (?)

Thanks Ron – do you mind expanding on #3 a bit?

Are you saying that all I have to do is change the site URL in the settings for the user’s site from https://username.foonetwork.com to https://username.com (assuming they have the domain username.com registered and a domain pointer set in their hosting account to send it to https://username.foonetwork.com ?

Is that the idea or am I missing something? I can certainly manually edit the URLs of the sites for my users if this will work.

It is a VPS but this VPS sits on a physical server that hosts other VPS accounts — so it is a shared server, it is *not* a dedicated physical server.

I need to keep the number of mySQL “open” connection events to a bare minimum. Am I ok using DB caching in this situation or will it cause other problems?

OK thanks Mike – that looks like exactly what I’m trying to do. Thanks for your help!