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

PIPPIN: Welcome back to Episode 73. This time Brad and I are going to go over some updates and then talk a little bit about some things that were announced at WordCamp US last month in Philadelphia, or actually earlier this month in Philadelphia. But first–

This episode is sponsored by Post Status. Post Status is a project by Brian Krogsgard and is a resource for news, updates, and other things happening in the WordPress ecosystem. It is a wonderful website to kind of pay attention to what’s going on.

Brian also has a members’ only section where you can subscribe to the site and get access to special resources that include video interviews, additional podcasts, blog posts, as well as a Slack channel where you can jump in and talk with other members of the Post Status community on everything from development to e-commerce to life and health and many, many other subjects. It’s one of my favorite resources for WordPress news, updates, and conversations.

Brad, I believe you’re also a member, aren’t you?

BRAD: I am. I am a member, and I love Post Status. I love the emails that Brian sends out to club members so that we can get — it basically just condenses all the news down to, like, little bite sized pieces that you can consume quickly, and so it just saves you from having to kind of troll through all of the WordPress news sites and figure out and separate kind of the noise from the signals.

PIPPIN: Yeah, when time is a premium, which it always is, those summaries are awesome.

BRAD: Yeah. It’s good to get his, like, viewpoint on things too. I really appreciate that.

PIPPIN: Yeah. Brian has been around for a long time, so he’s got some pretty astute observations and pays really close attention to what’s going on.

One thing I did want to mention real quick is that Brian just posted an interview that he did with Matt Mullenweg shortly after WordCamp US and talked a little bit about a new WordPress development cycle, the WordPress Rest API and more. Go check out PostStatus.com and give Brian some love.

Alrighty. Mr. Brad, what have you been up to in the last couple of weeks?

BRAD: Well, I think we haven’t done updates for, like, four or five weeks, actually. Quite a bit has happened for me. I’ve been to Scotland for the first time to meet up with the U.K. contingent of the Delicious Brains team, and we tried to do–

PIPPIN: How many team members do you have over there?

BRAD: We’ve got four, four guys that live in the U.K. Yeah, we met up. None of them are from Edinburgh, so we all met up in Edinburgh, and there was a WordPress meet up one of the evenings that we were there, so we went to that. It was cool to kind of meet the local WordPress community in Edinburgh, so that was pretty neat. Then, I mean, there’s castles all over the place and experiencing the culture and everything, yeah, it was a nice trip.

PIPPIN: How long were you guys there?

BRAD: Four days, I think, four or five days. Yeah, it was awful, though, the flights. I had three flights it took me to get there, and if I could fly direct, it would have been like a five-hour flight. On the way home it took me 23 hours to get home.

PIPPIN: Because normally that would only be, like, a ten-hour flight across the Atlantic, I would think.

BRAD: Oh, like a five-hour flight, I think.

PIPPIN: Wow!

BRAD: I think….

PIPPIN: What route did you take to get there?

BRAD: I had to fly — normally it would be like Halifax. Like a Halifax to London flight would be like five hours. But this was Halifax to Boston, Boston to Dublin, Dublin to Edinburgh. With all the layovers and everything else, it was, yeah, it was ridiculous. On the way home–

PIPPIN: That’s intense.

BRAD: Yeah. It was worth it in the end, but it was a process. And then I attended WordCamp US just a couple weeks ago. You were there, other people were there, and so that was cool. Oh, and my team was there, so the North–

PIPPIN: I thought you had either your whole team or most of your team there.

BRAD: Yeah. Yeah, the North American contingent of my team, so two Canadians and two from the U.S. We all met up in Philadelphia and ate some food, hung out, went to WordCamp US, and all that stuff, so it was pretty cool.

PIPPIN: It was a really, really great event.

BRAD: Yeah.

PIPPIN: I think it was probably better than last year, and last year’s was really good too.

BRAD: Yeah. I enjoyed it more last year. I think it’s because I didn’t stay up so late or something because I was just so exhausted, like, after the first day and I just didn’t recover. And so this year it was tougher for me.

PIPPIN: Yeah, see, I did the opposite. Last year I was–

BRAD: Right.

PIPPIN: –super late every night, and this year at 10:30, nope, I’m out, folks.

BRAD: Right. I remember that because you guys had — wasn’t it called the Post Status House? You were staying with–

PIPPIN: Last year, yeah, we had the Post Status House.

BRAD: Yeah, the Post Status/EDD House. You and Krogsgard had a house. Wasn’t Strebel staying there too?

PIPPIN: Yeah, I think there was about 20 of us there. We technically had three floors of this house that had been turned into apartments, so we had three different apartments, each one with like five to eight people in it.

BRAD: Right. Right, so you guys–

PIPPIN: It was a lot of fun.

BRAD: Yeah.

PIPPIN: But it also just meant that we had a lot of late nights.

BRAD: Right. Yeah. Cool. What else happened? Mergebot launched beta on–

PIPPIN: I’ve been seeing your emails coming through.

BRAD: Yeah.

PIPPIN: And it looks like you’re adding a lot of new beta testers to it, aren’t you?

BRAD: Yeah, we’re up to 110, about, beta testers right now, which is excellent. We’re getting lots of feedback coming in. The good news about the feedback too is that the majority of the feedback is stuff that we’re already working on that’s kind of at the top of our priority list, so we have to knock those things off to kind of see what’s next, what are the other issues people want to see resolved next. That’s kind of how betas go, right?

PIPPIN: I find that betas are a lot of times hit or miss because sometimes you release a beta and you don’t get any feedback.

BRAD: Right.

PIPPIN: Maybe one or two. How has it been for you so far with this one? Are you getting a lot of genuine feedback?

BRAD: I wouldn’t say we’re getting–

PIPPIN: Are you getting bug reports?

BRAD: I wouldn’t say we’re getting a lot. We’re getting a trickle, I would say. But the feedback that we are getting has been good so far. What I’m anticipating is, once the first month rolls around and subscriptions start renewing, I suspect people to either cancel their subscription or ask for a refund because they’re not using it. Then we can start to have those conversations or at least I’ll have more conversations at that point about, like, why are they canceling, what would they like to see.

PIPPIN: Are you able to see, of those beta testers, what percentage of them are actually testing it and using it? Because you have this set up as a service, so do you have those kind of activity logs and such?

BRAD: We do, but it’s pretty raw. We don’t have nice reports that I can run. I pretty much just ask the guys, you know, is this person active? Give me a list of people that are active. They would have to run their own kind of custom query to figure out what users are active, which users are inactive, and stuff like that. It’s pretty raw at this point. It would be nice to have reports that show that, but I mean, you know, priorities, right?

I think what I’m going to do is start reaching out to customers in the new year that are using it and those that aren’t using it just to nudge them to see. Maybe they’re stuck. Maybe I need to help them get unstuck, right? Just reaching out, I think, will help a lot with that.

PIPPIN: Of those 110 beta users, are those users all signed up for a subscription, so are they going to automatically convert into paid subscribers after the beta period is done?

BRAD: Oh–

PIPPIN: Or are they free accounts or anything like that?

BRAD: The beta is actually not free.

PIPPIN: Ah!

BRAD: We are actually charging $9 a month right now for the beta. That’s why I was saying, like, when people cancel after a month then I’ll know. Maybe they cancel because they weren’t getting enough value out of it. Maybe they weren’t using it. Why weren’t they using it? I can have those conversations when they stop paying, right?

Yeah, that’s why. That’s the main reason I decided to charge. I mean $9 a month is — I kind of regret not charging more, a more realistic figure.

PIPPIN: Sure, but it’s still going to let you get rid of some of the fluff in the beta users. Anybody who signs up for a beta, whether they actually go through with it or not, at least have the intention of utilizing it because otherwise they wouldn’t pay for it.

BRAD: Yeah. I guess my concern with charging the small amount is that some people might just keep paying it just to keep the grandfathering because I’ve promised all the beta users that get in at $9 a month that they keep that plan at $9 a month. They’re not going to be subject to price increases in the future as kind of a thank you for helping us out early on, right?

They might just hold onto it for the whole year because it’s not very much money in the grand scheme of things just to hold onto that grandfathering. But anyway, we’ll see what happens. It’s a good experiment nonetheless.

PIPPIN: Okay. Now you’re, what, three weeks into the beta period? Do you have a realistic public launch in mind yet?

BRAD: No, not yet. I think we’re a ways off from that yet with some pretty hefty issues. But we don’t know. We feel they’re hefty issues, but we need people to tell us that they’re hefty issues, right? That’s going to determine when launch can be, right?

If people tell us, “Okay, this is a problem,” that we didn’t even think was a big problem for people, we might have to tackle that before launch. Right now we just don’t have a good feel of what people need in the app, right?

PIPPIN: From the beta period, do you have anybody who is giving you either small or large success stories? Or is it too early to say?

BRAD: It’s a little early.

PIPPIN: You’re still only three weeks in.

BRAD: Yeah, it’s pretty early to tell. It’s funny. I was talking to people at WordCamp US. We had launched the beta on Tuesday, and some people had left for WordCamp US on Tuesday or Wednesday, so no one — people told me they had an invite, that they got in or had a subscription, but they hadn’t used it yet. It was a little frustrating. I was like, “Oh, I wish we had launched the beta a week earlier because I could have these one-on-one conversations with people about Mergebot after they’ve used it for a week or so.” Hindsight, 20/20, right?

PIPPIN: Sure. Well, it sounds like things are progressing pretty nicely with it.

BRAD: Yeah.

PIPPIN: I’m excited for you. It’s going to be a cool product when it comes out.

BRAD: Yeah. One of the issues that has come up actually kind of involves EDD a little bit.

PIPPIN: Ah! I’m sorry–

BRAD: No, no. It involves pretty much every plugin, but it’s interesting how it involves EDD. When EDD installs, doesn’t it go through all the users and adds something, a capability or something?

PIPPIN: We do add a couple of capabilities to the site, but it doesn’t go through all the users.

BRAD: It doesn’t go through all the users.

PIPPIN: It’ll go through. We have a couple of user roles. For example, we have a shop manager role that we create. We have a shop administrator. We have a shop worker. We have a shop accountant. And so these various roles are basically given to user roles with certain capabilities so that they can edit products, edit other people’s products, edit store settings, view reports, et cetera.

BRAD: Does it go through certain users and assign them those capabilities?

PIPPIN: It will go through. It’ll assign it to administrators. That’s the only–

BRAD: Right.

PIPPIN: –default role that gets edited.

BRAD: Right. Okay. When it installs, it runs that routine that queries for all administrative users and adds that capability.

PIPPIN: Well, technically it doesn’t add it to the users. It adds it to the role, but which in turn adds it to the users.

BRAD: Yeah, okay. Whatever. But right, so what happens, though, is let’s say you’re running Mergebot and you install EDD locally and it does that. Well, let’s say on the live site some new users get added, right?

On the local site, Mergebot is going to record those changes that happen that EDD makes. It’s going to record those capabilities that get added to those users. But if any new users get added to the live site between when you recorded and when you deploy, those new users won’t end up with the capability because Mergebot only knows about the ones that were recorded locally. That’s a big problem.

PIPPIN: Interesting.

BRAD: Yeah, yeah. We’re calling it — this happens in other — this is just one situation. Another example of it is with WooCommerce. When you save a product in WooCommerce, like let’s say it’s a digital product and you change the zip file. It’s a new version of the zip file. When you save the product, it loops through all the users and adds a product permission to the downloadable product permissions table. Mergebot could record all those changes that happen when you do that, right? But all the new users that get added on the live side won’t have those product permissions added at deploy time.

PIPPIN: Hmm. I don’t know if you saw this, the specific to that particular issue. That loop that WooCommerce does to add those permissions has actually been removed in the new version that’s coming up in 2.7.

BRAD: Oh, is it? Interesting.

PIPPIN: Yeah. It was too performance heavy.

BRAD: Oh, yeah.

PIPPIN: It took too much power.

BRAD: Oh, yeah. It takes — when we update a product, it takes like several minutes to run.

PIPPIN: Yeah.

BRAD: To run that.

PIPPIN: I think it’s on the develop.woocommerce.com site. They just announced. They first made a version of 2.7, and that’s one of the highlights.

BRAD: Right. But anyhow, so these are all operations that require the data at deploy time, right? Basically, you have to run this PHP code against the database at deploy time is really the only time that it could be run effectively. We’re thinking now, like, we’re going to have to solve this on a plugin-by-plugin basis and maybe get plugin vendors like yourself, allow us to trigger your plugin to run that routine at deploy time again. So EDD will loop through all of the admin users and add the capability again at deploy time. That’s the only solution that we’ve come up with so far, which is–

PIPPIN: It seems pretty reasonable.

BRAD: Yeah, it’s reasonable, but it sucks.

PIPPIN: It’s still a pain.

BRAD: It sucks because you have to do it on a case-by-case basis, right?

PIPPIN: Right.

BRAD: But sometimes that’s what solutions are.

PIPPIN: Making progress.

BRAD: Yeah. Yeah.

PIPPIN: What else have you got for us?

BRAD: Well, we attended Contributor Day at WordCamp US, and I started hacking away at a plugin to relegate image resizing to a background process. What a lot of themes do, they do what’s called on the fly image generation. And so when you hit the page for the first time, it will actually resize the image and then feed the image to the page. It could take a while to display the image because it has to generate it first before it comes back. That’s bad. That’s hard on the server, and it’s not a great system any for responsive. The resizers that I’ve seen only do one image size. The designer can’t define several image sizes that would work with their responsive design, right?

Anyway, this plugin just gives theme designers a function where they can just input a bunch of different image sizes, it will generate it, and it will add the necessary metadata to the attachment in WordPress so that if you delete the image from the media library, it will delete the resized images, which a lot of on the fly image generators don’t do that. They just leave the images behind.

It does it all in the background, so if you request. Let’s say you request a page and all the image sizes that are defined in the theme that the designer wants to show aren’t generated yet. It will just serve the best one. It will just choose the best one that already exists, so like the default, one of the default sizes that WordPress creates. But then it’ll queue it up in the background to create those other image sizes.

Does any of this make sense?

PIPPIN: This makes perfect sense. As you’ve been explaining this, I’ve been reading through the GitHub repository, the file, the plugin code, and the installation guide. This is really slick.

What was the inspiration or driving force behind this? You mentioned OTF, on the fly image generation, which is definitely an issue performance-wise. Now was this a personal need that you guys had from your own experience with your own sites, with maybe older projects, client sites, or something else? Or was this something that somebody else brought up during Contributor Day, and you realized, “Hey, I think we can solve this”?

BRAD: Yeah, so we had this background processing library that we use in Offload S3. It’s reusable, so other plugins are using it. WooCommerce is using it, and I believe some other plugins. I’m not sure. Definitely WooCommerce is using it.

We’re trying to figure out a way to develop it further and then eventually get it into WordPress Core. I was talking to Mike Schroder–we call him Shredder, though, right?–at WordCamp Europe in June. He was saying that background processing would be a good candidate for doing image processing in the background, and that would be a good kind of gateway to get the background processing libraries into WordPress Core if you could get it in with image processing. That was kind of the inspiration for it.

We also have problems with on the fly image generators and Offload S3, so all these things kind of came together. I was just like, “This solves — this is more than two birds with one stone. This is like three or four birds,” so this just made sense to do this. So I just finally got busy and did it.

PIPPIN: This is slick.

BRAD: Yeah.

PIPPIN: How many? Let’s say that you have a thousand images in the queue on a site.

BRAD: Mm-hmm.

PIPPIN: What kind of timeframe would we realistically expect that that queue will be worked through?

BRAD: I don’t know, man. That depends on a lot of things. That depends on the server, how powerful it is, how much demand is on the server.

PIPPIN: Okay. Let’s see if we can phrase this in a different way. This is all done in the background.

BRAD: Yeah.

PIPPIN: How often is the queue getting processed and, say, how large of — it’s doing it in batches right?

BRAD: Yes.

PIPPIN: Does it run, say, like a couple times an hour? Is it once a day?

BRAD: When the request comes through and the function is called, it will kick off the background process using an asynchronous request using cURL. It’ll kick off a cURL request to WordPress, and that’ll start generating the images. Then if it needs to do another batch, like if it has to stop processing for whatever reason, maybe PHP times out or whatever, it’ll kick off another one. It’s like a chain of asynchronous requests.

If for some reason that chain of requests dies or something and stops working, there’s a WP-Cron that is running to basically keep it alive to make sure it runs to completion. Once the queue is empty, it removes the cron. It removes everything so that the whole thing kind of cleans up after itself. It’s not constantly running.

PIPPIN: What kind of protection is there for preventing too many background processes getting triggered? Does it always only allow one to run at a time, or could potentially let’s say if your site suddenly got a thousand hits, would each one of those potentially trigger a new process?

BRAD: As far as I know, so Ashley is the one that wrote the background processing library, and I’m really just using it in this plugin as a proof of concept. But as far as I know, it’ll just run the one at a time. It won’t do several. If you hit a bunch of different pages at once, it won’t try to do all the regeneration of images at once. It’ll do them in order.

Also, it does take a look at memory, the memory that’s available. It takes a look at CPU usage, and it determines whether or not it should be running and whether or not it will run. It’s a pretty cool little system. And he’s currently working on setting it up so that you can run it as a daemon process on the server, so it’s not so dependent on WP-Cron, as we know is not all that reliable.

For most situations, you’re not going to use a daemon process, right? Most people are not going to be logging into the server with SSH and setting up a daemon. But in certain situations someone that’s setting up a very busy site or a site that they want to optimize for maximum performance, they could do this if they wanted to. Yeah.

PIPPIN: Very cool.

BRAD: Lots of stuff happening there. Yeah, I urge anyone to check that out. We’ll link it up in the show notes. Yeah, check it out.

Anyway, what have you been up to, Pippin?

PIPPIN: Well, we haven’t pushed a whole lot of updates in the last few weeks. We pushed some little updates here and there, but we’ve been mostly focusing on three major releases. We have 2.7 of Restrict Content Pro coming up, as well as 2.7 of Easy Digital Downloads, and then we have 2.0 of Affiliate WP, all three of which are hopefully getting released some time in January.

BRAD: Wow! Busy January.

PIPPIN: The main thing is that, with the way that our team has grown over the last year, we actually have developers working on all three projects simultaneously, so we’re able to do releases concurrently. It used to be that we would do one project, so like we would do RCP. Then we’d do EDD. Then we’d build something with Affiliate WP. Now we can do them all at the same time because we have team members working on all three simultaneously.

There’s a couple of major things that we’re doing in these three. Restrict Content Pro, for example, we are trying to get rid of some of our technical debt that we’ve had for a long time and making some improvements there. For example, there’s been some nuances with the way that category level restrictions work. Let’s say that you have content that you restrict to specific categories. These could be an actual category. It could be a custom taxonomy for another plugin. Think of, for example, product categories inside of WooCommerce.

There’s been a lot of nuances with the ways that those restrictions are handled. One little example is that we have this option in the plugin to automatically redirect a member away from a page that they don’t have access to. Let’s say that you are a subscriber on a site, and you try to access a page that is restricted to members of a subscription level other than your own. Maybe you have the silver level, but the post requires the gold level.

Those, that redirection from that page to somewhere else, maybe a landing page that says, “Oops. You can’t access this. You need to upgrade your account,” type page, those kinds of redirects would only happen at, say, like the page level restrictions. But if you restricted content at a taxonomy level or like a category, so all content within this particular category is restricted, that redirect would never happen.

There are a few other cases where basically an inconsistent behavior, inconsistent feature sets where, like, the redirect could only work in these conditions, but not in these ones, or there’s a method in one of our classes basically called Can Access, and so you can say, “Can this user ID access this post ID?” It will return true or false based on the member’s subscription, their status, et cetera. That check completely ignored taxonomy level content restrictions. It just didn’t even know about them.

There are other cases too. Those are just two. We’re bringing all those together and making it so that no matter how you’ve restricted that content whether it’s in a post specific settings or on the edit screen of a taxonomy, they all behave the same way, so like the redirects, the Can Access determinations, and a whole bunch of other things.

Getting rid of some of that technical debt is kind of exciting for us. It’s a little bit challenging to do without breaking things, but it’s a fun project.

Then we’re doing things like introducing HTML emails into Restrict Content Pro. It’s had really plain, basic, plain text emails for a long time that you can’t edit in any way. You can edit the contents of those emails, but you couldn’t edit, let’s say, the template files.

To customize the appearance of the emails we’ve introduced new HTML emails that have full template files that you can go edit the HTML and the CSS for. We’re adding in support for a new authorize.net gateway, so there’s a lot of people that wanted to use Restrict Content Pro with authorize.net. That’s going to get added.

Then there’s a whole bunch of little other things. Hopefully we’re going to have a new option for having one-time discount codes. Right now in Restrict Content Pro if you add a discount code and a customer registers a recurring subscription with that discount, let’s say for 20%. That 20% is going to apply to their first payment and every payment after that for that subscription. But a lot of people only want to discount the first payment, so we’re adding support for that and a bunch of other things.

That’s Restrict Content Pro. Hopefully it’s going to be ready some time in January.

In the Affiliate WP realm we’re primarily focusing on some new integrations. For example, there is a new integration for paid member subscriptions, which is a nice membership plugin from Cosmos Labs. There is a new integration for Contact Form 7. Interestingly, Content Form 7 is one of our most highly requested integrations that people ask for all the time.

BRAD: Wow.

PIPPIN: Which I find a little bit surprising, but maybe not because it’s still got a huge user base. Then we’ve got a couple of other integrations. WP Forms and–

BRAD: What kind of integration would that be between Affiliate WP and Contact Form 7? Why would they need to integrate?

PIPPIN: There’s two main things. Some sites want to do sign up tracking or just conversion tracking of a submission form. There are a lot of sites out there that actually will pay a commission for leads, and so if you send a lead to a website, we’re going to pay you $0.05 or something like that. It’s pretty common, and so that lead is based on the submission of a contact form. Or what they might do is they might record a pending referral, a pending commission. Then if that lead turns into a project, then they will pay out. That’s pretty common.

The other one is that Contact Form 7 actually has payment add-ons so that you could make a PayPal payment or a Stripe payment through Contact Form 7, and people want integrations for those.

BRAD: Oh, okay, so you need to capture the sale.

PIPPIN: Yep.

BRAD: Or market as a sale in Affiliate WP when the form is submitted.

PIPPIN: Right.

BRAD: Right. Okay.

PIPPIN: Yeah, and then the other big thing for 2.0 in Affiliate WP is batch processing. Affiliate WP is very data intensive. There’s a lot of commission records. There’s affiliate records. There’s visit logs. There’s a lot of things like that. And in order to produce really good reports and be able to provide good export options and any accumulation of data in a lot of different formats takes a lot of processing power. And so to make it so that we can do more advanced things, we’re adding in a generic batch processing API so that we could then set up whether we are exporting a payment file for affiliates, we are exporting commission records or affiliate accounts, whatever we’re doing, we can do it in a batch processing system so that we can handle much, much larger data sets.

That’s getting introduced. It’s getting close to being done. There’s a bunch of other small improvements, but those are the major things.

BRAD: Cool. The batch processing API, don’t you already have something in place, though, for that?

PIPPIN: We have it in Easy Digital Downloads, but not Affiliate WP.

BRAD: Oh, okay. But don’t you have like an export function in Affiliate WP already?

PIPPIN: We do, but it all does it in one process.

BRAD: Oh.

PIPPIN: If you go and say, “Generate payout file for the last 60 days for the 500 affiliates that I have and the 10,000 commission records they generated,” it does it all in one process.

BRAD: I see.

PIPPIN: Which causes scaling problems because once you get big enough, then your site crashes in the middle of a payout file generation and that’s no good.

BRAD: Yeah. No, that’s no good.

PIPPIN: Yeah, so we’re trying to fix that. I think I mentioned this on the previous episodes, but we hadn’t released it yet. We officially released Zapier for Affiliate WP. We now have a connection between Affiliate WP and Zapier, which can be really, really powerful.

A quick example that we use it for is we now sync all of our affiliate accounts directly into MailChimp with all of their account data, so everything from their commission rate to their payment email to their affiliate ID, et cetera. It all drops straight into MailChimp into what’s called merge tags so that we can send out emails, affiliate emails or market emails to our affiliates with their relevant data, so everything from their affiliate ID to their current earnings to different things like that is one of the things that we use Zapier for. Any time that a new affiliate is added, it automatically gets added to MailChimp. If we ever deactivate an affiliate, it gets removed. Any time that the earnings or the stats update for an affiliate, it goes straight to MailChimp. That’s all powered by Zapier.

BRAD: I just realized that I’ve been saying Zăpier wrong all along.

PIPPIN: I used to always say it as Zāpier, and then I got chewed out for being wrong.

BRAD: Ah, it is so wrong now that I think about it.

PIPPIN: Yeah.

BRAD: Zāpier, it’s not a zape. It’s a zap.

PIPPIN: Yeah, yeah.

BRAD: Why would I say Zāpier? Oh, man. That’s going to be hard to change.

PIPPIN: Yeah, it’s taken me a little while to get it right. But so that’s out, and there’s just a lot of things that you can do with Zapier. Zapier is a very powerful system. Once you recognize the possibilities of it, it’s kind of one of those – the possibilities are endless. But it’s actually a really hard sell to show someone or convince them that they should use Zapier, explain to them why they should. Because of that, I think Zapier actually has a much lower adoption rate.

We see the same thing in EDD, but not that many people use it because it’s a hard sell. I think it’s because it’s overwhelming. You go in and you see all of these options of how you can connect this system to that system to this system, and it can be challenging to kind of grasp in your mind what that really means.

BRAD: Yeah. I think it’s a marketing problem more than anything. I think the way you have to sell it is you have to give people examples of what–

PIPPIN: You have to sell a solution.

BRAD: Yes.

PIPPIN: Not a tool.

BRAD: Exactly, because all it is, it’s like a hub for all these other connections. It’s kind of like a universal remote, you know. But it’s hard to sell that as an idea, right? Oh, you could connect it to everything. But give me an example of how I can use that to–

PIPPIN: Yeah, it’s something that we’ve been trying to do in EDD, and we’ve done a variety of blog posts and tutorials on it, but we need to do a whole lot more.

BRAD: Yeah.

PIPPIN: We’re going to do the same thing with Affiliate WP.

BRAD: Do you have a Zapier extension? Is that what it is?

PIPPIN: Yes.

BRAD: It’s like an add-on?

PIPPIN: Yeah, we have an add-on plugin for both Affiliate WP and for EDD.

BRAD: Right. Is there some services that you don’t have an add-on for because you have Zapier?

PIPPIN: Yes. Affiliate WP, for example, a lot of people have asked for a MailChimp integration.

BRAD: Right, so you don’t bother.

PIPPIN: We’re not making the MailChimp integration.

BRAD: Right.

PIPPIN: Because we’re going to say, “You should use Zapier instead because you can do the exact same things, but so much more and at the same time, and there’s no reason to have two systems.” Now whether that remains true, that’s what it is right now.

BRAD: Right. On your site, though, you could create a new product, basically, that looks like a product. But then it just explains that you could use Zapier.

PIPPIN: That’s true. Yeah, you totally could.

BRAD: Just so that it shows up.

PIPPIN: The downside to it, though, is let’s say that somebody uses MailChimp and they have a paid MailChimp account, and then they want to use Zapier. They have enough traffic, and they have enough actions they need to perform that in order to use it they have to pay for Zapier as well is the big downside to it. But you’re paying for that endless flexibility and possibilities.

Another example of, like, an extension that we could add to add a feature set would be, say, like an integration with Google Docs or Google Spreadsheets. All right, every time the referral record is generated, log it to a spreadsheet. Well, that’s really, really easy to do with Zapier, so we’re probably not going to build that integration up. We’re just going to say, “Here’s how you can do it with Zapier.”

BRAD: Right. See, I never even think of using Zapier. That’s another part of the problem, right?

PIPPIN: Right. I think that is exactly the problem. It is absolutely a marketing thing because we don’t think of it as that solution. We think, okay, I need to integrate with Dropbox, so I’m going to go for a Dropbox tool. I’m not going to look for a Zapier tool that just happens to be able to talk to Dropbox.

Another way that we try to sell it to people is, okay, Easy Digital Downloads, for example, has a MailChimp add-on that is pretty powerful. But what if you want to do something outside of the box of that? That’s when Zapier comes into play. If you want to do something with a little bit more refined controls or conditions or, for example, you want to only subscribe people to this list if they buy X amount in something, or they buy X product, or they buy $500 worth, they get added to this VIP list or something like that. That’s another place where Zapier becomes incredibly useful. But it’s a hard sell. But it’s such a cool system. It was also a way for us to really test our Rest API that we released with 1.9 because it’s 100% dependent on Rest API.

In Easy Digital Downloads 2.7, which is also coming in January, hopefully. We’re doing a few things. One of the big focuses is on internal APIs and abstraction layers, so we have this long, ongoing project that is to move away from WP Post and post_meta tables and moving all of our data to custom tables.

One of the things that we have to do to make that happen is really thorough abstraction layers. We don’t ever want anybody interacting with the WP Post API, like the various helper functions for get_post, get_post_meta, update_post, et cetera. We want people to integrate with our abstraction layer on top of that so that they can use our APIs, and we can move the data without anything breaking.

We’re introducing a couple more layers of that abstraction API, including one called EDD Discount to handle for discount codes. There’s one for EDD Gateway. Now that one is not as much of an abstraction layer, but it’s still related. Then also there’s one for EDD Cart that we’re working on introducing. There’s a few other areas with that as well.

Those are the major things that are happening that are taking a ton of time to build. There are some other minor improvements, and some of them are actually major improvements, but they’re not as prominent, at least for us. For example, there’s a couple issues on checkout where, if you have an error, some of your checkout data gets lost, some of your personal details that you put in. That kind of stuff is getting improved. Basically just some more polished details.

We did have something really that’s been problematic for a while that we just got resolved this morning, actually, or we pushed an update that should resolve it this morning. In all of our plugins–EDD, Restrict Content Pro, and Affiliate WP, as well as several others–we have plugin updaters that talk to our stores so that if we release a new version of an extension, your website can communicate with our store to know about the new version details, get a download link, install the update, et cetera.

We’ve had this ongoing conflict for a long time with object caching, but not always. It only happens in some sites. It primarily happens with sites that run W3 Total Cache. The WordPress update API uses transients to cache the update data and to know whether or not it should check for new updates to know what the update details were, et cetera.

Our plugin updaters have always tied into that pseudo API. There’s not really an API for it. It just happens that there are filters and hooks that we can tie into to inject our data into that cache, so we can fire a remote request and then store it into the update data that WordPress and cache is going to transient.

Well, what we were seeing is update checks running on every single page load or at least every single page load of the plugins page. And so every now and then we would see a site that has just horrendous performance because every time they load the admin, it’s doing another check for one or even 20 different plugins, and each one of those plugins is a different API request. And so we were seeing really, really bad performance for some of these cases.

We eventually tracked it down that if you had object caching enabled in W3 Total Cache or your server had object caching configured in one way or another that when we try to set a transient, it basically just went into a black hole. Then when it reloads the page, guess what. That transient doesn’t exist any more.

Actually, on Friday afternoon, our Web host, Pagely, reached out to us and said, “Hey, we’re seeing a whole lot of repeat requests to your server. It actually took the server down a few minutes ago because this one site sent something like 500 API requests in a super short time span, and it was due to this same problem.” So we just pushed out a minor update that fixes it. Basically, the fix is to not use transients, but is to use options instead.

We’ll have a dev blog post that we’ll write up on our EDD development blog some time this week or next week about it. But it was kind of an interesting problem to track down, especially because it doesn’t happen to everybody. Most times we would go in and look at a site and, oh, it works perfectly fine. Then all of a sudden on somebody else’s site it would just obliterate their performance.

BRAD: Yeah, phantom issues that come and go like that are the hardest things to debug.

PIPPIN: Yeah.

BRAD: I’ve found.

PIPPIN: Super tricky.

BRAD: There’s one. We have one that we haven’t resolved yet in Offload S3. It just keeps coming and going. We can’t reproduce it with any reliability or reliably, I should say. If you save the settings, sometimes they’ll just be the same when the page reloads. Again, I think it has something to do with caching. But when you save, we’re definitely flushing the cache, and it definitely works most of the time. But sometimes it doesn’t. It’s a weird one, and we just haven’t tracked it down yet.

PIPPIN: Yeah, that’s weird.

BRAD: Yep.

PIPPIN: Well, so that’s pretty much what’s been keeping us busy. There’s a few other things, but we’ll run out of time if we keep going.

Should we chat a little bit about what was announced at WordCamp US and the State of the Word?

BRAD: Yeah, I think we should. Well, should we just give it in a nutshell kind of what the changes are?

PIPPIN: Yeah. I think there are a variety of changes, but there was one that was really–

BRAD: Yeah.

PIPPIN: –important or that’s going to be very noticeable in the next six months to a year.

BRAD: Yeah.

PIPPIN: Do you want to give a quick rundown on what that was?

BRAD: Well. They’re not doing scheduled releases any more. WordPress Core was released pretty much on, I think it was, three-month schedule. Was it?

PIPPIN: Yeah, every three months.

BRAD: Yeah, it was either every three months or every four months. I can’t remember which. Anyway, it was regular intervals that there was a WordPress release. They are scrapping that. There will no longer be any fixed date where we can expect a new version of WordPress Core, a new major version of WordPress Core. They’re still going to do security releases regularly, patch releases, but there’s not going to be any major version.

I think the reasoning behind that that Matt explained in the State of the Word was so that they can work on kind of bigger — they can tackle bigger things that will likely take longer than a three-month time window. It makes sense to me, but it makes me nervous as well. What were your thoughts? Did I get all that right, or is there anything else to it?

PIPPIN: Yeah. I think there was one other thing that should be included there. It’s not just to work on bigger projects, but it’s also saying, “Hey, when we have a project that’s done, let’s just ship it. Why delay this one project two months while other things are getting done?”

Now it’s kind of in this idea that we’re doing feature development and, when a feature is ready, it’s shipped. When another feature is ready it’s shipped. And so maybe that means there’s two big features that get shipped in one month and then nothing for six months. It’s kind of the idea of just saying, “We’re going to do continual releases, but features are not tied to big milestones any more.” Every feature is now it’s own milestone. That kind of idea. I really like that approach, actually.

Just as an example, in our own plugins, we have quite a few large features or improvements that are done, and they’re completely done and tested, but they’re sitting there not released because there are other features in the same milestone that are not done. And so this feature that we finished two months ago isn’t going to be released for another two months because it’s inside of the release that still has other things to do.

BRAD: Yep. Exactly. I completely agree. We’ve recently rejigged our release process to be more feature oriented, and we’ve seen the benefits of that in the last couple of releases.

We release when the focus feature is ready to go. We just release it. We just cut a branch and release it and then keep working on other things later. We don’t try to — before what we were doing, we were grabbing a bunch of issues, sticking them in a milestone, and saying, “Hey, we’re going to finish all of this and this is the release.”

PIPPIN: That’s exactly what we do right now.

BRAD: Right. One of those issues might look benign, and then you realize, “Oh, crap, this is going to actually take weeks to do.” Then you’ve committed. You could punt that issue, potentially, but I don’t know. The way we’re doing it now, it just feels so much nicer because one person is working on kind of the core feature. Whenever they’re done, that’s when we cut the release and we ship it. It just feels so much nicer to be able to do that.

PIPPIN: I’m excited to see how it plays out over the next six months or so and whether it means that we’re going to see five big updates in the next six months with five new, awesome improvements, or if it means that we’re not going to see hardly anything. I don’t know yet.

BRAD: That’s kind of — I think that’s what he explained, though, was that it was going to take longer for stuff to come out. My understanding of what he was talking about is that they’re going to work on three focus areas. It was the editor. There were two other things I can’t remember. Do you remember? There were like three.

PIPPIN: Not off the top of my head any more.

BRAD: Yeah. I can’t remember either. But anyway, there were like three areas that they were going to work on and really focus on. I think it was the editor, the customizer, and something else. I don’t know, though. I think it’s going to be — I would be surprised if we see a Core release in the next six months, a major release of Core in the next six months – just the way he was talking about it.

PIPPIN: That’ll be interesting, for sure.

BRAD: Yeah.

PIPPIN: It does make me think. If we go back, say, about two years when automatic updates were first getting pushed into WordPress–I think that’s about two years ago–one of the analogies that people kept referencing was Google Chrome and how Chrome is always pushing updates. You never really — it doesn’t matter what version you’re on. You don’t know that there was a big update.

I think this actually moves us further in that direction. In one way, I think we’ll be able to do a lot more updates over time, but they’re a lot less burdensome for users and site maintainers to update to because instead of having 13 major changes and then a whole bunch of little changes, instead you have one. I don’t know if that’s what we’re going to see, but that’s what I hope to see at least.

BRAD: Yeah. Oh, here’s the other area of focus was the Rest API. I’m starting to remember now. He was talking about basically testing whether or not the Rest API was good for WordPress or not by trying to convert whole sections of WordPress to use the Rest API.

PIPPIN: Ah, right.

BRAD: Sorry, whole sections of the dashboard to use the Rest API. For example, maybe editor would use the Rest API rather than admin-ajax.php, or the customizer. The same kind of thing, right? I think he was talking about tying all of these things together. Yeah, it’ll be interesting, nonetheless.

But the whole thing about Calypso and, like, basically Calypso-ifying the dashboard. I mean that kind of — I don’t know. That whole idea concerns me a little bit, but I guess we’ll see.

PIPPIN: There was some good commentary, I think, in Brian Krogsgard’s latest or second latest, either his newsletter to members or something he posted on the site that kind of brought up some issues. Not necessarily issues, but concerns. During the State of the Word, Matt announced that they were going to start working with plugins that have over a million active installs to bring in support for those plugins into Calypso, which for anybody that doesn’t know, is the dedicated desktop app built by Automattic for WordPress.

One example was WooCommerce. Being able to create products in WooCommerce and change and manage products from your desktop app in Calypso. It turns out that one of the primary weaknesses of that right now is that they don’t plan to do support for custom meta boxes. Well, the entire WooCommerce product edit screen is a custom meta box. That’s going to be a big challenge that they’re going to overcome. But I think that is one of the goals of trying to figure out: How do we do this? How do we add in this kind of–? A lot of that is going to be depending on the Rest API.

BRAD: Yeah. Yeah, that’s the thing. WooCommerce has a Rest API, so you could build a completely separate admin that just uses the Rest API to save all the settings that get changed via that new UI. Yeah, I don’t think meta boxes really factors into it at all in that case.

I think what concerns me about kind of building out the dashboard, like a Calypso version of the dashboard, is not supporting the backwards compatibility stuff, so not supporting meta boxes. Well, if you replace the dashboard with a Calypso thing that doesn’t support meta boxes, you’re just essentially eliminating tons of plugins, right?

PIPPIN: Well, here’s an interesting thing. As plugin developers, we see every now and then people come to us and they’re confused because they figure out how to install the plugins. It turns out they’re using WordPress.com, and it’s one of those examples of where, because the distinction between self-hosting WordPress and WordPress.com can be very confusing for people that are not already familiar with it that they know they use WordPress, so there’s a plugin for WordPress, so they can use it. It makes perfect sense.

I wonder if this move to doing more and more with Calypso is going to exacerbate some of that where suddenly somebody’s experience with using WordPress isn’t their WordPress dashboard experience or WordPress.org versus WordPress.com, but is suddenly my experience of using WordPress is Calypso. Calypso is WordPress, because it’s the only thing I’ve ever used for doing this. And so now I have this plugin, but how do I use the plugin because I can’t install it? I think that while I think we’re a ways from that actually being a reality, I think it is something that will absolutely come up in the future if Calypso is continually pushed to be the way that people interact with WordPress.

BRAD: Yeah. I do like the idea of rebuilding sections of the dashboard to use to leverage the Rest API. I think that makes total sense. I just hope we do it in a responsible way so that we don’t break all the plugins. WordPress Core, the way it’s operated to date, has been very responsible. It would be a departure to not be responsible going forward, so I hope so.

PIPPIN: It’ll be interesting, for sure. If anybody has thoughts or comments on it, please let us know, either through Twitter or on the episode post. We would love to hear your thoughts.

BRAD: Yeah, for sure.

PIPPIN: I think that’s going to give us a wrap for the day.

BRAD: Awesome. Well, thanks, everybody, and thanks again to Post Status for sponsoring this episode. Check it out, PostStatus.com

PIPPIN: Talk soon.

BRAD: Talk to you later.