INTRO: Welcome to Apply Filters, the podcast all about WordPress development. Now here’s your hosts, Pippin Williamson and Brad Touesnard.

BRAD: Welcome to Episode 76. This time Pippin and I will be answering questions from our audience that gave us questions through Twitter, Post Status Slack, and email.

But first, we do not have a sponsor this episode, but we are celebrating 100,000 download. We have ticked over. We’re like 101,000 or something, isn’t it, Pippin? Something like that.

PIPPIN: One hundred and fifteen thousand.

BRAD: One hundred and fifteen thousand. Ooh, that’s even better. Yes, so if you are interested in sponsoring, you can get this spot right at the top of the show for about $300, and that will get you about 2,100 unique downloads, so about 2,100 people will listen to your ad. That’s about $0.14 per person, so a pretty good value there, I think. Yeah, if you’re interested in sponsoring the show, we have a form at ApplyFilters.fm, so check it out, and we’d be happy to talk about most products. Not every product, but most products.

Pippin, shall we proceed?

PIPPIN: Yeah, let’s dive in. We’ve got a number of questions from people this time. Some were left over from when we asked for questions a couple weeks go. We’re going to start with one from Travis Northcutt. He asked a really good question in Post Status Slack this morning. It might take up our full time, and so if we end up just talking on this one for a while, then we’ll go ahead and get to the rest of the questions the next episode and who knows however many after that.

Anyway, I’m going to read to you what Travis wrote, and then we may rephrase it just a little bit. Travis said, “So if you think it’s going to be an interesting discussion, perhaps talking about working in advanced strategies vs. just shipping. I often get excited about learning some new techniques or tools, but it’s easy to get sucked into over-optimizing for perfection as opposed to just getting something built. You could spend hours and hours using all the latest best practices, but that doesn’t mean you’ll ship your product.”

Really, I think what Travis is really asking here is having a discussion on the philosophy of just ship it, basically get the MVP out the door as early as possible, versus getting your product, whether it’s a 1.0, a 2.0, a 3.0 perfect and getting all of the rough edges smoothened out and making sure that it’s really well polished. I think this is an excellent topic and something we’ve known for a while, but we just got reminded of this at the beginning in our pre-show discussion is that Brad and I actually have different philosophies about this.

I think Brad, you and your team tend to do a lot more polishing before shipping something. I’m not saying that my team and I don’t polish things, but for me, my personal philosophy has always been: Let’s just ship it. Let’s get it live.

It should be fully functional. It should be good to go, but it doesn’t necessarily have to be perfect because I really like the approach of release often, iterate quickly.

BRAD: Right. I think what you just said is fair. I think we do polish things. We tend to polish things quite a bit before we release.

I do think that it’s a balance, though. I mean that’s the whole thing, right? How much do you polish it? You have to polish it a little bit, don’t you? It can’t be a complete unusable thing, right?

PIPPIN: Obviously it can’t be broken.

BRAD: Yeah.

PIPPIN: And it can’t be completely disjointed. There needs to be some form of polish to it. But I think the real discussion there then is how far is enough and how far is too much before you get yourself into a trap.

There was a followup comment from another Post Status member, Darren Ethier, who said, “Seriously, though. The discussion is a good one. Part of the tension is that until you ship, you don’t really know if the idea you have is crap. The difficulty with possibly shipping too early is determining whether it’s crap because of the idea or the implementation. So it’s a good segue into measuring the right data to help you answer the right question,” which is a really important point.

You could very easily work on a product for months and months and months, or not necessarily a product. It could be a feature. It could be a UI design change. You could spends months or years doing it and then ship it only to discover that you did something terribly wrong because you misunderstood what your customers wanted or how your customers used a product. I think anybody that has ever built a feature into a product and then later on realized that nobody used it or that the feature didn’t fulfill the need the customers had, understand that pain.

BRAD: Yeah, absolutely. I mean it’s tricky, though, when you’re talking about a feature, right? Let’s say you launch a feature. You go the “just ship it” approach and just get it out as pretty rough. You’re measuring usage, and no one is using it, or people use it and then stop using it immediately. Is that because it’s not very good, or is it because the feature is just a feature that no one wants? If you don’t polish it to your own satisfaction, then you can’t really write off that idea.

PIPPIN: I have an example of this, I think, from EDD. In, I want to say, version 1.5, which was 2.5, 3, maybe even 4 years ago at this point–I’m not sure how long ago it was–EDD did not originally ship with anything to collect sales tax. Number one, because I had the philosophy of, look, I’m just going to ship something early and we’ll add features as we go.

But then we did decide to add sales tax, but we added a ridiculously simple implementation of sales tax, like to the point where it was almost useless for a lot of people. That implementation was definitely an example of, hey, let’s just ship it and we’ll iterate later. But the feedback that we got from customers after that was basically nobody used it because it was broken.

They didn’t not use it because they didn’t need it. They just didn’t use it because it was broken. And so that’s one case where we should have polished it a lot more before ever releasing it.

But then again, on the flipside, by releasing a broken feature, we better knew that people really did need the real feature.

BRAD: Right. That’s a really good point. We kind of did the same thing with Mergebot. When we pushed out Mergebot there was a lot of limitations, let’s just say. There was a lot of things that we hadn’t done yet that we were very sure that people were going to — not 100% sure, but pretty sure that people are going to want these things, right? That they’re not going to be able to even do very much without these things.

When we launched it, that’s the feedback we got. These things are things people need. And so although we launched and people couldn’t use it right away because of those things, it did at least give us that confidence that we’re pushing forward on the right path, that our priorities are in order, and that these are things that we absolutely do need to knock out that people need. Yeah, I mean I see the value of just shipping it, for sure, and I wouldn’t have done — I think doing Mergebot differently, if we had tried to polish everything before getting people’s feedback, I think that would have been probably worse because we probably would have done some stuff that would have been unnecessary.

PIPPIN: I think there’s two kinds of maybe development areas where I think that these two philosophies can really apply. One is adding features or changing an existing product, whether it is removing or adding features or changing features. The other one is shipping brand new products.

I think the most dangerous trap is when you’re shipping a brand new product like Mergebot, for example. You spend months or years building this thing and only to discover that people don’t actually want it as much or that people wanted something different than you built. What you guys did with Mergebot was probably very, very smart by not only releasing a beta version, but also being very clear with what you were trying to build into it and getting that feedback from people.

BRAD: Yeah. I think if we were to start Mergebot again today, like if we could go back in time kind of thing, I think we would have even narrowed the problem space down to an even smaller thing so that we could get something out a lot sooner because it did take over a year in development to get the first beta out of this. Because the scope of what we were trying to fix was so big, that’s how long it took. But if we had to narrow that scope to, let’s say, solving the merging problem for WooCommerce or EDD or some plugin or some very small subset of data, I think that would have been maybe more manageable and we could have shipped in maybe 4 months or something instead of 18 months.

It’s tricky. It’s easy to say now, right? But it’s hard to foresee that when you’re in the moment.

PIPPIN: Another aspect, as developers and product creators, or really any kind of crafts person that works on things whether you’re talking about code or construction or some kind of hobby project or art project, when you work on the same thing for a really, really long time you get tired of it. You can get burnt out on it. You can stop seeing the value in it for what the value really is.

One of the things that I think is really, really healthy for creators to do is build new things a lot. Sometimes I think it’s really healthy to just sit down and hammer out something completely new and then just let it go. Basically build something, put it there, whether it’s on a piece of paper, on a screen, in a code editor, or in some kind of like physical art form.

Just doing it and pushing it out to people can be really, really healthy for us as creators, especially as developers because I think too often we get caught up in thinking about the, “Oh, I needed to do that one. I need to figure out that. I needed to take care of that problem. I need to add this, or I need to add this before it’s ready.” I think the effects not just on having somebody else come and use what you’ve built, but the internal mental effects of just building something and pushing it out and releasing it right away is really, really good for us.

There was a follow-up comment from John Jacoby in the Post Status Slack this morning on the same topic. John was at LoopConf where I was also last week, and he gave a talk about some Unix philosophies. He mentioned this in his comment. Anyway, here’s what he said.

BRAD: Hang on. Is this Unix like the operating system Unix?

PIPPIN: I would assume so. Yes.

BRAD: I guess the design of that operating system, so these are some of the philosophies in there?

PIPPIN: Some of the philosophies they use in building Unix.

BRAD: Okay.

PIPPIN: Yes.

BRAD: Okay. Yes.

PIPPIN: Here’s what John said. “One of the Unix philosophies I talked about at LoopConf is about prototyping early. I think that applies to both agencies and individuals. What doesn’t always happen with either group is the additional polish necessary to take an idea from prototype to production ready. The reasons for which could be time, budget, stress, personal, professional experience, et cetera. The best part of shipping is the byproduct. What did you learn? What other things did you do to do the thing that you tried to do?”

Then there’s a follow-up comment, but first need to give a little bit of info. John and I actually sat down at LoopConf and had a little code session for about eight hours in a bar. I had presented him with an idea of something I wanted to build, and we ended up just saying, hey, why don’t we go sit down and build it? And so we ended up building this plugin called WP Meta Manager.

Anyway, here’s what John said about that. “The byproduct of Pippin and I jamming on WP Meta Manager at LoopConf was feeling energized about writing crappy, raw code again.”

I think there’s two really important takeaways, at least for me in this. Number one is he’s right. A lot of people do just ship something and then don’t have the follow-through to actually continue polishing it to make it really production ready. They build a prototype and that’s as far as it gets.

On the flipside, sometimes just building a prototype and not worrying about the polish can be really, really healthy. What John said was feeling energized about it. It was really fun to just sit down and throw crappy code on the screen and just make something work out of nothing. That’s something I think some people get too caught up on with the polish. Now, when it comes time to actually release that as a final product, I think it is still really great if you can take the time to go ahead and find that polish.

BRAD: Right. You guys, I’m guessing you guys weren’t writing unit tests for your code.

PIPPIN: No, we didn’t write unit tests, but we were striving to write testable code, and I think we mostly did.

BRAD: Right. That’s good. That’s cool.

PIPPIN: Anyway, I think it’s an excellent discussion. If anybody listening has any follow-up comments or questions related to ship it versus polish, let us know.

BRAD: Yeah. I mean I guess to summarize what we both said, it’s just a balance. Isn’t that it? There is no easy answer to this.

PIPPIN: I think absolutely there’s definitely no easy answer.

BRAD: Right. Yeah. There you go, Travis. We haven’t helped you at all, but hopefully you can glean something from the discussion.

Our next question is from Scott Fennell, and he says, “How do you go about debugging front-end performance? How do I know if my JS is using too much CPU?”

PIPPIN: Ooh.

BRAD: Mm-hmm.

PIPPIN: Can I turn this over to you?

BRAD: No, I was hoping you knew the answer to this.

PIPPIN: I’ll be honest. Front-end performance testing, at least in the realm of JavaScript, is something I have not really done much of. I have had the opportunity to see some comparisons of, say, whether it’s a single piece of code or all of the code for a particular page and seeing a bad version and a good version. It is pretty astounding.

I think a lot of times, especially people that are primarily backend developers or system developers, tend to forget about or ignore front-end performance. Basically we can toss anything into JavaScript, whether it’s DOM manipulation like click actions or anything that we want and it’s going to be super fast. We’re not going to have any kind of performance slowdown because we’re not querying any databases. We’re not writing files. We’re not doing anything like that. I think that’s the attitude that we tend to have a lot of times, and it’s totally not true. We can destroy front-end performance with JavaScript very, very easily, so I think you should keep it in mind. Unfortunately, I really don’t have any tips for how to debug front-end performance.

BRAD: Yeah. I don’t either because, like you, I haven’t done it, really. Where I would start, though, is I would start with Chrome’s developer tools. I notice just opening it here right now that the profiles tab allows you to record a JavaScript CPU profile. I’d play around with that. I’d probably do some Googling to see what other people are doing with the console and the Chrome developer tools.

I know we had CPU. We had some JavaScript performance issues, although I guess they were more like DOM performance issues. What was happening with Migrate DB Pro is that we were adding. Like if you were migrating media files, let’s say, and you had like 10,000 or more media files, it would just add them all to the DOM for the progress, to display the progress. And so when you add 10,000 elements to the DOM, the browser starts to get pretty sluggish.

But I guess that’s not really JavaScript CPU. That’s more the DOM itself. Yeah, I don’t know, other than that. That’s the best I’ve got for you.

PIPPIN: All right. Moving on. Earlier we read a comment from Darren Ethier, and Darren also had a question or a topic that he had submitted a couple weeks ago. I think we had him on the list for the last episode and then we didn’t get to him. Anyway, Darren says, “Could you talk about what PHP features would make WordPress development easier if WordPress was no longer restricted by supporting PHP 5.2?”

BRAD: Yes.

PIPPIN: He gives–

BRAD: I have an answer for this because I actually did the research last week because this is not obvious, right? I had to actually look up what new features were added in PHP 5.3 to see what’s the difference between PHP 5.2 and 5.3. It’s not like 5.3 came out yesterday. PHP 5.3, I think, was released in 2007, so it’s been, well, a decade or just about.

Name spaces were introduced in PHP 5.3. Closures, also known as anonymous functions, so allowing your PHP code to look a little bit more like JavaScript. Late static binds were added. Jump labels, which I didn’t think was in any programming language besides–

PIPPIN: I have no idea what jump labels are.

BRAD: I know “go to,” you could say “go to” and you go to a label. It comes from Assembler kind of stuff, like label, jump labels. If I saw them in some PHP code, I think I might throw up a little bit in my mouth because it just seems wrong. Maybe I just don’t know how they’re supposed to be used in PHP.

Then another thing is magic methods, so methods like underscore underscore call static, and underscore underscore invoke. Those are just a few of the nice features that we could start to use in WordPress development if the day comes where we drop support for PHP 5.2. Those are pretty significant features, though, in PHP, right?

PIPPIN: Yeah, and that’s not taking into account any of the other major improvements that there are, as well as security problems that have been fixed. That’s just syntax, basically, that’s available in 5.3 and greater.

BRAD: Yeah, but I mean some of these features allow us to use other kinds of patterns in our programming. We’re limited right now by the features in PHP 5.2. It’s really interesting. Name spaces alone, to be able to organize the code better, I think that would be an interesting development. I know people have been talking about name spaces in the WordPress community.

PIPPIN: I think that the discussion that’s really interesting to have is, first of all, let me preface this by — for a moment, we’re going to completely ignore all of the other reasons to drop 5.2, from security to performance … et cetera, and only focus on the syntax that we have in 5.3 and greater. The discussion is basically, is there a significant something that can be done in 5.3, 5.4, 5.5, and 7 that cannot be done in 5.2? There’s tons. There’s a lot of syntax you can do, but I think it’s really interesting to look at actual examples, like for example for someone to put forth a feature or a something that they can build in 5.3+, and they cannot build it in 5.2.

I actually think that there are very, very few of those examples. Sometimes you have to be a little bit creative, but I think it is worthwhile to look at.

Don’t get me wrong. I’m not advocating to use 5.2 at all. I really–

BRAD: 5.2 for life, man!

PIPPIN: Upgrading everything that I have to 7 might be one of the best upgrades I’ve ever done.

BRAD: Absolutely. Yeah.

PIPPIN: But I do think it is interesting to look at what are — again, ignoring security, ignoring performance, ignoring some of those things, which should not be ignored. It’s only for this exercise. It is interesting to look at what you can do in 5.2 or what you can do in 5.3+ that you cannot do in 5.2.

Sometimes I think it’s an interesting challenge. Developers are problem solvers, and so take something that you cannot build in versions below 5.3 and find a way to build it in 5.2 is an interesting challenge. I think that’s a place that WordPress actually deserves a lot of credit for.

BRAD: Yeah, limitations is the friend of creativity, right? You’re able to be more creative when you have certain constraints that you have to get around.

Anyway, the next question is from Scott.

PIPPIN: I think we have time for probably two more.

BRAD: Yeah, sure. From Scott Fennell again. He says, “Do you have a plugin template that you recommend? I struggle with class architecture in each new plugin.”

All right. What do we got here?

PIPPIN: There are two pretty well known templates for plugins available, at least that I’m aware of. I’m sure there are many, many more. And lots of people, whether they’re independent developers or agencies, have built their own, but there are two main ones.

Number one is the WordPress Plugin Boilerplate Generator, which you can find at wppb.me. What it does is it basically gives you a base plugin. It gives you a form. You fill in your name, the slug, the URI, the author name, the author email, et cetera, and it builds you a basic template that you can then download and use as a start.

This template was originally based on Tom McFarland’s WP Plugin Boilerplate, which was a really good started plugin that Tom maintained for quite a while. As of recently, transferred it over to Devin Vinson, who I believe now maintains the boilerplate generator as well.

The other one is the WordPress Plugin Boilerplate, and that is at wppb.io. Now, I may be wrong, but these might actually be the same. Yes, these are the same project. He’s got two things, actually. He’s got one that is just the plain boilerplate that you can download and the rework yourself, and then he’s got one that actually is a generator that downloads a boilerplate with all of the names and such replaced for you.

BRAD: Oh, okay. I see.

PIPPIN: Which is super handy.

BRAD: Okay.

PIPPIN: We’ll include links to those in the show notes.

BRAD: Right. Yeah, yeah.

PIPPIN: But I think that’s probably the main one that people tend to use.

BRAD: Yeah, I think so.

PIPPIN: All right, so for our last question this is from Brady Vercher. He asks, “How do you handle and encourage responsible disclosure of security vulnerabilities?”

BRAD: Hmm.

PIPPIN: Do you guys have a formal method?

BRAD: No, we don’t have a formal method, I don’t think. I mean the responsible thing to do is to fix it, depending on the severity, right? If it’s a very severe security vulnerability, fix it immediately. Push out an update, and then let everyone know about it.

Sometimes, if it’s really serious, you should wait before so that people have a chance to update. We saw this recently with WordPress Core, the most recent version. I can’t remember the version number.

PIPPIN: 4.7.2.

BRAD: 4.7.1, is that right?

PIPPIN: 4.7.2.

BRAD: 4.7.2, yes. Yes, so they pushed 4.7.2 out. Then I think about a week later they let everyone know that there’s a serious vulnerability in 4.7.1 and that everyone needs to update if they haven’t already done so. I think that process seems to make a lot of sense to me.

Do you guys have a formal process, Pippin?

PIPPIN: Well, we have a couple of things. Number one, we have a security email address that people can email us. Two, we have a private security channel inside of our Slack rooms to be able to have a private, secure place that we can discuss security problems.

Then beyond that we have things like, on our GitHub repositories for example, inside of the contributing MD file and in our Read Me files we will often include a section about security vulnerabilities to try and prevent people from opening GitHub issues about security vulnerabilities. It just explains to them, hey, if you found a security vulnerability, please report it via this channel privately, and then we will work with you to get it tracked down and get it resolved.

I think that’s the main thing is first you just need to provide a way for people who have found something to report it to you privately, and you need to try to encourage that. And if you do get something reported publicly, say on a public support forum or via Twitter or Facebook, do what you can to get it removed ASAP, and then move that to a private channel.

BRAD: Right. Those are all very good things. I like the idea of having a dedicated email address for security stuff. Yeah.

PIPPIN: Another thing that I think a lot of people are probably unaware of is that if you have a WordPress plugin or a WordPress theme, it’s more likely to happen in a plugin, but it can happen in a theme too, and it has a security vulnerability, you can reach out to [email protected] or [email protected], and the teams there will work with you to get that resolved.

Now, if you have a commercial plugin, this is a different story because then it’s all hosted by you. But if it’s hosted on WordPress.org, reach out to the WordPress.org teams because, if it’s a severe enough vulnerability, they can help you actually push out an automatic update to all users of your plugin or your theme, which can dramatically deescalate the problem, especially if it’s a really secure vulnerability.

BRAD: Right. Cool. Should we wrap it up?

PIPPIN: All right. Yeah. Thank you, everyone, for your questions. We’ve got quite a few more, so we’ll probably do this again next episode or soon after that. If you have any other questions that you would like to see answered, send them to us on Twitter or Slack, or send them to us via email, whichever way is the easiest, and we’ll do our best to get them included.

BRAD: For sure. This is the part of the show where we usually thank our sponsor again, and that could be you. So if you’re interested in sponsoring, again, just head on over to our site ApplyFilters.fm, submit the form that’s there, and we can go from there. Thanks, everybody.