Tag: mailbag

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
Mailbag! .htaccess questions
New thing! So many people email me for tech support, which I’m pretty clear on how you’re not going to get it. But Ken (the web mechanic) asked some pretty basic questions, and I’ve decided to answer some of them.

In public. Lucky you, Ken. Don’t worry! These were good questions. See, one of the (many) reasons I love WordPress and the support forums is that the answers are public so everyone can see what the question was and how it was answered! This is hugely important to foster a community, so that’s why I’m going to answer this in public, with your personal information removed, of course.

Ken’s basic concern is that .htaccess is confusing, and is there a preferred order? The answer is yes. The basic idea is that .htaccess rules are a top-down process. The server reads the file from the top on down, in order, 1-2-3. For this reason alone, it’s obvious why you don’t want a super long .htaccess file: more to read takes longer!

The WP permalink area… Should that always be dead last?

Yes! WordPress rules always go last. Remember what I said about top-down? If you were to put WordPress at the top, you would load WordPress, process it, and then do the rest of the rules. Which once you say that, it’s pretty obvious eh?

Deny IP addresses/ referrers. To me it would make sense for them to be at the beginning… Would that be true?

True! The access controls (including IP blocks) first. Redirects go next, starting from most specific (about-me to about) first to general last. Then your Rewrite rules.

Compression/Caching/mod_expires… I haven’t a clue where they most appropriately go. Securing wp-config, htaccess itself, other files, etc. … Before? After? the WP permalink block.

I put them before my re-writes. Since I use a deny to secure .svn type files, it’s an access control so it goes first.

So how does this work? Here’s a practical example. You want to do the following: remove www from your domains, protect your wp-config file, protect your comments and login from direct attacks, redirect some old pages from before you were WordPress, redirect your old permalink formats, and gzip/compress things. Oh and run WordPress!

The order would go like this:
1. Access Control: This is the part where we’re protecting specific files, but also blocking IPs. Basically it’s ‘Security First.’
2. Remove WWW: We want to make sure everyone’s redirected to the non-www page. If you’re redirecting specific domains (like I send tech.ipstenu.org to halfelf.org), you do it here as well.
3. GZIP: I do my compression here, though it woudl work just as well swapped out with the next one.
4. Redirect: Here we’re talking one-off redirects like sending ‘about-me’ to ‘about’.
5. Rewrite: The ReWrite rules are the ones where you say “Send http://example.com/2014/01/10/postname/ to http://example.com/postname/” with those rules with regex.
6. WordPress Rules: Last. Always always last.
And that is .htaccess!

If you want a look at how my .htaccess is structured, see My super-secret .htaccess file, which hasn’t changed much since 2013. I do a couple things out of order, but they’re minor enough. As long as I can limit any recursive loops with the .htaccess checks, I’m doing good.
7 May, 2014

Tag: mailbag

Mailbag: Multisite Theme Activation

Mailbag: Multisite Files

Mailbag: Multisite Caching

Mailbag: I want to make WordPress.com

Mailbag! .htaccess questions