Author: Ipstenu (Mika Epstein)

Better Headers
I review a lot of code and by extension read a lot of source code files. One of the things that drives me to distraction is trying to sort out what a specific bit of code is licensed. Now, I don’t care about GPL the way a lot of people do. When I’m reviewing plugins for WordPress.org, I only care in that a repository requirement is that all code in your plugin is GPLv2 (or later) compatible. If you’re not hosting on WordPress.org, I only care if I want to use your code and I need to see what the possible restrictions are.

While I’m mostly talking about JS files here, I wish people would remember to put in the right header information for all their code.

Headers I Hate

It absolutely kills me to see this as the header of a JS file:
```
/*! My Awesome JS - v1.0.0 - 2015-01-14
* http://example.com/myawesomejs/
* Copyright (c) 2015 John Doe */
```
Actually, what’s worse is this:
```
/*! My Awesome JS - v1.0.0 - 2015-01-14 */
```
This means I know nothing about your code license. If I have the URL, maybe I can be really lucky and go there, see a link to your full source code, download, open the zip, and maybe you put a license file in there. Most often, however, the answer to that is not. With a lot of newer projects, they link to Github, which is great since I can go and look for that LICENSE file. Github even prompts you about making one when you create a project. Love ’em

Realistically, if you’re releasing code for the world to use then you’ve got to license it. Even if you don’t care about licenses, putting a public-domain clause on your code means it’s free for all nations to use is so easy a caveman could do it.

Headers I Love

Okay, so if you’re making your own JS, what do I think your header should look like?
```
/**!
 * My Awesome JS v1.0.0
 *
 * @copyright Copyright 2015 John Doe
 * @author    John Doe
 * @link      http://example.com/myawesomejs/
 *            http://github.com/johndoe/myawesomejs/
 *
 * @license   Use permitted under terms of CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
 *            https://creativecommons.org/publicdomain/zero/1.0/
 *            http://example.com/myawesomejs#license
 */
```
That’s it. Obviously that’s the non-minified version. If I wanted a minified version it would be this:
```
/*! My Awesome JS v1.0.0 | (c) 2015 John Doe | example.com/myawesomejs#license */
```
There’s an argument to be made about minification and how I shouldn’t have any headers in order to compress the code to the extreme, but let me show you the jQuery minified file’s header:
```
/*! jQuery v2.1.3 | (c) 2005, 2014 jQuery Foundation, Inc. | jquery.org/license */
```
It covers your license and your copyright information there in one go. It protects your interests and makes it plain for everyone to see what’s going on, how to get in touch with you for changes, and all sorts of awesome open-source things.

Picking a license…

In the above example, I picked CC0 for a reason.

That’s the ‘unlicense’ I think you should be using if you’re releasing code to the world and don’t want to be bothered by the hassles of any informal sort of license. Sadly, not declaring a real license can cause problems outside the United States. Here, we would interpret the license based on what the author intends, which is already a bit of a dangerous idea, and presume a license means exactly what it says, which makes them non-copyleft free software licenses and compatible with most other free software licenses. It may make it outright incompatible with commercial software. And worse, other countries have stringent views on the copyright aspects of these licenses.

Now that said, my other favorite ‘For god’s sake, just take my code’ license is the WTFPL license.

For me, if I want to release code that really is free and can and will be used by anyone, I pick the CC0 or WTFPL. It covers this for everyone, as far as I’ve been able to tell, even commercial.

The GNU have their own license recommendations of course, and Jeff Atwood has a good post about picking a license that explains how most of us feel about the headache. Of course, if you’re forking someone else’s code or building on their work, check the license they used to make sure you don’t violate it with your new license. Not all licenses are ‘backwards compatible.’
14 January, 2015
Listing Everything on DreamObjects
I was asked about listing everything in a DreamObjects bucket, which is practically the same thing as listing everything in an Amazon S3 bucket, just on a different server.

This isn’t as easy as we’d like, because while there is a nice Amazon S3 PHP class we can use (and I forked it and flipped it to be a DreamObjects PHP Class), telling people they have to download the S3.php file and then make this separate PHP file is a little annoying.
```
//include the S3 class
if (!class_exists('S3'))require_once('S3.php');

//AWS access info
if (!defined('awsAccessKey')) define('awsAccessKey', 'MYACCESSKEY');
if (!defined('awsSecretKey')) define('awsSecretKey', 'MYSECRETKEY');

//Bucket Info
$bucketName = 'MYBUCKETNAME';

/* STOP EDITING HERE */

//instantiate the class
$s3 = new S3(awsAccessKey, awsSecretKey);


// Get the contents of our bucket
$bucket_contents = $s3->getBucket($bucketName);

foreach ($bucket_contents as $file){

    $fname = $file['name'];
    $furl = 'http://'.$bucketName.'.objects.dreamhost.com/'.$fname;

    //output a link to the file
    echo '<a href=\'$furl\'>$fname</a><br />';
}
```
I know, it’s not too terribly complicated, but it is annoying to make two files for that, and my DreamObjects listing page is very barebones. You could style it with CSS, make it show the image, make it show in a grid, or even show the file size and have it pop up in a new window.

It does highlight one of my issues with CEPH (AWS whatever) storage, and that it’s still not quite friendly enough. It dumps us back to the old days where we FTP’d our images up to a server and then manually crafted our links. Certainly there are plugins for WordPress that can help us with that, but in general it requires knowing code (or where to get the code) in order to display content.
12 January, 2015
MailBag: Why Do You Do It?

Zaman dropped me a year end note. He’s been asking people, interviewing them, for a site, and had three questions about why I do what I do (and a little bit of how). It deserved a public reply.

1.You have been actively volunteering at WordPress support forum and with your solutions individuals and companies save big chunk of money. Your family and Job at DreamHost are your top priorities. Then your priority becomes the website you run (halfelf.org). You still manage to take out couple of hours to hit WordPress forum. You mention in one of your blog that some people volunteer because they enjoy it and some do it to master skills. What drives you to volunteer at WordPress?

What drives me to volunteer at WordPress is little more than a bit of technical socialism. I give back because I get back, and it seems only logical and fair and just to make the time to do these things. Admittedly, having my job actually be know WordPress’ ecosystem and keep a good relationship between WP and DreamHost makes this far easier for me than most. But at the same time, I was doing this before it was my job. And I did it because I could.

I have a hard time explaining the need to give back to people, because it’s something you either understand in your heart or you don’t. Call it a random act of kindness to the universe, I help with WordPress because I can, because I enjoy it, and because it makes me feel good to do it. I won’t deny I get awesome emotional props from doing it, a feeling of absolute satisfaction and pleasure knowing I can help people, but it’s really just that. I like doing it. I make the time for it.

2.Your insights on halfelf.org are remarkable and the blog “whose responsibility is it” in particular draws my attention. You convey it is the business owner responsibility and not the WordPress core or Webhosting Company to perform due diligence before they install plugin’s. You also call out there is a need for more security experts. Is there a shortage of wordpress security experts in general or in wordpress public support forum?

Do I think there’s a shortage of WP security experts? No, I think there’s a shortage of security experts in general. I think the masses of people would rather do awesome and create awesome than study security and delve into things. The fact that I can think of a hundred ways to socially engineer going to see a movie for free without breaking a sweat, the fact that someone like Frank Abagnale was able to pull off what he did underscores the issue.

At our heart, humans want to trust. We want to believe people won’t screw with us. And when you factor in just how complex computers and code can be, of course we have faith that the people who write code are writing the best code to their ability and know what they’re doing. And we have faith that, when a bug or a security flaw is reported, people will fix it as fast as they can.

WordPress complicates this, since there are so many plugins and themes out there that there isn’t a centralized place to reply a problem. Even if there was, there’s no way to enforce the bug is fixed, and there’s no way to be certain everyone will upgrade. Just look at the nightmare from the RevSlider situation. Once you add in the world of non wordpress.org hosted code, it’s impossible to maintain any control.

If more developers were security conscious this might be less of the case, but it’s a problem in Open Source. The Heartbleed vulnerability is a prime example of that. One change, missed by many. It’s not just WordPress, it’s how we develop in Open Source. The speed of our work makes issues like this sadly more common and possible. So we need more people who love hacking into things and breaking them and then responsibly passing on fixes to make things more secure. I do feel that Github and sites like it are actually a great step forward. I can file a pull request with a fix and pass on the help in that way.

This does require hobbyists to step up and be a bit more of a true developer, but they have the most to gain from it in the end.

3. Examining and reviewing the plugin software may not be possible for small businesses. Do you have a list of plugins that should be avoided or a checklist that should be considered before installing the plugins? I am not asking if you to list here. May be an article in halfelf.org will be very useful for WordPress community.

I don’t have a list. I can’t have a list. It’s impossible, given the rapidity with which plugins are updated, fixed, released, and closed. It’s just not feasible. I tried, at DreamHost, to keep tabs on plugins like that for about a week. Then I gave up. It would be a full time job.

And I disagree it may not be possible for a small business to have an audit done on their plugins and themes. They can hire someone. It would be expensive, certainly, but frankly I find the alternative untenable. If you had a physical store, you’d pay to have a security audit once in a while, if only by your security company. This too is a part of running a business. Period. You just can’t dismiss it as ‘not possible’ when it’s your career on the line. Complicated, expensive, and annoying I will grant you. But you have to do it. Even if it’s just once a year, you’re a step or ten ahead from where you were before.

I’ll say this, however. I would expect someone like Pippin over on Easy Digital Downloads to be reviewing all add-ons he lists on his site. Anything he sells, certainly, but also this big list of free add-ons should be checked for basic security before being listed. In this way, a small company can know they’re reasonably secure with that suite of plugins.

Are there plugins that should be avoided? Sure. I suggest you avoid anyone you can’t figure out how to contact in case of a security issue, anyone who encrypts their code so you can’t read it, and anyone whom, when you do contact them, blow you off.

9 January, 2015
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