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 35. Today, Pippin and I will be talking about what we’ve been up to. I’ll talk about my ordeal moving from one email platform to another, and Pippin will talk about Easy Digital Downloads 2.3. Pippin, where have we been, man? It’s been, like, what, a month and a half?

PIPPIN: Something like that. Whenever we last talked with Patrick in Episode 34, which was some time after PressNomics. Yeah, it’s been at least a month, maybe a month and a half. We’ve been traveling mostly, so right after we got back from PressNomics, I know at least I did, I needed a little bit of just relaxing time. Kind of took things easy for a little bit.

Then, after that, I left for a week and went to Chicago. We had a company meet up with my brother’s company, who I do some work for every now and then and have been involved with for the last couple years. I spent a week in the cold, cold Chicago. Then I came home. We normally would have recorded an episode right after that, but then where did you go?

BRAD: Yeah. After PressNomics, I flew right to Vermont. We did the Big Snow Tiny Conf right after that, so went snowboarding, talked business for two or three days in Vermont. We got a huge dump of snow while we were there, so we had powder and went snowboarding, so it was pretty sweet. Really, the house was amazing too. It couldn’t have went any better, really.

PIPPIN: That’s good. How many people did you end up having there?

BRAD: Twelve, including the organizers, including myself and Brian, so 12 total.

PIPPIN: Excellent.

BRAD: Yeah. Actually, one guy didn’t make it, so it ended up being 11. That’s right. Yeah, yeah, it was really great. The only thing, the funny thing – I asked the group while we were there if we should eat out more often because we only eat out one night. We only go out for a dinner on the last night. Actually, everyone pretty much agreed that they would rather stay in, eat in because it’s cold out, right?

PIPPIN: So cold.

BRAD: Yeah.

PIPPIN: When I was in Chicago, we kind of did the same thing. They have a studio space there that has an extra room where everybody was sleeping, kind of had a bunkroom. It has a full bathroom, full kitchen, so we can live there, practically. Most of the time we were there, it was really, really cold. There are 15 or 20 restaurants within a 2- or 3-block walking distance. Even then we’re like, you know, let’s order something in. Let’s make it here.

BRAD: Yeah, exactly. You don’t want to go outside.

PIPPIN: Not when it hurts your face.

BRAD: Yeah. Then after Big Snow, I came home for a week. Then I went to Mexico with my wife and my five-month-old son because it’s the first real vacation my wife has had for a while, so it just made sense to go away. I certainly didn’t need it after being in Phoenix and in Vermont, but it was still nice to get away from the winter here.

PIPPIN: I’m sure. Now, did you take the whole time off and actually not work at all there, or was it kind of a workation?

BRAD: It was kind of a workation. I put in, on average, two hours a day, probably.

PIPPIN: Compared to a normal day, that’s barely anything.

BRAD: Yeah, exactly. I basically just kept on top of email. That’s basically it.

PIPPIN: Yeah.

BRAD: Anyways–

PIPPIN: Very cool.

BRAD: What have you been up to work wise?

PIPPIN: Well, for the last month or so, and I know even over the period of the last couple of episodes, we’ve been busy working on EDD 2.3. We’re now getting really, really close to having that wrapped up. We shipped our first beta out the beginning of last week. The same time as we shipped it out, I put it out on PippinsPlugins.com. PippinsPlugins.com has been running the first beta version of 2.3 for the last week and a half or so, just kind of as a real world test for the new version. So far, it’s been running really smoothly.

BRAD: Cool.

PIPPIN: And so, over the last week, we’ve been working through bugs reported with the beta and getting things finished up. We’re hoping to get it all ready to ship, I think, by March 10th. We’re getting ready. The whole team is flying in for a team meet-up around Prestige Conf, which is happening at the end of this week in Vegas. The whole team is flying to Vegas. We’ve rented a house, and we’re all going to stick around there for a few days. We’re hoping to really finalize the 2.3 release while we’re there.

This release, it’s been a lot of fun for a couple of reasons. Number one, because it’s the first major release where I’ve had a co-lead developer. Chris Klosowski came on January 1 as co-lead developer. We’ve done a couple of point releases since then, but this is the first major release, so there’s a ton of new code that’s been written in here from Chris. We’ve introduced a really big, new, customer management UI with some really significant improvements there, as well as some of the underlying APIs for that.

There’s been a fun kind of trial for backwards compatibility with some of these things that we’ve done. There are three major changes that we’ve made in 2.3 that I kind of want to talk about real quick related to backwards compatibility. One of them is the customer management UI, and there’s some stuff that we’ve been doing there. Another one is signed URLs that have actual signatures and tokens on them for security reasons. Then one is we’ve modified how we store taxes.

Each one of these has had a repercussion for backwards compatibility either with just sites as they are, or with specific extensions, or specific hosting environments. For the customer management UI, we had a bug in the last few versions where customers wouldn’t have payments properly connected to their account, maybe because they purchased with a guest account. They purchased as a guest even though they had a user account on the site, and so then they wouldn’t get connected.

BRAD: Oh, okay.

PIPPIN: We’ve introduced a new upgrade routine that goes through and makes sure it goes through every single purchase of every single customer on the site and ensures that everything is connected the way that it needs to be. Making sure that that kind of upgrade routine works, even on giant sites, is a little bit challenging.

Something that’s kind of funny with that is our upgrade routine. We got it really, really good, I think. It actually was running too fast and was causing perception issues for users in that, when the upgrade routine was running, they didn’t see the indication that it was running because it was going too fast. So we actually had to intentionally slow it down by, like 50 milliseconds on every single step and then had to show an indicator that says, “You are on Step 5 of 272,” because we had people open tickets that said, “It’s doing stuff, but I think it broke.”

BRAD: Right.

PIPPIN: It didn’t actually break. They just didn’t realize it was still going.

BRAD: Did you take into account sites that are going to be really busy?

PIPPIN: Yep.

BRAD: Is it going to slow them down?

PIPPIN: It will slow down a little bit, but it shouldn’t cause anything significant.

BRAD: You can just suggest that they do it during their less busy time.

PIPPIN: If you have a really large site, I would suggest doing it on a slow period.

BRAD: Yeah.

PIPPIN: The good thing is there are a couple of things that we’ve done with the upgrade routine as well. Number one is that if it fails at any point, it keeps track of where it is, and it can be restarted at any time and it will tell you if it fails. Let’s say, for example, it’s going and you close the page or your server dies for some other reason. Unlikely that it would be tied to the upgrade routine. The next time you load your site, it’s going to tell you that this upgrade started, but didn’t finish, and it’s going to go back and finish it for you.

BRAD: Nice, so it’s pretty robust.

PIPPIN: Yeah.

BRAD: Did you guys build this with reusability in mind? Are you going to use this again in the future?

PIPPIN: Yep, we have a general API that we can reuse any time that we want.

BRAD: Nice.

PIPPIN: Actually, it’s the same API that we’ve had for the last five or six releases. We’ve just been iterating on it each time and improving it. We used to store our upgrades. The way that we knew if an upgrade needed to be done was simply based on the version number in the database. It’s database version 2.7 or something like that. It was always the same as the main plugin version. This is version 2.3. It was database version 2.3. If we saw that the database was 2.2, we needed to run an upgrade routine if there was an upgrade for that version.

Now we’ve changed this a little bit so that we’re actually going to start logging every single upgrade routine that happens, and we can see the exact routines that happened. The reason for this is, let’s say that there’s one user that starts using EDD on 2.0, upgrades, and is now on 2.3. Another user installs on 2.3 and doesn’t need to do the upgrade routine. Well, if one of them runs into an issue, it can be really important to know whether or not they’ve actually gone through the upgrade routine. Maybe, for whatever reasons, they didn’t notice that it said they needed a routine, needed to run it, didn’t show. We’re now tracking whether or not an upgrade routine has been run and so that we can go back and see exactly which ones they’ve run and which ones they haven’t.

It’s also good for times if you have multiple routines that need to run in a single release. For example, this version has one upgrade routine for customers and a second upgrade routine for taxes depending on whether or not your site supports taxes. In previous versions, if you ran one, it would actually run both of them simultaneously. It just didn’t show you that. Now we’ve kind of separated them out so that they run separately. You can run them at any time you want. You can run them independently. Then, if you ever have any problems, if we’re going in, if the support team is going in looking at it, we can actually identify which ones have been run, which ones completed, which will be nice.

BRAD: Cool. Yeah. What about the signed URLs thing? Is that about protecting your file downloads from just being publicly accessible? Is that what that’s about?

PIPPIN: Not entirely, but sort of. It is related to the file download URLs that we generate. First of all, a fun, little fact: This is actually the longest outstanding issue that’s ever been opened on EDD. We finally finished it, and we finally closed it out. It’s been, like, two and a half years, something like that.

BRAD: Nice.

PIPPIN: Yeah.

BRAD: You guys, your tickets are starting to look like WordPress core.

PIPPIN: I know, unfortunately. Oh, well. What it is: Previously, the file URLs that we generated, they were secure in a sense, but they were really easy to manipulate. The URLs in plain text would contain the file ID that you’re downloading, the product ID, the purchase receipt number, the email address, and the expiration date encoded in Bay 64.

What that meant was, number one, it wasn’t great because we were revealing things like email addresses in a way that we didn’t necessarily need to do. Number two: It meant that if you wanted to, you could actually tweak the expiration date on a download URL. All you had to do was generate a new expiration date, Bay 64 encode it, drop it into the URL, and you have a new URL–

BRAD: Nice.

PIPPIN: –which was kind of nasty. Honestly, we avoided fixing it for so long because we knew we were going to fix it in this one, in signed URLs, so we were doing it all the way or nothing at all. We went all the way, and we finally fixed it. Now, number one, a URL is about 75 characters shorter or so.

BRAD: Nice.

PIPPIN: Something like that. They’re much, much shorter. They look prettier. They also cannot be manipulated anymore at all. If you manipulate them, the token no longer validates. It’s not longer a valid, signed URL.

BRAD: Are you using HMAC for that, or do you know?

PIPPIN: I think, out of the box, we’re using HMAC. I’d have to go back and look. We set it up, actually, so if somebody wanted to, they can change what’s used.

BRAD: Nice.

PIPPIN: We put some filters on there, so you can control which method you use. It turned out that this had some really problematic backwards compatibility issues, primarily with extensions. Due to the way that URLs were validated before, we had some extensions that were hooking into the file download process, maybe to apply a watermark to a PDF or a watermark to an image, maybe to redirect to a different file, extra validation, or something like that.

The way that those extensions were doing it was not very good. It wasn’t their fault. It was because we didn’t give a very good way for them to do it.

Basically, a whole bunch of extensions were doing stuff during the download process based on variables in the URL. The product ID, the file ID, the email address, et cetera, all of these existed as query remarks in the URL. Well, when we replaced them with new, signed URLs, those variables didn’t exist anymore, and so every single one of these extensions broke, which was kind of nasty and obviously not good. We had to get really kind of creative and figure out how to backfill some of those super globals and make sure that those were still available after we validated a URL without actually putting them back into the URLs themselves just so that extensions still work.

BRAD: Oh, yeah. How did you do it?

PIPPIN: What was that?

BRAD: How did you do it?

PIPPIN: Well, after we validated the URL, basically we can extract data from it because we now have the associated purchase record and things like that.

BRAD: Right.

PIPPIN: We can actually just backfill those super globals.

BRAD: Oh, I see. I see.

PIPPIN: In the same was as if they were in the URL, but they’re not actually in the URL.

BRAD: Right. Then any hooks fire after that.

PIPPIN: Right.

BRAD: And so it just looks like the old way of doing things.

PIPPIN: For example, if you said get_file_ID=1, and we do that before the hook runs, it doesn’t matter that it doesn’t exist in the URL because we’ve set it up.

BRAD: Right.

PIPPIN: We had to do some kind of creative and really kind of ugly things like that just to deal with our past mistakes to make it so they didn’t break. We did. We succeeded, so we’ve been now extensively testing it to make sure that everything still works. We had a big list of about 15 different extensions that all had to work flawlessly, both with old URLs and the new URLs.

One of the other things that’s kind of problematic about changing the URL structure is that your old URLs still have to work because we don’t have any idea how long the expiration date is on some of those URLs that already exist.

BRAD: Right.

PIPPIN: Out of the box, we set up 24 hours on download URLs. But we know that people can set them up to be 10 years, 15 years in the future, so we can’t just assume that there’s no valid URLs anymore. We have to support those still.

BRAD: Right, and so you do.

PIPPIN: And so we do, yeah.

BRAD: You detect the old format and the whole code.

PIPPIN: Yeah, basically we have a condition that says if_is_legacy_URL, process it this way, otherwise do it this way.

BRAD: That’s awesome, though.

PIPPIN: I’ll be honest. The one issue that I’m the most happy with, I think, simply because it was really challenging to get around and not break anything. As of now, we’re aware of only one extension that is broken beyond repair. The reason for that is it’s a plugin that completely overwrites our entire download process, removes all of our hooks, removes everything and redoes it, and there was no way for us to do it.

BRAD: Right.

PIPPIN: There is no way around it.

BRAD: Was part of the reason that this issue was the longest outstanding, is it partly because of the complexity of making it backwards compatible?

PIPPIN: Yeah, it’s a bitch to deal with.

BRAD: Right.

PIPPIN: And so it was very easy to be like, “Oh, I don’t work on that today. Okay, I don’t want to work on it today. I don’t want to work on it today,” and you keep going.

BRAD: Yeah.

PIPPIN: Then you get a week from the release date and you’re like, “Oh, well, damn. We can’t do this yet,” so we punt it to the next major release.

BRAD: Right.

PIPPIN: For 2.3, we got together. We decided we are going to work on this day one and it will be tested in the first beta, the second beta, the third beta, and everything in between.

BRAD: Nice.

PIPPIN: That’s pretty much what you have to do if you’re going to get through a bigger issue like that.

BRAD: I try to promote a culture in our team of owning these things and dominating them.

PIPPIN: I agree.

BRAD: This is the challenge, and this is awesome that we can solve.

PIPPIN: I love the challenge of backwards compatibility.

BRAD: Yeah, and I think you’re doing a talk coming up soon about backwards compatibility.

PIPPIN: I’ve got one at WordCamp St. Louis coming up in two weeks, three weeks, and then another one at LoopConf in May.

BRAD: Is backwards compatibility something that you’ve more recently embraced as something that you love to conquer now, or was it always something?

PIPPIN: A little bit of both. I think backwards compatibility has always been something that, at least as a team for EDD, we’ve always been interested in always maintaining backwards compatibility with no exceptions.

BRAD: Right.

PIPPIN: If there’s a way that we can maintain backwards compatibility, we’re going to maintain it because, no matter the reasons for the backwards compatibility, a broken site for a user is a crappy situation. And so, it is our job to work on preventing that. We can argue and justify until the sun goes down whether or not we should still support outdated technology like PHP 5.2 or something like that. But at the end of the day, that doesn’t really matter to the user. They don’t really give a damn. If our system breaks on their site, regardless of whose fault it truly is, that’s a bad experience for them. I think it’s our job to make sure that we try and prevent that as best as we possibly can.

Now, that aside, I also love the challenge. I think looking at something and your first reaction is, “Well, damn! How the heck am I going to do this?” because you immediately think, “Okay, there’s no way to get around this. How could I possibly make this still work?”

If you look at it, and you kind of step back, I’m not really convinced that there’s ever a backwards compatibility issue you can’t solve in some way or other. I like taking the challenge and learning from it. You both get to learn what you screwed up on in the past or what you could have done better, and you might learn cool, new tricks.

Just as a really quick example, and then I’d love to move on and hear what you’ve been doing some more, in 2.3 we’ve also changed how taxes are stored on payment records. Early, early on, I made a really stupid mistake and dropped taxes and a serialized array of other data, which was stupid, really, really stupid. It made it so I couldn’t query on the taxes. I couldn’t do easy calculations. We couldn’t do a lot of things like that, so we’ve changed that in 2.3. We’ve fixed it.

The problem is that we know for a fact that there are a lot of extensions that are retrieving the taxes and setting taxes on payments such as extensions that integrate with other tax systems like Taximo or the EU VAT API, or other things like that. They are setting and retrieving taxes from that serialized array using the standard get_post_meta calls and update_post_meta. We had to get creative, and we had to go intercept those queries to get_post_meta and update_post_meta to make sure that any time that they retrieve information or set information, it comes from the new way that we’re storing the metadata, not the old way. Even though the extensions are technically doing it wrong now or doing it in an outdated method, it still works.

BRAD: Nice.

PIPPIN: I think maintaining that kind of consistency and making sure that we don’t break things, both for users or developers, is really important.

BRAD: Nice. Yeah.

PIPPIN: And it’s a fun challenge.

BRAD: It is fun. I enjoy it. It’s also satisfying to know.

PIPPIN: Oh, yeah.

BRAD: Because if people don’t notice, then you’ve won.

PIPPIN: You’ve done something good.

BRAD: Exactly.

PIPPIN: As much as I would love for a bunch of people to install EDD 2.3 and just be like, “It’s great! It’s awesome! You guys did awesome work!” At the same time, I would love to hear nothing.

BRAD: Yeah.

PIPPIN: If we hear nothing, that means nothing broke, or at least nothing drastic.

BRAD: Yeah, exactly.

PIPPIN: Anyway, enough about what we’ve been doing. What have you been doing?

BRAD: Well, we’ve got Ian in New Zealand is working on the multisite tools add-on for Migrate DB Pro. That’s what he’s been cracking on.

PIPPIN: Ooh. What is that going to do?

BRAD: Well, we’re taking a phased approach to it. The first release will just be an export. You’ll be able to export a sub-site of a multisite install as an SQL file that can then be just imported as a single site somewhere else.

PIPPIN: Very cool.

BRAD: Yeah. We have a doc already that you can step through to get that same result, but this will just be one click and you get that sub-site out as a single site install. It’s been a pretty highly requested thing for us.

Then Ian, and Ashley in the UK, are working on the pro version of the Amazon S3 plugin. We’ve been cracking away at that and getting the UI right and stuff.

PIPPIN: Do you guys have an expected release date for that yet?

BRAD: No, we don’t do release dates.

PIPPIN: Not necessarily a true release date that you’re publishing, but maybe some sort of timeframe.

BRAD: Yeah.

PIPPIN: Is this something you’re looking for a month, two months, a year?

BRAD: Probably about two months from now, in that area. I haven’t even started the marketing site yet, which takes a while, so I really have to start that soon.

PIPPIN: Sure.

BRAD: I’m kind of two weeks behind because I’ve been working on this other thing. I started kind of reorganizing our email lists that we have. We use Campaign Monitor to manage. I’ve got maybe eight lists in Campaign Monitor that one comes from one plugin, so when someone submits the opt-in form in one plugin, it goes to this list, so I can kind of easily track where the subscribers are coming from.

I wanted to kind of reorganize this in a better way. I also wanted to allow people to unsubscribe from certain lists and not from all lists–

PIPPIN: Sure.

BRAD: –which is kind of the way that it was set up. I was trying to figure out a way to do this in Campaign Monitor because I hadn’t done that kind of granular reorganization before. The whole reason for this is because we started publishing more general articles on our blog, and I didn’t want people that are just interested in news about our products to get annoyed and just unsubscribe from all of our lists, right?

PIPPIN: Right. You don’t want to annoy someone with one developer post and then not give them anymore product posts.

BRAD: Exactly, exactly, so there was a big risk factor there that I wanted to mitigate against. I started playing around with the Campaign Monitor forms, and it turns out I couldn’t create a form that subscribed people to multiple lists in one form submission because, the way the forms work, it overwrites. It just overwrites the setting.

For example, say you were to subscribe to all of our lists except for one – say, WordPress development tips. Then you submit the form to subscribe to WordPress development tips. Well, it’ll overwrite your subscription settings and remove you from all the other lists.

PIPPIN: Lovely.

BRAD: Yeah, so that’s how it works. Also, in the testing I was doing, I found a really weird quirk with their forms is that you could overwrite any subscriber, any subscriber’s fields. For example, if I knew you were subscribed to this list in Campaign Monitor, I could just submit the form to subscribe you to the list and put a different first name in. Let’s say, “Asshole.”

PIPPIN: You mean, as a subscriber, you could do that?

BRAD: No, anybody can do it – anyone.

PIPPIN: Right, so if I go to the form, and I know your email, and I know that you’re subscribed, I can update your preferences?

BRAD: Yes.

PIPPIN: Oh, that’s awesome.

BRAD: Yeah, just by submitting the form again with the email address of the subscriber, it will overwrite whatever is in there already. If I put your email address, and then I put the first name as Asshole, it will overwrite your first name field as Asshole. Then the next time you get an email, it’ll say, “Hi, Asshole.”

PIPPIN: Awesome.

BRAD: I didn’t like that, so I reported it to Campaign Monitor. They were like, “Eh, whatever.” I guess it’s not really been a problem that people have noticed or have exploited.

PIPPIN: Yeah, but the moment that some asshole does notice it, they can do some serious damage.

BRAD: I know. I know. It’s not hard to identify a Campaign Monitor form, right? You can tell by the URL that that’s where it’s posting to. Yeah, it’s definitely open to vulnerability.

Anyway, I asked them, “Is there at least a way that I could subscribe to multiple lists and not overwrite the subscription setting?” and they said, “No, you have to do some API programming.” I was like, “Oh, well, if I have to do that, I’m just going to move to a better platform,” because I’ve been kind of looking for an excuse to move to something that’s more flexible and more modern in terms of email marketing.

PIPPIN: Right.

BRAD: Campaign Monitor and MailChimp, they’re great when you’re first starting out, but they don’t have some of the more advanced features like marketing automation stuff that’s pretty awesome these days. I’ve moved over to Drip is basically the….

PIPPIN: How is that working out for you? I’ve never actually used Drip at all.

BRAD: It’s been great. It’s a really, really great platform. One of the things you can do is tag your subscribers. You could tag all your customers as customers and do those kinds of things. They have events, so there’s just more flexibility to the platform.

PIPPIN: That’s great.

BRAD: It’s pretty good. The big problem that I faced here moving from Campaign Monitor to Drip is that I have a bunch of opt-in forms all over the place, and some of them are inside plugins, and some of them are just links to opt-in pages on Campaign Monitor. I can’t really get rid of those or update them quickly and easily, right?

PIPPIN: Right.

BRAD: I’d have to do a release of every plugin that I have, and then I don’t even know the opt-in pages. I don’t even know how that would work at all.

PIPPIN: Did you figure out a solution? If not, I have an easy answer for you, I think.

BRAD: I took the hard solution, but what’s the easy one?

PIPPIN: My answer would be to ignore it, ignore those forms in terms of don’t go and try to update every single one of them. Just leave them there. Maybe update the ones that are easy to access that you immediately know where they are, et cetera. Then use something like Zapier. Any time someone subscribes to Campaign Monitor, just move them over to Drip.

BRAD: Yep. Good idea. I’ve tried it.

PIPPIN: It didn’t work?

BRAD: It wouldn’t work, no.

PIPPIN: Really?

BRAD: Yeah. Here’s the problem with that. That was the first thing I tried. The problem is, in Campaign Monitor, the first name/last name fields are stored as “name,” so one field. In Drip, you have first name and last name fields. Zapier can’t do a simple operation of splitting that name.

PIPPIN: Right.

BRAD: Then that’s not an option.

PIPPIN: Okay. More difficult, but still possible way, drop them. Use Zapier to go from Campaign Monitor to Google docs to Drip. It’s crazy, but I’m pretty sure you could do it.

BRAD: Yeah.

PIPPIN: Zapier is insane.

BRAD: Yeah.

PIPPIN: I’m with you that I wish it had some kind of parsing ability just to be like, “Look, this system was dumb and didn’t split my field the way it needed to. Split it for me.”

BRAD: Right.

PIPPIN: That’d be cool.

BRAD: Yeah, that would be cool, like a data transformation thing.

PIPPIN: Super awesome.

BRAD: Yeah, I’m sure that’s on their radar somewhere. So I do what I usually do. I scripted it. I just took the Campaign Monitor SDK and the Drip SDK, and I just mashed them together and wrote a sync script that, every hour, runs on my server.

PIPPIN: Nice.

BRAD: Then copies any new subscribers from Campaign Monitor over to Drip.

PIPPIN: It goes to Campaign Monitor, finds the newest ones, pulls them down, sends them to Drip.

BRAD: Yep, exactly.

PIPPIN: Okay. Yeah, that works.

BRAD: I basically built a little Zapier.

PIPPIN: Sure. Nice.

BRAD: But it works.

PIPPIN: I wonder if you could have also done it with Web hooks. I don’t know if Campaign Monitor has Web hooks or not.

BRAD: It does. I thought about that. I thought about using Web hooks, but the moment that they don’t work, so it fires and the server doesn’t receive it or something happens, then you kind of just lose that subscriber.

PIPPIN: Sure.

BRAD: Whereas this way if the script fails–

PIPPIN: If it fails, it’ll get it next time.

BRAD: –it’ll get it next time, yeah.

PIPPIN: That makes sense.

BRAD: It’s got that advantage, so I went with that one.

PIPPIN: Nice.

BRAD: Yeah, so that’s been my journey. A hell of a journey, right?

PIPPIN: Are you really liking Drip so far now?

BRAD: I am. It’s great. I feel like I’m just starting, though, because I’ve just gotten Drip to where Campaign Monitor was, right?

PIPPIN: Sure.

BRAD: But I feel like I’m in a better spot.

PIPPIN: I’ve worked with a lot of the newsletter systems and email lists in a basic form because I’ve done integrations on a basic level with most of them. What made you choose something like Drip over MailChimp? Even though I’ve done integrations with them, I’ve only used MailChimp extensively.

BRAD: Right.

PIPPIN: What’s great about Drip?

BRAD: It’s email-marketing software – marketing automation software, right?

PIPPIN: Yep.

BRAD: Which is not what MailChimp is.

PIPPIN: They have it now.

BRAD: Yeah, they have something.

PIPPIN: Their automation stuff.

BRAD: They have some automation stuff built into it. Anyway, Drip is built basically as a kind of stripped down or kind of a light version of — what’s it called? There’s a big company that’s really expensive that does this stuff. I can’t remember.

PIPPIN: Is it like Customer IO?

BRAD: No, no. Customer IO is quite different because it’s really for transactional stuff, right?

PIPPIN: Okay.

BRAD: It’s illuding me right now. Infusionsoft, that’s it.

PIPPIN: Yes, okay, I know. Yes.

BRAD: Yes, but the price points on Infusionsoft are quite a bit higher than Drip. You’re basically getting a slightly reduced feature set in Drip, and so it’s kind of like Infusionsoft for smaller businesses, basically. You get a lot of nice marketing automation features. For example, say someone subscribes to your list. You can start sending them an automated string of emails. The sign-up form could be like, “Sign up for a crash course on how to build your first WordPress plugin.”

PIPPIN: Sure.

BRAD: Then Drip would send them a string of emails based on that on a certain schedule, and it allows you to set that up. Then if maybe they become a customer or something, maybe then it fires an event and switches them to a different string of emails. You see?

PIPPIN: That is actually very similar to the new MailChimp automation stuff.

BRAD: I’m sure it is.

PIPPIN: Almost identical. But you’re right that MailChimp did not use to have that.

BRAD: Yes.

PIPPIN: It’s still something that’s very new for a lot of people.

BRAD: Yeah.

PIPPIN: That is awesome. That’s something that I want to get into a lot more in doing more email automation, especially as our email lists have grown. I am not an email marketer at all. I never have been. I really don’t think I ever will be, but I can see its tremendous value. As our lists get bigger, bigger, and bigger, I keep looking at it and thinking, “Man, what are we leaving on the table here by not taking more advantage of it?”

BRAD: Right, yeah. Yeah, I don’t know how much I’ll use those features, but it’s just nice, for example, to be able to tag your subscribers and know who are your customers and who are not, and actually send tailored messaging to that segment of your customer base, right?

PIPPIN: Definitely.

BRAD: You could tag who is a customer of this product, and who is a customer of that product.

PIPPIN: Yeah.

BRAD: That kind of stuff wasn’t possible in Campaign Monitor. I don’t know if MailChimp has tags or any of that kind of stuff.

PIPPIN: They do now. Out of the box, they don’t. But if you use their MailChimp e-commerce 360 API, you get to store all purchase data. Any time that somebody purchases something on any of our sites, they get added to a MailChimp list, and they get their purchase information recorded. I can go back at any time and say, I want to email every single person that purchased software licensing within the last 30 days or at this time, or I want to email every single person that’s every purchased something, or everybody that is a customer with a greater than $500 value, or things like that.

BRAD: Ah, neat. Yeah, it sounds like MailChimp and Drip are really competing. It sounds like they’re really competing.

PIPPIN: Based on everything that I hear from you and from others, they definitely have a lot of similar features now.

BRAD: Right, yeah.

PIPPIN: Which is great. Competition is good.

BRAD: Yeah, for sure. Do you want to talk about Password Generator for core?

PIPPIN: Yeah, I do. This is in WordPress core. There is a ticket that I’ve been kind of babysitting for a while that will hopefully make it into version 4.2. We don’t know if it will or not yet because it’s still got some things to figure out. Basically, for anybody who is interested, it’s ticket 24633 in WordPress Trac.

The idea is to allow site admins to generate and send passwords to users. If you’ve ever managed a site that has user accounts on it, you’ve probably had someone email you and say, “I can’t get in. Reset password doesn’t work. Can you change my password for me?”

Well, as an admin, you really should never know what a user’s password is. Even if it’s a temporary password, you just shouldn’t know, and you should be able to generate them a strong password on the fly. This ticket is based around the idea of adding the option to generate a strong password for any user at any time, either editing their account, creating a new user account, et cetera.

I think it’s getting close to where it might get at least part of it committed. We’ve tried to separate it out into several components, so we’ve added a general JavaScript API to WordPress to generate a password that would then allow you to add a password generate button anywhere on the site you want, either through a plugin or in WordPress core itself. Then we’re adding those password generators to the “Edit Profile” screen, to the “Add New User” screen, to the “Registration” screen, et cetera.

Hopefully it’s going to get committed. We’ll see. It’s still a milestone for 4.2, but it’s not officially signed as a task, so it’s not guaranteed to go in yet.

BRAD: Right. Has there been any pushback about, “Oh, this should be in a plugin”?

PIPPIN: It started as a plugin. The original ticket was inspired by a plugin written by Jake Goldman called Simple User Password Generator, which does exactly this and allows you to generate a password. It’s just a phenomenal little plugin. There are a couple of other variations on the plugin from other people. For anybody that manages a site with a lot of users, it’s just super nice and valuable.

Aside from the security aspect of not knowing your users’ passwords, even when you reset them, it also just makes the process of resetting someone’s password easier because, if you need to manually change it, instead of going in and typing in “password123” or going in somewhere and generating the random password, all you do is say, “Generate password. Send via email.” Done.

BRAD: Right. When you create a new user right now, it generates a password for them, right?

PIPPIN: No, it doesn’t.

BRAD: It doesn’t?

PIPPIN: Nope.

BRAD: What am I thinking of?

PIPPIN: If you create a new user right now and invite them to the site, it will invite them. It will send them a link, and then — well, they might get a temporary password then, but then they have to reset it. That I’m not 100% sure on because I think it differs between multisite and non-multisite.

BRAD: Right. I can’t remember.

PIPPIN: Sometimes I forget which one is which.

BRAD: We were just looking at this the other day with WooCommerce. If you have a certain setting turned on, it doesn’t show the password field on the checkout form, and it actually just auto generates a password for them.

PIPPIN: Right, but I think that’s WooCommerce, not WordPress core.

BRAD: Yeah, I think you’re right. Yeah.

PIPPIN: You can. There is a function in WordPress to generate a random password that there are a lot of plugins that use it. We use it in EDD with one of our EDD extensions where we basically do the same thing where it allows us to automatically register an account. For that, we generate a random password.

BRAD: Yeah.

PIPPIN: This is a ticket that I would really love to see get into 4.2. It’s been kind of inching along slowly since around 3.8, I think, maybe 3.7. If anybody wants to go in, jump in, give some feedback on the UI, feedback on the API, please feel free. It’s ticket 24633.

BRAD: Cool. I’ve also been working on WordPress core.

PIPPIN: What have you been doing?

BRAD: Just last Friday, we had our company–

PIPPIN: Your core contributor day.

BRAD: –core contributor day.

PIPPIN: I love that idea.

BRAD: Yeah. Everyone at Delicious Brains works on core, and so the first thing I did is I went through all my existing kind of tickets that I’ve participated in and just made sure that the patch is still applied cleaning against trunk.

PIPPIN: That’s a great idea.

BRAD: I had update one because it didn’t. Yeah, it made me realize you really do have to keep doing that. You have to tend to your tickets.

PIPPIN: Absolutely.

BRAD: Like you’re tending a garden or something.

PIPPIN: I know that, just as an example of refreshing the patches, going back and doing that, like with this password generator ticket, it’s got 29 patch versions on it, I think.

BRAD: Wow!

PIPPIN: Probably 15 or 20 of those were just for refreshes.

BRAD: Yeah.

PIPPIN: Just to make sure that, as things changed in core, just to make sure it still applies.

BRAD: Yeah, because things get bad for the ticket if it doesn’t apply cleanly anymore.

PIPPIN: Yeah, things move really quickly in core, and so you’ve got to keep them up.

BRAD: Yeah.

PIPPIN: Honestly, it’s probably one of the easiest ways to ensure a ticket actually gets merged into core at some point because, the easier it is for one of the core committers to test it and patch it, the faster it’s going to go in.

BRAD: Yeah, exactly. I also jumped on a new ticket. The title is Allow More Specific Image Size Editing. The ticket is really about adding — when you’re editing an image, there are little radio buttons in sidebar underneath a title that says Apply Changes To. Basically the idea is you can apply these changes that you’re making to the image to all image sizes, just the thumbnail, or all sizes except thumbnail. That’s the current way it is in core. This ticket is about changing those radio buttons to really just show all the available image sizes as checkboxes.

PIPPIN: Oh, man. That is an excellent, excellent idea.

BRAD: You could just choose exactly what images you want affected by the changes you’re making.

PIPPIN: I can’t even think of the number of times when I’ve had an image that, let’s say there was an image size on the site. Maybe it’s your featured post image. You upload an image, and it doesn’t quite work for that image size.

BRAD: Yeah.

PIPPIN: Being able to edit just that size would be magnificent.

BRAD: Yeah, yeah, I thought it was a great ticket when I looked at it. It’s five years since it was opened, so it’s an oldie, but I thought maybe now is the time we can get this thing.

PIPPIN: That would be awesome. Does it have a finished patch that works?

BRAD: It had one patch that was submitted five years ago when the ticket was opened and hasn’t had an update since then, so I looked at it. There was also a problem with the patch. It didn’t take into account additional image sizes. In fact, five years ago, there may have not even been additional image sizes. I don’t know.

PIPPIN: Five years ago – I don’t know.

BRAD: Probably not.

PIPPIN: If there were, they were pretty rudimentary.

BRAD: Yeah. I had to include that in my patch so that it supports the custom image sizes that you add using the add_image_size function.

PIPPIN: I’m looking at your patch, and it’s really not complicated.

BRAD: No, it’s pretty straightforward.

PIPPIN: Very cool.

BRAD: I did add some notes about what I had done because I think there are still some problems that need to be addressed. I’m using the image_size_names_choose filter, which is the filter that, when you go to insert an image into a post, there’s a little dropdown for the image sizes, so you can choose what image size you want to insert into the post. Well, that list, that dropdown list is created by this filter, the image_size_names_choose filter. If you know the add_image_size function at all, there is no label for an image size, right?

PIPPIN: Right.

BRAD: There’s nothing to display. We use this filter to basically create a list of image size names.

PIPPIN: At some point that should probably get fixed.

BRAD: Yeah, it’s kind of janky, isn’t it, the way that’s set up? I feel like add_image_size would be better off having its own label or labels, right?

PIPPIN: Sure.

BRAD: But, for now, this is the way core does it, so I just followed its lead. I think, really, we should be using a different filter here because the names of the images in this list might not really make sense to be the same names as the list where you’re inserting an image.

PIPPIN: Right.

BRAD: The context is different.

PIPPIN: It actually really seems like a great candidate for the add_image_size function to get extended to allow you to register labels.

BRAD: Yeah.

PIPPIN: Then display those labels.

BRAD: Yeah, and I think add_image_size might actually need to be completely — like the parameters need to be reworked because, right now, there’s already three parameters and they’re not all–

PIPPIN: Isn’t there an args parameter on it?

BRAD: No, there isn’t. That’s what I think–

PIPPIN: Oh, I thought there was.

BRAD: I think that needs to be proposed.

PIPPIN: Yeah, that makes it way harder.

BRAD: Yeah, it does. I think add_image_size really should just be the ID of the image size.

PIPPIN: Followed by arguments?

BRAD: Followed by args, yeah.

PIPPIN: Yeah. Yeah, that would be way nicer for sure because that would then allow you to say, “Okay, here is a label,” yeah, lots of other stuff for it.

BRAD: Yeah. Maybe the better way to do it might be to create a new register image size that’s in line with registered post type and the other register functions.

PIPPIN: That makes sense, and then add_image_size could just call that.

BRAD: Exactly. I think that would work.

PIPPIN: Perfect case of where backwards compatibility matters.

BRAD: Yeah, exactly. Anyways, should we wrap it up?

PIPPIN: Yeah. Real quick, is there anything coming up in the next couple of weeks that people should know about for you?

BRAD: For me? I don’t think so.

PIPPIN: Any short-term releases?

BRAD: I don’t think so, no. We might put out–

PIPPIN: You’re just going to keep cranking on.

BRAD: Yeah, we might put out Migrate DB Pro in the next couple weeks, a small release, just a maintenance release.

PIPPIN: Sure.

BRAD: We’ll see. I don’t think so. You?

PIPPIN: Aside from EDD 2.3, which will hopefully go out within two weeks, not much. If you’re coming to Prestige Conf, come say hi. I will be there, along with the rest of the EDD team.

BRAD: Awesome.

PIPPIN: We’d love to chat with anybody who is there.

BRAD: Cool.

PIPPIN: All right. Thanks, everyone, for chiming in.

BRAD: Thanks, everybody.