Author: Ipstenu (Mika Epstein)

Housing Large Media Files
For the most part, the WordPress media library is fine. It falls down when we start needing to upload large files, though, for a variety of reasons. When we look at files like large PDFs or movies or podcasts, it’s really not a great solution to upload through WordPress itself. It’s slow, it’s clunky, and worst of all, those large file downloads can slow your site.

The ‘right’ fix is to offload large media to servers that are built for this sort of thing. And in this case, I’m talking about Amazon AWS or DreamObjects.

Of course, if you search for solutions like this, you’ll be disappointed. You will mostly find plugins that are geared towards syncing your media library with the cloud services. To be honest, the more I think about doing that, the less I feel like it’s a sustainable idea. Unless the CDN is super fast, it could actually make your site worse off by adding another domain to download from.

I Don’t Trust Simple CDNs

I’ve always been skeptical of CDNs in general. When there’s a shared library, it makes sense for everyone to call the same library. That keeps the world in sync. But your own media? The reason a CDN is good is that you can distribute your content across multiple locations. Provided you can actually, you know, do that. And keep them all in sync.

Before hosting, I worked at a bank, and one of the headaches we had was pushing software updates across multiple servers and locations. After all, you can’t just upgrade the Chicago servers and not the LA and Atlanta ones. Plus you have to do them all at the same time, or make sure Jane in Idaho isn’t in the middle of depositing money when we reboot her server.

Knowing how crazy all that is, I worry about keeping data in sync across all the servers. What happens when media is updated? Is the CDN built so that my primary location properly triggers updates for everything else, and the data is updated? No matter what, I’m sure I’ll end up with some data out of sync for at least a little while.

In short, CDN synchronization isn’t simple and anyone who tells me it is, is selling something.

So Why A CDN At All?

Big files.

The goal of a CDN is to speed up delivery of content without slowing down your website. For most images on a website, this isn’t a huge issue. But for those big files, it sure is. And uploading them to the could means three things:
1. No lost disk space
2. No lost bandwidth (if someone’s watching a movie for example)
3. No lost speed (see the aforementioned movie)
The rest of your CDN ‘needs’ can be handled properly by caching. I prefer server side, but as you like it. This means if I upload my large files to the CDN, I can link directly to them in my post content. Everyone wins.

Except Uploading Sucks

The common solution is to manually upload the file via a client like Cyberduck or Transmit, copy the URL, and then paste it into a blog post. Yuck. What I need is a file manager for the cloud. And that doesn’t seem to exist for WordPress.

So I made something. DreamHost Objects Dropzone lets me upload files to DreamObjects, through WordPress, without touching the file server at all. It’s not perfect. It can be slow when trying to get stats on all the items in a bucket, and I don’t quite have an interface to make it easy to insert links and content into posts. Yet.

Something to look forward to though.
14 September, 2017
But Seriously…

In reviewing people’s code for WordPress, I’m constantly struck by the lack of foresight people put in to their success. When a developer makes it clear they intend to run a business or have some modicum of popularity, one would expect them to put a bit of effort into it. Instead, I’ve watched people make the same mistakes over and over. And they complain to me about why their plugin is failing to become “the one” to use.

The answer always seems to surprise them. People don’t take them seriously because they are unprofessional.

WordPress Basics

First of all, no one magically knows all this when they start. So it’s alright not to know. However. If you’re going to go into business based around anything, you need to learn the rules of the road. Take the time to learn that it’s WordPress with a capital P, that there’s a foundation, a trademark, and, yes, that you cannot use WordPress in your domain name.

If you were going into business with PayPal or CitiBank, that’s all legwork you are expected to do beforehand. This is a business, and when you don’t take WordPress seriously, you won’t be taken seriously by WordPress.

SEO Basics

Pick a good domain name for your business site. Make sure you’re not violating a trademark or copyright. Pick a good name for your product. For the love of all things whiskey, don’t name your slider plugin “Slider” and stop using “Mega” as a prefix for anything. Remember, the name of your product cannot infringe on anyone’s trademark. So while “Shoppable Cookie Cutters” is not trademarked, “Shoppable” is. And yes, you’ll get a C&D for being similar.

Write good copy for your website. Have a clear mission statement, a human about page, and some semblance of being real people. This extends to your documentation. Write it. Write it good. Write a readme that tl;dr pitches your product, explains why someone needs it, and details out what kind of services it uses (if any). Remember that most of your SEO comes from humans. Write for them.

Community Basics

The OpenSource community in general will help anyone who asks politely. So be polite. Be respectful. Be courteous. Be generous. If people are helping you for free (and most of them are) then thank them and ask how to pay it forward. Offering services, answering generic questions, educating users, or even just publicly thanking volunteers helps.

The community also includes your users. Respect them. Especially when they’ve gone off the deep end and accuse you of wild impropriety. Your plugin hacked their site? Probably not, but treat them with respect and kindness. It goes a long way to inspiring the volunteers to back you up. But also don’t spam your users with a million in-product reminders to review your product, give it five stars, or otherwise distract them from actually using your plugin.

Universal Basics

Do your research. There is nothing on this earth that is a get-rich-quick, so study what you’re getting into. Don’t jump in blindly. Make sure the community is one you can work with, that they have ethics similar to yours. And if not, make absolutely sure you really are comfortable with going for the money.

Set your expectations realistically, and be willing to have them reset. Take your work seriously, don’t make excuses like “someone else did this first!” Own up to any mistakes or missteps you make. Remember, you absolutely will screw something up along the way. The measure of success can be found in how you handle it.

12 September, 2017
Be Nice to Future You

Sometimes the brunt of my education of developers is a constant reminder to be nice to the future them. Future you, or Drunk You if you’re Otto, loves you most when you take the time to prepare things for them. A little bit go foresight and planning will make life so much better for future you, and I’m going to break down six tips to make you love yourself in the future.

Document, Document, Document

Yes. Document everything. Did you make an API for your system? Document it somewhere everyone can get to. For my LezWatch TV project, I painstakingly documented out all of that, plus how the git repositories worked, how they deploy code, and how to get access. This is for something that two people work on. But by documenting it, we all know what to do! The better my documentation, the less likely I get a panicked message from my cohorts in crime.

Make Good Commit Messages

I’m terrible at this when it’s for personal use (the number of commits that are ‘I am stupid’ cannot be counted), but at work I’m pathological about a good subject and a descriptive summary. I want someone down the road to know what the patch does, but also why I did it.

icons: Add new icon set

Add 17 new icons from LIBRARY. This adds support for iconography with job descriptions, as well as better defaults for taxonomies and categories.

It’s not complicated, but it’s helpful when someone wonders “When did we add those new icons?”

Inline Document Weird Stuff

One of my coworkers is great at this. Ben litters his code commits with them, and I’m sure some people find them annoying but I see them as helpful and amusing. Sometimes he puts in “I hate that we do this, but I needed to pass X.” That tells me two things: First, this code could be better. But second, I know what he’s trying to do and generally why. He’s given context to the situation, and future us will hopefully be able to make this better.

Make Note of To-Do Items

Another great habit is to put in notes, as inline comments sure, but also in the documentation. I’ve been using Trello in addition to inline comments (usually things like “To Do: Add in a check for foobar”) to make sure that my future plan is known. You want to make sure future you knows where you were going, and those to-dos are your sticky notes.

Follow Existing Project Standards

Okay. I hate this one. But. If your project has a standard, keep using it. The other day I ran into a problem where a new version feature wasn’t behaving the same way as the old one, but only in very specific situations. I walked backwards through the code until I determined a parameter didn’t exist on the new version. I had two options. One was to edit the code to check “If this new version, also…” and the other was to add the parameter to the 500 or so impacted items and then fix my code so it was always fixed going forward.

The project had been using the parameter method for years, so that was my solution. It followed the standards.

If You Have A Plan, Use It

This sounds weird, doesn’t it? It came up when I was reviewing a plugin and noticed that some code looked very ‘generic’ while still being specific. I thought that it had to be a library the company had made for themselves, and asked if that was the case. I explained, if it was an original library they planned to reuse, they should use an if-exists check.

What Are Your Tips?

What tips do you have to make life better for future you?

7 September, 2017
Query Strings vs Static Resources

If you ever do a page speed check on your site, you may have seen the notice to “Remove query strings from static resources.”

What Are They And Why Do I Care?

At their most basic, a query string is any URL that has a ? in it. For example, if you go to a url of https://example.com/?lang=en then that last bit is the query string. It’s job is to tell the browser to pass on specific information to the website. It’s essentially a variable that will be read by the website or the browser.

A static resource is a file used by a website that doesn’t change much (if at all). These are usually images but also CSS (style sheets) and javascript files. These resources can be stored on web servers, proxy/CDN servers (like Cloudflare or MaxCDN), or even a web browser, which makes your sites run faster.

However. The explanation is that browsers don’t cache anything with a query string. Which means, yes, if your static resources have one, they won’t get cached.

Or will they? (It’s complicated.)

Why Do My Resources Have Query Strings?

If query strings break caching, why would anyone have them? Because we don’t always put version numbers in our paths for common files. For example, in WordPress if you call jQuery (a common javascript library), you’re calling a path like https://example.com/wp-includes/js/jquery/jquery.js and that has no version number. But WordPress has certainly updated that a number of times.

In order to make sure that jQuery gets properly cached when you upgrade, WordPress adds a query variable like this: https://example.com/wp-includes/js/jquery/jquery.js?ver=1.12.4

This is important because otherwise when you upgraded WordPress, you’d see a page formatted weirdly and misbehaving, all because the wrong (cached) jQuery was loaded.

Should I Remove The Query Vars?

Maybe.

Yes, allowing your resources to be cached will make your site faster, and it will get you a higher score in those page speed checks. At the same time the speed benefit is pretty low compared to the dangers of those files not being properly updated. Features on your site will, literally, cease to function.

So you’ll need to decide for yourself which is more important.

5 September, 2017
Is This A Good Idea?
I’ve joked about this a few times, that I should go into business telling people if their web idea is a good one or not. The prices would be simple.
- $25 – A quick yes or no.
- $100 – I’ll tell you if it’s dangerous or possibly illegal.
- $500 – Details of everything.
While I doubt anyone would ever actually pay for that, let me tell you some things I think are bad ideas for the web, and why.

Obvious Bad Ideas

Excluding the whole “Facebook but for pets!” and “Uber but for Pizza!” ideas, and dismissing every single ‘disruptive’ concept out there (seriously, no they’re not), some ideas are really easy to point at and say ‘this is a bad idea.’

If you’re thinking about making something new for WordPress, before you start coding, please use google. Because the first kind of bad idea is the idea that’s been done before, ad nasueum. For example, sliders, snowfalls, BMI calculations (actually ANY sort of calculators including loans), ‘simple’ contact forms, and Google Analytics.

These are bad ideas because they are overdone.

If it’s been done more than 10 times, and you’re not introducing something totally new (this includes the fellow who made a ‘login logo slider’ – no, it wasn’t new), then file it away as a good experiment. Write the code, but don’t publish it.

Illegal/Dangerous Ideas

Depending on how often you hear me rant, you may or may not be surprised to find out how often people write code that’s illegal.

Now hold on. Before a single one of you says “But the GPL!” let me remind you. The GPL doesn’t make things magically legal just because it’s open source. You can use GPL code to break laws (like, say, make a child porn website), and while that’s fine for the GPL, it’s still illegal.

On a less creepy but still illegal note, the Yahoo! finance APIs aren’t actually legal for you to use in your code. Yes, I am well aware of the number of people who make packages for it. I’ve actually spoken to Yahoo about this and the way they explained it was this. Their Finance API is for your personal use. You’re not meant to use it to retrieve data for apps (and yes, plugins are apps) or any third-party usage (again, plugins). Also they do make it pretty clear with this comment:

By accessing the Yahoo! site, you agree not to redistribute the information found therein.

A lot of public APIs have these restrictions, including Airbnb and even some Google APIs (finance again). And using them without checking the terms of use and verifying they’re allowed to be used in your situation puts you at risk for breaking the law and that is dangerous because, in the case of a plugin, it’s not just you who pays the price.

Ignorant Code

Really the magic of everything, the answer to all ‘is this a good idea’ questions can be found in this. Did you bother to do the research first? And no, I don’t mean did you do market research (though that’s a good idea too).

Did you check if the idea existed already? Did you check if the tools you want to use permit that kind of use? Did you read the terms of use of any service? Did you listen to your gut or not?

Think first. Look before you leap. And above all, please don’t make yet another snowflake tool. No one actually likes them.
1 September, 2017
Loading Common Libraries Smartly
When you’re writing code, there’s a desire to not reinvent the wheel. This is a good desire. If someone else has made the code you need, using it is a better use of your time. But there’s a right way and a wrong way to include those common libraries, especially in WordPress themes and plugins.

PHP Is Dumb

Okay, PHP isn’t dumb, but it’s a very top-down/left-right kind of language. The whole reason we tell people to name functions and classes uniquely in WordPress plugins and themes is that if two people name a function the same thing, PHP gets dumb and errors, telling you it can’t define the same function twice.

This means that commonly used PHP libraries should also be uniquely named. To their credit, most do. But still, what happens if two WordPress plugins or themes include the same library? That same error comes back about not defining the same function twice!

What this means is that when using a common library, it’s important that you enqueue it safely and smartly.

Check If The Library Exists

The magic is that you need to detect if the code is already included and not re-include it. PHP gives you two straightforward ways to do this: class_exists and function_exists.

It’s much easier for me when the code is wrapped nicely in a class. Assuming you have a library file that includes the class but doesn’t call it, you can check like this:
```
<?php
if ( !class_exists( 'MyLibraryClass' ) ) {
    include( 'path/to/library.php' );
    $mylibraryclass = new MyLibraryClass();
}
```
If it does include the class (with a new MyLibraryClass() in the library) then you can leave that bit out.

When you have a library that perhaps predates classes, you’ll want to pick the primary function and call it like this:
```
<?php
if ( !function_exists( 'my_library_function' ) ) {
    include( 'path/to/library.php' );
}
```
What About The Weird Stuff?

There are two things I left out. What about namespaces and javascript libraries?

First of all, it’s impossible to check for the existence of a namespace. You see, a namespace doesn’t really exist. What does exists are the structures within the namespace. That means if you wanted to check for the class ClassName in the namespace of MyName you have to do this:
```
class_exists( '\MyName\ClassName') );
```
Second, if you’re looking for javascript libraries, and you’re using WordPress, you don’t have to. Just enqueue it.

The WordPress function wp_enqueue_script() registers the script but does not overwrite and enqueues it.

Now there is a trick to all this. If you use the enqueue command properly, then this always works. By this I mean if you do it this way, it’ll work:
```
wp_enqueue_script ( 'chartjs', 'https://cdnjs.cloudflare.com/ajax/libs/Chart.js/2.6.0/Chart.bundle.min.js' );
```
But… A lot of people do this:
```
wp_enqueue_script ( 'my-plugin-chartjs', 'https://cdnjs.cloudflare.com/ajax/libs/Chart.js/2.6.0/Chart.bundle.min.js' );
```
And that means WordPress will load both chartjs and my-plugin-chartjs which sucks.

Also you don’t need to append -js (or -css) to your enqueues, as WordPress will do that for you.
30 August, 2017