February 18, 2016

Apply Filters
Apply Filters
Episode 55: Automatic Renewals, Vagrant vs. Docker, and Varnish
Loading
/

Welcome to Apply Filters, Episode 55.  We’d like to let you know that we do have an open sponsorship available. You can sponsor an episode, a series, whatever works for you –  check out our Sponsors page for more information on the opportunity.

It’s been awhile since our last update episode and we’ve been pretty busy so we’ll do our best to get it all in. Today we’ll also be talking about automatic renewals for our plug ins and the challenges of implementing automatic renewals for code.

Pippin’s update:

Pippin returned from New Zealand after a two week trip to visit his teammate Andrew Monroe, who works on Easy Digital Downloads and Affiliate WP with him and is the master behind the site design for Affiliate WP, Pippin’s Plugins, and Restricted Content Pro. While down there, he expanded his team by two.

He also brought on a developer to do some work on the next version of Restricted Content Pro. All these additions have been instrumental in getting the recurring payments plugin for EDD built. He’s also added an update to WP for Sign-Up Referrals and is now available for free download.

Brad’s Update

Just welcomed a new full time developer, Matt Shaw. They just did two major releases last week, the first was Assets Add-On 1.1 for WP Offload S3 and it’s a big improvement. Ashley wrote a blog post about the release.

They also released a Multi Site Tools Addon 1.1. It allows you to push a subsite from a multisite install to a single site install, so basically spin out a subsite as it’s own standalone. And it goes the other way-from a single site install you can pull in a multisite install.

Brad’s team has also been busy blogging, a recent one comparing Vagrant to Docker, one of the most popular recent posts. Ashley did a post and published a library on Github for doing background processing on WordPress themes, Jeff did a review on WPPusher, and Brad’s looked into Varnish Cache. They also had the opportunity to check out the Day of Rest Conference on which they’ve written a review.

In today’s episode we’ll will talk about automatic renewals

  • What exactly is an automatic renewal
  • Combining licenses into one key
  • Issues and solutions with Paypal

Resources mentioned in this podcast:

If you’re enjoying the show we sure would appreciate a Review in iTunes.  Thanks!

Transcript

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 55. This time Pippin and I will be talking about whether or not we should have automatic renewals for our plugins and the challenges of implementing automatic renewals in code.

I guess we’re going to give our updates first, and it’s been a long time, right? How are you doing, Pippin?

PIPPIN: I’m doing good. It’s definitely been a long time since we’ve done an update. Our last episode was with Carrie Dils, and we kind of jumped right into the subject matter there, so I know we’ve been busy for the last, well, it’s been at least a month to a month and a half since we’ve done an update. I’m sure you guys have been just as busy.

BRAD: Yeah, man. I’ve got all kinds of stuff to share. I had to cut some stuff out.

PIPPIN: Yeah, we can’t get everything in either.

BRAD: Yeah, it’s right. But first, I just want to mention that we have a sponsorship spot available for kind of like ongoing, like if you want to sponsor our show for X number of episodes or kind of semi-permanently, we have a spot available.

PIPPIN: Or a single episode.

BRAD: Yeah, or a single episode. Whatever.

PIPPIN: Just shoot us an email from the website, especially if you have a product or a service that you would like us to check out. We’d be more than happy to review it.

BRAD: Cool. What have you been up to, then, Pippin?

PIPPIN: Well, as I mentioned in the last episode, I got back from a trip to New Zealand. Maybe our last episode was right before I went to New Zealand. Dang! Now I don’t even remember, but I went to New Zealand for about two weeks.

My wife and kids and I went down, and we visited my teammate Andrew, Andrew Monroe, who works on Easy Digital Downloads and Affiliate WP with me. He’s also the master behind all of the site design for Affiliate WP, Pippins Plugins, and Restrict Content Pro. Went down and visited him and visited, just explored New Zealand for a while. It was awesome.

BRAD: Cool. Were you on the north island or the south island?

PIPPIN: North island, so we were in Auckland, which is one of the main cities, and we stayed in Auckland the whole time. We ventured out and went to various places.

BRAD: Okay. I did quite a bit of touring around the north island. I haven’t gotten to the south island.

PIPPIN: Oh, fantastic.

BRAD: Did you check out Tulum while you were there?

PIPPIN: No, that doesn’t ring a bell.

BRAD: I think it’s called Tulum. I might be wrong. That’s where I did a skydive. Tulum is like a big crater, basically. It was like the biggest — you know what? It’s not Tulum. Tulum is in Mexico.

PIPPIN: Slightly different part of the world.

BRAD: Yeah. No, it’s something like that though. Anyway, I’ll describe it. It’s like this giant lake that was created by the largest volcanic eruption ever recorded.

PIPPIN: I have heard of that.

BRAD: The Chinese, in ancient times, recorded it in their history books and, at the same time, the Roman Empire did as well. It was a huge event. There it is: Taupo, Lake Taupo.

PIPPIN: I’ve heard of that.

BRAD: Yeah.

PIPPIN: I think Andrew mentioned it to us and was definitely an option to go look at, but we didn’t make it up there.

BRAD: It’s pretty far from Auckland.

PIPPIN: Sure. I really want to go back now. I want to go explore all of the south island and more of the north island. It was a great time. Definitely looking forward to going back again.

One of our other contributors is down there, Lisa Gibson. She does a lot of work on Affiliate WP and starting to do more on EDD and the other projects as well, and so she’s also in Auckland, and got to go meet her face-to-face for the first time, and it was nice to put a face to a name. It’s a good time.

While we were down there, we also expanded our team. We added two new part-time support people to Easy Digital Downloads.

BRAD: You just went to New Zealand and just started hiring the first people that you saw or what?

PIPPIN: Well, one is in the U.S. and one is Canada, so I had to leave the country to hire them.

BRAD: Okay.

PIPPIN: Yeah, so we went down, and it was actually kind of unplanned, but we had an impromptu team meeting and just decided, "You know what? We’re a little overwhelmed. We need more people onboard. We need to get some more help in support," and so I sent out some quick messages, and we got a couple of people interested. We had them going the next day.

BRAD: Are those people that were already contributing somehow to EDD?

PIPPIN: Yes. Yes. Barbara Atkinson, she joined us. She is the developer of a theme called Square Code that’s been on ThemeForest for a while, as well as many other themes. She and her husband run a themed business called Creative. Square Code is actually an EDD marketplace theme, so she was already very well versed in EDD, knew the system pretty well, and so it was a no-brainer pick for us.

Then the other one is Phil Johnston, who is the owner of Mint Themes and Mint Plugins, and has also done a lot of EDD work over the last couple of years, and so again was pretty much a no-brainer pick when both of them emailed back that they were interested. And so, they’ve now been working in the support for EDD for three weeks now, and everything is going great. It’s made an amazing difference.

It actually was just kind of cool. I wanted to look and see what does adding two people do to our stats in terms of, like, our ticket stats. I realized that it has improved the number of emails that we send out by 30%. It has increased the number of tickets that we close by 30%, and has decreased the number of tickets that each individual person handles by like 30% or 40%.

BRAD: Wow. That’s impressive.

PIPPIN: It was definitely, I think, the right move for us at the time. We also, about the same time, or actually just a little later, a couple of days ago we brought on another part-time developer to at least do a four-week development period to work on RCP (Restrict Content Pro) for about 15 hours a week to do some major improvements and see if we can get our next major version pushed out in the next month or so. That will be great as well.

All of that has also been very, very helpful in allowing us to get a big project wrapped up, which has been the rebuild of our recurring payments plugin for EDD that we’ve had. We’ve had a recurring payments plugin for EDD for nearly three years now, but it was always kind of lackluster. It never did quite what I wanted. To me, it felt like an NVP and not much more than that.

BRAD: Was that plugin, were you using that yourself on your site?

PIPPIN: We have never used it ourselves.

BRAD: Okay. What do you guys use then?

PIPPIN: For which?

BRAD: For automatically renewing licenses and stuff.

PIPPIN: Well, that’s a brand new thing, which I guess we’re going to get into here in a little bit. That was one of the reasons for completely rebuilding recurring payments.

BRAD: Oh, right, so people don’t actually automatically renew. They get the email, and then they manually renew.

PIPPIN: Right. Our license renewals have always been manual.

BRAD: Right.

PIPPIN: We’ll get into this discussion a little bit, but we’ve wanted to turn them into automatic renewals. In order to do that through Easy Digital Downloads, we needed to rebuild the system to make it not just possible. It was already possible, but we needed to make it a whole lot better. It had some serious weak points and some issues, and so we decided to rebuild it from the ground up.

We basically said, "Let’s ignore backwards compatibility. Let’s ignore everything that was the plugin, and let’s build it the way that we want it to be. Then, after it’s done, let’s see what we can do about backwards compatibility."

That was kind of a cool experiment for us because we’ve never done it that way. We’ve always gone with the, "We’re going to maintain backwards compatibility throughout the entire development process." In this particular case, we decided that the changes that had to be made were so drastic that we would cripple ourselves if we did that.

BRAD: Right. Was it also a matter of looking at how many people were using it and was that a factor?

PIPPIN: No.

BRAD: No? Okay.

PIPPIN: No.

BRAD: There are a lot of people that are going to–

PIPPIN: Recurring payments is in our top three most popular plugins.

BRAD: Okay.

PIPPIN: Yeah, so it’s a huge plugin for us. This rebuild is going to dramatically boost it much, much further because, honestly, it’s not even the same plugin. We actually considered even launching it as a new plugin. Ultimately, the reason we didn’t is because we wanted to make sure that every existing customer could still get access to it without us having to do a bunch of work to add things to their accounts and such like that.

BRAD: Right. Are you going to release this and just tell people that currently have it, "You can’t upgrade yet, but we’re working on it," kind of thing?

PIPPIN: Well, we’ve done a few things. Number one, I told you that we broke backwards compatibility, and it’s kind of a lie because, after the fact, we went through and it all works. We built an upgrade routine, and it all works. We’ve tested migrating over 20,000 subscriptions on a site to the new system, and it works perfectly.

One of the main challenges is that the original plugin only supported one subscription per user account, and we wanted to support multiple subscriptions per user account. Well, to do that, we decided that the best option — the old version stored, basically, subscription data in user meta, so it gave them an expiration date, a status, and a couple of other things.

We decided to move everything to a custom table, so we have precise control over our data schema, and so we took all of those records from user meta into a custom table. We took records from our payments data, which is stored in WP Post and a couple of other places, and moved it all into a custom table, and so that was a migration routine that we had to do.

We also had to go in and account for, because the old system was, to put it frankly, really crappy, we found that we had a lot of cases where we’d have subscriptions that have missing data, so they wouldn’t have a payment profile ID from Stripe or PayPal. It was just missing for some reason. And so, in our upgrade routine, we built out calls to the actual Stripe and PayPal APIs to go and retrieve that information so that we can not only move data, but fix data as well.

BRAD: Oh, yeah. That’s really nice.

PIPPIN: There is a couple of places where we have broken backwards compatibility, but only on a very minor scale.

BRAD: If you could let people know about that somehow, like by showing a little notice after they run their migration that says, "Oh, by the way, we fixed these things that you didn’t even know about," because you’re doing it. But, if you don’t let people know, they’ll never know that you’ve done this awesome extra work.

PIPPIN: Yep, that’s absolutely true.

BRAD: Yeah.

PIPPIN: Yeah, we should probably consider doing that.

BRAD: Yeah, it seems to me communicating that you’re doing something awesome is always the part I feel like developers always leave out because it’s extra work to add that notice, so why do it.

PIPPIN: There are a few things that we did break backwards compatibility on in terms of a couple of code things. We tried to make them work as best we can, but there are some nuances to it. For example, we had some helper functions that would retrieve a customer status. Well, suddenly if you have one subscription and now you have five subscriptions on a customer, what status do you retrieve? Do you retrieve the status of the first subscription or the last subscription? There were a few things like that.

We ended up writing up a big blog post that detailed every single change that we made that was breaking or could affect people in some way, and published that on our developer blog. We’ll put that in the show notes. Then we also wrote up a preview post recently that just shows all of the new things that are coming in the plugin and very excited about it.

It was nice to finally get it built. It’s been about a six- to eight-month process, plus another six months of kind of planning. The planning for this release started at PressNomics last year, and we’re almost to PressNomics this year.

BRAD: Right. Wow.

PIPPIN: So, it’s been a year process.

BRAD: Yeah.

PIPPIN: It’s very close. Then one last update that we did is over at Affiliate WP. We just released a new add-on called Sign-up Referrals. For a long time, we’ve had a lot of people request the ability to record referral commissions any time that an affiliate basically refers an account. So, if a user account is created from an affiliate, then record a commission.

We built the pro add on that does that, and it integrates with a lot of the popular plugins that create user accounts, user registration, so things like EDD, WooCommerce, Gravity Forms with User Registration add-on, Ultimate Member, User Pro, and a few others. It’s a new add-on that’s available to all of our professional and ultimate license holders as a free download. We put up a blog post, and I’ll include a link in the show notes to that if anybody is interested in checking it out.

BRAD: Cool. One question about the recurring add-on for EDD: You said it took eight months or so. When you first started, did you feel like it was going to take that long? Did you kind of know, or was it kind of a surprise?

PIPPIN: Yes and no. I knew it was a big project to take on. I didn’t necessarily know exactly how big, for one because we weren’t really sure what it was going to look like in terms of the upgrade process.

One thing that I left out on our upgrade process, that we’ve actually decided to disable automatic updates to the new version. If you want the new version, you have to install it manually if you’ve previously run a previous version. We ultimately decided to do that because: Would the upgrade work? Yes. Would everything work properly after the upgrade and the run the migration routine? Yes.

However, because there are breaking changes, for example there are a couple of short codes that we’ve changed because they’re just totally irrelevant now, there could be unexpected changes to a site. As we all know, there are a lot of people that are not good at reading change logs, and so it would be unexpected to them. Even if we put it in giant, bold letters, "These are gone. This has changed. Do this or do this," there would still be people that would get caught off guard, and so we decided it was better to ensure that only manual updates are done so that we can ensure that everybody who updates this knows what they’re getting into.

BRAD: Right.

PIPPIN: Honestly, everybody should update because the new version is amazing in comparison.

BRAD: Yeah, but it should be done manually and with yourself at the controls kind of thing.

PIPPIN: Exactly.

BRAD: I don’t know. I would say that that’s probably a bad idea anyway for people to have automatic updates on major version numbers anyways, right?

PIPPIN: Well, not necessarily automated updates, but the one click updates.

BRAD: Oh, you’ve disabled one click updates.

PIPPIN: Right.

BRAD: Okay.

PIPPIN: Yeah, we’re not going to allow that.

BRAD: Oh, so why again? Why? What’s the difference between that and just installing with a zip?

PIPPIN: The big reason is this: A one click update where WordPress says, "Hey, there’s a new update available. Do you want to install it?" "Yes, I do." That’s a one-click process. You’re done.

You have an opportunity to read a change log if you click a different button. But, let’s be honest. A lot of people don’t. I would go as far as to say the majority of people don’t.

What’s going to happen when you update from version 2.3 to 2.4 is, number one, there are several short codes that don’t exist anymore. We’ve left them registered with WordPress, but they’re going to return an empty string because they’re completely irrelevant now. There are some PHP functions in classes that, while they exist, their behavior is potentially changed because of introducing multiple subscriptions per account. And there’s a new customer dashboard, and there are some other front-end changes that we decided that because e-commerce is so sensitive, one little tiny change on the front-end could be considered drastic or even, in some people’s mind, catastrophic.

We’ve had people respond with, "Emergency! This is a catastrophe. You have to help me immediately. My site is down because a button got put onto the next line on the front end."

BRAD: Right.

PIPPIN: That was the only thing that changed.

BRAD: You feel that people having to go to your site first and get a zip file and install it manually is just a little bit more work, so they’ll be more likely to check the change log?

PIPPIN: Basically, but putting people through a manual update process, we can be sure to get them in front of, "These are the changes. This is what you should expect." Will there be people that still just update to the new version blindly? Absolutely. But, we’re going to prevent some of it.

This is something that we’ve debated for a while. Ultimately, in the end, we are glad we’ve got it to a point where it would be safe to update. By safe, I mean there’s not a single fatal error that’s going to happen anywhere, ever. At least not that we’ve been able to account that we can think of. It would technically be a safe update, but we’re not sure the risk is worth it.

BRAD: Did you consider, after they install the update, putting a big notice or even redirecting them to what we call a Welcome page, but you could call it a Critical Notice page?

PIPPIN: Yeah.

BRAD: Yeah?

PIPPIN: Yes, absolutely. But, here’s the problem with that. The update is done.

BRAD: Right. It’s too late.

PIPPIN: Imagine if, let’s say, you are a shop owner.

BRAD: Yeah.

PIPPIN: You have no technical knowledge, and you get put to a welcome screen that says, "Hey, by the way. All of this functionality is changed. These short codes don’t exist, so you need to go update them. These functions don’t exist or they’ve been deprecated, so you need to change them," and your mind explodes with, "What do I do?"

BRAD: Right.

PIPPIN: Unfortunately, that would be putting it in front of the wrong people.

BRAD: Yeah, that’s a really good point. I never thought of that. Yeah, what ends up happening there is they pick up the phone and start yelling at a developer.

PIPPIN: Or they call; they start yelling at us.

BRAD: Yeah.

PIPPIN: And so, we kind of want to try and be preventive and prevent some of that.

BRAD: Yeah. No, good point. Yeah.

PIPPIN: This is the only time we have ever done it, and it’s interesting because usually I would be so against a lot of this, like the idea of, number one, breaking some compatibility and, two, not allowing auto update and things like that. But, ultimately, we just decided that it’s such a drastic improvement and a drastic change that we decided it’s necessary.

BRAD: Right. Yeah.

PIPPIN: We’ll see. It could be that a week after we release it, realize, "You know what? Let’s re-enable auto updates, or re-enable one click updates."

BRAD: Do you think it would have taken you a lot longer to do it if you had just gone the backwards compatibility route and made everything–?

PIPPIN: Longer? No. Actually, I think it would have been faster, but it would have been much more limited. We would have said, "Okay. This feature simply can’t be done."

BRAD: Ah, right, so you would have sacrificed.

PIPPIN: Which is exactly why we said we have to break it; we have to break backwards compatibility because there were certain features that ultimately just either they couldn’t be done or they would be broken.

BRAD: Right.

PIPPIN: Or severely limited.

BRAD: Ah, okay.

PIPPIN: And so, we kind of looked at it as, "We want to build the plugin that we wanted from the get go. This is our opportunity to build it, so let’s do it." It’s something that people have been asking for it since day one. Almost everybody that uses the existing recurring payments plugin for EDD asks for what we’ve put into this.

BRAD: Right. It sounds like, from what you just told me, I probably would have made the same decision as you did.

PIPPIN: That’s validating, at least.

BRAD: Yeah, because sometimes progress is more important than backwards compatibility, right?

PIPPIN: I think, as long as you don’t ignore the backwards compatibility, yes.

BRAD: Yeah.

PIPPIN: Which is what we ultimately did here is we said, "Look. We are going to ensure that, number one, here’s a rule: No site goes down because of this updates because we ignored something." Anybody who installs this update, their site should still function. Absolutely. As long as we’ve maintained that level of backwards compatibility, everything else is negotiable.

BRAD: Right. Yep.

PIPPIN: Okay. Anyway, we’ll get back into a little bit more in recurring here in a little bit. Let’s move to you, Brad. What have you and your team been up to in the last few weeks?

BRAD: Yeah, so we’ve been hiring for the last few months at least, and we ended up just welcoming a new full-time developer. Matt Shaw has joined us full time.

PIPPIN: Awesome.

BRAD: Yeah, so we’re pretty stoked about that. What else have we been up to?

PIPPIN: What is Matt’s role in the company? Is he working on a specific product? Is he working on everything?

BRAD: Yeah, yeah. He’s a developer, so he’ll be working on Migrate DB Pro with Jeff, and they’ll be pushing that forward. But, he’ll be helping out with support, doing documentation, writing on our blog, all the stuff the rest of the team does as well.

PIPPIN: Very cool.

BRAD: Yeah, so there’s that. We just did a bunch of releases last week. We released; did two major releases, so Assets Add-on 1.1. That’s for WP Offload S3.

The funny thing with that add-on is that the first release was kind of a beta, even though we called it 1.0. I wouldn’t call it a beta because it didn’t break anything. There weren’t major bugs that would break your site or anything.

But, it actually didn’t make your assets any faster–that was the big problem–because it didn’t gzip or minify them, so it didn’t really do much. It just sent them to Amazon S3, and then you could use CloudFront to serve them. But, that really didn’t help that much compared to using your own server.

Yeah, we added those two features: minification and gzip. Now it’s a big, big improvement.

PIPPIN: That’s awesome.

BRAD: Yeah. Ashley wrote a blog post about the release, and he did some testing with Page Speed, Google Page Speed, and he brought a score from a C to an A.

PIPPIN: I’m looking at that right now. That’s a substantial improvement.

BRAD: Yeah, so it’s pretty huge. The funny thing is, while we were building it, Amazon CloudFront released gzip support. So, if you’re using CloudFront, you don’t actually need to enable our gzip feature. In fact, we tell you not to, specifically, if you’re using CloudFront, and to use CloudFront because it just makes way more sense to just have CloudFront handle that because, the thing is, the browser requests.

It sends the header accept in coding. You know, when your browser supports gzip, it sends the header, "Accept in coding, gzip," and then that tells the server, "Okay, I can send them gzip, a gzipped file, and they’ll be able to decompress it and read it."

Well, before CloudFront released gzip support, if you sent that header to CloudFront, it would just ignore it. It didn’t know what to do with it. But now it actually understands that and will actually serve you a gzip version, and CloudFront does the gzipping for you. You don’t have to.

PIPPIN: Oh, that’s nice.

BRAD: You don’t have to do it. You don’t have to worry about anything, really. Yeah, yeah, I would recommend using that. But, if you’re using a different CDN or if you’re just using S3 for some reason, which we don’t recommend, you could use our gzipping feature.

PIPPIN: Super cool.

BRAD: Yeah. We also released, last week, a Multisite Tools Add-on 1.1. That gives you the ability to push a sub-site from a multisite install to a single site install, so basically spin out a sub-site as its own standalone install of WordPress.

PIPPIN: That is frickin’ stellar.

BRAD: Yeah.

PIPPIN: I love that feature so much.

BRAD: And it goes the other way, so you can actually, from a single site install, so you’re on a single site install, you can pull in a sub-site from a multisite install.

PIPPIN: That’s so cool. All right, I have a feature request for you.

BRAD: Okay.

PIPPIN: And/or a question of maybe this is possible because I ran into this the other day.

BRAD: Okay.

PIPPIN: I was actually trying to use Migrate DB Pro, and I realized I couldn’t use it. What I wanted to do is I was actually testing our migration routine for recurring payments for the 2.4 update. And so, what I had done is, a few weeks ago, I had gone in and I had set up an old testing site and set up some live subscriptions in it that were processing and recording renewal payments on a daily basis, and so I had a couple hundred records in there.

Then, what I wanted to do was go in and test the migration script and say, "Okay. Let’s make sure that this works." I wanted to then have a quick reset in the case that it failed.

Now, there are numerous ways to do this, but one of the ways that I was hoping to do it and turns out I couldn’t is I wanted to pull that. I did this in a multisite, so I had done this on one sub-site. I wanted to pull one sub-site into another sub-site, basically to duplicate a site.

BRAD: Yep. Yeah.

PIPPIN: If you can make that possible, that would be so awesome.

BRAD: That is slated for version 1.3 of Multisite Tools Add-on.

PIPPIN: Whoo-hoo!

BRAD: It should be out hopefully this year.

PIPPIN: That’d be awesome.

BRAD: But you know how priorities work.

PIPPIN: Oh, absolutely.

BRAD: BUT, I will give you a way to do that today.

PIPPIN: Ah, nice! How do you do it?

BRAD: With this update, you can do it. What you could do is you can stick a single site install in between your two multi-sites. You push your sub-site into the single site. Then, from your other multisite install, you pull that single site into the sub-site.

PIPPIN: Ah, got it. Okay. You basically have a staging site where you say, "Okay, let’s push the data temporarily and then pull it back out."

BRAD: Yep, exactly.

PIPPIN: That makes sense. That’s cool.

BRAD: Yeah, so you could do it that way. It’s a little extra work, but it might be less work than doing it manually.

PIPPIN: Yeah. I know that there are other ways too. Anybody listening, if you have a good way to do this, please shoot me a ping on Twitter, on Slack, email or whatever. I know there are ways to duplicate one sub-site and just completely duplicate it into another site in the network. I think maybe BackupBuddy does it right now. There’s a plugin called Duplicator that I could have sworn did it, but I don’t know if it was just me having a stupid day. I couldn’t figure out how to make it work.

I’m talking about a super easy way, nothing related to manual DB queries or anything. Just push a button and duplicate a site. If you have a preferred way to do it, let us know. And, if you want to donate money or time to make Brad get it finished faster in his plugin, that also works.

BRAD: Yeah, that’s okay. That’s okay. We’ll get it done.

PIPPIN: What else have you got?

BRAD: We’ve been blogging like crazy.

PIPPIN: I know. I see your posts coming out like, what, twice a week right now or just once a week?

BRAD: No, just once a week, but the posts that we put out are exhausting to develop. Gilbert did one, a comparison between Vagrant and Docker. That was really eye opening for me because I had heard about Docker, but I just hadn’t looked into it, so I didn’t know really what it was. The spin that he puts on it is, "Which is better for WordPress development?" specifically. That’s a really popular article that we’ve had in the last couple months. It’s probably the most popular.

Ashley wrote a great post and published a library on GitHub for doing background processing in WordPress plugins and themes.

PIPPIN: I saw that. Very cool.

BRAD: Yeah. We’ll probably have a chat next episode about that in more detail. I think that would be a good topic to cover.

Jeff did a review of WP Pusher, which is a plugin for automatically deploying your WordPress code. If you have your site in a GitHub repo, and you push it to GitHub, it will automatically update your site. That’s a pretty cool plugin.

PIPPIN: Yeah.

BRAD: I looked into Varnish Cache because we’ve been running Varnish on our site, and Ashley did this series of posts about setting up your own WordPress site, your own WordPress hosting. He was using Nginx’s fast CGI cache. I was like, "Well, isn’t Varnish better?" because we’ve been using it for, like, three years. I kind of thought it was, and it turns out it wasn’t. It isn’t, really. It’s really not worth having Varnish in your stack.

PIPPIN: Is that just if you’re using Nginx?

BRAD: Yeah, pretty much. Well, Apache is a different beast. I think it has its own caching stuff as well. That’s what we’re using. We’re using Apache on the backend of our site right now. Yeah, I think if I set up a new stack, I’d probably do what Ashley did in his series. It seems to be the most modern way. Yeah, check that one out.

Then three of the guys went to a Day of Rest conference in London, and Ian wrote a summary of their time there. Check that one out.

Then just a couple other things: I was on the Office Hours podcast with Carrie Dils, who was on our podcast just recently. We talked mainly about business stuff, so if you’re interested in business stuff.

PIPPIN: I haven’t had a chance to listen to it, but I’ve been meaning to go back and check it out.

BRAD: Yeah, it was really cool. It was a live show, and there were people asking questions during the show and stuff, so it was a little different, but really cool.

Then, just this week, or just yesterday, I was at the local community college here just giving a two-hour session on how to contribute to WordPress Core. Actually, I was trying to convince them to contribute to EDD and WooCommerce or another kind of big WordPress plugin.

PIPPIN: Sure. Contribute to the WordPress ecosystem, but not necessarily WordPress directly.

BRAD: Yeah. Basically, what I told them was that WordPress Core kind of moves really slowly, and you should definitely work on it and try. But these are students that are graduating in a couple months, right?

PIPPIN: Right.

BRAD: So, in terms of their employability, if they want to show that they’ve been contributing to open source, it could be a while before they have much to show for if they’re contributing to WordPress Core whereas tackling some bugs in EDD or something, they could really get kind of a more immediate benefit there.

PIPPIN: Right. Smaller systems allow you to have faster turnarounds.

BRAD: Yeah, exactly. It’s just the nature of the beast.

PIPPIN: That makes sense.

BRAD: Yeah, and I also told them, though, that everyone that you’ve ever hired has actually contributed to EDD.

PIPPIN: There we go.

BRAD: That was probably a good sell for them.

PIPPIN: You’re setting up my future team. I like it.

BRAD: Yeah, that’s right. Yeah, that was kind of fun.

PIPPIN: Cool.

BRAD: Maybe we should get on with chatting about automatic renewals.

PIPPIN: Yeah. Yeah, we’ll be here all day, otherwise.

BRAD: Yeah.

PIPPIN: Okay. This is, I think, a really important subject.

BRAD: Should we define what automatic renewals, what we mean by that?

PIPPIN: Yeah.

BRAD: Yeah.

PIPPIN: Yeah, why don’t we do that? Go ahead.

BRAD: Basically, right now, when your license expires, for Migrate DB Pro, let’s say, you get an email. Actually, you get an email 30 days before your expiree asking you to renew and then, like a day before your expiree, if you haven’t renewed yet, you get those two emails. In the email, there’s a link to log you in to my account and drop you off at a page that’s just basically one click to renew your license.

PIPPIN: Mm-hmm.

BRAD: That’s manual renewal.

PIPPIN: Yep. Ours is pretty much exactly the same way.

BRAD: Right. Automatic renewal would be: You get an email the day before your expiree, or whatever, maybe 14 days, whatever makes sense, and it says, "You’re subscribed to automatically renew your license. We will be charging your card in X days." Then it just happens, and they get a receipt emailed to them that their card has been charged. That’s basically what automatic renewals are, but there’s much more complexity to it.

PIPPIN: I wish it were as simple as that. That’d be great.

BRAD: Yeah. I’ll just add one little complexity that’s actually user facing. Let’s say your card expired during the year. Well, you’re going to have to at least update your expire date of your card or even potentially add a new card number. We have to email you and ask you to do that because we can’t automatically renew an expired card, right? That’s one small part of the complexity.

Another part would be, when we go to charge your card, it fails and for unknown reasons. It could be your card is maxed out. It could be who knows, right? There might be a hold on it because of fraud or whatever. Then we have to deal with that somehow. There are two pretty complex things.

PIPPIN: I’ll add another one to that mix. Now this is a little bit more specific to, say, the EDD ecosystem. But, let’s say that you sell five products.

BRAD: Ah, yes!

PIPPIN: Or you sell ten products. Or, in our case, let’s say that you sell 250, and so an average customer purchases five to ten products. Some people purchase them all at once. Other people purchase one. A few weeks later, they purchase another. A few months later, they purchase another, et cetera.

Basically, you have, say, five to ten different license keys all with different expiration dates because they were purchased at different times. That now means that if you’re going to make those automatically renew, every single one of those has a separate subscription. That means that a customer now has five subscriptions on their account that expires and renews at different times. Each potentially have a different card attached to them. It gets very complicated very quickly. This is what we’ve been dealing with in the EDD ecosystem for the last year trying to work through.

BRAD: I’m interested. Are you working towards combining those into one kind of renewal? What’s the solution there?

PIPPIN: Well, all right, so we have a couple plans. First of all, for us, the decision to go to automatic renewals started at PressNomics last year. We were having a fireside chat, and we were comparing our renewal rate to somebody else’s renewal rate, and theirs was about 60% higher than ours, and we just said, "Damn! Okay, that’s what we’re going to," and the difference was that they did automatic renewals and we did manual renewals, and they had at least a 60% improvement.

BRAD: Mm-hmm.

PIPPIN: Which, depending on your scale, is a pretty big chunk of change. So, we decided that night that this was going to happen. Now, we are 11-1/2 months later, and it’s mostly done. Well, kind of.

Actually, while I was in New Zealand, we launched automatic renewals on Affiliate WP, and we decided to launch it there because Affiliate WP is the simplest of the products that we offer in terms of the sales system. There’s one product. There are multiple add-ons to it, but there’s one product. You have one license key, so there’s only one subscription per customer – much, much simpler.

We launched it there, and it’s worked really, really well so far. Ours is powered by the new recurrent payments version for EDD that we discussed earlier in the show, which is getting released here pretty soon. For anybody, if you’re running a store on EDD and you want to do this as well, go pay attention to recurring payments because the update is going to go out in the next two weeks.

So, yeah, we enabled it on Affiliate WP as kind of our live beta test, one, to beta test the actual recurring payments update for our customers, but, two, to beta test the idea of automatic renewals for our systems. We’re going to do it on EDD as well, but that challenge of, well, we have customers that have 20 license keys, and they’re all different. They have different expiration dates. We don’t necessarily want them to have 20 different subscriptions, or maybe we do. Maybe we don’t care. Those were the questions that we had to work through.

Ultimately, I think what we’ve decided to do is to try to go kind of the route of a club membership type thing where all of your license keys get combined into one subscription, and so you have a variable amount. If you want to purchase a new add-on, we just add a little bit to your monthly subscription or something like that.

BRAD: Yeah. I think what I would do, as a Phase I, I would just make it so that each of the licenses automatically renew, if they choose to do that, because that’s still a big improvement over them manually having to renew 20 different licenses, right? At least it’s automatic.

PIPPIN: Right.

BRAD: Yeah.

PIPPIN: Well, let me throw you another caveat, another challenge.

BRAD: Okay.

PIPPIN: That was our plan, and then we had a monkey wrench – PayPal.

BRAD: Damn monkeys.

PIPPIN: Yeah. PayPal. Now, it actually turns out that we believe we’ve gotten past this, and this is no longer a problem. All right, so if you work through Stripe, now in our case we take both Stripe and PayPal. The reason being is that there are a lot of customers that have a credit card, and they don’t want to pay with PayPal. There’s a lot better of the opposite; they want to pay with PayPal. We take both.

In Stripe, from the developer’s perspective, during the checkout process, and we want to go create numerous subscriptions, we can do that no problem. Piece of cake. You can’t do it in PayPal. Turns out that PayPal’s system, not one of their products support multiple subscriptions in a single checkout.

BRAD: Oh, really?

PIPPIN: Except, well, until yesterday we figured out how to do it.

BRAD: Okay.

PIPPIN: There is a way to do it, but that’s what we thought.

BRAD: What’s it called?

PIPPIN: You can do it through the PayPal Express and the Website Payments Pro API. It’s just, you have to figure out how to use the API properly because they don’t have it documented, and there are a lot of places on the Web that do have it documented as a tutorial that says you can’t do this. We figured out that, yes, you can if you just pass the right parameters.

It’s kind of one of those, you play around with the API enough. You plug different things in. You try different things. You eventually figure out things that are supported, even though they’re not documented.

It turns out that PayPal’s API does support it through their Express Checkout API, but that was a giant problem for us because we have a lot of people that purchase multiple products at a time and multiple license keys. If we were going to just go ahead and enable subscriptions for them, that would mean that if you wanted to pay with PayPal, you could only buy one item at a time, and that was a showstopper. We weren’t going to do it. Now that we figured out how to do that in PayPal, it’s not necessarily as much of a problem.

BRAD: With PayPal, are you referring to reference transactions? Is that what they–?

PIPPIN: Well, that’s one way to do it, but no.

BRAD: Okay.

PIPPIN: A reference transaction, for anybody who is not familiar with it, is basically a special kind of transaction in PayPal. It’s basically a merchant agreement where you, as a merchant, can get authorized to charge a customer at any time.

BRAD: Right. They have to give you permission, obviously.

PIPPIN: Right. The customer gives you permission to create transactions on their behalf. And so, if you ever pay with PayPal in iTunes or any Apple product, they’re using reference transactions. The same thing with UPS.com or basically a lot of the giant merchants that use PayPal, they’re doing it through reference transactions where they receive a customer’s permission and PayPal’s permission to charge customers at this time or on this interval.

Reference transactions make it very easy, but reference transactions are really hard to get enabled on your account.

BRAD: I just got ours enabled this week.

PIPPIN: Yeah. Maybe I’m just talking to the wrong people. I haven’t even succeeded in getting enabled on a Sandbox account.

BRAD: Oh, really? Huh. I hope the developer that I’ve got to do this can get it enabled on his Sandbox. Otherwise I’m going to have to make some calls, I guess.

PIPPIN: I’ll have to look into that more, but we’ll find a way to do it.

BRAD: Honestly, all I did was I emailed them, and then they send you their automatic response. Then I said, "No, that doesn’t answer any of my questions." Then I got a response saying, "Oh, yeah, reference transactions. Yeah, you can’t do that through email." So then I called their stupid number, and then I talked to somebody who seemed to know what I was saying. They said they’d take care of it, and then I got an email a couple hours later saying it was enabled.

PIPPIN: All right, well, that’s pretty cool.

BRAD: Yeah.

PIPPIN: I’m going to look into doing it, and we want to get it enabled for us just so we have the option to do it. However, I didn’t like that as the solution because we try and make it so that any feature that we build is usable with all of our customers.

BRAD: Exactly.

PIPPIN: That is not something that is going to be enabled by all customers. I can almost guarantee you, you guys got it enabled pretty easily because you have a high volume.

BRAD: Yeah.

PIPPIN: Somebody who has $100 a month or $1,000 a year or something is not going to get it enabled.

BRAD: Right. Yeah, that makes sense. Yeah, that totally makes sense from a product perspective for you guys to do.

PIPPIN: Yeah. We try and use all of our products as out of the box as possible.

BRAD: For Affiliate WP then, when you turn on automatic renewals, you must have only done it for–

PIPPIN: We only do it for new customers.

BRAD: Oh, just for new customers. I see.

PIPPIN: What we did is we said, "Okay, number one, we turn it on. Every new purchase is a subscription. There is no opt-in. It is automatic." Well, we decided we have it set up so that our refund policy is kind of a no questions asked, and also you can cancel at any time, so anybody who doesn’t want a subscription, just cancel it. You still get the product for a year. Your license key is valid for a year and we won’t charge you again.

BRAD: Can existing customers opt in if they want to?

PIPPIN: Yes.

BRAD: Okay.

PIPPIN: Yes. We have a couple of caveats with it. Basically, you renew early, so the act of renewing turns you into a subscription.

BRAD: Right. Okay, that makes sense.

PIPPIN: At some point, we wanted to offer just like a one click from your account. Okay, active, it’s a subscription; it’s going to bill you at that time. We haven’t done that yet simply because it wasn’t within the scope of our recurring payments product that we were building. We are trying to build our system that we’re going to use on our own stores at the same time as we’re building the product because it was kind of kill two birds with one stone.

BRAD: Right. Okay. The PayPal subscription, they get bounced to PayPal, and then it asks them if they want to start a subscription, and then they get bounced back, I guess? Do they?

PIPPIN: Well, it’s just like their PayPal Express checkout process where you go to PayPal. Yes, I authorize this. Go back, confirm, and done. Then it creates a subscription.

BRAD: Right. Okay. Cool. Yeah, I was wondering about, like, how you turned it on. You probably could have turned it on for your Stripe customers because all those cards would be saved in your system, like all the card IDs?

PIPPIN: Technically, we could go through and we could turn every customer into a subscription, at least every Stripe. We decided that it was a breach of ethics.

BRAD: Okay, yeah.

PIPPIN: Simply, each customer at that time, when they purchased, they have not purchased on an automatically renewed subscription, and we’ve had numerous people ask us. "Hey, are you going to charge me automatically?" We say no.

BRAD: Yeah.

PIPPIN: For us to suddenly just go and do that, we felt was wrong.

BRAD: Absolutely. Yeah, and when we turn it on for an existing customer, it’ll be opt in. They will choose to opt in or not, or stay the way they have it.

PIPPIN: That’s pretty much kind of what we did. We sent an email to every customer and said, "Hey, would you like to opt in?"

BRAD: Yeah. I think what I’m going to do is offer them a discount or something to opt in.

PIPPIN: We did that. We offered, I think, an extra 20% off. Our renewals are discounted at 40%.

BRAD: Right.

PIPPIN: And so we said, you can get an additional 10% off, and so you get a 50% renewal if you opt in.

BRAD: Cool. That’s nice.

PIPPIN: Yeah. We didn’t change any of our pricing when we did the subscriptions either. Let’s say when you buy Affiliate WP, and you buy the $49 license, your first payment is $49, but then every other payment after that is $34.50 or whatever the discounted real price is.

BRAD: Right. Hmm. Cool. Yeah, with reference transactions, I think we probably made it sound like it’s this completely crazy thing. It’s really pretty much the exact same thing as what Stripe does. It gives you a reference ID to be able to charge someone’s credit card that’s stored in PayPal. Not even their credit card, but their PayPal account. It’s just a reference to their account.

PIPPIN: Yeah. It’s kind of like storing a card for Stripe, like a credit or debit card.

BRAD: Yeah, it’s very similar.

PIPPIN: It’s a pathway to processing a charge programmatically.

BRAD: Yeah. When you set up the subscriptions, so when someone pays with Stripe and you set up that subscription, are you also using Stripe’s subscription system that they have?

PIPPIN: Yeah.

BRAD: Oh, you are?

PIPPIN: Yeah.

BRAD: Ah, interesting.

PIPPIN: All right, so this is actually, I think, a really good discussion. I think it’s really good for developers to consider this. When you do subscriptions, at least in my mind, there are two primary ways to do it. One is you rely on the subscription processing of the merchant, so Stripe’s subscription system, PayPal’s subscription system, their automatic billing systems, or you rely on your own processing of those subscriptions and you simply have the ability to initiate a charge to a customer at any time.

BRAD: Yep.

PIPPIN: Cron, basically, or something like that.

BRAD: Right.

PIPPIN: They both work very, very well, or they can. I believe WooCommerce subscriptions relies on a Cron process.

BRAD: It does, yep.

PIPPIN: Right, and that’s one of the reasons why reference transactions are so important for you guys. We have always decided not to go with that route. Now, for me, there are a couple of reasons. To me, there are disadvantages as well for what we’ve decided.

We chose to always rely on the merchant processing of subscriptions for one primary reason. If my site goes down, I don’t want to have those customers not charged, and I don’t want their charge to be delayed and catch them off guard. I know that my site and my customer sites are far more likely to go down than Stripe or PayPal. Just shear scale and infrastructure. I would rather not properly record a subscription payment than to completely miss charging a subscription payment.

BRAD: Right. Yeah, I think another good reason for you to choose to go that route is you just said that PayPal subscriptions, you just want to use — I mean you don’t want to do reference transactions because a lot of people won’t be able to use those, so you’re using kind of the old school PayPal subscriptions where PayPal handles the transaction. Well, if you use that route for PayPal, and then you do managing your own subscriptions with Stripe, you’ve kind of got two systems going there, two different systems, right? Whereas if you just say, well, PayPal, we have to do it so that PayPal processes the subscription renewal, why don’t we just do it the same way with Stripe? Then it’s a cohesive system, right?

PIPPIN: Right. Yeah, and we tried. We want to make sure that all of our payment gateways, whichever one we’re using, all behave more or less the same way. Now, we are considering, inside of EDD recurring payments, of actually doing a combination because we’ve discovered that there are some payment gateways that actually don’t have subscription handling.

BRAD: Oh, God.

PIPPIN: Like Amazon payments, for example. Amazon payments does not have subscriptions.

BRAD: Right.

PIPPIN: A lot of people do subscriptions through Amazon, but they’re all with billing agreements, basically reference transactions where the merchant is approved to charge you at certain times.

BRAD: Right.

PIPPIN: But they still have to initiate the charge.

BRAD: Oh, man.

PIPPIN: We’re actually going to go a combination.

BRAD: There’s no winning.

PIPPIN: There is no winning. Now, one of the advantages, and this is a significant advantage of processing on your own, like WooCommerce subscriptions do and like you guys are doing with reference transactions, is that it makes it far easier for you to manipulate the parameters of the subscription.

Oh, you want to change it to $10 a month from $15, or you want to go pump it up to $25 a month? You want to make it a quarterly billing versus a monthly billing? That’s very easy to do.

BRAD: That’s exactly why we chose to go that route so that we have control over it.

PIPPIN: Right. Depending on the merchant that you’re using, that may or may not be possible. Like Stripe, you can do that no problem because Stripe’s subscription API is beautiful.

BRAD: Mm-hmm.

PIPPIN: PayPal? Good luck.

BRAD: Well, PayPal reference transactions, you can.

PIPPIN: Well, right, right, but I mean if you’re relying on their actual subscription processing.

BRAD: Right. Forget about it.

PIPPIN: I can’t just go in and take a subscription that’s running in PayPal where PayPal is handling the billing and say, "You know what? I want to change you to be quarterly billing."

BRAD: No.

PIPPIN: "I want to change you from $30 a month to $57 a month."

BRAD: No.

PIPPIN: You can’t do it.

BRAD: You basically have to get the customer to do it all over again, right?

PIPPIN: You cancel and then recreate it.

BRAD: Yeah, it’s really annoying.

PIPPIN: Which is super crappy, right. That, I think, is the biggest downside to relying on the merchant because not all merchant APIs provide it.

BRAD: Yep. Exactly. Oh, well. There’s no perfect solution, I don’t think.

PIPPIN: No, there’s really not. It’s a whole lot of figuring out what is the best for each individual situation and compromises.

BRAD: Right.

PIPPIN: Compromises, mostly.

BRAD: Yeah.

PIPPIN: You guys have an estimated date for when you’ll turn on auto renewals?

BRAD: Well, I asked Ross. Ross McKay is going to work on this part-time for us. He runs WebAware – is his kind of handle. Anyway, he’s got quite a bit of experience working with WooCommerce and EDD, actually. So, he said three weeks.

I think that’s probably generous, and so that’s three weeks of development. Then we’ve got to test it, integrate it, and who knows what else. I’ll probably say, like, a month and a half, probably, before we get this thing rolled out to new customers. Then there’ll probably be additional development to enable it for existing customers and send that email out to allow them to opt in and all that stuff. Hopefully in the next couple of months, we can get that rolled out. I’ve got a lot going on besides that, too, so I don’t know.

PIPPIN: Nah. You’re not busy. You’re not doing anything.

BRAD: We’re redesigning our entire site, so that might have an impact.

PIPPIN: Just possibly. Yeah, I think automatic renewals are a super smart way to go. I’m really glad that we’re in the process of moving that way, and we’ve got Affiliate WP launched on it. We’re going to do Restrict Content Pro next, and then we’re going to try to do EDD in one form or another.

If you are selling annual products, I would seriously consider doing automatic renewals. I’m telling you, it was that one fireside chat where we had something like 15% to 18% renewal rate and they had 80%. That kind of blew my mind, and it’s very easy to make that decision at that point.

BRAD: When I was at Big Snow Tiny Conf last year — oh, yeah. I didn’t even talk about that. I went to Big Snow Tiny Conf last month as well. Anyways, last year, I was at Big Snow and one of the guys was like, "So you’re not doing automatic renewals?" He was just baffled. He’s not even a developer or anything. He’s just a business guy, and he was just baffled why we wouldn’t be doing it.

I gave him a bunch of really thin excuses, and he was like, "Well, you know what? Next time, next year when I come back, you’re going to have this enabled." Then last month I showed up, and he’s giving me grief about it because I still haven’t done it. That was the tipping point. I was like, "Okay. I can’t go back another year and I still haven’t gotten this done."

PIPPIN: Yeah.

BRAD: Yeah.

PIPPIN: I’ll just put this out there. One of the other things, so if we go from X percent renewal, if we increase our renewal rate by 60%, the single act of turning on automatic renewals has more than doubled our revenue one year from today.

BRAD: Wow. That’s crazy.

PIPPIN: Think about it for a second.

BRAD: Yeah.

PIPPIN: Depending on what your renewal rate is, if we increase that by 60%, yeah, if it’s not double, it’s going to be pretty darn close to it, a year from turning them on, simply because of the increase in renewals, and that’s pretty huge.

BRAD: Yeah, definitely. Definitely worth it.

PIPPIN: Yep.

BRAD: All right, should we wrap it up?

PIPPIN: Anyway, we should probably wrap up here. Yeah.

BRAD: Yeah, sounds good. All right, well, if anyone has any comments or questions about this stuff, just head to our website, ApplyFilters.fm, and submit the contact form.

PIPPIN: And a quick reminder: We have a little survey form at /survey on the website. Basically just let us know if you want development questions, you want business questions, other comments, et cetera. It takes 30 seconds or less to fill it out. Let us know. It’s helping us to figure out what we’re doing in the future for this podcast and things that we want to change or directions we want to go, et cetera. So if you have thoughts and opinions, let us know.

BRAD: Awesome. Thanks, everybody. Talk to you next time.

Apply Filters © 2024