Category: How It Is

Making philosophy about the why behind technical things.

So Take an Upgrade, Maria!

A year ago I asked how do we solve a DB like Maria, and my friend James and I had a good laugh at the long list of issues.

It’s been a year.

I’ve upgraded to PHP 7.

It’s time.

What about Oracle vs Google?

Oh you heard about that? Google won a case against Oracle about GPL code in Android which I want to be really happy about, but it illustrates a major flaw in the judicial system. To whit: The player with the deepest pockets wins.

That case about Java though, not MySQL, which has been a long standing issue with the Open Source Community. The summary? Well it’s kind of like Prohibition. They can try to outlaw it, but we’re going to do our own thing. Which is where MariaDB comes in. It was a fork of MySQL, made in order to stay free and open. I strongly support open source software and so I change to MariaDB.

What Are The Issues?

There aren’t as many for MySQL 5.6 vs MariaDB 10.x as I’d thought. In looking at that, I determined it wouldn’t really impact my sites or setup. In fact, I was certain none of it would be an issue.

How to Upgrade?

I’m on WHM, so first I made a backup: /usr/local/cpanel/bin/backup --force

Then I went into WHM and said “Upgrade Maria!”

I picked the interactive upgrade since I wanted to see what it was doing. Step one went rather quickly and updated everything. It asked me to check my compiled software (which meant two non-WordPress sites that historically act odd when I upgrade). Once that was done, I clicked ‘next’ and was told I didn’t need to do anything else…

Now what?

I ran off to GTmetrix and checked my sites. I had two that were PHP 7 and they had no real change. I then changed another one to PHP 7 and Maria and checked it, and got bigger gains. Speed was up and everything, code wise, appeared to work as needed.

It was entirely a non-event.

10 June, 2016
Is This A Good Name For Your Project?
If the answer to any of the following is not a ‘yes’ then no, you should not use the name for your project.

Again, every answer here should be yes.
1. Did you Google the name?
2. Did you check if the domain name was available?
3. Did you make sure no one else is using it for a similar project?
4. Did you check for trademarks and copyright conflicts?
5. Did you check it against a five year old and made sure they don’t giggle?
Congratulations! You Have a Good Name!

Maybe.

I do a lot of arguing with people over the idea of ‘how’ to name a project, because people want to make add-ons

For example, if you have written an add-on plugin for Microsoft Word, you can’t name your project “Microsoft Word Super Snazzy Map Add-On” but you can name it “Super Snazzy Map Add-On for Microsoft Word.”

Using a name like “My Product for Other Product” is something I consider common sense. Consider the example of Keurig. If you made an eco-friendly brew cup, you could market it “EcoBrew Pod for Keurig” but you could NOT attempt to market it as “Keurig EcoBrew Pod.” The latter implies a direct relationship to Keurig and may be against the law in some countries.

Being Original Is Hard

I don’t mean to dismiss this. It’s hard to come up with a name that is original, descriptive, and unique. It gets harder and harder every day. Consider that a number of today’s companies seem to have ripped their logo out of a 1989 design book

The Beats logo on the right compared to one found in the 1989 design book Tweeted by Spencer Chen.

Now we have long accepted in logos the limitation of language, letters, and combinations. It’s probably not theft, but it’s something you have to be aware of when a new project is named. Similarly, we accept the fact that naming something that is at once unique while still displaying your own flare is problematic.

I can’t offer you an answer that will fit everything, but I can offer you this. When you pick a name for your project, regardless of if you’re the big fish or the little one, it’s your responsibility to check if something even possibly related is already there. If you happen to name things at the same time, that’s an honest mistake, but if you know better going in, don’t be the bad guy.

What About The Bad Guy?

What happens, though, if a year or three down the line, you get an email telling you that your product is infringing on trademarks?

You have two choices:
1. Fight
2. Flight
There are weird issues in the US with Generic Trademarks. Like did you know heroin, thermos, and aspirin are genericized? That means we use the words ubiquitously to mean the general concept of ‘a thermos bottle’ or ‘that horrible drug’ without reference to the trademark holders.

That said, there are terms that are not generic, and yet we use them similarly. Band-Aid, Kleenex, Post-It, and Google. Yes. Google. Google actually has gone to the point of downranking you for terms like ‘googling it’ because they want to protect their brands.

So what happens when you get that email from Johnson & Johnson, telling you that your product “Mika’s Band-Aid for WordPress” is a trademark violation?

Fight or flight.

You can argue that no one would logically think that ‘band-aid’ in this case would ever be confused for their product. Or you can say “Oops, my bad. I was totally trying to leverage the term band-aid.” You can also ask them “Are there circumstances in which I can rebrand this so as to make it clear I’m not intending to violate your trademark while not losing the ground I’ve made with my product?”

I will suggest, if you chose to fight, to get a lawyer who specializes in trademark law.
6 June, 2016
SSD: An Anecdotal Journey

After I upgraded to Ogra, I noticed that my server’s load stats were a little janky. They were pretty high, actually, bouncing between .5 and 2 all the time. Now this isn’t really all that bad, but as I looked at my server, I realized I was paying a little more than I needed, since I’d cut down on space by offloading backups better.

This matters because I needed only 50G of diskspace (I only use about 30 right now for all the sites), and while I did want 2G of RAM, I could easily switch to an SSD on my hosting plan. It was cheaper, and it was as easy as pressing a button. I’ve never really gotten to play with SSD for this site, so I thought “what the hell” and pressed the button.

A weekend later…

The five minute load average shows a massive drop. It’s incredible. The red and blank spots are where I was running the actual migration process and disabled monitoring for a bit. Literally all I did was reboot the server and the move it to SSD. That’s it. It’s insane when you think about it.

By the way, I saved disk space by offloading the backups to Amazon S3. Amazon costs me about $3 a month, and while I detest their interface, the integration is built into WHM. I have an open feature requests to allow arbitrary CEPH destinations as backup so please vote for that if you like the idea.

SSDs had the bonus of changing my backup from taking 2 or 3 hours to taking 15 minutes.

Anecdotally SSD is an incredible improvement of the old bog hard drives.

3 June, 2016
Why I Don’t Use Git Flow Anymore
Please don’t get me wrong. I love git-flow. I think it’s great. But it was great to teach me how to use git. It taught me not to use master for my development, and how to make branches and all that. Git Flow got be in the habit of doing good things and testing and showed me how to work with multiple projects. It was a great crutch to get comfortable with the ideas of Git that (for a long time) confounded me.

But I don’t need it anymore. Instead, I do things very, very simply and my flow is as follows.

$ git checkout master ; git pull

I always start by assuming I’ve forgotten something and need to sync up. This works for me, since I run on two computers.

$ git checkout NewProject

Once I’m in the new project, I start making all my edits, add my code, etc. Now here’s where I get a little silly. If I’m working on my own stuff, it’s Coda, always, so I’ll constantly ‘commit all changes’ and fill in my commit messages and then cancel out. I do this over and over until I’ve reached a point where I think “This code is ready to be tested.” Then I commit for real.

This means my commit logs look like this:
```
Convert Font Icon to SVGs

 - Add new images for social media
 - Optimize CSS for pagespeed
 - Remove unused function.php file
 - Add shortcodes

Fixes #1234
```
There are other ways to do this, of course. I’m a huge proponent of keeping change logs but a commit message should be useful too.

It’s too easy to put in this: git commit -m "Adding new icons"

While it’s more time consuming, just use git commit and put in a good message like I did up at the top. Now, this is not new. A hundred people have all said this before, but it bears repeating.
- The first line is your subject, keep it to 50 characters.
- Capitalize the subject line but don’t use a period
- Use the imperative mode – “Add new icons” and not “Adding new icons”
- Leave an empty line between subject and body
- Explain what you did in the body, keeping lines to 72 characters
- Bullet points are okay – use a space before a hyphen for best compatibility
- Reference any issues at the bottom – “Fixes: #123” or “See Also: #456 #789”
If, like me, you commit and then, before merge, realize you have changes, use git commit --amend to add your new changes to the existing commit.
25 May, 2016
Encrypting Source Code Doesn’t Make It Safer
I’d love to think that’s all I have to say on the matter, that you all will read the subject, go “Yup!” and we’re done.

The reality is that I have to argue this, regularly, with people.

Here’s the code from a plugin out there:
```
<?php ${"\x47L\x4fB\x41\x4c\x53"}["w\x73\x78\x6e\x69\x66\x69\x6f\x71\x6c"]="\x73l_s\x65arch\x61bl\x65\x5fc\x6f\x6cu\x6d\x6e\x73";${"\x47L\x4fBAL\x53"}["\x66\x6b\x78xg\x63\x6ap\x68\x6d\x6ft"]="\x73\x6c\x5fdb";${"\x47\x4c\x4f\x42AL\x53"}["\x65\x62\x67\x79\x6b\x66\x64"]="\x69\x73\x5f\x73\x6c\x5fca\x74e\x67\x6f\x72\x69\x7a\x61\x74\x69\x6fn_\x63\x6f\x6c\x75\x6dn";${"\x47\x4c\x4fBA\x4c\x53"}
```
The whole file is like that. The developer explained it was done that way for ‘security’ — it would make things harder to hack. I pointed out that’s simply not true.

Here’s what having encrypted, hashed, packed code does:
1. It makes your build process take longer.
2. It adds another failure point into your code.
3. It makes it harder for the end users, other developers (who write plugins), web hosts to debug, and you to debug.
4. It makes you look like a developer with evil intents.
5. It sets an expectation with users that this kind of code is ‘normal’ in WordPress.
Recently Sucuri posted about a redirect hack that works by putting junk code in your header.php file which looks rather similar:

The issue here is that an end user, your normal WordPress user, cannot tell the difference between the somewhat safe code I quoted before and this code. They see ‘gibberish’ where as I know they can use a hex decoder to translate ["w\x73\x78\x6e\x69\x66\x69\x6f\x71\x6c"] into ["wsxnifioql"] … which is still pretty terrible.

Well written code, well named functions, are self-explanatory. You see a function called redirect_404_pages() and you have a pretty good idea of what it’s for. You see a function named wsxnifioql() and good luck knowing what the heck that’s for. This goes back to the claim that the code is more secure. It’s not. It’s needlessly complicated, and as I shoed with the hex decoder tool, it can trivially be decrypted and read.

So what is the real point of hiding your code? Who are you trying to protect? What’s ‘safer’ about any of this?

The answer is that it’s about about you, you, you. You don’t want someone to take your great idea.

That’s it. And that’s foolish.

WordPress is GPLv2 (or later). Furthermore, to be hosted on WordPress.org, your code cannot be encrypted or hidden or otherwise non-human-readable. The basic reason is that WordPress’ success is due to it’s understandability and extendability. Anyone can read WordPress’ core code, parse it, learn from it, and enhance it. When you take that away from users, you isolate your code and prevent people from extending it.

This person, this developer, charges upwards of $1000 for the add ons to their code. Yes, a plugin that costs over a grand. It sounds economically sound to try and lock things down so people don’t steal their intellectual property. We can all understand that impetus. I support it. I also feel that part of being in an open source community is being aware of how your actions impact the world at large.

Because WordPress is open and because there is a standard expectation of non-encrypted code (except by evil-doers), the burden moves to developers to not hide their code that is installed on users’ servers. The code that is deployed to an end-user is expected to be human readable. This comes at a risk. I have a copy of a theme I bought, and I could give it away to anyone I wanted. They may not get updates, which means I have to be aware of the risk I’m introducing to my friends when I give them something like a premium theme or plugin.

Similarly, what are the risks of telling people it’s okay to install plugin code in uploads instead of the plugins folder? What are the risks of allowing people to think that encrypted code is generally okay? In and of themselves, neither action seems particularly dangerous. PHP code is PHP code, right? If it runs, you’re good. But the reality is not so. By installing code in uploads I’ve made it so it’s no longer fully protected by WordPress and ‘standard’ security practices. I’ve also made it riskier that my code would even run, since many hosts prevent executable code from running out of that folder for security.

So how do I meet the (assumed) criteria of not having someone rip off my code?

You don’t. Your machinations aren’t preventing it now, and they won’t prevent it tomorrow. Hexcode is easily parsed. Even the Zend framework has to be able to be reversed to be run, so a dedicated person will always find a way around it. And the majority of your users aren’t going to be the problem. It’s those extremes. So what you’ve done is wasted time, effort, and money to annoy the majority to stop the minority. Let people inspect your code. If someone steals it, there are laws to help you handle them. Use them. Theft is theft. The GPL may allow them to take your code, copy and expand on it, but it doesn’t let them violate your copyright.

All the work you’re doing to hiding your code is about as useful as preventing right-click on images. It doesn’t protect the end users, and it doesn’t protect your intellectual property.
23 May, 2016
PSA: DreamObjects URL Changes

If you use my DreamObjects plugins, don’t worry, I’ll have them updated before September.

What Changed?

As part of ongoing service improvements, DreamHost made a subtle, but critical, change to how everyone accesses DreamObjects. Specifically, they changed the DreamObjects hostname to prepare for upcoming enhancements.

Old hostname: objects.dreamhost.com
New hostname: objects-us-east-1.dream.io

I’m a developer who uses DreamObjects. What do I need to do?

If you were ever using the URL objects.dreamhost.com in your site, you need to change it to objects-us-east-1.dream.io and everything will be awesome.

Is it really that simple?

Not always. For some plugins and code, it is that simple. For my backup plugin, I added in a new option:

if ( !get_option('dh-do-hostname')) {update_option( 'dh-do-hostname', 'objects-us-east-1.dream.io' );}

This way I can later make it a dropdown for people to select as they want.

But for my CDN plugin there’s a major issue. You see, the way it works is that it updates the URLs of images within your posts. It, literally, edits your post content. And that means a change has to go back and fix all the URLs. I had to write some fairly weird code to do this. I’m still testing it fully, and I think it’ll do everything I need, except it’s not going to perfect.

Right now it does it’s utmost best to fix any URLs on a site, however it will only fix the ones for images it can detect are on DreamSpeed. I am aware that some people with a phenomenal number of images manually copied their uploads folder to DreamObjects and ran a command like this:

wp search-replace 'example.com/wp-content/uploads' 'objects.dreamhost.com/bucketname/wp-content/uploads'

Or maybe they used the InterconnectDB script or another plugin. Those people you’re going to have to watch out for and inform in a useful way as to how to fix it.

I’m an end user. Do I need to care?

Yes. You do. Do not try to fix it on your own just yet. Not until the plugins you use have updated and said they’ve corrected the issue. Then read the FAQ or any alerts to make sure you don’t need to do anything else. If you’re not using DreamObjects as a CDN, this should be pretty painless.

If you did, or if you moved it all manually, you will have to do it again before September 5th, 2016 or all images will break.

Thankfully, if you’re on DreamHost, you can run the following command:

wp search-replace objects.dreamhost.com objects-us-east-1.dream.io

That will upgrade everything for you. If you’re not, you’ll need to use the search/replace tool of your choice.

Again: WAIT until any plugin you use for this has been updated. I personally contacted everyone in the WordPress.org repository and informed them about it, but since I know that’s not perfect, I’m doing this too.

This sucks!

I know. It does. But I don’t see a better way around it.

When will your plugins be updated?

Before the end of May. I just want to test it on as many large sites as I can find.

20 May, 2016