Author: Ipstenu (Mika Epstein)

Multiple Domains, Multiple Logins
Every month or so, someone asks me why they have to log in again on multiple domains on WordPress. That is to say, they’re using Multisite and they log in to example.com and then they have to log in again on sub.example.com and this is weird.

The answer is due to cross-domain browser protection. This is not to say you can’t do it! If you’re just using subdomains, this is really easy:
```
define( 'COOKIE_DOMAIN', 'example.com' );
define( 'ADMIN_COOKIE_PATH', '/' );
define( 'COOKIEPATH', '/' );
define( 'SITECOOKIEPATH', '/' );
define( 'COOKIEHASH', md5('http://example.com') );
```
The last one is just to prevent conflicts with other sites you may have on example.com that aren’t WordPress related. Or maybe are, but are a separate install for whatever reason.

But if you’ve read my older posts, you know my COOKIE_DOMAIN is set like this:
```
define( 'COOKIE_DOMAIN', $_SERVER[ 'HTTP_HOST' ] );
```
That’s because I’m mapping domains without a plugin to handle that for me. And that means I have to log in separately to halfelf.org and ipstenu.org and it sucks.

Like I said before, this is called cross-domain browser protection. You can’t use a cookie on multiple sites, even with integrated logins, with different domains.

Point in case. The exact same user ID/Password I use on wordpress.org is used on buddypress.org and bbpress.org and I have to log in to each site separately.

Why? To stop evil people from being evil. Can you imagine what would happen if someone sorted out your cookie hash and was able to let your login work on their sites? That would introduce new levels of phishing scam hells because you would be able to go to fake-paypal.com and your paypal.com login would just magically log you in.

So at this point it looks like you can’t have your cookies magically work for multiple domains and automagically log you in to them without interaction. But you’re safer this way. But what if you could?
```
$cookiehash = md5("http://www.example.com/");
define('COOKIE_DOMAIN', false);
define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');
define('ADMIN_COOKIE_PATH', '/');
define('COOKIEHASH',  $cookiehash );
```
Notice how I changed the COOKIE_DOMAIN? Without it being defined, it doesn’t restrict the cookie to one domain. The HASH will protect you ‘enough’ and you should be able to log in on all domains on your network.

Mind, I don’t do that. It doesn’t work reliably in my experience, which makes sense. It’s just not as safe.
7 January, 2015
The Road to PHP 5.x

If you use WordPress, you may be surprised to see that WordPress still supports PHP 5.2

PHP 5.2 was released in 2006, which is nearly a decade ago, and in the way that the internet ages, an impressively long time. In 2010, only five years ago, the last version of PHP 5.2 was released: 5.2.16. At that point, PHP no longer supported 5.2, but did apply security patches. True end of life hit in January 2011.

But back in 2006, when WordPress was getting off the ground, a lot of people were still using PHP 4. Not 5, 4. It wasn’t until mid 2010 that WordPress itself dropped support for PHP 4 (and MySQL 4). At that point in time, roughly 11% of WordPress installs used anything lower than 5.2 and this made it a pretty safe bet.

So why does WordPress still support PHP 5.2? Today if you look at the (not very accurate) WordPress stats, you can see that over 30% of people still use PHP 5.2

Back in 2010, WordPress was about 10% of the entire web. It’s double that today, so 33% of people on 5.2 is significantly larger than 11% back on pre 5.2, and with those numbers, it’s easy to see why it has to keep supporting PHP 5.2 … for now.

But the next obvious question becomes why is PHP 5.2 out there? And the answer is that WordPress is only 22% of the internet. Flip that around and remember that 78% of the internet is not WordPress. WordPress is not everything, nor should it be, so the webhosts of the world do have to consider than when they begin to upgrade.

Most major webhosts are in some state of killing PHP 5.2 with fire (seriously I am very excited for when it’s finally gone from DreamHost). When we upgraded people to 5.4, we found a lot of people who had very odd code out there that just didn’t work on 5.3 or 5.4, and upgrades broke them. We also found a number of people using WordPress who broke, mostly because they’d customized PHP 5.2 and forgotten, but also some who were on things like WP 2.x and were shocked, just shocked, it needed to be upgraded.

As developers, we want to be able to force everyone into a place where we can upgrade PHP (and WordPress) and have no compatibility fears. We want to use the new features of PHP to allow us to craft better, faster, more efficient code. We want to give users the features they ask for. But we can’t until everyone upgrades. And thus the vicious circle begins.

Would WordPress dropping support for PHP 5.2 speed up it’s demise? No. Not at all. Because WordPress is a drop in the ocean of the hassle that is upgrades. Do I think WordPress should drop support for PHP 5.2? Yes, but not the way you’re thinking. I would love to see WordPress stop supporting 5.2 in the sense that it should stop testing against it and worrying about backwards compatibility with PHP 5.2. It should check, on upgrade and install, that PHP 5.3+ is used and go from there. Heck, if it had a big alert “Hi, you’re on PHP 5.2, please upgrade!” on the admin page, that would be awesome.

But I don’t know that there are any PHP 5.3 (or 5.4 … or 5.5 or 5.6) specific features that absolutely require WordPress to be on 5.4 at this time. Frankly, that doesn’t matter at all because the issues with upgrading are far less related to where WordPress is going and more directly the cause of where servers have been. Most hosts grow organically, servers being built following a process and then (eventually) via an automated tool. But because of that, a lot of old servers and operating systems don’t lend themselves well to upgrades because they’ve been built rather … higgeldy-piggeldy one might say.

It’s that history, the drama of people not seeing the future 10 years ago, that puts many hosts in a position where upgrade is actually going to mean moving users to a new server with new features. And that is not something to be done lightly. We can’t just pick people up when we want and move them. There will be downtime, there will be outages, there will be delays. And because of all that, these moves take longer than you want.

This is not to say the hosts aren’t doing the right things, just that they take longer than anyone (especially the host) would like. And believe me. No one wants PHP 5.2 gone more than a web host.

5 January, 2015
Mailbag: Where Do I Start Learning?

Kenny flatters me (though I think have better hair than Trump) asking this:

If I wanted to be a millionaire, I’d ask Donald Trump, which is why I’m asking you…What would you recommend as a learning path or in specific resources to gain foundational knowledge and expertise in WP/ hosting? Knowing what you know now and if you had to start from the beginning today, what would you do? Thank you.

The same place I did when I started.

I would download WordPress, install it, and use it every day for a while. Understanding how to use the product tells you more about how it works than almost anything else. All problems you have will, eventually be traced back down to code if that’s how your inclined, or documentation, or just plain understanding.

See, how I got good at WordPress was because I used it, I had problems, and I decided to learn how to fix it instead of relying on the kindness of strangers. If I had to do it all over again, I’d do it the same way because it let me learn at my own pace and in my own way. WordPress was a place where I could (and still can) sit and study how and why things work, ask questions, get answers, and learn from them.

How did I learn about hosting? Same way. I had problems and I asked my host. “This code I want to use says it needs PHP 5 and my server is PHP 4. How do I change that?” It was really that simple. They moved me to a new server for PHP 5 and I looked up why that was necessary. That was how I learned what a nightmare server upgrades are and why they’re so complex.

The secret to it all is I never said “It should be easy to…”

Weird secret, right? Well, how many times have you heard someone say “It should be easy to fix this problem!”

It’s not. It never is. If it was, we’d be done. It’s always hard or weird or prone to conflicts, which is why that wasn’t a statement I made. Instead I asked myself “Why isn’t this easy?” I wanted to know what made things hard.

But I’m blessed with a natural curiosity about the world and I want to dig into things to see why they do what they do. This is especially true when I’m trying to use them and they, for whatever reason, don’t do what I want. That spurs me forward into research and reading and understanding and then writing. Eventually I get to the coding part. Because isn’t that how we all learned in the beginning? We wondered and we played and we learned by doing and experiencing.

If I did it all over I’d do it the same way and use the heck out of WordPress.

2 January, 2015
Take my SPDY, Please

When I upgraded my server to Apache 2.4, I lamented that the choice had killed any ability I had to run SPDY. This led to me installing an Nginx proxy on my box and being pretty happy with it.

I wanted to like the idea of SPDY on Apache, but there were serious issues with mod_spdy. First of all, it’s incompatible with Apache version 2.4. That sucks. While someone had forked it, issue number two made me worry. You see, mod_spdy requires OpenSSL version 1.0.1c and modifies mod_ssl. If it was Google’s suggestions for it, I might be okay, but now we’re talking about trusting some random person out there. No. Finally the dippy thing hadn’t been updated in years.

Someone finally shamed Google enough, because earlier this year Google gave mod_spdy to Apache. The plan is for it to be a part of Apache 2.4, as well as the future 2.6/3.0 world:

Being a part of Apache core will make SPDY support even more widely available for Apache httpd users, and pave the way for HTTP/2.0. It will also further improve that support over the original version of mod_spdy by better integrating SPDY and HTTP/2.0’s multiplexing features with the core part of the server.

Finally!

Except not. Sadly, there’s been very little activity since this summer. You can look at the code on Apache SVN and mod_spdy hasn’t been touched in 3 months. It’s sad to see this linger. I had high hopes that Apache would jump and run, but they haven’t even made it work with Apache 2.4 yet.

I’m not going to hold my breath for parity on this one just yet.

31 December, 2014
Themes Suck

“I need help finding a good theme!”

No question will make me want to run screaming more than that. Not even the dreaded “Should I use Multisite?” question is as bad as that one, because picking a theme is hard!

I mentioned to my coworker that it’s like trying to find a needle in a pile of tainted needles and the reason is really simple. Themes are ‘easy’ to code and hard to find the right one.

A theme is personal

What you think looks good is different from what I think looks good. I love larger fonts for readability, but at the same time I don’t like too much whitespace. I don’t want an overabundance of clutter, but a single column isn’t always what I think looks ‘good.’ I’m fond of a sidebar. I also like certain color schemes, like aqua and blues and greens, but not others like yellows. That means I’ll want a theme that either matches my colors or lets me change them easily.

I need to know what you like before I can help you out.

A theme meets your needs

What you need out of a theme is different from what I need. You may need things for custom post types built in. I don’t. I may want a grid layout for content. You don’t. What you need is very specific to your vision of your site, and picking out a ‘good’ theme to match that isn’t easy. But you have to know what you need before you start to pick out a theme. Asking me ‘what’s a good theme for my comedian website?’ is not a simple answer. What do you want to do with it? Do you want to sell things, show your gigs, blog, have a survey?

I need to know what you need before I can help you find something.

A theme will cost you money or time (or both)

What you can do and what I can do are different. I hate coding themes. I am happy to pay the right people to do it for me. That said, I’m happy making a child theme or forking a theme, or using a plugin to extend it. I’m willing to spend money and time to make a theme suit me, because I look at them and get ‘most of the way there’ with pretty much all themes. No theme has ever been 100% perfect for me ever, but I think that’s okay. A theme that is the right shape will be enough, provided I can extend it (or pay someone to do it). I may need support, and I need to make sure I get that, so if I pay for a theme, I want to know how far down the rabbit hole they’ll go with me.

I need to know your budget before I can point you to the right place.

A theme represents you

Who you are and who I am are different. This is the most wibbly-wobbley part. Your theme shows off ‘you.’ If you, like me, have issues visualizing that, it’s hard to find the right theme except to say “You’ll know it when you see it.” But understanding yourself, your likes and dislikes and the aspects of you that you want the theme to show off will help you pick the right theme. You may not know it all to begin with, but start making notes. When you see something you love, think about why you love it. When you hate something, do the same. Make a list of what you love and hate, what features make you wince and which ones you crave. Understanding why you make those visceral reactions to a theme helps you understand you.

You need to know who you are before you ask anyone to help you find a theme.

Why do you love (or hate) suggesting themes?

Do you feel like I do? Let’s hear why!

29 December, 2014
Mailbag: What Plugins Do I Use?

This was actually a bit of a shill from someone I didn’t know, asking to help him with his own ’roundup’ of various experts. I didn’t reply, mostly because I was super busy and favors like this from random people are low on my list of things I’ll ever reply to. But the question is interesting.

Which WordPress plugins do you use most in the following categories: Seo, Social Media, Commenting, Performance, Captcha and Payments.

Answer to all: None.

Seriously, though. The only ‘Social Media’ plugin I use is Jetpack, and that’s just to push my content to Twitter and Facebook reliably. I don’t use any SEO plugins though when I do, I use WordPress SEO because I trust Yoast. Most of the time, my themes handle SEO for me just fine.

Captcha I never use. I won’t. I hate captcha. Captcha isn’t accessible, as I’ve been saying for four years. Similarly I don’t use commenting plugins because I don’t need them, and I like owning my content. When you put up barriers to comments, you get fewer comments.

Performance plugins are a weird area. Yes, I use plugins for that, but it’s got to do with what I installed on my server. I have memcached and ZendOptimizer, so I use a couple things for that. Zach Tollman’s memcached object-cache.php plugin and Batcache. But really most of the work is on the server already having the backend required for those. That’s the same reason I have Google Pagespeed on the server.

Payments… I don’t know how I could answer this. I use Easy Digital Downloads for sales, and I handle payments through Paypal and Stripe right now. But that isn’t so much a plugin question as a who do I trust with my money question. I’d be using them regardless of if I used EDD or not.

Asking me what I use ‘most’ is a very weird question since I use what’s right for the job I’m facing. If that answer is ‘Not WordPress’ then I don’t use WordPress. So with that in mind, I rarely blanket recommend any plugin out there. I listen to people, what they’re asking, what they mean, and how they sound, and I try to recommend based on all to those aspects. There’s rarely one perfect answer for everyone.

If you think I’m joking, read Chris Lema on the perfect WP shopping cart plugin. There are a lot of choices and decisions and options out there, but you’ve got to know what you really need before you make a choice.

Of course for me, when the choice is between two equally well written plugins, I pick the one where I’ve worked with the developers before hand.

26 December, 2014