Author: Ipstenu (Mika Epstein)

Mailbag: Learning Resources

Ann asked about books:

[..] if you’re open to throwing a few key book recommendations – sites – blogs – whatever resources that you use/have used and particularly liked – I would be grateful. Essentially – I love your blog and am always looking to improve my WP developer skills. I want to get better. I want to be really really good. So I ask the greats if there’s something in particular that they think I should read – out of the huge sea of articles/books/blogs/etc out there. Something that they’ve singled out and thought was really worth paying attention to. And then I read it! [..]

She got an email reply right away, but here’s for everyone else.

The best advice I have is to pick something you like (or that drives you absolutely up the wall) and poke at it.

I got started and good because I really, really, really, wanted to do something that (at the time) WP didn’t do. After banging my head a lot, I started googling and trying to figure out what was there to use. I looked at a lot of code that was ALMOST what I wanted. And I broke my test site. A looooooooot.

The biggest problem is we all learn differently. I learn by doing, so for me the act of writing BAD code helps me understand it better. I hate videos.

But do I have a specific resource for learning? Sometimes I do. The majority of my ‘research’ remains search engines and constantly refining parameters, or trying to remember the name of the one thing with the thing. The problem is that I’m very haptic, I learn by doing things, so for me it’s way easier to take the examples and break them than anything else.

13 March, 2015
What I Learned From The Man

It’s no secret I worked for “The Man” for nearly fourteen years. I’ve learned some pretty amazing technical things from that, but I also learned some tricks about ‘working’ with a big company that have yet to fail me no matter where I worked. They were all lessons my family instilled in me, but having some pretty amazing people like Bonine, Margie, Joe P., Nikki, Rae, and a host of other amazing people all reinforce the morals of the stories, and it made me know that these were the right things.

Always Admit Fault

Scariest moment of my life was the day I accidentally rebooted a trading server at 10am on Thursday. Those were only supposed to happen at 10pm on Thursday nights, well after all trading was done for the day. I did it mid-day which meant there was a high risk that in-flight data could be lost. I was tasked with diagnosing what had happened and, after a lot of review, I came back and said the only logical reason was I had typo’d when I scheduled the time. We since changed to 24/7 clocks and not AM/PM to mitigate, but I was up front about the error being me. Similarly, when a bad change I made to a script broke the internet for all of our UK offices, I said it was me, I fixed it, and I took the hit. This meant later when a change I’d fought against was put in and caused an outage, everyone believed me when I said I’d done it, but it was someone else’s idea. I had credibility and history and (of course) documentation on my side.

Document It Or It Didn’t Happen

I had a boss whom I did not like. I liked the work, but working with him was terrible. He didn’t grove like I did, he was misogynistic and racist. He also had a flagrant disregard for protocol. Love it or hate it, when your company has specific steps to follow to do a thing, you do the steps. He didn’t want to and demanded I make an on-the-fly change. Verbally. I didn’t. This ended in a shouting match which our manager had to step in and settle. But before that event, I was told to make a change I knew was wrong. I demanded it be documented that this was a change in scope and a requirement by him. I then, under duress, made the change. It broke. I backed it out. That marks the last time I ever let it go that far and may explain to many people why I’m so firm about not letting people do ‘wrong’ or ‘bad’ actions. If I know something’s wrong, I won’t do it and I won’t help you do it.

Remember You’re Special, And So Are They

I’m a techie. I know all sorts of weird things. Remembering that I know those things and understand the different between minimizing a screen and closing a window is important. Joe reminded me about that once. I never forgot it. I also don’t forget that my place is to make sure problems are solved. So just because I don’t panic doesn’t mean I’m being cavalier, but at the same time I have to make sure the other person knows that.

Credit: xkcd

That window resize via a resolution change was the only way to fix a specific problem with a specific app. I used to travel across town to do it for people because trying to walk them through it on the phone was too difficult.

Use Your Calendar

“I’m sorry, I’m really busy.” has a lot more weight when they look at your calendar and see it’s booked. Solid. When I know I need to spend time working on a specific project, I schedule it as booked time and that way everyone can see and understand I’m busy. This is also a respect issue. If someone schedules a meeting, you confirm and click that damned ‘I accept’ button. It’s a contract, or a friendly agreement, in order to tell someone ‘Yes, I will be there.’

Don’t Waste Group Time

Irony. If you think about big companies, you think about wasted meetings where people never get anything done. I’m not talking about that (which is a thing). I’m talking about wasting time with being disrespectful of the meeting. Keep your phone/mic on mute in a conference call so no one hears you pounding on a keyboard. Turn off your video feed if you’re not presenting so you speed up the internet for everyone. Joining in a massive meeting with hundreds of people? Get a conference room for your location to prevent overwhelming the system. If it’s an on-line, text meeting, follow the announced protocol.

What Did You Learn?

I’m not the only open-sourcer who used to work for the Man. Did you learn anything that you still use today?

Those meetings, by the way, are generally a waste of time. I greatly prefer stand-ups. Everyone gets 60-90 seconds to state status. Everything after is taken outside meetings.

11 March, 2015
Markdown Isn’t All Bad
It’s not a secret I hate markdown. It’s annoying to remember various commands, and one of the things I loved about WordPress from the start was that I didn’t have to learn bbCode or anything beyond the HTML I knew. When Jetpack included Markdown, I was a huge opponent. I thought it was useless and pointless and a waste of space.

I now use it in many of my posts.

You see, I don’t write in the visual editor. I used to, but there are ‘glitches’ with it. Like I couldn’t see the embed for Facebook (it showed up blank for some reason), and I had trouble embedding video content that required me to paste in script code. Then when I starting writing code, like I do on this site, I needed to make sure the formatting didn’t get mangled. It all boiled down to giving me two places where I use the Visual editor, and everything else is text.

That’s all well and good until I fell in love with my iPad mini.

You see I also have a major annoyance with the iOS app for WordPress. It’s too easy to post to the wrong site and it’s problematic when you want to upload featured images or make custom excerpts or have any custom post types. That means I use Chrome or Safari on iOS to write blog posts. If I’m offline, I write it up in Notes or Byword and just have it there until I’m ready to import. But I use WordPress in my browser because that’s where it works ‘best.’

Except HTML on an iPad is a pain in my ass.

It really, really, is. The number of clicks you have to do just to make a header, or strong text, is annoying. It’s three clicks to make an <h2> and it’s not even in the same place. It’s one click to get to the numbers, another (one up from where you hit to get to numbers) to go to advanced characters. Then you can press the button. Any chance I have to minimize my clicks means I can type even fast.

And you bet your bippy I’m fast at typing on my iPad.

Markdown’s syntax is intended for one purpose: to be used as a format for writing for the web.

John Gruber’s Markdown syntax primer is the only place that really took the time to make sense of Markdown to me. Everyone else just said ‘It’s what we use’ or ‘It’s faster’ or (worst) ‘It’s better.’

No. No. No. Better is what works for you. HTML, for the most part, works for me. And for me, a small subset of markdown syntax terms work very, very well to speed up my writing:
```
## Title

### Subtitle

&amp;amp;gt; Blockquote
```
There are a few more, like the codeblock (which I don’t use, since I like pretty formatting better) but the ability to use backticks and say <code> is pretty nice.

So do I like Markdown? No. It’s hard to remember ‘new’ syntax. But the ones I can use without having to close tags makes me a little happier and speeds me up a bit. For that, it’s pretty good. I can use it to enhance my HTML, and I wish that MediaWiki let me use HTML and Markdown instead of their woe begotten WikiSyntax. My kingdom for <table> in MediaWiki. Am I right?

Now. If I could just get John Gruber to increase his font size.
9 March, 2015
Mailbag: What Code Makes You Sigh?
When I was talking about ThemeForest, I mentioned we had code on WordPress.org that made me sigh. Or cry depending on the day.

Here it is:
```
if (!defined('WP_CONTENT_URL')) define('WP_CONTENT_URL', get_option('siteurl').'/wp-content');
if (!defined('WP_CONTENT_DIR')) define('WP_CONTENT_DIR', ABSPATH.'wp-content');
if (!defined('WP_PLUGIN_URL')) define('WP_PLUGIN_URL', WP_CONTENT_URL.'/plugins');
if (!defined('WP_PLUGIN_DIR')) define('WP_PLUGIN_DIR', WP_CONTENT_DIR.'/plugins');
```
Why do I sigh?

It’s not needed.

You can use functions to determine those directories and while I’m sure someone’s thinking “But WP_PLUGIN_DIR is shorter than plugins_url()!” it’s not.

That code block above was used so that one line of code could exist.
```
include(WP_PLUGIN_DIR.'/PLUGINNAME/settings.php');
```
Those four lines, plus the include, could be replaced with this:
```
include( plugins_url( 'settings.php' , __FILE__ ) );
```
So yes, I sigh. Because with just a little work, you could see that there’s a more efficient way to make your plugin smaller.
6 March, 2015
Packaging Code

I love that people do it. I hate that they don’t review it.

The number of projects I review, only to find that the author ran a tool like Grunt to combine files, but forgot to go over what the result was is fairly high. And this is a problem when you consider how many times I have to tell people “Your submission still has demo files, test scripts, and other files that aren’t applicable for distribution.” What happens is that people use the very cool auto-scripts and never stop to make sure that everything’s right. They make sure the code works but they don’t remember to clean up the package.

So let’s talk about what should never be in your plugins for WordPress.org

Deployment Scripts

Now I know a lot of people use scripts to copy their code from GitHub to WordPress’s SVN repo, and I think those scripts are great. They’re helpful, they speed up development, and please keep them out of your plugins. Your script should include a note not to distribute itself. I understand why, when you link us to the GitHub default zip, those scripts are in the review package, and that’s okay. But I do sometimes run a sweep through the repository to see how many people are accidentally including those SH files in their plugin packages. You’ve got to remove those. They don’t matter to the final product and without them, your plugin will be smaller.

Demo Folders

Here’s the thing. They don’t matter. A lot of awesome 3rd party tools come with detailed demo files and extensive things you’ll never need. Those demo folders also tend to be where you’ll find all sorts of crazy things like Google Analytics tracking, calls to external resources (like jquery’s JS files), and more. Your users will rarely, if ever, need that sort of thing. They generally don’t notice it, unless you code it into your plugin, at which point you’d be better served by making it look like WordPress.

Test Scripts

Your test scripts don’t need to be in your plugin. They’re cool, to make sure that the code is going to work before you push it, but that code doesn’t need to be in the plugin on my site, does it? No it does not. All automated tests should be separate from your plugin code files. People don’t need to see the Travis checks in the code on their sites. If they’re developers, they’ll go look for them at your code’s home, after all.

Compressed and Uncompressed Files

Pick one. You don’t need both. When you’re talking about a framework or a library, it’s fine to pull in a minified (but not p,a,c,k,e,r compressed) version of the file as your own version. If there’s no need or plan to edit that file (and there shouldn’t be), you can make the plugin smaller. Of course, I feel that if the JS is all of 7 lines, for goodness sake, it’s fine to leave it all human readable.

What Else?

What do people leave in plugin or theme packages that drive you up the wall?

4 March, 2015
I’m Fine With Envato

I just don’t use ThemeForest.

Look. I think Envato is actually pretty awesome. They’ve made a way to help people monetize development within WordPress. I’m all about that! I want to see people making a living from WordPress and I want people to be able to succeed and make WordPress even better. A number of people I know who are currently successfully running their own WordPress related business got started over there.

So why don’t I use their products? I haven’t had a need to. I don’t use WooCommerce either, or their themes. There’s nothing wrong with that. But there is a ‘problem’ with Envato, or rather there’s one with ThemeForest, and it’s the same problem as we have on the WordPress.org plugin repository.

The last (and possibly only) time I mentioned them, I said I had an issue with their lack of upgradability. If I buy a theme or a plugin, I can’t easily get updates. I’m stuck on the old way of download when I get an email. There’s no way to do it easily from inside my dashboard. This is a problem of our own creation. Ten years ago, that was normal. Today, we have a reasonable expectation to easily upgrade WordPress, it’s themes and plugins.

I happen to know Envato’s working on it, so I still look forward to their solution.

But they have the exact same problem as we have with the WordPress.org plugin repository: crap code.

You see, there’s only no practical difference between the WPORG repository and ThemeForest and how it handles reviews except they actually may be checking on every upgrade. If you didn’t know, ThemeForest does review things. But they do it exactly like we do! They read the code, they test it, they look for evil things, and they approve or not.

Theme review on WPORG is a tighter ship than plugin, for a few reasons, but frankly I doubt the overall quality of code on WPORG (plugins) or ThemeForest is all that different. We’ve had some pretty insane vulnerabilities in plugins, after all, and the WPORG repository doesn’t have a great way of dealing with them. But to say that you don’t trust ThemeForest because the code quality is bad while simultaneously using any free plugin from ORG is naive at best.

The constant problem we have with plugins, and one they have with ThemeForest themes, is that we allow a lot of different types of code. In being liberal like we are, we can allow for a lot more creativity and expression and, well, art. The downside is that there’s a practical limit to what a human being will be able to catch. We’re like the TSA. We try, but we’re fighting a loosing battle and that’s why we’re always going to miss things and we’re always going to be running behind and cleaning up.

And worse they have the same problem with any code they yank. How do you upgrade everyone? When is it right and safe? When is it an overstep? Weighing security risks with information with compatibility is complex. For the WordPress.org repository, we have a long way to go before we’ll be able to push minor security updates like core can… at least not without a lot of fear and consideration. We’re on the road there, though, so one day you may wake up to a plugin magically secured on your site.

Oh and as a reminder? If you see a WordPress.org plugin hosted that is insecure or doing evil things, email plugins@wordpress.org with the plugin URL and all the possible information about how it’s insecure. If you know how to hack it, please tell us exactly what you did. You make it faster for us to sort things out.

For Envato, you can report these things via their Helpful Hacker program.

2 March, 2015