Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • Admins Are Humans Too

    Admins Are Humans Too

    This conversation happens often enough that I've ceased to be mind boggled by it. A developer will submit code, I review it, and I'll tell them to please sanitize the input. Instead of just using the functions, they'll come back and ask why? Invariably they'll point out that they're using nonces to make sure only authorized actions can happen (no cross site scripting), and they're checking user permissions too, limiting access to only admins. So why am I being pedantic? My default reply:
    Admins are humans. Humans make mistakes. Computers do exactly what they're told to do. 

    Admins Are Humans

    I'm often a broken record, telling people to sanitize, validate, and escape. When people ask me which sanitize function to use in WordPress, I play Socrates and walk them through the logic process. What kind of data are you saving? What will it look like? Okay, now what of these looks the most appropriate based on their descriptions? Sanitizing data is contextual. By this I mean we sanitize for what the saved data should be. If you're saving an email address, make sure you sanitize for email and so on. This has a side benefit of helping validate your data as well. If you check that the email address entry actually is an email, you're both sanitizing and validating. Now you've prevented someone from putting in a domain instead of an email!

    Humans Make Mistakes

    The details of 'best practices' for coding change often, as we learn about how to make code safer and smarter. That said, the ultimate best practices have nothing to do with the language you're writing in, the app you're writing for, or even the platform!
    • Restrict access to only the people who need it
    • Sanitize and validate the data you're given
    • Provide helpful error messages
    • Test your code with good and bad data
    • Document what the code does and what the errors mean
    Those practices transcend every single minutia of programing. If you do those five steps, your code will be robust, sane, and safe. Because you will have taken the steps to ensure that humans can make as few mistakes as possible. You don't save 'Dog' when true/false is the only valid answer.

    Computers Do What We Tell Them To Do

    The real problem is that AI doesn't exist.
    Source: CommitStrip.com
    Computers can't think for themselves, and humans have a tendency to stop thinking at weird moments (or just go on auto-pilot) which means nothing can destroy work faster than a human. And since a computer does what it's told, the most dangerous computer tool is the one that doesn't account for how big a mistake a human can make.

    Sanitize, Validate, Escape

    Especially when it's an admin.
  • Housing Large Media Files

    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.

  • But Seriously…

    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.

  • Be Nice to Future You

    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?

  • Query Strings vs Static Resources

    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.

  • Is This A Good Idea?

    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.