Author: Ipstenu (Mika Epstein)

Impostercide

This is not about my plugin of the same name.

For my first ‘real’ adult job, I was asked if I knew what WinINSTALL was. “Its like WinImage,” they said.

I had no idea what they were talking about. I thought I was applying for a software testing and deployment gig, and that sounded like images. I’d like to say I told them the truth, that I wasn’t sure what that specific software was for. I didn’t. I bluffed. “WinImage? Sure. I know that one.” And then I rattled off what the job description had said. “It takes snapshots of operating systems in order to collect all the changes to know exactly what software did when it was installed. Right?”

Could they see I knew nothing? I guess not, because they hired me. And I had no idea what that actually meant. Sure, I understood the concept, but had no idea what I was really getting into, so I bluffed. I talked around the subject, hitting the technical points I did know and, in doing so, got hired. And I was scared for years that one day someone would realize I didn’t know jack.

We all start out not knowing, and when we get to the point that we do know, we feel that those early bluffs mean one day, someone will find out, we’re liars. That we know nothing. Learning to deal with the fallout from that one interview has been a years long process. It set the tone for my tech life, my life in general, because I’d built everything on a lie. The lie eventually became truth, but trust me that doesn’t make you feel any better.

When I started speaking at WordCamps, I was terrified because of that lie a decade before. Why would people want to hear from me? I had nothing to say that other people hadn’t said. The second and third times got much easier, but I still get scared. I’m scared now! When I wrote my first eBook, someone said something hurtful. He said “Why would anyone buy your book? They can just google and find that out themselves!” But I wrote it, sold it, and even made a sequel. That was really hard to do because I was facing people telling me things were worthless.

Imposter Syndrome stems from our self doubts. It comes from the place where, like me at twenty, we bluff a little bit in order to get our foot in the door. It’s worse when, like a lot of people these days, we don’t have college degrees. We feel every day that someone will realize we know nothing. Let’s take a deep breath. There’s no magic cure to say “Do this and you will never again have these fears” — I have them all the time. Every time I take on a new role or task, I worry I won’t be able to succeed, and I can trace it back to that niggling fear from that day I bluffed. So I fake the confidence I need to stand up here. But I also remember these facts.

Fact One: Everyone’s bluffing about something.

We all do it. We all do it. If someone says they never exaggerate or bluff about their abilities, they’re liars. Hold on to that thought, because we all want to be seen as better than we are. It makes us feel good.

Fact Two: Some people ARE smarter and/or better than you are.

There’s at least one person out there who is smarter than you are or better than you are at a thing. That’s just a statistical reality. The different between them and you, however, is that you are here. You showed up. You’re here. It’s okay. The only way to get better and smarter is to keep doing things. So step one is show up. Accepting the fact that you’re not the best is hard, but as soon as you do, the constant fear to be best starts to fade a little.

Fact Three: Sometimes it’s just in your head.

Anyone who has a mental illness, be it depression, SAD, anxiety, can tell you this. Sometimes you get hit by a feeling of nothing and you don’t want to leave the house. You may stop answering your parents’ phone calls. You may just get really quiet. Or maybe you have a manic phase, or maybe just being around people hurts. This is all complicated and messy. But when that sort of thing happens, it can take a lot of time to remember to understand your brain and what you’re doing and when it’s you and not the world. You have to constantly judge things and ask yourself if your looking at things reasonably.

Sounds like I’m speaking from the heart, huh? When this happens to me, I rely on my friends. I ask them if I’m being irrational, if I’m just feeling self-doubt, or if there’s a real reason.

Fact Four: Just because it’s all in your head doesn’t mean it’s all in your head

You all saw or read Harry Potter, right? So in the last movie, when Harry’s in the weird limbo place and meets Dumbledore again, he asks if their conversation was real or if it was all in his head. Dumbledore points out that just because it’s all in his head doesn’t mean it’s not real. Just because you know you have a mental illness doesn’t mean that your feelings aren’t real. Separating the two isn’t easy. It helps to have friends who can spot-check you. Of course, most of my friends work in WP, and I don’t want to embarrass myself in front of them. Welcome back, Imposter syndrome!

Fact Five: It’s okay to say you don’t know

That’s hard. That one always makes me think “Oh god, they’ll fire me because I don’t know this basic thing.” It’s not the case. If it is, well you would have hated working there anyway. You have to be able to able to learn. You need that freedom. You need the freedom to fail and experiment and say “I don’t know this.” But. You have to hold up your end of the bargain.

Fact Six: It’s not about what you know but how you know

If I’d been honest in the beginning, I might have started in a better place. If I’d just said “Nope, never used WinInstall but I’m willing to learn!” I could have set myself up different. Today, I don’t know much javascript. I’m still a bit touchy on sql. But I know how to know. I know how to google. I know how to research. I know how to learn. I’m okay with looking foolish for not knowing because I know I can’t know everything! I take notes, I document, and I learn. And the more I learn, the less I fear my own self.

10 February, 2016
Working with Webhosts

Working with a host isn’t just sending in tickets into the abyss and hoping they answer them. Whether you’re communicating on behalf of a client or for your own benefit, it’s not the same as working with fellow developers. You need to approach a host with different expectations and explain situations in different ways in order to get the best results.

What Is A WebHost? Why Are They Different?

You’ve had this problem where what works on Host A doesn’t work on Host B, right? All webhosts are different for a really obvious reasons. There’s more than one way to solve the problem of webhosting. Every host has decided, on their own, what works well for THEM. Which means no two of them are the same, nor will they really ever be. This is okay, if it’s a little annoying, because not only are YOU a special snowflake with your customized website, but so is your webhost with their customized server and environments.

Setting Expectations

Hosts Are Not Developers

Your host is not going to generally debug themes and plugins. They’re just not. They don’t have the manpower for it. The host cares first about your servers, THEN about your code. And if they find your code is the problem, that discovery is often the limit. They’re not always going to help you debug exactly why plugin X is causing a specific feature on their servers to grumble. This doesn’t mean they can’t do it. Many hosts, especially ones with WordPress hosting plans, can and do debug code all the time. To be more precise, you shouldn’t expect the host to reverse engineer your code to understand why it does what it does. They are problem identifiers.

Hosts Will Fix What’s Theirs

This doesn’t mean that a host will leave you high and dry. A host will fix whatever they can. If their code broke your stuff, you bet they should fix that. Did they run a WordPress upgrade that left your site with bad permissions? Yes. But… If they ran an upgrade and you have a theme incompatible with WordPress 4.2, who’s problem is that? Should they be on the hook for fixing it or should the person who owns the site? This is why I say hosts will fix what’s theirs. It’s a lot of grey areas sometimes. It feels like people are always making exceptions or telling you that you’re an edge case. But at the end of the day, a host is NOT on the hook for upgrading your custom theme to work with the new version of WP.

All Hosts Are Different

Telling a host “But it works locally” or on another host doesn’t do them ANY good, nor do they really care. Everyone sets up servers differently, and sometimes the issue will be with PHP or the Linux OS or maybe, help me, Windows. It’s apples and oranges, like trying to compare two similar themes. Now this puts developers in a bad spot. WordPress is incredibly flexible and works, out of the box, in the majority of situations. The same cannot be said of all code. Most people don’t have the resources core does to test in so many iterations. And even WordPress misses things. Not all code will work in all configurations in all circumstances on all hosts. Sometimes you are a special snowflake. You are the edge case.

Don’t Assume

So what can we do to make things better? Telling the host the important things, especially if you’re a dev, will help everyone. If you’re not a dev, then start with the basics. The important thing here is, even though you having a bad day, not to freak out. You need to be calm, you need to be clear, but you need to provide a GOOD bug report. Don’t assume the host magically knows everything, since the error MIGHT be their servers, certainly, but it may also be a combination of what the user is doing, how they’re doing it, and the server that causes the problem. Hosts are not psychic. They only know what you’ve told them.

Give the Right Information

Who Are We Talking About?

The most obvious question? “What’s the domain?” Many people will have multiple domains with a host, and if the issue only happens on one, you can speed up their searches just by being up front! Many, many, many times I see people complain that their ‘site’ is down. One user had 107 domains. I stared at it for a moment, tested a couple, and finally emailed back. “I looked at these five domains and they seem alright. Your email didn’t specify which domain was broken or how. Can you please be a little more precise? It’ll help us find out what’s wrong faster.” Start out with exactly what’s wrong and where.

Are You The Owner?

The next important thing to tell a host is “Who are YOU?” This is secretly “Who owns the site” because if it’s not you, you may not be able to get all the answers due to security. The host will know who you are, based on the email, so this also means “What kind of person are you?” Are you a user who can’t code? A high end dev? A middle-of-the-road guy caught in the problem? Let the host know what you can do and they can help tailor answers better. It’s okay to say that you’re the new dev taking over and you don’t know everything yet. Just let the host know where you stand. This lets them know what to expect and what they are permitted to tell you.

Where Does It Hurt?

With WordPress, sometimes a host has to ask “Can WE log in?” I hate this. I hate asking someone for access to log into their site. It makes me nervous. But sometimes if the error only happens when you do specific things, a host has to log in to reproduce it with debug on in order to track it down faster. If it requires logging in to reproduce the problem, remember to provide them access. I strongly suggest making a second account for the host and deleting it when they’re done.

Explaining The Problem

Even If It’s Tricky

All the information before should have gotten you here already, but it needs repeated. Explain the problem! “This site is broken” is a terrible email and yet I see it daily. A better one is “This site is broken after we upgraded to WordPress 4.2. This is the error, this is what I’ve already tried. I THINK the issue is this other thing. Can you help?” Give the right information. Tell the host what’s wrong. Give them an error. Don’t assume they’re familiar with every single possible error. You’re not, after all, unless you’re Nacin.

Details Are Important

I know I said to tell them what you think the problem is. It’s okay not to know, but it’s not okay not to give the details on what you DO know. You know some things. Is the problem happening for logged in or logged out users? How do you reproduce it? Start by assuming the host knows NOTHING about your site and how it works. Even if you’re sure they know how a blog works, take the time to step back. This is really hard. You have to give them enough information without spewing your whole history.

Walk Them Through It

Walk them through exactly how to reproduce it. Use screenshots when possible. Videos? Not really as helpful as you might think. If you get an error message, make sure that you give them the WHOLE message as well as the context. I mentioned not assuming before, this goes double here. Don’t assume a host knows how you upload an image. There are multiple ways to do that, so tell them how YOU did it.

You’re Not The Customer? They May Have To Talk Tech

When you’re not the one who pays the bills, you may need to play intermediary and have the owner contact the host. Some hosts let you add specific email addresses as secondary contacts. You should always make sure of that early on. If you hate the social engineering that comes with people cracking into other people’s accounts, that’s WHY many hosts won’t just tell you everything. Playing the middle sucks, and when this happens, try to be patient. Everything will take longer. That said, have the customer ask the host if there’s a way to add you on as someone the host is allowed to talk to. Most have a way around it.

Pick The Host You Like … And It’s Subjective

Speaking of that … You should find a host you like. Figure out what you can work with, and here’s a big secret. Hosts won’t mind if you tell them that they can’t meet your needs. Okay that’s a lie, they do mind. But if the reason is “You don’t have 24/7 phone support!” well they understand. If the reason is “I need a type of server you don’t provide” that’s also okay. And sometimes, sometimes, no matter how much you love a specific person (or people) at a host, they just don’t meet all your support needs. And that too is okay. Hosts understand that. One brilliant person doesn’t make up for the masses, after all. Hosts aren’t the same. It’s okay.

Everyone Wants Everyone To Be Happy

In the end, the host wants the same things a customer does. A good, fast, website that does what they want and makes them happy. If you’re clear about what’s wrong, what you need, and you’re willing to work with a host to experiment a little, you may be surprised at how well you can work with them to succeed.

8 February, 2016
Mailbag: The Trouble of Rollbacks
Anonymous asks:

Why doesn’t WordPress let me rollback a plugin?

Answer: Because the education of developers as to how to properly tag and number releases hasn’t hit critical mass.

Other answer: Because no one’s paid me enough yet to sit and manage every single WordPress plugin release to ensure the developers are properly using tags.

Other answer: No one’s written the code to enforce proper tagging for plugins.

Look. Let’s step back. Why does rolling back WordPress work? I’m going to assume you disabled auto-updates for a moment. They work becuase WordPress understands semantic versioning.
- 4.4 is a major release.
- 4.4.1 is a minor release (bug and security fixes)
Now go look at your plugins. Look at their versions. Let me show you what I, a plugin reviewer, sees:
- 20151205-295323 is a major release
- 3.2.3.1 is a minor release
- 4.2.1 is a major release
- 14.4 is a critical bug fix
- 738741 is a minor release
It goes on and on.

But even if we fix that, we have to trust that people will remember to actually use the SVN tags folder. They don’t. Trust me, about half the time I contact a plugin developer about a problem, I have to ask them to please use SVN properly.

The trunk folder is for the ‘latest’ version of your plugin. This may be a beta, and it may be the same as your stable release. Either way, trunk should be a working version.

The tags folders are for your releases. Finished up version 1.3.4? Great! Update the plugin readme and the main file to have the new stable version and run svn cp trunk tags/1.3.4 to copy it over. Done. But no, they don’t do that.

This is the ‘fault’ of open source and freedom, of course. We let plugin developers do what they want, a lot more than themes, and with that freedom comes risks and responsibilities. Different people rise to those responsibilities differently. Most of us stumble along, make mistakes, figure out what best practice works for us, and move on.

Should WordPress enforce proper behavior? I gotta tell you, I don’t think it would be sustainable. Not without a much smaller repository and not without some sort of signed contract with developers to agree to the guidelines. And I don’t think developers would like it.

I don’t think we’re (yet) at the point where auto-updating plugins is wise. Themes, yes, but I don’t think plugins are quite there yet. Maybe we’ll get there, but there are so many hurdles before us it’ll be a while yet.
5 February, 2016
Packaging and Shipping Resource Folders
No, I don’t mean resources to get help.

Have you ever opened a plugin or theme and seen a folder that says bower_components or node_modules? Yeah, I hate those. I don’t hate Bower or Node, I use them quite a lot. I hate how people use them in their plugins.

What Are Those Folders?

In order to make life easier, Bower is a package manager that lets you install libraries that your plugin needs. Making a plugin that needs AWS SDK?

bower install aws-sdk-js

Boom. And you can easily upgrade it too with bower update – which I love. This is a great idea.
```
$ bower install aws-sdk --save
bower aws-sdk#*                 cached git://github.com/aws/aws-sdk-js.git#2.2.28
bower aws-sdk#*               validate 2.2.28 against git://github.com/aws/aws-sdk-js.git#*
bower aws-sdk#~2.2.28          install aws-sdk#2.2.28

aws-sdk#2.2.28 bower_components/aws-sdk
```
But notice that last line? bower_components/aws-sdk is where it saved my files. And if I go in there, the JS file I need is bower_components/aws-sdk/dist/aws-sdk.min.js and that is surrounded by other files:

Now as a developer you have a couple choices here. You can leave the file where it is and just call it from there or you can move it. If you move it, you want to make a simple way of updating it. After all, the whole point of using Bower here is to make life easier. Personally I use Grunt for these things. I talked about it last year but my basic idea is to use Bower to download the latest and greatest versions, and then Grunt takes care of (a) updating the Bower packages and (b) copying the files to where I need them.

Okay, but what if I have something a little more complex?

What Resources Do I Need?

This seemingly innocuous question is surprisingly deep. It’s not just ‘what package/library am I trying to manage’, but how do I manage it and with what? What if, instead of the javascript, I wanted to use the PHP AWS SDK instead? Well, the AWS SDK for PHP is not available in Bower! Instead it uses Composer.

Here’s where things get weird. Composer is a package manger. Grunt is a package manager. Node and Bower are too. This means I have to stop and think hard. Which one do I need? Why do I need it? What am I going to be managing?

It’s time to ask this:

What Are My Packages For?

Within Node there are two kinds of packages:
- “dependencies”: these packages are required by your application in production
- “devDependencies”: these packages are only needed for development and testing
Take a moment to think what you need to dev and what you need to run. Your test code doesn’t need to be in your release, does it? No, of course not. It would make perfect sense to have in your Git or personal repository, but the WordPress SVN repository is not actually for your own code management. It’s a release management tool. That’s another post for another time. Just keep in mind that you should really only be pushing your code to SVN when it’s a version ready for use (be that beta testing or releases).

Back to what things are for. When talking about the AWS SDK javascript, I’m talking about front end packages. So that’s a dependancy. But Bower? It’s a devDependency. The users don’t need to know (or care) that I’m using Grunt and Bower to package things up. That means they shouldn’t be installed in my plugin!

In the case of my AWS SDK a ‘devDependency’ is Composer. I only need it to build my packages.

My dependencies are as follows:
```
    "require": {
	    "aws/aws-sdk-php": "2.*",
	    "doctrine/orm": "*",
	    "monolog/monolog": "*"
	}
```
Adding that to my composer.json file is a simple thing and now I can just run composer update to get everything I need!

Where Should My Packages Live?

This is generally pre-destined. If you use Node they go in node_modules and Bower likes bower_components and Composer uses vendor and so on and so forth. You can, of course, customize these. I often make a folder called ‘assets’ or ‘assets-dev’ so I can easily ignore it in my version control. Frankly I don’t need them and neither do my users and it’ll help save space.

There’s a cool thing about composer. If you use composer init then it asks, at the end “Would you like the vendor directory added to your .gitignore [yes]?” This is great, because if you looked at the folder vendor you would see a lot of folders and files you don’t really want. I actually only want one folder vendor/aws/aws-sdk-php/src/Aws/ and I want that folder to be located in aws/Aws please and thank you. Composer adds this into .gitignore for you.

You’ll still have to add that into your SVN ignore file, which is a little more annoying. To ignore all composer.* files it’s this:
```
svn propset svn:ignore "composer.*" .
```
And if you want to ignore multiple files or folders use the following command to bring up the text editor:
```
svn propedit svn:ignore . 
```
For SVN I would ignore composer.json, composer.lock, and the vendor folder.

How Do I Move Folders?

Remember I want to move things to another folder? I use Composer’s scripts to do this. I admit this is ugly code. I have this in my composer.json:
```
	"scripts": {
        "post-update-cmd": [
	        "rm -rf aws/Aws",
	        "cp -r vendor/aws/aws-sdk-php/src/Aws aws/",
	        "rm -rf aws/Doctrine",
	        "cp -r vendor/doctrine/common/lib/Doctrine aws/",
	        "rm -rf aws/Guzzle",
	        "cp -r vendor/guzzle/guzzle/src/Guzzle aws/",
	        "rm -rf aws/Monolog",
	        "cp -r vendor/monolog/monolog/src/Monolog aws/",
	        "rm -rf aws/Psr",
	        "cp -r vendor/psr/log/Psr aws/",
	        "rm -rf aws/Symphony",
	        "mkdir -p aws/Symphony/Component/EventDispatcher",
	        "cp -r vendor/symfony/event-dispatcher/* aws/Symphony/Component/EventDispatcher/"
        ]
    }
```
This runs whenever I run composer update in this folder and it copies everything where I need it to be. I did tell you it was ugly, right? But it does work.

The Result?

The result is my vendor code is never uploaded to WordPress.org’s SVN, my users never see the stuff they don’t care about, and I have a faster way to update my plugins when I need to make sure all the packages are right.
3 February, 2016
WP JSON API Challenges
In my frustration of my static process, I ripped everything out by it’s roots and decided to take things in a strict order.

Decision: All-In-One or Separate?

The first question was do I want to download everything as one big JSON file and split it out later, or do I want to, from the start, download each post as it’s own file? The time to download shouldn’t change, and if I do it right, I could script it to check if the date stamp on my downloaded file was older than the post date in WP. That means I could have this logic:
```
if ( ! post file exists || post file date < post datestamp ) {
    download JSON for this post
}
```
That made it an easy win. Let’s split away from the original plan. Now my goal is to extract all the posts from my WP site in JSON format.

Remember the goal here is to run a static website with WP. There are plugins that convert WP to static HTML, which you can then use to power a site, and this isn’t a bad idea.

How To: Get all the posts from a WP site via the JSON API?

This sounded easy. http://local.wordpress.dev//wp-json/wp/v2/posts listed posts, and the v1 comparison chart says that you can list all posts, it stands to reason that I can easily get all my posts.

In a way, this is a WordPress problem. WP doesn’t want you to show all posts. It would make your site very slow if you had, say, 10,000 posts. Which means that the claim that the JSON API can lists all posts is true, it just doesn’t do them all at once.

I happen to have 40 published posts on my test site, so when I GET with this URL, it loads all of them: http://local.wordpress.dev//wp-json/wp/v2/posts?per_page=100

But that isn’t sustainable. And the old trick of making per_page equal to -1 didn’t work.

I did determine that the JSON API actually knows what the amount of posts is!

The header “X-WP-Total: 40” is what I needed. Of course, that is rather weird to get. It means to get all the files, I have to write ‘something’ that does this:
1. Get http://local.wordpress.dev//wp-json/wp/v2/posts and parse it to get the value of X-WP-Total
2. Get http://local.wordpress.dev//wp-json/wp/v2/posts?per_page=X-WP-Total
Okay. So how?

Well remember how I mentioned a plugin that made a static site already? I was talking about things like Really Static. Save a post, it saves the JSON file! Why not write this plugin?

Why not use “Really Static”? Well I don’t want to have WP doing more than be my content generator. I want to separate content (the blog) from WP. And that means I will end up writing a plugin…

Am I In Too Deep? Or Am I Over My Head?

So far, this has been an incredible amount of work. It’s been a lot of two steps forward and three steps back, over and over and over. And yes, it’s been very frustrating. I’ve given up many times and, if my posts about multiple approaches are any indication, I’ve deleted and restarted many, many times.

And I have to be honest here… I’m giving up on this overly ambitious plan right now.

This marks two major failures (three if I could how insane the entire ‘use Jekyll/Hugo to run a gallery’ was). First, I’ve failed to sensibly convert JSON files to MD in a scriptable and reproducible way. Second, I’ve failed to export JSON from WordPress in a simple way. Both those failures can be worked around. I can build a plugin that exports the JSON. It’s not trivial, but having done similar things I’m sure I can do it. The issue is ‘is it worth it’? And right now I think the answer is no.

I’m back to the drawing board right now, sketching up new plans and ideas. I want to eliminate as many steps as possible. I’d like to leave WordPress alone, let it be WordPress, and similarly let my static generator be static. These failures have taught me more about the interdependencies than I expected, and I’ve learned more from them than I may have if I’d had outright success from the start.

While I’m starting over, again, I feel hopeful and less ‘I hate you, JSON’ than I thought I would. I now understand things more clearly and I see how I made things far, far more complicated for myself.

The future of this project is, weirdly, bright.
1 February, 2016
Mailbag: Can I Track Issues with Github Like WP Support?

How do I see all my Github issues for all my projects?

I was asked this at a WordCamp by someone who had seen my ‘how to get into Github’ series with Carrie Dils.

If you’re tracking the WordPress forums, https://wordpress.org/support/view/plugin-committer/YOURID will list all of the support requests and reviews for any plugin you have commit access.

Not a comitter, just someone listed as an author? Use https://wordpress.org/support/view/plugin-contributor/YOURID

But Github? Turns out it’s super easy!

https://github.com/search?q=is%3Aissue+is%3Aopen+user%3AYOURNAME&type=Issues

Basically you can go to the Github Search Page and put inis:issue is:open user:ott42 and you’ll see them all! There’s no RSS feed mind you but you do get emails for all those so you should be okay.

29 January, 2016