Tag: wordpress

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
The Wheel Is Fine
“I have an idea for a plugin!” he said to me. Everyone does, but I encouraged this question. “I want to make the media embeds in WordPress more responsive.” I paused. There are already a lot of those, like Responsive Video Shortcodes. So I asked what made his different. “I’m going to make NEW shortcodes!”

I see a lot of plugins. Many times I see plugins where people want to tweak a normal part of WordPress, like the gallery or the embeds. The problem I see is that instead of extending those, they decide it’s better to make a plugin that recreates all the shortcodes and embeds, but with a new name, so users have to remember to use (which is default to WordPres) or [youtube] (which is in Jetpack) or [someothervideotool] (which I made up for an example).

Now I’m guilty of this myself! I have a private plugin which is HTML5 video embeds and it gives the video in HTML5 format, which I could do in the default embed code, but it also plunks a link underneath that says “Can’t see the video? Click here.” And the Click Here goes right to the mp4 video. Because I have some rather dim people. But. I don’t have to reinvent the wheel here. I could instead filter that shortcode just to put my little blurb on the end! Doesn’t that seem smarter?

The first time I thought about this, I said “What I need is to filter and slap something on the end!”
```
function halfelf_oembed_filter($html, $url, $attr) {
    $html .= "<p>I am a monkey.</p>";
    return $html;
}
add_filter( 'embed_oembed_html', 'halfelf_oembed_filter', 10, 3 );
add_filter( 'video_embed_html', 'halfelf_oembed_filter', 10, 3 );
```
This puts “I am a monkey” below every embed, which is great for stuff like YouTube and Twitter. The second filter is for videos when you’re using Jetpack. And this works great, I could even wrap the HTML in something, like a div or js code, and enforce responsiveness. You can check the URLs, see if it’s youtube or whatever, and apply different settings per URL. Works nicely. I actually have my just div-wrapping for padding reasons.
```
    $html = "<div style='padding: 5px;'>".$html."</div>";
```
This works brilliantly, however … I’ll get to that in a second. Now, for my friend’s initial idea, once we banged on this, he said he was just going to use the other plugin, but embed-filtering was way easier than trying to over-ride the shortcodes and reinvent the wheel. It also makes it easier to upgrade.

But then there’s my problem with my site and the need for that “Hey, get the MP4 here!” message. You see, 90% of the videos I have on this particular site are locally uploaded, and since I always upload an mp4 and a webm (and sometimes an ogg), how do I parse it?

First of all, I’m using the Video Shortcode, so I know there’s a simple filter for wp_video_shortcode_override (it works roughly the same as img_caption_shortcode but that’s not what I want to use. I don’t want to replace everything, that’s my whole point here. I just want to make a link! In addition, I know I’m only going to want this when I have a video with a defined mp4, so why not just filter wp_video_shortcode instead?

So that’s what I did:
```
function halfelf_video_shortcode($html, $attr) {
	
	if ( !empty( $attr['mp4'] ) )
	{
		$html .= "<p>Can't see the whole video? Click <a href='".$attr&#91;'mp4'&#93;."'>here</a>.</p>";
	}
	
	return $html;
}
add_filter( 'wp_video_shortcode', 'halfelf_video_shortcode', 10, 2);
```
This slaps a link for my tech challenged friends on browsers that refuse to tolerate videos.
23 June, 2014
C’mon Get Trac’in!
After every major WordPress release I trawl the forums and look for new superstars. I usually find one or two people who, like I did five years ago, catapult themselves into the stratosphere by taking notice of issues of communication and correcting them. That’s how that OMGWTFBBQ post was born! WordPress 3.0 dropped with a lot of changes and people lost their minds. That’s the best part of a complex release.

The worst part is people losing their minds in the wrong places.

Oh there’s nothing wrong with going batty over a change or reporting something is broken. What’s wrong is when you go into a half-dozen similar posts and repeat the exact same rant. Much like the superstars who get noticed because they’re being helpful, when you spam-rant, you become noticed in a bad way.

No release is perfect, and WordPress’ ideology of ‘Release and iterate!’ means that we know we’ll have missed something, or not totally finished another, and it’s not everything we want yet, but also that the fastest way to get ready is to get more people poking at it and breaking it. This means we know things aren’t perfect, but it doesn’t mean we ship broken code. Still, change breaks things, and some of those things are outside our control (like TinyMCE 4 changed how it implements a lot of things).

Naturally though, big changes cause loud complaints. For people who shout and demand to know why we had to change, the problem is where they do it, not so much how and with what language. The where problem is that someone will post a rant in a bunch of similar posts, or create a trac ticket when they haven’t done any debugging.

It’s pretty easy to remember that the support forums are not your personal soapbox to stand on and shout about how much everyone sucks (or is awesome, I know). The forums are a place to describe your problem and get help.

So … How DO you know when it’s time to get trac-a-lacking and make a ticket, and when it’s not?

Is it just you?

A quick search of the forums will tell you if you’re the only one with an issue. If you see one or two other people with similar issues, read deeper. Similar is not the same, so just because you both have a white-screen-of-death on the post editor does not mean it’s the same bug.

Did you do the needful testing?

Have you tried:
- flushing any caching plugins you might be running, as well as server and/or browser caches.
- deactivating all plugins (yes, all) to see if this resolves the problem. If this works, re-activate the plugins one by one until you find the problematic plugin(s). If you can’t get into your admin dashboard, try resetting the plugins folder by FTP or PhpMyAdmin (read “How to deactivate all plugins when you can’t log in to wp-admin” if you need help). Sometimes, an apparently inactive plugin can still cause problems. Also remember to deactivate any plugins in the mu-plugins folder. The easiest way is to rename that folder to mu-plugins-old
- switching to the Twenty Fourteen theme to rule out any theme-specific problems. If you can’t log in to change themes, you can remove the theme folders via FTP so the only one is `twenty fourteen`. That will force your site to use it.
- manually upgrading. When all else fails, download a fresh copy of the latest.zip file of WordPress to your computer, and use that to copy up. You may need to delete the wp-admin and wp-includes folders on your server. Read the Manual Update directions first.
(Can you tell I use that a lot?)

Does it happen on a clean install?

The best testers test on a test site. Even on my personal, I don’t code on it, laptop, I keep a copy of MAMP handy, as well as a pure test site on a live server. But I’m weird. Still, if you’re even considering making a trac ticket, have a test site and test it there before you click that ‘new ticket’ button. It may feel like an extra hurdle, but having that clean test will make sure you’re not losing your mind sometimes.

Have you asked anyone else about it?

I admit, this works better if you know people, but if you do know someone, just ask. I bug my coworkers sometimes “Hey, do you see this? No? Okay…” It helps me sort out if I’m being crazy or not, and sometimes just asking “Anyone know why I might get this error…?” gets amazing results. Again, this works best if you have a network already, so don’t worry about this too much.

Hope you’re right…

Even I don’t know if it’s right to make a ticket all the time. I hesitate over those buttons a lot, and often delete the whole thing. It’s not super simple to know, so you have to make your best guess.
30 May, 2014
How to Market Your Blog

I recently had a poll on my ebook store, asking people to vote for what I should write about. Someone suggested this: how to market your blog-best strategies and “no no’s”

For a while, I looked at the suggestion with Reddit face. I’m not in marketing. I’ve never been in it, I don’t have the foggiest idea how one goes about marketing anything, and I don’t really care to. Why would anyone ask me to write about that? But then again, maybe they’re asking specifically because I don’t normally write about that.

With that in mind, here’s how I market a blog, and it’s one really simple step:

Know my audience

You’ve got to know who you’re writing for if you want to sell it. If I’m going to be blogging about dog food, then I should take the time to learn about how dog enthusiasts act online. What kind of ‘fan’ blogs are there, what kind of official/professional sites are there, what sort of forums. I need to understand who they are, how they act, and what they expect. A blog for tech people will accept different design styles than ones for pre-teen books.

A side-note to knowing who I’m talking to is knowing what they consider normal. Even if you think the current ‘trends’ on their sites are ugly as sin, you have to aim at them in order to be accepted. Similar but different. People don’t like big changes, and you may find yourself ignored. At the same time, being different is good, you stand out. Find that balance.

But when I tell people “I know my audience and I write for that” it sounds at once insanely overly simplistic and bloody genius. The fact is that I’m not a marketer, so I don’t ‘market’ my site, I write good content, put it on a theme with good SEO (thank you Carrie Dils for your Utility Theme and StudioPress for Genesis), and the rest magically takes care of itself because what I put into the world isn’t my blog, but myself.

I said once that Chris Lema doesn’t sell himself, he sells you on yourself. He liked that so much, it’s on his header for his blog redesign. Chris, I suspect, gets what I mean when I say I don’t actually market anything. See, I go out there, I find people who need help, and I help. I spent time without really meaning to building up a rep of being helpful and knowledgable and understanding because I have some skills that were perfect for my audience. Not only do I know them, I am them!

What’s on this site is essays, how tos, and ebooks. I sell the books based on the attraction from what I do in the world. See, Open Source is weird. We put stuff out there for free, and then people pay us for other things they can’t do themselves. It’s like how I tell my coworkers to ‘sell’ people on our managed hosting. It’s a question of where people want to spend their time. I like playing on the server, my wife doesn’t. If she didn’t have me for hosting, I’d actually tell her to get managed hosting from the start, because it lets her do what she wants to do!

And that’s what you’re selling. That’s what you market.

Steve Jobs was right when he said your customers don’t know what features they want. But don’t sell them or market them just because they’re features. Sell them what you are what you use. Tell them the truth. Market by representing what they could be, help them get there, and don’t sell ‘As Seen On WordPress.’

We build in WordPress things we need. We should market them as that. “I needed this. Here’s how I did it so you don’t have to reinvent the wheel.”

I’m Mika Epstein, aka Ipstenu. I know things you don’t because I do things you don’t, and I write about them for you to be able to do them even easier and faster. I know what it takes to learn because I learned. I know how to explain it because it’s how I explained to myself. I know who to talk to, because you’re my people.

26 May, 2014
So Your WordPress Upgrade Broke

I’m delving into angry-land here, so hold on to your hat.

So. You upgraded to WordPress to a major release without testing it first, and broke your site? It’s probably your own fault. Bring on the stones and when you’re done, let’s talk.

Ready to talk? Okay, you didn’t test. That’s why it’s at least partly your fault. This triples if the next words out of your mouth are “And my WordPress site is my life!” It quadruples if you say “My client sites broke!” It’s infinite if you broke your company site and you happen to be a WordPress based company.

But notice how I said probably? I can honestly say that 50% of the time my site breaks, it’s WordPress, not me, but I happen to run trunk without testing, which makes it my fault, not theirs. Seriously. I’m running trunk on a live site, which updates twice a day. I’m a little reckless. My life is WordPress, which makes me in violation of one of my own cardinal rules, but at the same time, the part of WordPress that is my life is supporting it, or breaking it and reporting it. For me, a broken WordPress install is one that needs my love to fix it, and I embrace that role.

You’re not me. And in fact, neither is my dad or my friends’ sites that I host. For them, I have a couple options: Let them upgrade themselves, upgrade them automatically, upgrade them myself. I use all of those methods, in different situations and with each of those, what happens when they break? I will say this, for everyone but me, if I have a contract to manage their updates, I test the update first. To the fellow who complained he had 200+ sites to test, I say “Well, that’s your job.” You agreed to manage them, you better do it right.

Telling people “Your site broke because you didn’t test.” isn’t an answer, though. It doesn’t explain why the site broke. The answer to that is a little more simple. “You have code that doesn’t work with the upgrade.”

And yes, it’s really that simple. You have a plugin, or a theme, or an add-on to your server, that doesn’t like the newest version of WordPress. Now, it’s a struggle to fix one’s site at the same time as placating one’s customers/clients/visitors, because you’re in a race against time. This is why you have to do that usual testing with plugins off and so on. Complain all you want, there’s no way around it. Point out you’re not a coder all you want, that’s actually why this happened to you and not me.

What do I mean? Well I am a coder, so when I install a new plugin I review it first by looking at all the code. You’re not a coder, I hear, but you can still review the plugin by looking at the updates, the author, their contributions to WordPress, the support forums, and the size of the plugin. The larger a plugin, after all, the more chances to go wrong. I also like to check /wp-admin/credits.php and look for the author. If they’re there, the odds of them not knowing that there was a change in WordPress that impacts their code is pretty negligable.

And this is how it works. It’s the addition of all things, combined to make a good, educated, guess as to the relative safety of your site. Good plugins that you’ve checked on, good themes ditto. Sure everyone can make a mistake, but good code makes fewer, good coders adapt well, and responsive coders react well. That’s the biggest thing. People will make a mistake and break your site, but if you use a theme were the developer is on the spot with patches and generally responds quickly (say, within 5 days), then you can be pretty sure that this developer knows when WordPress is releasing a new build, and that they should test Betas and RCs. That’s what you’re looking for.

This is especially important if your site breaks on a MINOR upgrade. If your site broke going from 3.8.2 to 3.8.3, and you find out it’s a theme, stop using that theme. That’s really hard, I know. But it’s really serious. A theme or plugin that breaks on the minor updates is doing something really wrong, or is taking advantage of a vulnerability which makes it dangerous to use. That’s it. That’s the reality. Either code is really bad or it’s really unsafe.

Neither of those things means the developer is a bad person. It just means they did bad code. We have all done bad code. We have all been the cause for bad and dangerous code, and we will all be so again. But again, it’s how we respond that makes us heroes or not.

Look for the heroes. They stand out. Use their code.

23 May, 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

Tag: wordpress

Mailbag: Multisite Caching

The Wheel Is Fine

C’mon Get Trac’in!

How to Market Your Blog

Know my audience

So Your WordPress Upgrade Broke

Mailbag: I want to make WordPress.com