Tag: multisite

Mailbag: Multisite Theme Activation
Briany from Ireland has a cool idea (put the guilt away, Briany, I think this is a pretty wild concept and I like it). This is the sort of ‘support’ email I love because it’s not a yes/no answer, but a theoretical concept to think about and parse!

Here’s the meat of the email:

SO MY FASCINATING QUESTION IS THIS; In a multi site network is there any way to use 2 separate themes for each or any sub-site based on the URL used (or any other method) Example 1 Visit www.sitename.platform.com and view the whole site using theme A (Standard) Visit www.sitename.com and view the whole site using theme B (custom)

At first I thought “Briany can’t possibly be asking ‘How do I activate a separate theme per site.’” and then I realized the question was for the network! So to phrase it in WordPress terms, if I visit the site via foo.example.com, I get theme foo on every site on the network.

(If you just want Site A to have one theme, and Site B another, that’s easy. Either network activate the theme and select it on the site, or go to WP Admin -> Network -> Sites, click on edit, click on the themes tab, and activate the theme you want for the sites. Then go back to the site and select that theme. A couple steps, yes, but relatively easy.)

Theoretically yes, yes you can. There’s a plugin called Theme Switcher which lets users pick, and based on some code on StackExchange, you can change the theme based on users, but the issue here is that you want to only change it per domain for that user.

It’s certainly possible to change settings by detecting the domain, I do that with SSL.
```
if ( $_SERVER["HTTP_HOST"] == "foo.example.com" ) {
    // My Code Here
}
```
That’s the easy part. The hard part is keeping that setting when I go from foo.example.com to example.com…

I sat and kicked this idea around for a while. It would be much easier on a single install of WordPress, since I could make everything relative and then just use the host name. But you have to have a way to track the starter domain, and have it be per-visitor, which means you have to use cookies, and read from that, using setcookie() (which is a PHP thing, not WP specific).

At that point, I think I would close the book and say “No, it’s possible, but not a good idea.”

Why, you ask? Caching. How the hairy hell could I possibly cache that if the theme changes every time for every user? Maybe, maybe, I would do it with multi-networks, and define a theme per network, but not per-domain. Obviating any caching would pretty much kill my sites, and even a good opcode cache (I use memcache) will be usless in that scenario.

By the way, there are a lot of neato plugins to change themes based on weird things, like Domain Theme, which is great for single installs of WordPress.
11 July, 2014
Mailbag: Multisite Files
Another mailbag! This one is a few people… No, this is the one most people ask me. I understand why.

@jbenton @Krogsgard Basically read everything @Ipstenu has written (including when she suggests to not use it).

— Andrew Nacin (@nacin) December 20, 2013

I really do understand it’s intent, it’s goals, and I try to keep up with it. I use it daily. When I write plugins for it, I spend hours trying to decide how to properly support it. I may even write in checks on the ones that don’t work on Multisite to auto-fail when you activate and prevent you from using them. I will argue till the cows come home that Multisite is for multiple separate sites. But that said, there’s also an exception to every single rule.

Let’s get to the letter! Kevin in Canada has a Multisite with a uploaded files conflict:

The site is setup as default /files for the upload dir. Problem is, my client already has a directory in the root called /files. It cannot be changed as it houses software exe’s and needs to remain as /files. I need to set the upload path to /media for the images and not mess the site up. I read your blog post about this issue but wondering if you could clarify the steps. Right now, software download requests are redirected to the homepage!

The steps are, alas, complicated because the situation is complicated. The blog post Kevin’s referring to is called Dumping ms-files. If you’ve installed WordPress as of WP 3.5, this is the new default anyway. That would mean that Kevin has an old Multisite.

The ‘easiest’ option would be to start over with Multisite, use a fresh install of 3.9 and go from there. Second to that? Well the dumping MS files stuff is not easy and it really can’t be easy. You can try trepmal’s directions but after that you’re getting into writing a little bit of your own custom directions, and that is going to be really complicated.

I’m not 100% clear on why these can’t be moved, so I’m guessing that the issue is the lost redirections. While I believe good URLs never change, I think that redirecting them is okay. These are .exe files, which means if, before the .htaccess rules for WordPress, you were to put in a rewrite rule and check ‘If you’re looking for /files/*.exe, go to /otherlocation/filename instead’ that might get around it, or even to say ‘if files and NOT exe.’ Maybe something like this:
```
# uploaded files
RewriteCond $1 !\.(exe)
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]
```
Mind you it’s weird. Either you had Multisite first, which would explain the /files/ for uploads, or you had the EXEs in /files/ first, which doesn’t explain how you got this far into it at all, since 3.5 came out in December 2012, and that would imply you built the Multisite in 2012 and have had this problem for at least 18 months, give or take, which is a long time to have a problem and do nothing about it.

If you started with WP 3.5 or later, you just make a /files/ folder and off you go, no code needed. If you started before that, you can follow the directs to undo MS files and then make a files folder and be done. Make sure not to forget about the .htaccess rules!
4 July, 2014
Mailbag: Multisite Caching

Dave has a question abtou Multisite and caching!

I asked about caching on multisite setups. I’ve got 10 of these, with between 10-50 sites added to each- and the content is static- never going to change it much. I have a feeling I could benefit from caching, you recommended server side. I could use some help here. I know your site says you’re maxed out time wise- I’m thinking I just need someone to help me with one site, and show me what to do. Or, if they want to set things up on all of them. Do you have any recommendations?

Thanks again for the help.

Dave

Caching! There are three main types: plugin, server, and proxy.

Plugin caching is WP Super Cache, or W3TC, and it’s letting WP make a static cache file on demand. Server caching is APC/Memecached and such, which lets the server make a dynamic cache. Proxy caching is Varnish and the like, which puts a cache before the WordPress server, kind of like a static file on another server.

Which one is best for Multisite with static content? Probably a proxy cache there. Though I’m going to go out on a limb and say if you’re not using WordPress for all it’s useful for, maybe you don’t need it at all. If you have a pretty static site, where you’re not changing content all that much, there’s nothing wrong with static HTML. But if you want to use WordPress (like you’re a WordPress only shop) then you have to consider the options. What is your site doing?

This is actually not a Multisite Question so much as a cache management question. The part that’s multisite specific is who to you let manage what aspect of the cache. I maintain a plugin called Varnish HTTP Purge, which is a pretty basic plugin that checks for common actions, like posting or commenting, and flushes your cache selectively on Varnish when those things happen. One of the Multisite specific issues with that code came up when I added in a new feature: Purge Cache.

That feature lets you press a button to flush the whole cache. Pretty cool, right? The problem was Multisite with Subfolders. See, the way the cache flushes is to say “Dump everything under domain.com!” which works fine with subdomain sites, as that will only flush domain.com and not foo.domain.com. On a subfolder, though, it’ll flush domain.com, domain.com/foo/ and domain.com/bar/ and everything else. That would suck! So the best thought I had was I should lock the flush down to Super Admins only on the main site on a subdomain setup. Normally I allow the site admin to flush their own cache, but this way only the Super Admin could make a full flush.

And that’s the crux of the issue with caching on Multisite. Do you want each admin to maintain their own cache? Do you want it to be something you control for everyone? W3 Total Cache can do that, by the way. You can do it both ways with that plugin, and only control what you want to control for the network. But what about if even I don’t want to do that? What if I want to be lazy and trust my tools? That’s when you look at the server itself and try to make it as brainless as possible. Decisions, not options, remember?

And that brings up another question. Why do I want to manage who flushes at all? In my Varnish example, it’s because careless flushing clears the whole cache, which means my server and site have to recache everything and it slows everyone down. Obviously I want to limit that as much as possible. The other reason is work. People who have a managed hosting site generally aren’t the most technical savvy users in the world. Some are, of course, but many are more likely the ones who don’t want to know about the crazy server stuff. This is great, but it means I want to make their life easier so I have to provide less support, then I want things that do their job and do it well, and that means taking options away and making decisions for them.

How would I cache a static Multisite network and fully control it as a network admin? Probably server side caching like Varnish or ZendAccelerator Memcache. If I can’t do that, I’d use W3TC and lock it down so only I, the super admin, in my fancy cape, can edit settings and purge the cache. And always, always, remember to only catch what should be caught in your cache. If you have a site that’s a store, account for that.

27 June, 2014
Mailbag: I want to make WordPress.com

Justin is not the only person who’s asked me this one, and it boils down to “How do I run my own wp.com?”

I wouldn’t. It’s insane, and if you want just an inkling as to how frustrating it is, spend 8 hours a day, for 2 days, doing free support in the WordPress.com forums. That’s going to be your life. If you hate it, don’t do it. And more to the point … I don’t feel we need more generic ‘Anyone can host here.’ sites. The most successful modern one is Medium, which doesn’t give you a site like ‘ipstenu.medium.com’ but instead just share-posts everything. I’m personally not sold on the efficacy of it, but my point is I feel these gateway blogs are less and less necessary, the better we make WordPress software. We’re lowering the bar for people to own their own sites.

If IF I was going to consider it, I’d be looking at it from the aspect of a small group of people. For example “A network for small town newspapers.” I take care of the servers and code, they just write. That’s a smaller, niche, market, but also one that probably can’t afford VIP WordPress.com. You can always expand, after all.

But Justin actually has a security concern. Let me share in his own words:

I want to build a service like wp.com, blogger.com but with free and commercial themes and plugins. Drag and Drop themes (Headway, Ultimatum), plugins (Visual Composer). If my site is feature-loaded, people will come, is’t that right? But I wonder why people don’t use all those nice software to build better than those companies. I want to ask, is it because people can insert malicious codes in css and javascript code editors?

Yes and no.

Its not the malicious codes in CSS and JS, though that is a concern. WordPress.com has a CSS editor that you can pay extra for, and the question many people ask is “Why isn’t that free?” The issue isn’t with security, it’s support. Frankly, people who need (note the word ‘need’) a managed site like that generally haven’t a clue what they’re doing in CSS for design. They need those baked and locked themes because they’re not ready for the rest without a conscious choice and a monetary investment. You’re paying more for something, ergo it’s worth more.

But JavaScript? Well that would be security but also support. I certainly don’t want people messing with JS because it’s easier than CSS to break your site with it. Don’t believe me? Go look at everyone’s whose visual editors broke after upgrading to WordPress 3.9 because of plugins that don’t work well with the new JS settings in TinyMCE. Those are plugins, written presumably by people who know what they’re doing. And they broke.

Is there a security risk to letting people edit CSS? No.

Is there a security risk to letting people edit JS? Yes. And worse on Multisite (which is what WordPress.com is running) as that could break the entire network, not just one site. A bad CSS call will only break your own site on the network, after all.

But I think the question may be “What’s so dangerous about JS anyway?” and the answer there is “Cross Site Scripting” (aka XSS). XSS is a vulnerability that will allow hackers to inject scripts from their computer into your site, which is normally (in WP land) used to bypass the requirement to be logged in, dump garbage into the database, and then log in and create merry havoc on your site. I’ve been told up to 84% of all vulnerabilities in the web are XSS related. This may or may not include CSRF (Cross Site Request Forgery). The XSS article on Wikipedia is pretty good.

Based on that alone, I would not allow users to make their own javascript edits. I would perhaps provide plugins to allow them to make certain adjustments, but not anything they wanted, any time they wanted. If they need that, then they need to get their own hosting on their own server, so they only blow up themselves.

Oh and whatever you do, don’t try to become ‘the next…’ anything on your own. That way lies madness. Get some help.

16 May, 2014
Mapping Domains Without a Plugin
Recently I wrote WordPress Murder Mystery. The day I released it, I got on a plane to fly to Miami, and proceeded to have a pretty awful travel day, thanks to a storm that pretty much knocked travel to the SouthEast out of commission. While I waited for my flight to DFW, I got pinged. “Hey, I can’t add anything from your store to my cart!”

I pulled up my laptop and thought about what I’d changed. Oh. I’d turned off domain mapping. But not really.

You see, I love the WordPress Domain Mapping plugin. But I’m not using it here. No, I’m actually doing something I expressly and patently tell people not to do … because time has changed with 3.9 and it’s almost okay to do things this way. The change here is that WordPress is smarter now, and it’s safer, and you actually can just edit the home and site URLs in the Network Dashboard. But you know how I said ‘almost’ back there? Your ability to shoot yourself in the foot is directly proportional to how smart you think you are.

What I did? It’s basic but assumes you already know how to add a domain onto another.
1. Go to Network Admin -> Sites
2. Edit the site in question
3. Change the URL to the mapped domain, check the ‘change home and site URL’ box, and click update
That was it! Three steps and everything still worked! This also let me force change a site to https all the way, and since I didn’t have content, I didn’t bother with a search/replace. If I had, I’d use that Interconnectit Script or WP-CLI for it. Still, like a wise person, I always get the domain ‘right’ before I add content.

And at this point, everything seemed to work just fine! And so I left it as is and published my book. And as you know, it all failed, spectacularly. I rolled everything back (because I knew what I’d changed last, see? always remember that!) and it worked again, so I knew I had to have missed something big here. Since I was stuck in an airport with choppy wifi, I disconnected everything and fired up my localhost version of my site. Banging on that for a while, I saw I missed a small, but hugely important factor in the plugin.

See most of what it does is that pretty interface to say “Pull domain.foo content from site #2 (aka foo.example.com)” and force redirects. It also lets you do cool things like “Allow users to log in from foo.example.com instead of domain.foo” but really I didn’t need any of that. The meat of the code is in the sunrise.php file, which when I studied, I realized was just doing the redirects “Send Site #2 to domain.foo” and for me, by renaming the home and siteURLs, I was already doing that.

So what had I missed?

define( 'COOKIE_DOMAIN', $_SERVER[ 'HTTP_HOST' ] );

That was it. I forgot to tell it “Cookies belong to the domain you’re on.” What this means is that if you log in at example.com, the cookie you get is for example.com and not domain.foo! For the most part, this isn’t a problem since no one logs in but me … until you try to make a purchase and it validates a cookie which doesn’t match the domain. I added that to my wp-config.php (down at the end of my Multisite section, where the SUNRISE define had been earlier) and everything magically worked.

Two lessons! First, test everything. Second, you can map domains without a plugin, safely.

I will note that, over time, it’s possible those settings for home and site URL may vanish from display. They’re powerful and dangerous settings, and you should not mess with them without a good backup.
12 May, 2014
Changing Your Domain Name In Multisite
Even I hate moving Multisite if I have to change folders (like from domain.com/wordpress to domain.com). But if you told me “Mika, I need to change my domain from cocobanana.com to cocoabanana.com!” I’d say “Hold my beer for five minutes.”

I will note: If this process freaks you out, remember to never make changes like this without a backup. If it’s still super spooky, you may not be ready for Multisite yet. I would consider this to be a good litmus test, though, for a wanna-be-multisite-master. You’re going to need to be able to do these things to get there.

Step 1: Search and Replace

This is the easiest one. If you have WP-CLI it’s super easy.
```
wp search-replace http://cocobanana.com http://cocoabanana.com
```
Don’t have WP-CLI? Okay, grab Interconnectit’s Search/Replace DB Tool and use that.

This will take care of 99.999999% of your site. It’s imperative you remember to use this tool! If you don’t use a tool that searches and replaces with consideration to data serialization, you will cry and reset all your themes and widgets. Manually. See? Told ya you’d cry!

Step 2: Edit the Database

Go into the database. Look at the wp_site table. Change the domain field from cocobanana.com to cocoabanana.com (seriously, that was it!).

Then look at wp_blogs and change those domains similarly as needed.

Step 3: Edit wp-config.php

Open the file and look for this:
```
define('DOMAIN_CURRENT_SITE', 'cocobanana.com');
```
Change the value to cocoabanana.com and save it.

Step 4: .htaccess and plugins

I lied. There’s another step. Make sure you weren’t super smart earlier. Like if you used some rules to block hotlinking, make sure the new domain is added in there. Also make sure your plugins aren’t calling your domain in some weird way (though that search and replace should have fixed that too).

Also if, like me, you hate www’s in your URLs, you’ll want to put this in your .htaccess to force everyone around. It also has the benefit of making sure the weird redirect of www being treated as a subdomain stops happening on Multisite. By the way, I still strongly encourage you to NOT use www in your Multisites, it’s a pain in the ass and you can educate people as to why no one has to have www anymore. Also WordPress itself has always suggested you NOT use it when activating Multisite. Do you know better than WordPress? No? Okay then, don’t use www.
```
&amp;lt;IfModule mod_rewrite.c&amp;gt;
	RewriteEngine On
	RewriteBase /
	RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
	RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
&amp;lt;/ifModule&amp;gt;
```
Now can I have that beer back?
21 April, 2014