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

PIPPIN: Welcome back to Apply Filters, Episode 64. Today, Brad and I are going to talk about some of the things that we’ve been up to, a few blog posts that we’ve either written or read recently, some of Brad’s trip to WordCamp Europe in Vienna. But before we do that, let’s have a quick word from our sponsors.

BRAD: I registered my first ever domain name in 1999, 17 years ago. Back then there was one place to register domain names, a company called Network Solutions. Many of you probably already know this, but did you know that Network Solutions also has a WordPress hosting platform? They do.

It’s called Secure WordPress. It’s a managed WordPress hosting platform with an emphasis on security. They automatically keep WordPress core and your themes and plugins up to date. They have daily backups. They provide malware scanning and removal. And they put your site behind a data center class firewall to protect against zero day hacks and DDoS attacks.

They have expert tech support available 24/7 via chat and phone. Network Solutions takes care of keeping your site locked down and up to date, so you can focus on your business. Visit GetNetSol.com/ApplyFilters today to get started. That’s GetNetSol.com/ApplyFilters. And now back to the show.

All right, Pippin. What have you been up to, man?

PIPPIN: Well, the last couple weeks have been pretty busy with a couple of big plugin updates. We’ve been working on Easy Digital Downloads 2.6, which has been in progress since, I think, January is when our last major release, 2.5, was. It’s been about a 6-month development period, obviously with point releases in between. When we measure our development periods, we usually go major release to major release, so it’s been about six months for that.

We got that pushed out last week on Thursday, I believe, and so far it’s been a very smooth release. I’m very pleased. We have done two little point releases, 2.61 and 2.62, since then, but they were really to fix pretty minor issues. They weren’t even necessarily user or customer facing bugs. They were things that we realized that we needed for ourselves, and so we went ahead and pushed out updates.

2.6 is an update that we’re pretty happy with. It does a couple of things that have been on our want list for a long time with two major ones. The first one is we introduced native import options for payments and products.

Previously, let’s say that you had a CSV file of purchase records or products and you wanted to import those into your site. We had this free plugin called EDD CSV manager, and it’s one that one of our other team members and I wrote almost three years ago, two years ago, something like that. It worked okay, but it was outdated. It hadn’t progressed along with the rest of EDD, and it was pretty cumbersome and unreliable to use, especially on certain hosting environments.

We’ve been wanting to dramatically improve those, and so we did. We’ve introduced new import options that are directly in the core plugin for importing payments and products. They work off of our batch processing API that we’ve used pretty extensively throughout the plugin now so that they’re designed to be able to handle massive CSV files, hundreds or thousands or many, many thousands of products in the majoring of hosting cases. There are still some environments where we’ll have trouble processing massive files, but usually it works pretty well.

BRAD: I’m just looking at the user interface for this import tool. Has this been updated or has always been the same UI?

PIPPIN: Are you looking at the new one or the old one?

BRAD: I’m not sure. It’s the screenshot that’s in your release note, so I’m assuming it’s the new one.

PIPPIN: Okay, so that’s the new interface.

BRAD: Right.

PIPPIN: That’s only showing one stage of it. If you go to that screen, the first thing it’s going to show you, it’s going to ask you to upload a file. It’s going to then upload that file using AJAX upload. Then once it uploads a file, it does a couple things. First, it reads all of the columns from the CSV file. Then, two, it also reads the first row of the CSV to get sample data. Then what you’re given is you’re given a list of fields to map. And so for either payments or products, we have each of the fields.

If we’re talking about payments, let’s say you’re going to have a currency code. You’re going to have an email address, a mount, a products purchased, the date it was purchased, a status of the purchase, IP address, various things like that. Those are the ones that EDD needs to create the payment. Then you go into a mapping column and you pick each of the columns from the CSV that correspond to the EDD field.

BRAD: Is that new or is that what it was like before?

PIPPIN: The old UI had a similar mapping system, but it wasn’t as smooth or as reliable.

BRAD: Yeah. It looks good, man. This interface looks really intuitive.

PIPPIN: We think it’s pretty smooth, and then everything is AJAX, so there’s no page reloads for any of it, including the import process. So far we’ve been testing it, and it’s pretty reliable. We found one little issue with it that we’ll probably have to push out a point release again in a day or so, but otherwise not too bad.

There are two or actually three other major features that we added. First was we added support for customer records to have multiple email addresses, so everybody has multiple email addresses – almost everybody. You have maybe a personal email, a work email. Maybe you have multiple work emails or let’s say that there’s a team and so then there’s a billing@. There’s a support@. There’s an info@, et cetera. And so customers very frequently will purchase with multiple email addresses even though they’re the same person or team. We’ve added support for tracking multiple email addresses on a single customer record, and so then, regardless of which email it’s purchased from, it all gets tracked properly, so there’s kind of one canonical source as opposed to having three duplicated customers with different emails.

Then we added the ability to refund payments for PayPal Standard directly inside of EDD. It makes the refund process a little less painful. We figured nobody likes processing refunds, but at least we can make it a little bit easier and less painful, so we did that.

Then we also added a customer metadata API. Previously, if you wanted to store metadata for a customer such as a second email address, you had kind of two options for where to store it. You could store it on a purchase record or you could store it on user meta. Well, neither one of those were very good because, number one, a customer could have 20 payment records, so you don’t want that metadata duplicated. Then user meta is no good because not every single customer has a user account, so we introduced a new metadata table that you can store metadata for customers now.

We had some other things that were just kind of nice little improvements, and you can check them out at the release post. Beyond that, now actually there is one other thing that we did in 2.6. Actually, this wasn’t really in 2.6. It was 2.61 and 2.62. Since about two and a half years ago, EDD has had a usage tracking system in it, so a customer or a user installs EDD on their website and then they are given an option to opt-in to data tracking.

When they do this, it sends a report to our site. We log it in a database and then, once a week, their site checks in. As long as EDD is active and as long as they’re still opted into data tracking, their site will check in once a week. We’ve been running this for a while. We’ve collected a whole ton of data from about 75,000, 80,000 websites and it’s been very, very valuable for us. We’ve recently been working at aggregating our data and making it easier to query so that we can use it better.

Well, when we rebuilt our internal data system, we rebuilt the database, basically, and migrated it from one database to another database. When we did this, we realized a problem. We discovered that our weekly check-ins were never working, so the only data we actually had was from unique sites. We had 75,000 unique sites that had checked in, but we never had updated data from any of them, even if they had been running for two years because we discovered a couple of bugs in the way that our weekly check-in worked.

We figured it out and we pushed out an update that fixed it. We made a couple of changes. Number one, we made it so that any time you install an update now, it fires a check-in. Even if your weekly cron isn’t working, it’ll check in each time you update. That way we have updated information with the EDD version that’s used, the plugins that are on that site, et cetera.

It’s revealed some really interesting insights. First of all, we had graphs that we’ve built out that show us the breakdown of things like EDD versions, PHP version, locals, WordPress versions, server system, Apache, Nginx, et cetera. Originally most of our data was not very useful because, since we had about 75,000 websites and some of the data we had added in, things like the local, the server system, and the EDD version were not originally in our data tracking. We added them, so that meant that the only sites that we had that data for were the new ones, which was about maybe 2,000 websites. And so we had another 73,000 sites tracked that didn’t have any up-to-date information about them.

What’s been pretty cool to watch is, after we pushed out the 2.6 update, that data has just been flowing in insanely fast. We have a graph that shows our check-in, the number of check-ins per day and, over the last two years, it’s averaged around 652 check-ins a day of data being pushed to our site. Most of those were all brand new check-ins, so that’s about 600, 650 new installs or new opt-ins per day. That’s not per day. It’s around a few thousand a week.

Well, the moment we pushed out 2.62, that went from 635 on a graph point to over 2,000, which has then proceeded up to over 3,400. In the last 5 days we have updated something like 6,000 records on our site with up-to-date information about the data tracking, which is going to be very, very valuable for us because what it means now is, over the course of another month or two, as we get more and more sites updated to 2.62 and we get our data tracking working, we will have much more accurate information about the kinds of sites that are running EDD.

Now, there’s no personal information tracked. It’s only things like the EDD version, the other plugins installed, the WordPress version, et cetera. But it’s going to start giving us some pretty cool insights that we didn’t have before because our tracking wasn’t working properly.

BRAD: Right. As an example of a decision you could make there is you could look at, for example, how many people are using PHP 5.3 — what is it, the lowest one?

PIPPIN: Yep, 5.3 right now is 1% of the sites that we know about.

BRAD: Right, so if you drop 5.3 support for whatever reason, if you guys wanted to, it would affect–

PIPPIN: How many people does that affect, basically?

BRAD: Very, very few people.

PIPPIN: Right. Well, in a way. All right, so I’m going to give you a couple of examples because I think it’s fascinating. Of our PHP versions, right now we have over 75,000 sites. We have stats on 75,000 sites. Now, 91% of those are unknown. We don’t know the PHP version on them due to that because we didn’t originally track the PHP version.

A week ago, that 69,000 was at 75,000, so we know the stats for 6,0000 sites in the course of a week. In another two weeks, three weeks, or four weeks, we’ll have a much better percentage. But just to give you an idea, right now of the sites running EDD on PHP 5.2, there’s 161 known sites. 5.3 is 778 known sites. 5.4 is 2,772 known sites, PHP 7 is 269. The majority of sites right now are running PHP 5.4.

Now here’s another one that I think is fascinating, and this is one that’s super valuable for us. We want to make sure that we’re now only catering to the people that we maybe talk to the most or that we’re the most familiar with, a.k.a. English speakers. We want to make sure that we’re international friendly.

What do you think is the biggest local aside from English for us?

BRAD: Chinese.

PIPPIN: Incorrect. Farsi.

BRAD: Oh, wow.

PIPPIN: Yeah, so Farsi is the number two language that we know of for EDD installs, which tells us something very, very important. We need to make sure that our right to left support is perfect. These are the kinds of decisions that we can make when we start to have this accurate data. I’m really excited for the insights we’ll be able to have over the course of the next six months, as we get our data more and more up to date. This has been a pretty fun little thing to see after pushing out 2.6.

The last thing that we’ve been up to was Restrict Content Pro is getting a big update, which also happened to be version 2.6. We just published the beta version a couple of days ago. It’s got a few pretty nice things that we’re pretty excited for.

Number one, we’ve had this interface in Restrict Content Pro for a long time on the post and page edit screen for choosing how you restrict content. For example, is this post restricted to this subscription level or this subscription level or this user role? We’ve always known that the UI was not very intuitive because we get tickets every single week with people saying the restriction isn’t working. We go in and realize that they’ve simply done it wrong. They’ve done it wrong because our interface is unintuitive. Or they come to us and say, “I just don’t know what to do. I don’t know how to set it up the way that I want.”

The biggest change in 2.6 that we’ve done is we’ve said let’s rewrite this interface from scratch. Let’s figure out, with the various methods that we can restrict content, so like to specific subscription levels, to a tiered system called access levels, to user roles, et cetera. What does a UI look like that we feel would be a lot easier to understand. And so we built that. Then we worked backwards to try and figure out how to make that backwards compatible.

We’ve done that, and I’m really excited to see what kind of change that makes over the next six months in terms of the reduction in support tickets from people just knowing how to use it more intuitively because the interface is better. We’ve made all of our tables inside of CRP, which include a members list, a discount code list, a payment history list, subscription levels. These were all list tables, and they’ve never been responsive, and now they’re all fully responsive, which is nice, so you can actually manage your membership site from mobile a lot easier, which is nice.

BRAD: I have a question about designing your products. Who does the design for your products?

PIPPIN: You mean like logos and mascots and such?

BRAD: No, I mean user experience design of the product itself. Who designs your setting screens?

PIPPIN: It’s all in-house. We don’t do anything external unless there’s somebody that just happens to volunteer and provide some feedback.

BRAD: Right. Andrew is a designer on your team, right?

PIPPIN: Mm-hmm.

BRAD: Does he get in there and do mockups or anything like that?

PIPPIN: It depends on the plugin. Each one of our major projects is segregated in terms of the team that works on it, so there’s an EDD team. There’s an Affiliate WP team. There’s an RCP team. And so it’s members of that team.

Then we try to get feedback across teams, especially because it kind of gives you fresh eyes. Usually it’s if I’m working on an issue, like for example I worked out rebuilding the interface, so that was me first building just kind of a here’s my suggestion. Here’s my idea. Pass it over to John. He gives me feedback on it and kind of go from there.

Then, like for this one in particular, once we had a rough mockup, we decided then to reach out to the EDD side of things and say, “Hey, guys. You’re familiar enough with RCP. What do you think? Does this make sense to you? Is this better than it was?” And that’s usually how it works.

BRAD: Okay. Cool.

PIPPIN: What else is new in RCP 2.6? We added the ability. With Restrict Content Pro, when you’re restricting the content on a site, most of the time we’re working through a filter called The Content, so we’re modifying the actual main content area of posts, pages, et cetera. Then we’re either hiding that content, modifying it, or showing it depending on privileges of the user that’s logged in.

A request that we’ve had for a long time is to automatically hide comments on restricted blog posts. Let’s say that you have a blog post restricted to paid subscribers and then it has a whole bunch of comments on it, you should not be able to read those comments unless you are also a paid subscriber. That has never been supported and now it’s supported in 2.6.

In both EDD and RCP 2.6 updates, we added tool tips. For some reason I’ve always been a little bit against adding tool tips throughout a plugin. Part of it is the idea that I’ve always felt that interfaces should be self-explanatory and that if you need a tool tip, that says something is wrong with the interface. There’s a couple of ways to react to that, but one is you just say, okay; if people are having trouble with an interface and you need a tool tip, we should work on redesigning that interface so that you don’t need one any more. The other one is to say, well, why don’t we just add a tool tip because that’s probably easier than figuring out what works or what doesn’t in an interface? I don’t know. I still don’t love having a bunch of tool tips inside of an interface, but we did decide to add them.

BRAD: Yeah. I don’t like the idea of having little question marks next to everything. You’ve got a dozen or more frickin’ question marks on a screen.

PIPPIN: Yeah.

BRAD: It looks just like kind of a cartoon, like question mark, question mark, question mark, question mark.

PIPPIN: It has always kind of bothered me, but I think, at the same time, there’s a level of compromise you have to have to say, look; even if we make a great interface, there’s still going to be users that won’t get it the way that you intended, and it’s not because they’re a dumb user or anything like that. It’s just everybody reads and perceives things differently, and everybody has different levels of knowledge. Some people know what a term is. Some don’t. I think that you kind of have to try and find that middle ground of, okay, well, we can’t fix an interface problem with a tool tip, but it’s one more way to help customers help themselves.

BRAD: Right. Yeah, we’ve been experimenting. We have tool tips in both of our products. I feel the same way about it. I don’t like adding tons of question marks.

One thing we’ve done, instead of adding question mark icons for tool tips, we add more links to our documentation on our site. That way you can actually expand even more and provide a really rich body of information related to whatever that thing is that people might want more information on. I like that idea. I like people being able to really dig into things.

PIPPIN: Yeah, that’s something that we’ve been trying to do as well. For example, in the new import options that we added to 2.6 in EDD we made sure to include links to documentation inside of those because people are not going to know what every single feed hold that EDD wants is or they don’t know what format of data it needs to be in or how do they map their CSV file. That’s just one example. I think you’re absolutely right that that’s something we should be doing more often. Not to mention, if you add a link to a documentation, you can update that doc any time.

BRAD: In real time, yeah.

PIPPIN: Yes.

BRAD: That’s another reason to do it. I also like the idea of just adding links to labels, just making them discoverable so like when people hover over the status label or whatever, they can just click on it to get more information. It doesn’t have to be an icon or more info link. It doesn’t have to be so explicit. It just needs to be clickable. Yeah, we haven’t gone that route yet. We still do more info and little question mark icons, but a UI should be, I think, more like the Web in that way that things are just clickable, you know.

PIPPIN: Yeah, I totally agree.

BRAD: Yeah.

PIPPIN: Yeah, so that’s something that I always want to strive for. But, at the end of the day, there’s only so many things that you can do and sometimes redesigning your UI and doing user testing on it and doing all of these things to try to make an informed decision as opposed to a guess takes a lot more time than adding a little bit of help.

Two other things or a couple other things we added in RCP 2.6 that I’m excited for: number one, we added support for Alipay through Stripe. Anybody who is not familiar with it, it’s a Chinese payment processor that is very widely used in the Chinese market. Stripe actually natively supports it through their Stripe checkout system, and so we’ve added support for that so memberships can now be purchased through Alipay.

We added a new add-ons page to the main menu inside of Restrict Content Pro. Now, this is something that we discovered in EDD that surprised us a lot. There are a lot of plugins out there that will have multiple screens. They have a settings screen. They have various configuration screens. Then a lot of times they’ll have maybe an add-ons page or an upgrade screen or something that’s showing the premium upgrades, showing you what you can get if you buy the pro version.

For a long time I’ve not been super fond of them. They’re not something I’ve had a great love for, for one because, as a user, I didn’t love them. Then two, as a product owner, I always just assumed that they weren’t very valuable. Wrong! It turns out that, for example, the add-ons page inside of EDD is one of our number one drivers of sales to the site of all sources. It beats out all of our social campaigns. It beats all of our email campaigns. It beats everything. It is the number one driver of sales, which we found very interesting, not to mention valuable.

And so we added it. We added an add-ons page just like EDD has to RCP to show, hey, these are the various add-ons that we have that are available as part of the pro license and also here are some free add-ons that we have, and things like that. I’ll be very interested to see, once 2.6 goes out, if we see an uptick in upgrades because of that.

BRAD: Yeah. It’s a little different because there is no free version of Restrict Content Pro, right?

PIPPIN: You’re correct.

BRAD: Yeah, so it’s a little different situation, so probably not going to have the same impact.

PIPPIN: No.

BRAD: But maybe it’ll move the needle a little bit.

PIPPIN: Yeah.

BRAD: So that’d be cool.

PIPPIN: It’d be interesting. We know that people look at it at least, and then three other things that we did in it that will be interesting. Number one, we used to have some very defined CSS on the registration screen that forced some WITs for labels and input fields. Early on I made a decision that I felt RCP’s registration form should always look the same on a site instead of having a theme define the WITs and the sizes and the alignments of input fields and labels because, if we can create a consistent experience, that’s probably better than inconsistent experience that depends upon a theme.

Sometimes you’re going to have problems with it because sometimes it’s going to clash a little bit of somebody wants a slightly different styling. But we’ve decided to move away from that and so now we’ve removed some of our CSS for the default registration forms. It’ll be interesting because one thing that we’ve discovered is that the biggest area that people get really, really uptight when it comes to updates to a plugin is the front end of their site for membership and e-commerce sites. And if you change any element of the front end it can be disastrous in their experience, in their mind. Not to mitigate it as a problem, but I’ll be interested to see if our 2.6 update causes significant problems because we’ve removed a WIT from the labels.

Honestly, we probably shouldn’t have had them there in the first place. Basically it used to be that the labels and the input fields on the registration form would be side-by-side. Now, unless your theme styles them and puts them side-by-side, they’re going to be on top of each other. We went from a shorter form to a longer form by default because we removed our styling. It might be something that we have to roll back because people aren’t happy with it, but we’ll see.

BRAD: You know what I would do for the people that aren’t happy with it?

PIPPIN: Provide the CSS that they can drop in?

BRAD: Exactly.

PIPPIN: Yep, that’s what we already plan to do.

BRAD: People that are upset, all they care about is fixing it.

PIPPIN: True.

BRAD: They don’t really care how.

PIPPIN: That is totally true. Then we also added subscription payment meta APIs, which is kind of like the customer metadata API that we added to EDD, so we can now track metadata for payments and subscription records. Lastly, we added better invoices to RCP. If you, as a customer, make a payment and you want to view that invoice, you can do that. It used to be that we provided PDF invoices to download. Have you ever looked at how large a PDF library is?

BRAD: Yeah.

PIPPIN: Giant! So we ripped it out, and we replaced it with a simple HTML invoice, and we dropped the size of the plugin by 10 megabytes.

BRAD: Wow.

PIPPIN: The original plugin is something like 11 megabytes, and 10 of that is from the PDF processing, which is just crazy, so we ripped it out and I’m pretty happy to have it gone. Anyway, that’s what we’ve been up to, and I’d say that’s enough about me. I’ve been rambling for a while. Brad, what have you and your team been up to?

BRAD: Well, we just got back from our company retreat in Vienna, which we organized it around WordCamp Europe. We rented an apartment right in the center of Vienna. It happened to be a rooftop apartment, so beautiful views, really well lit apartment, and so it was just a really nice space. We had trouble with our apartment last year for our first ever company retreat.

PIPPIN: I was about to ask how does it compare.

BRAD: It’s night and day. Just stress free. The host met me and welcomed me, and the place was just perfectly clean. There was just–

PIPPIN: Plenty better experience.

BRAD: Aah, it was just so good. In fact, so it was really hot during our week there. For probably three or four days, actually, it was 36 degrees (Celsius) plus, which is 90 Fahrenheit, I think.

PIPPIN: I think that’s about right.

BRAD: Something like that. Anyway, it was hot, really hot, and all the buildings that we went to ended up being pretty hot, even the ones that were air-conditioned. The air conditioning wasn’t turned up very high. Our apartment was like a meat locker. Every time we’d come back, it was just refreshing just to enter it. Yeah, the apartment was excellent.

We didn’t do a whole lot of work. It’s so hard to work together at the same table, especially when you’re a remote team and you’re not used to it. We just ended up chatting a lot, so we’d get through support and then that would be basically it. There was no way to focus on doing some development or anything. We just had a really hard time.

PIPPIN: That’s always been my experience with team meet ups. I think that’s super valuable, but I think it’s important to try and maybe change what your goal is to focus on. Instead of saying, all right, we’re going to all sit together and we’re going to just pound out code for a while. Instead maybe, at least in my experience, better to treat it as a brainstorming session because you have everybody there and you can bounce ideas back and forth really quick. Then when you go home, then act on it.

BRAD: Yeah. Absolutely, and that’s what we did. We had pretty low expectations for actually getting work done, so it wasn’t like we felt like we failed or something.

We were only there for two full days before WordCamp Europe started, which did feel kind of short, so we’re thinking about the next company retreat maybe not doing it around an event, just doing our own thing, picking a location and going, just ourselves, or maybe inviting some other product teams to join us to do their retreats at the same time or something. That was another idea we had. We’ll see. It’s a whole year to plan it, so we’ll see.

A couple of things that we decided on that came out of the conversations that we were having: we were talking about testing quite a bit lately, like stopping manual testing so much. When we test a release, usually we put three developers on testing and they do it in kind of a relay format. One developer will start testing. It’ll take them two or three days. Then the next developer will start and it’ll take them two or three days, et cetera.

It takes a long time. It takes up a lot of our developer’s time and it’s boring as hell because you’re just going through this manual testing spreadsheet and just performing these tests that pretty much anyone could do. What I’ve seen done in the past is build a QA team, right? Build a team that just does this for you, that goes through the spreadsheets and does the testing.

Just before we left on our company retreat, I stumbled on this video by Trish Khoo from Google. Her talk was called Rock Solid Software Testing Without Hiring an Army, so it was exactly contrary to the strategy that I had started implementing. The video really upset my whole idea of what we should be doing for testing.

I got all the members of the team to watch it before they left for Vienna, and so we had this conversation. Everyone was on the same page. We had this conversation face-to-face, and everyone was on the same page on this that the video was right. That we should put all our effort into automating our testing and stop this madness of doing the manual testing and trying to get other people to do the manual testing. And that it’s worth it, that it’s totally worth it to spend the time and energy to develop and maintain the automated tests versus the energy and overhead of building a QA team and managing that.

PIPPIN: In this case automated test being not only things like PHP unit test, but also UI tests.

BRAD: Yeah, so both unit tests and integration tests and acceptance tests, so the whole thing. The thing is, though, what was incredible is doing this face-to-face was everyone was enthusiastic about it and we decided on what to do. Instead of just talking about it, what we were going to do to implement it. And so Ian Jones, one of our team members, volunteered to be the test guy and that’s all he does–well, for the foreseeable future–is crank out tests and strengthen our testing and start eliminating the manual testing.

But then we thought, you know what? Let’s make this. Let’s speed this up. And so Jeff is going to do the Migrate DB Pro unit tests and start beefing those up at the same time Ian is working on beefing up the ones for WP Offload S3. We’re really aggressively tackling this problem because every time we do a release right now it sets us back because all this manual testing takes so much effort to accomplish. And every time we do it, we just have to do it again, so it’s just compounding. If we can eliminate this, the sooner the better that we eliminate this.

It’s one of those things that’s hard to prioritize from a business perspective because it’s not going to cause new customers, but it needs to be done.

PIPPIN: Right.

BRAD: It’s just not sustainable. There’s no other way to do it sustainably, I don’t think.

PIPPIN: Well, and there are a couple of things that are going to happen once you have it in. Number one, you’re going to lose fewer customers, theoretically, assuming your testing is done well, because you’re going to have fewer problems between updates that frustrate customers, so less likely for somebody to leave. Two, it may take, say, 50 hours to get it all set up, but on every release after that it may save 150 hours.

BRAD: Yes, exactly.

PIPPIN: And that’s huge.

BRAD: Yeah, and the confidence of being able to push out a minor release without the worry that, oh, we didn’t run through all the tests, so there could be something that we didn’t cover that we didn’t test.

PIPPIN: Which is so easy to do.

BRAD: Sure. Yeah, absolutely.

PIPPIN: Especially if a major release has 30 bugs fixed and 5 new features and 27 minor enhancements. Something will be missed.

BRAD: Yeah and, as a team, we’ve kind of taken the approach of don’t refactor things because–

PIPPIN: …refactoring?

BRAD: Well, if you refactor something, you’re very likely to introduce bugs, right? But that’s where unit tests can save your bacon, right?

PIPPIN: Absolutely. Right now, in RCP 2.6, I told you we refactored our UI. Our unit tests are failing right now with that. They were not failing beforehand, and so we broke something. We’re not sure what we broke yet, but we know we broke it. We’ve been trying to track it down, and it’s just an example where, hey, get those tests in.

BRAD: Yeah, absolutely. Refactoring is good because it removes technical debt. It can make things more readable for developers, more pleasant to develop with. There are tons of benefits to refactoring, but the downside is always it’s not broken now. Refactoring is likely to introduce bugs.

PIPPIN: I’m excited because in the next few months or over the last three months we’ve been putting in a ton of unit tests for Affiliate WP. Affiliate WP always had very minimal unit tests in because of me. I didn’t get around to it. Since Drew and Rahmi have come onboard and are working on, we’ve had a lot more time to be able to actually put in a lot of tests, and so I think, in the last three months, we’ve added 200 or 300 unit tests to it.

BRAD: Yeah.

PIPPIN: That might be for the future.

BRAD: If you test manually over and over again, unit tests actually become satisfying to write because–

PIPPIN: Oh, yeah.

BRAD: –you’re realizing you’re automating things, so you’ll never have to run this test manually again, right? You won’t have to step through the UI or whatever to test this again. That’s so valuable. It’s so satisfying to get that. It’s like automating anything. It’s got that feeling of satisfaction.

Another thing we decided on our retreat was that we were going to have more retreats. We’re going to start doing regional retreats every year.

PIPPIN: Regional meaning like the team members that are in that region?

BRAD: Yes, so North American team members will be going to WordCamp U.S. this December, and the U.K. contingent will be going to something closer to home, maybe something in Ireland or who knows. They have yet to decide.

Yeah, so just kind of less of a commitment travel wise and maybe time wise maybe it’s shorter as well, so maybe we go to WordCamp U.S. and that’s only like three or four days or something versus an entire week. At least half the team gets to see each other every six months.

PIPPIN: We’ve been kind of doing that for, I don’t know, a year or two and I really like it. Not even really with formal retreats. More of just, hey, let’s try to make sure that we get face time, even if it’s just two members, three members, or four members multiple times a year. And so we try to get a couple people at a WordCamp, a couple people at that camp. A couple people — oh, hey, let’s fly somebody in and let’s just hang out for a few days. I think those are super valuable.

BRAD: Right. Yeah. Then just a note on WordCamp Europe: It was a good camp. I enjoyed it. It was really hot in the auditoriums and stuff. I tend to kind of hang out in the hallway most camps anyway and just chat with people, catch up, and so I did a lot of that again, which is always great. There were lots of new people that I could meet that went to WordCamp Europe that wouldn’t normally go to, let’s say, WordCamp Miami or WordCamp U.S., so that was really cool.

I’ve gotten a few people came up to me and just was super excited about Apply Filters and just gave us some encouragement saying, you know, keep up the good work and I really love the show.

PIPPIN: Did you wear your Apply Filters T-shirt?

BRAD: I didn’t because it’s cotton.

PIPPIN: You are fired!

BRAD: I did, but then I had to come home and change because it was so hot. Yeah, a cotton T-shirt in that weather was just kind of gross, so I didn’t wear my cotton shirts.

PIPPIN: It sounded like a great event, and I was originally planning to go. I had been accepted to speak at it as well. About two months ago I backed out of it. My wife and I just decided, you know, let’s spend a summer at home not really doing much. We travel a lot, and it was the right choice. We’ve been enjoying just kind of hanging around.

BRAD: Yeah, I hear that. I’m pretty much done for the summer for traveling and stuff.

PIPPIN: Yeah. I have a couple of little regional trips. I drive back and forth between Kansas City, which is about three hours from me, and that’s kind of like a weekend trip for me, and then I’ll be driving down to Austin tomorrow for a completely unrelated, non-work-related event. Then after that my next trip is LoopConf in October, and I’ve been enjoying not traveling as much as I usually do.

BRAD: Yeah. Yeah, it’s nice just to stick around home for a while. Yeah.

PIPPIN: Yeah.

BRAD: A couple other things–

PIPPIN: What else have you got?

BRAD: A couple other things: We’re launching automatic renewals pretty soon on our site.

PIPPIN: Fantastic.

BRAD: Getting close.

PIPPIN: So you say pretty soon. Do you have a rough date or a set date?

BRAD: Yeah, so we’re recording this on June 30th. I’m thinking tomorrow, so July 1st – maybe. I’m traveling tomorrow.

PIPPIN: If you’re releasing tomorrow, shouldn’t that be a definite?

BRAD: Well, so I’m traveling. Tomorrow is a holiday here in Canada, so I’m traveling tomorrow morning. But when I get to my parent’s place, I may launch it then because I won’t be on the road for three or four days, and it’s the weekend. I like launching things on the weekend because it’s low volume in terms of sales, and this is a holiday weekend too, so it’s going to be even lower volume, so it’s a good time to kick the tires, I think, in production. We’ll see. I just don’t know. We’ll see what happens when I get there, how I feel. The thing is, I have to stay near the computer the whole weekend, right?

PIPPIN: Yeah, absolutely. I remember when we launched our first auto renewals. We were pushing updates to the site every hour, every two hours just fixing little issues that we found. Now, granted, we were doing that while also simultaneously beta testing our own plugin, so it was maybe a little bit of a different scenario, but still it’s a big change, so you want to be around.

BRAD: Right. Yeah, exactly. Oh, and also this should have been at the top of the show, not as a footnote, but I’m going to say it now anyway. Peter Tasker is joining our team full time on Monday, on July 4th. He’s Canadian, so that’s not a holiday if you’re wondering. Yeah, so we’re adding a full-time team member, which is super cool.

PIPPIN: Very cool. What’s he going to be focusing on?

BRAD: He’ll be working on Migrate DB Pro to start, so helping to push that forward and help with support. Yeah, so hopefully that means that releases will speed up a little bit for Migrate DB Pro.

PIPPIN: That’s exciting.

BRAD: Yeah, very. Well, I mean, actually releases probably won’t speed up because Jeff is doing unit tests full time.

PIPPIN: Right.

BRAD: We’re still going to be back to two people working on the release. Probably releases will be about the same for now, but in the future may be faster because we’ll have unit tests.

We already have unit tests. I think we have 16% or 18% coverage right now, so we’ve got a good start, but we have no automated acceptance tests. There’s a lot of work to be done there. But anyways–

PIPPIN: Very cool.

BRAD: Should we mention some of the blog posts we’ve been writing?

PIPPIN: Yeah. What have you written about? Maybe we’ll talk about it next episode. Anybody who wants to kind of get a heads up on it, go read it, and then chime in in two weeks.

BRAD: Yeah. Yeah, or maybe even ping us on Twitter that you really want to hear about it and maybe offer a question or two. We’d be happy to answer those questions as part of the episode.

I wrote a post titled: Hey WordPress Developers, Your Clients Should Own Their Plugin Licenses, because what I’ve seen is a lot of times developers will buy a license for their client or they’ll just use their own developer license when they build a site for a client. Then they walk away and the license expires a year later and the client tries to update the plugin. It doesn’t update and they’re left with an outdated plugin on their site with security vulnerabilities, et cetera. Yeah, I go through all kinds of reasons why that’s bad.

PIPPIN: I read this post right after you released it. I love it and I agree 110%. It reminded me of a rant that I went on a year and a half ago on the exact same subject. We had a customer come in and, well, I won’t…. We’ll talk about it next time.

BRAD: Yeah, we’ll go into it.

PIPPIN: Awesome post….

BRAD: Yeah. Anyway, check out the post. What have you been writing?

PIPPIN: I’ve got a couple that I’ve written. Some of these are actually a couple weeks old. One of them I titled: The Monster that is a Poor Database Schema.

We’ve been slowly, slowly working on moving all of our EDD data into custom tables, so not products, but payment records, customer records, license keys, et cetera. We want to move all of them into custom tables for performance reasons and such like that because, as we’ve discovered, the WordPress post table is a terrible place for e-commerce data. We can go into more details about that in the next episode.

But anyway, I wrote a post describing it as a bit of a monster and just how do you deal with it. How do you work on transitioning that data? What are some of the things we have to think about when you introduce a new schema and then migrate all your data over? There are so many caveats, so many challenges, and it’s something that you have to work on over a long period of time. It’s not a: okay, let’s build it in two weeks and we’re done. Not if you care about your user base anyway.

BRAD: Right.

PIPPIN: I did that.

BRAD: Did Andrew do the artwork for that post?

PIPPIN: Yes, Andrew does all of the artwork on PippinsPlugins.com.

BRAD: Yeah, it’s a cute little monster.

PIPPIN: Yeah. Actually, I have two other posts that I wrote. One of them is I started a new personal blog recently on my other domain name outside of PippinsPlugins.com. PippinsPlugins.com is really just for WordPress work related stuff and, for a long time, I’ve wanted to have a new place to write a little bit more personal stuff or maybe stuff that isn’t associated with business directly or isn’t WordPress related, and so I launched a new site at Pippin.com a few weeks ago.

I wrote a blog post called Escaping the Tyranny of My Desk. It’s a little short thing, but it’s something that I’ve been thinking about a lot. Look, as remote workers, we have the ability to work anywhere as long as we have a wi-fi connection. Sometimes we don’t even need a wi-fi connection. The idea that we spend most of our lives in a two-foot square in front of our desk and allow ourselves to suffer the physical consequences, the health consequences of that over years, the fact that we do that is crazy to me, and so I’ve been very actively trying to do better myself at getting away from that and working in other locations, taking advantage of the fact that I can work from anywhere, whether that’s traveling to different parts of the world or traveling to a different part of my city. A little bit of a personal health thing, for me at least.

Then I wrote one other called Extending the WordPress Metadata API. Earlier I mentioned that in EDD 2.6 we introduced customer meta, and in RCP 2.6 we are introducing payment meta and subscription meta. About a year ago we introduced affiliate meta inside of Affiliate WP. All of these extend the WordPress metadata API, and so I wrote a tutorial about that, finally. I think it’s a little known feature of the WordPress database system and the metadata API that you can add custom metadata APIs, and it works very, very well.

BRAD: Very cool.

PIPPIN: Anyway, we’ll talk about all of these next time in depth.

BRAD: Yeah, for sure.

PIPPIN: Awesome. Anything else you want to add, Brad, before we close down?

BRAD: No, we should wrap it up.

PIPPIN: Awesome. Thanks for chiming in, everybody. Brad, it sounds like you guys had an awesome trip.

BRAD: Yeah.

PIPPIN: We’ll talk very soon.

BRAD: Yeah. Talk to you next time.