December 17, 2015
WordPress 4.4 is out and Brad and Pippin share their impressions on today’s show! Brad and Pippin are fresh from Wordcamp US a week long educational and networking conference for WordPress users. For an honest review of the new WordPress 4.4 check out today’s show. This podcast is sponsored by WP Ninjas.
We begin today’s episode with Brad and Pippin’s time at Wordcamp US. Wordcamp has meetups and conferences all over the US. Developers and users come with all levels of experience to share and learn together. During Wordcamp US WordPress 4.4 was the star of the conference.
With the release of WordPress 4.4 wordpress.org offers new classes. Such as WP Post, WP User, WP Network, and WP Comment. For every positive change to the platform there are some issues with plugin updates and SSL certificates. To avoid these issues Pippin suggests using Pagely to keep up with upgrades and bug fixes.
Other big topics at this Wordcamp were Calypso and Rest API. Brad and Pippin talk about the difference in the core. Besides the changes made to WordPress, the guys shared updates on their personal projects.
- Easy Digital Downloads 2.5 upgrade. Improvement to the Payment system and settings.
- New Restrict Content Pro add-on.
- Easy Content Types needs a new owner.
- Offload S3 bug fix.
- Multi Site Tool add-on to be released in January
- Let’s Encrypt Certificate Authority
If you’re enjoying the show we sure would appreciate a Review in iTunes. Thanks!
INTRO: Welcome to Apply Filters, the podcast all about WordPress development. Now here’s your hosts, Pippin Williamson and Brad Touesnard.
PIPPIN: Welcome back to Apply Filters, Episode 52. Today, Brad and I get back into what we’ve been doing for the last few weeks, after we’d taken a small break due to some traveling and other things, and also talk about some of the new changes in WordPress 4.4.
Before we do that, though, once again, this episode is sponsored by the WP Ninjas, the creators of Ninja Forms. They just recently published the alpha 4 version of version 3.0, so they’re getting closer and closer to actually releasing version 3. If you want to check it out, we will include a link to that in the show notes.
Also, the WP Ninjas are going to be at WordCamp Miami here in a few weeks. If you’re going to be there, make sure to find them, say hi, and thank them generously for their continued sponsorship of Apply Filters.
BRAD: Definitely. Awesome.
PIPPIN: All right, where have we been, Brad?
BRAD: Yeah. Good question. We were supposed to record an episode with Brian Krogsgard and do kind of like a cross-episode between us and him because he has a podcast. What’s it called, The Post Status podcast? Is that what it’s called?
PIPPIN: Yes, I believe so.
PIPPIN: He’s probably going to yell at us if we got it wrong.
BRAD: I hope so. I’m looking forward to that. Yeah, so there was a little scheduling conflict there, and then we went to the Community Summit and WordCamp U.S., which was like a weeklong thing. So, you know, now here we are already. It didn’t take much.
PIPPIN: Yeah, well, and you know always a few days after a conference, we’re always a little bit behind and hectic. Then, because the conference was a full week long, yeah, we took a little bit longer.
PIPPIN: I might have slept in a few times.
BRAD: It was like a double conference, right? I had to dig deep for this one. It was rough, man. And the parties, there were parties every night, staying up late and, oh, man, the drinking.
PIPPIN: Yeah. I think, on average, at least for me, it was like 7:00 a.m. to 2:00 to 3:00 a.m. every day for a week straight. I was just beat by the end of it.
BRAD: Oh, I know.
PIPPIN: But it was a good time.
BRAD: Oh, it was great. I was really impressed with Philadelphia and the weather there. I had really low expectations. I thought it was going to be miserable and cold, but it was really nice while we were there.
PIPPIN: It was nicer in Philadelphia than it was here in Kansas, and I’m a lot further south.
BRAD: And the city is really nice. That was the first time I’ve ever been in Philadelphia.
PIPPIN: Yeah, it was my first time too.
PIPPIN: The area around where the conference was was just excellent.
PIPPIN: It’s actually going to be at the same place next year, and tickets are already on sale. So, if you didn’t go and you would like to go, WordCamp U.S. is definitely one that I would recommend.
BRAD: It’s so huge, right?
PIPPIN: Yeah. There are so many people there.
BRAD: That was the mind-blowing part about it. I thought WordCamp Miami was pretty big, and it is pretty big, but this felt like twice the size of Miami. You’ve been to San Francisco before, right?
BRAD: How did it compare to that?
PIPPIN: I think it was bigger than any San Francisco WordCamp has been. Not hugely bigger, but definitely bigger. At least, it felt bigger to me. Some of that might have just been because of the venue itself was enormous.
BRAD: Yeah, it was really cool. It was a really cool venue.
PIPPIN: Yeah. That conference center is designed to hold, I think, 20,000 to 50,000 or even 200,000 people. We had like 3,000 people there or 2,000 people, something like that.
BRAD: Yeah, it was cavernous. It was like the rooms were–
PIPPIN: Enormous. The tallest escalator I’ve ever been on.
BRAD: Yeah, yeah. It was cool, though. One thing I really loved about it was the hallway was always filled with people, so at any point in time if you wanted to chat, you just go out there and you’d find people to chat with.
PIPPIN: Yeah, the hallway traffic was really, really excellent at this WordCamp.
BRAD: Yeah. Yeah, I’ll probably be there next year.
PIPPIN: I think we’re going to try and do a full company meet-up there.
BRAD: Yeah. I think we might do the same.
BRAD: We’ll see what happens. What have you been up to, man?
PIPPIN: Well, actually, during WordCamp U.S., I think we did it during a session, even. We pushed out the first beta version of Easy Digital Downloads 2.5. Since then, we’ve pushed out a second beta as well, and we published some blog posts over on our development blog that describes some of the new things that are in it.
For users, 2.5 isn’t all that different. There are a few nice enhancements to it, like we built a new product exporter so that we have a better product to CSV export system – just some general bug fixes and some other general enhancements.
But, the main thing is in the foundation of the platform. We built a new class called EDD Payment. Because it’s e-commerce, everything revolves around the payment records. Some people call them orders. We call them payments.
Up until now, payment data in EDD was pretty messy and kind of difficult to interact with. They’re all stored in the WordPress post table, which has its benefits and cons. But, to access any particular piece of information or update it, you would just call getpostmeta or updatepostmeta, which meant that you needed to know the proper meta key and all of that stuff.
Creating a payment record was really, really tricky. You had to know exactly how to do it. It was a multidimensional array that you had to have just right. And, it was silly. It was one of those poorly designed things from the very beginning that’s just kind of difficult to change, and so we never really did. We slowly iterated on it. But, in 2.5, we built out a new class called EDD Payment, which makes interacting with, creating, updating, deleting payment records really simple.
BRAD: That’s going to be nice for developers then, right?
PIPPIN: Right, it’s purely meant for developers and for ourselves, really. If you want to update a payment record, or if you want to add a product to a payment, give a customer access to it, or whatever you want to do, it’s now super simple. We actually just pushed out a blog post this morning that gives some examples to show kind of how you can interact with it and how you can use it. For anybody that’s interested, go check that out. That’s probably the number one thing in 2.5
BRAD: You didn’t actually make a change to the underlying data structures. You just created a better interface for it.
PIPPIN: Now, something that’s really, really important to think about is: Previously, all of the data was accessed, updated, interacted with, et cetera, through the metadata API in WordPress: updatepostmeta, getpostmeta, deletepostmeta, et cetera. While that’s fine, at some point in the future we want to really look at the possibility of migrating to custom database tables for EDD.
EDD Payment is one of the first steps to doing that because it has now abstracted the access methods to that data, so we can now change where the data is stored without affecting anybody if they are using EDD Payment. It will actually make it a lot easier for us to manipulate how the data is stored in the future, which will be huge.
We had a couple other things in there. We added some tools for recounting or recalculating stats and earnings. We improved some of our settings organizations and some other things. But, the EDD Payment Class is the big one. It’s been actually a pretty long development process because it occurred to us that if we break EDD payment, we break every single site running EDD, so it was a little important that we get it right.
BRAD: For sure.
PIPPIN: I just pushed out a small update to an add-on for Restrict Content Pro. Restrict Content Pro has an add-on for WP Job Manager, which is a really nice job board plugin from Mike Jolley, the lead developer of WooCommerce. This add-on basically connects Restrict Content Pro and Job Manager together to allow you to require somebody to have a paid subscription to submit jobs.
Well, one of the requests that has come in a lot is also the ability to restrict the viewing or uploading of job résumés. WP Job Manager has an add-on for managing résumés so that potential employers can see the résumés and the candidates that have been submitted to the website, and so people wanted to allow that to require a subscription. I just pushed out an update that does that, which was kind of a fun little update.
Any time I get to play around with some of Mike Jolley’s code, it’s always usually a pleasure. It’s always nice to dig into someone else’s code.
Then the other big one for me, which this was just announced yesterday. I have a plugin that I built five years ago and have maintained it ever since called Easy Content Types.
BRAD: Is that to make working with custom post types easier?
PIPPIN: Right. It provides a UI for registering and editing post types, taxonomies, and metadata, so meta boxes and meta fields. And so, it’s basically just a GUI for that. It’s honestly one of the plugins that got me started into building plugins as a career, like as a full-time job. And, it’s been a staple of my personal portfolio for a long time.
Well, yesterday, I decided to announce that I’m ready to sell it. As much as I love the plugin, as much as it’s been super important to me, I can’t give it the focus that it deserves, so it’s kind of been neglected in the last year and a half just because the other projects take up more time. And so, I’d like to pass it off to a new owner. If that interests you in any way, I pushed out a blog post at PippinsPlugins.com, and you can find information about it there.
BRAD: Cool. We’ll link that up in the show notes too.
PIPPIN: Okay. Enough about me. Brad, what’s been keeping you busy in the last week and a half, aside from hopefully sleeping?
BRAD: Oh, man, I just feel like I’ve been, yes, sleeping and just catching up, just kind of knocking things down that keep coming up, because things kind of piled up while I was at the Community Summit and WordCamp U.S.
When WordPress 4.4 came out, we thought we were ready, but there was a last minute change, a bug fix that actually broke Offload S3. Well, I shouldn’t say it broke it. It broke responsive images working in Offload S3. If you’re offloading your media files, the SRC set tag won’t get added. Sorry, the attribute won’t get added to those images.
I’ll link the track ticket up in the show notes. It’s actually a bug that was discovered just before a release that they fixed. It definitely needed to be fixed because the symptom of the bug is that incorrect images would have been shown.
PIPPIN: Oh, no!
PIPPIN: That’s kind of a big one.
BRAD: Yeah, so it was a big one. That fixed that, but also broke our support for responsive images in Offload S3, so we need to do some work and get a fix out for that soon.
This has also kind of brought us to a place where we’ve been thinking about using a filter instead of the way we’re doing it right now. The way we do it right now is when you insert an image into a post. It inserts the URL to Amazon S3. Whereas, you could just have it insert the URL to the image on your local server. Then, before that content is output onto the site, you could replace that with a filter and kind of do the find and replace dynamically.
That’s what they’re doing for responsive images, right? They’re doing it on the fly. We’re thinking about changing up our plugin to do that as well. It would eliminate some problems that we’ve been having.
PIPPIN: I can think of two things for that. One, if you are replacing them dynamically, that’s nice because, the moment you deactivate the plugin, the images still work.
BRAD: Exactly. Yep.
PIPPIN: But, wouldn’t it also be a lot less performance friendly?
BRAD: Well, not really because we’re already filtering the content for short codes and for this, for responsive images, so it’s actually doing a regular expression through the post content. I guess the bottom line is you should be caching your site anyway, right?
PIPPIN: Sure. Even if it has an impact, it’s only on a few page loads.
BRAD: Well, it’s on uncached sites, right?
BRAD: The fix for it is to cache your site, I guess, is the point. I think WordPress, I think the core team may have just made the decision like, “You know what? We’re just going to use filters because it’s the better way to go,” because there was quite a bit of discussion about that for responsive images, whether or not the SRC set attribute should be added in at the time of inserting the image or whether it should be done as a filter, filtering the content on output. The latter is what they ultimately decided on.
PIPPIN: The nice thing about that as well is if they do a post or they do it on render, then it takes care of all the images that were uploaded prior to 4.4.
BRAD: Yeah, and then you don’t have to do any finding and replacing on the old content. But also, it has other effects. For example, let’s say you added an image size and you regenerated all your thumbnails. Well, you wouldn’t have to go through, find and replace all of your SRC set tags and add those extra images in or remove some that you’ve deleted. There are a few advantages there as well.
What else? Oh, Ian wrote a nice sneak peek post and has a video in it of the upcoming multisite tools add-on.
PIPPIN: I was just looking over that. That is stellar.
BRAD: Yeah, it’s pretty cool, right? You can push and pull between multisite, subsites, and a single site install.
PIPPIN: All right, so this one I can’t quite tell from the screenshots. I know that with this it allows you to pull an external site into a sub-site. Let’s say that I have development.site.com. This is one site within a multisite network, and I want to update just that site. I can do that, right?
BRAD: Yep. You can do that, yep.
PIPPIN: Can you create a new site in my network from an external, so like take an external site and merge it into my network? I guess I could. I would just have to create a placeholder site for that first.
BRAD: Yeah, I think that’s the way we decided, Ian decided, to do it. I actually haven’t tested it, personally, very much, so I don’t know all the ins and outs of it. But, yeah, we’re in the testing phase right now, so that’s coming out probably early January, hopefully.
PIPPIN: Very cool.
BRAD: Yeah, that’s coming down the pipe. I just want to say, at the Community Summit and WordCamp U.S., I got really excited about the HTTPS everywhere, let’s encrypt stuff.
I think the last episode of our podcast was about HTTP2, and HTTP2 only works if you have a secure site. It only works on HTTPS. None of the browsers support regular HTTP. To get all the benefits of HTTP2, you need HTTPS. HTTPS, have you ever had to install an SSL certificate or even buy one?
PIPPIN: I’ve had to buy them numerous times. Thankfully I’ve never had to do the actual install process.
BRAD: Right, but even to buy one is a huge pain. You have to create a certificate signing request.
PIPPIN: It’s a giant pain.
PIPPIN: Every time I do it, I feel like I’m using technology from 15, 20 years ago.
BRAD: Yeah, yeah, and then they email you the certificate.
BRAD: You copy and paste it out of your email.
PIPPIN: Like the Comodo site. Remember that site or company is?
BRAD: Yeah, yeah, Comodo. Yeah.
BRAD: Yeah, yeah. Let’s Encrypt allows you to get a free SSL certificate that expires in 90 days. The reason that it expires in 90 days is because they want people to automate it. They want people to automatically renew their certificates at least every 90 days. Ideally even sooner, maybe every month you would renew your SSL certificate and automatically install a new one. That just promotes better security.
Basically, this will allow people to get free SSL certificates and never have to deal with them again. How awesome is that going to be?
PIPPIN: It’ll be amazing.
BRAD: John Blackburn and Zach Tollmanz are working on a WordPress plugin that connects to the Let’s Encrypt API and sends the necessary information that it needs to generate a certificate and then downloads the certificate to your server, and so it does a lot of the work to get your certificate. Then there are plans. I’m saying it’s done. There is no WordPress plugin yet. It’s still early days, but the plan is that it will use WP CLI, so you’ll be able to do wpcertnew, and it’ll just get you a new certificate, and just spit it out right there in the folder that you’re in.
PIPPIN: So cool.
BRAD: Yeah, so anyway, I wrote a blog post about it. Check it out if you’re interested about the details there.
PIPPIN: Yeah. Actually, I was not in the talk that Zach gave, but I read your blog post afterwards, and that was the first time that it kind of all clicked for me what they were discussing, and it’s so cool. I really want to get in and set it up on a site. I think my server supports it, so I need to go and give it a try.
BRAD: Yeah. This really won’t be an issue for you if you have Web hosting. Your Web host is going to end up setting it up at some point. It’ll just work, and you’ll have HTTPS, right? But, if you’re managing your own server, that’s where this stuff you kind of need to be aware of setting it up.
PIPPIN: Yeah, definitely.
BRAD: Yeah, that’s about it. We’re in the process of hiring. We’ve got a couple of guys on trial right now.
PIPPIN: Are you hiring a developer, support, something else, all of the above?
BRAD: Another developer. Yeah, another developer that will also pitch in with support. All of our developers are also support people.
BRAD: We spread it out.
PIPPIN: Where does that put your team at right now? How many people are you?
BRAD: We’re five. Not including me, there’s five, and this will be our sixth hire.
PIPPIN: That’s great. Very cool.
BRAD: Yeah. Yeah.
PIPPIN: All right, should we jump in? We want to talk about some of the new things in WordPress 4.4.
PIPPIN: All right, do you want to start us off with responsive images?
PIPPIN: We actually touched on this a little bit.
BRAD: yeah, we did touch on it a little bit. We touched on it a lot, actually, way back in April in Episode 39. We really did a deep dive on responsive images, what it’s all about, and how it plays into WordPress. I’d really recommend going back there and learning all the ins and outs of it.
Really, you don’t need to do anything because WordPress 4.4 just has responsive images. It just flipped the switch, and it’s automatically turned on for your WordPress site. If you’ve upgraded to 4.4, just take a look at the source on the front-end of your site where images show up in posts, and you’ll start to see, or you’ll be seeing, an SRC set attribute. That’s responsive images.
Should we kind of touch on what responsive images means? Should we go into that?
PIPPIN: Yeah, why don’t you go ahead and give a quick overview for anybody who is not aware or hasn’t listened to the previous episode.
BRAD: You don’t want to serve a giant image, right, for a mobile device that has a six-inch screen or whatever, a four-inch screen. What responsive images allows you to do is you just define all the image sizes that you have, and then the browser determines which one to use. It also takes into account not just the size of the screen, but the pixel density.
If you have a retina display, for example, it’ll serve the image that’s going to look best on a retina display. That’s basically what responsive images is. It’s a big improvement over the previous solution, which I think was, well, for retina it was to have the @2x suffix on your images. Do you know what I’m talking about?
PIPPIN: I do.
BRAD: Yeah, and then you would swap it. Then you’d use CSS to determine if it was a retina screen or not and swap it in. It’s a pretty big improvement over that. Yeah, that’s basically it. Have you tried responsive images?
PIPPIN: Honestly, I haven’t yet. My primary sites aren’t updated to 4.4 yet, so I just have it on my local. I don’t do a whole lot with images locally, so I haven’t. Honestly, I haven’t dug into it.
BRAD: Good point on not upgrading because I upgraded, and the Markdown plugin broke. Luckily it’s coded in a way so that it doesn’t actually break all of our posts. It didn’t just start showing up in Markdown on the public side.
PIPPIN: My site not being upgraded is just because they’re all managed by Pagely, and so Pagely does the updates, and they roll them out to all sites simultaneously at a certain point in time.
PIPPIN: Usually it’s about a week or two weeks after the release goes out, so I don’t even touch it. I just wait until they’ve done all their testing and confirm everything works well on their platform, and they take care of it.
BRAD: That’s nice.
BRAD: That’s really cool.
PIPPIN: It’s super nice. Some of the other things that were in 4.4 that are really going to be handy for primarily plugin developers, there are three new objects, new classes that they’ve introduced. If you’re familiar with, say, WP Post or WP User, those would be two of the primary ones.
There are three new classes now, one for WP Comment, so for interacting with a comment object. There’s a WP Term for taxonomy terms, and then there’s WP Network for interacting with a site within a network. I’ve got links to them that we’ll put into the show notes on the new developer.wordpress.org site that describes them in detail, as well as show the source code for them. Definitely check them out.
BRAD: Have you played with these at all?
PIPPIN: I haven’t yet, but I’m going to be playing with probably WP Term and WP Network soon. For WP Term, in the near future, I’m going to be using term meta inside of Restrict Content Pro.
Restrict Content Pro has a feature that allows you to restrict a post category and say that every post inside of this category is automatically restricted to these subscription levels of these particular access requirements, things like that. But, it doesn’t work on custom taxonomies because, until 4.3, the idea of term meta didn’t exist. If you wanted to do custom metadata on terms, you either had to register your own table, or you had to use WP Options, which was kind of a messy workaround. And so, I just chose to not do it. Here in the hopefully very near future, I’m going to update that feature to work on all custom taxonomies as well using term meta, in which case I’ll probably use WP Term.
PIPPIN: Then WP Network, I’m going to do something similar. I’ve been wanting to build out, like if somebody subscribes. Let’s say they sign up for a subscription. Create a new site in the network for them, and that we’ll use WP Network for sure.
How about you? Have you or do you have anything in the near future?
BRAD: No, I haven’t touched those. I’m curious about WP Comment because I heard a lot of chatter about it. I’m not sure why. People kept mentioning WP Comment, but they didn’t explain why it was super cool that it’s been added.
PIPPIN: I don’t think it was necessarily directly related to WP Comment, but I think it was related to a separate subject, which was basically the side loading of comments on posts. I could be completely wrong, but I believe there was a lot of discussion about the way that comments are queried and cached.
The discussions were along the lines of, like, if we query a post, we’re also querying the comments, so it stayed with that post at the same time. I believe it went hand-in-hand with the development of WP Comment.
BRAD: Huh. Okay. Interesting. I know I worked on a Trac ticket that improved the performance of comments, of loading comments. I think we were getting every comment individually or something, like one comment at a time. I can’t remember exactly.
PIPPIN: That might be it.
BRAD: Yeah. Yeah, I didn’t see it in Trac. You know how you can go into Trac, and you see My Tickets? It wasn’t showing up in there, so it might be resolved. That might have been part of that. I’m not sure.
Anyway, let’s talk about the REST API since that was pretty much what everyone was talking about at WordPress U.S. That and Calypso, right?
BRAD: Were pretty big topics.
PIPPIN: All right, so do you want to start and give us a quick rundown of what actually made it into core for the REST API, because I think anybody who has paid any attention knows that not the entire API is in core? It’s just part of it, so what part is in core right now?
BRAD: I don’t even know! I never really looked into it. My guess–I’m going to guess, and you can tell me if I’m right–is that just the scaffolding of being able to add your own endpoints is in there.
PIPPIN: Yeah. Yeah, that’s correct.
BRAD: Okay, but the actual, like if you wanted to query posts and stuff, those endpoints aren’t in there yet. Is that right?
PIPPIN: Yep. Yep, that’s exactly it. You can now register. Well, actually, you can do your endpoints. You can do fields and, I think, maybe one other thing. A field would be like if you want to register a particular meta field on an existing endpoint.
PIPPIN: Right. Right now you can register your own custom endpoints, which is super handy. Let’s say that you want to build an API for your plugin, whatever your plugin does, and you want to register an endpoint for it and then output all that data in JSON. You can do that now with what’s in core.
I’m not 100% sure on this. I need to double-check, but I believe one of the caveats to that is all of the authentication, the Oauth2, the basic authentication, those are not in core yet, but I could be wrong on that. If you know, and you’re listening, please correct us because this is something I haven’t delve into enough yet.
I did just start playing with it, actually, on my flight to WordPress U.S. I started building a REST API for Restrict Content Pro. I was extending the one from core. Yeah, super handy. I was able to build a fully functional REST API with both get and post and delete methods in, like, an hour.
BRAD: Somebody mentioned that you should stop using, like if you’re using the admin-ajax endpoint to output JSON as your API right now, you should stop doing that.
PIPPIN: Oh, absolutely.
BRAD: But why? I don’t remember.
PIPPIN: Because the API is a whole lot faster.
BRAD: It’s faster, so it’s just more performant.
PIPPIN: Yeah, so the thing is there’s a whole lot of things that run when admin-ajax is loaded.
PIPPIN: All of WordPress is. The only thing that’s not loaded, I think, is the front-end. With the API, that’s not the case.
PIPPIN: It’s a whole lot faster.
BRAD: It doesn’t load your plugins?
PIPPIN: No, it loads the plugins still, but a lot of the actions that would normally run are not run.
BRAD: I see.
PIPPIN: I don’t know exactly which ones, but I have to double check. I think Chris Christoff did some testing on it because he was actually working on a senior project related to some EDD stuff, and he built out a custom REST API. I believe he tested the performance of it and benchmarked it. It was dramatically faster.
Another good person to ask about that would be Josh Pollock from Caldera Forms. He’s done a lot of custom REST API work, and I believe he actually might have either done a post or a discussion somewhere that mentioned the performance impacts of it.
BRAD: Oh, yeah. I think I heard about that.
PIPPIN: There are some other advantages as well. One of the big ones is that if you’ve ever built anything that relies on admin-ajax, and you have enough users of the plugin, you probably had somebody else’s plugin completely break your processing because they installed a privacy plugin or something that blocks admin access to non-site administrators, which also blocks admin-ajax. One of the nice advantages is that if you use the REST API, that just doesn’t even happen anymore.
The disadvantage, however, is that REST API can be easily disabled. There’s an actual way to just say, “Nope. REST API, you don’t even exist,” whereas, admin-ajax is always there. The only way to disable it is to block access to it through, say, a specific hook like admin… or through htaccess or something similar.
BRAD: Right. Yeah, we’ve run into that Web host blocking admin-ajax or something, which is crazy. Yeah, I guess it’s not completely crazy because, in that case, they were blocking it where the referrer was not the local host. If I open the dashboard for DeliciousBrains.com, it would allow any requests from DeliciousBrains.com. But, if I tried to run admin-ajax from your site or something, it wouldn’t allow that request. That’s not completely crazy, but yeah.
PIPPIN: Still slightly obnoxious when you’re trying to track it down.
BRAD: You know what we actually did? We just spoofed the referrer. When we submit the referred header, we submit it for the site that we’re submitting to so that it looks like it’s coming from the local, like the dashboard.
PIPPIN: See, and this is why you can’t trust referrers.
BRAD: You can’t trust headers, yeah, for sure.
PIPPIN: They’re too easy to spoof.
BRAD: Yeah. Jeff, on my team, Jeff Gould, he actually wrote a post about the WordPress 4.4 REST API. He wrote a single page app that interacts with endpoints that he set up and all that stuff, so it’s a good place to check it out if you’re interested.
PIPPIN: Yeah. I was just looking over that a little bit ago. It was an excellent post.
PIPPIN: There were a couple issues that have come about with the release of 4.4, two that I’m aware of. I found these ones through our support systems. One is that sometimes plugin updates are failing.
If you ever see an error message when installing a plugin or even uploading a brand new plugin that says, like, “You can’t install this because the file already exists,” type of error message, there were some changes made to the file system API with how it interacts with, I think, the FTP class or something that is causing those to fail on some servers. The Trac ticket is already, like, 150 comments long.
PIPPIN: It’s huge, but so that’s happening for select cases. Honestly, as much activity as there is on the Trac ticket, I think it’s still a pretty localized issue. I’ve done a ton of plugin updates since, and I haven’t seen any problems with it.
The second is that SSL certificate verification when, like, verifying the local cert is failing for some sites. We discovered this because, basically, if you’re using the WP remote API, the WP HTTP class, and you are passing, as you should, the SSL verify parameter as true, which is the default, and if that local cert doesn’t verify, it kills the request.
One way to get around it, which is only a temporary thing and you shouldn’t do unless you absolutely have to, is you can tell it to not verify the cert. But, there is a fix that they’re working on, and I think it’s milestoned for 4.4.1. I think some cert files accidentally got removed, modified, or something like that.
We discovered it because we have a MailChimp add-on for EDD. Suddenly, like in two days, we had three, four, even five tickets from people saying, “Um, the lists that I have in MailChimp aren’t showing up in my settings screen. What’s going on? We tracked it down and figured out that the cert verification was failing. If you see anything like that, it’s probably related to that ticket.
PIPPIN: Any other issues?
BRAD: Try to find that bug.
PIPPIN: Ugh! It took us forever just to even track down why it was happening. Actually, I got lucky because Danny, who writes the main MailChimp for WordPress plugin, probably the most popular MailChimp plugin for WordPress out there, he had tracked it down and beat me to it. And so I actually found the solution in his support forums, so thank you, Danny.
PIPPIN: Yeah, because I was having a heck of a time trying to do it because it wasn’t failing on my local site. It wasn’t failing on any of my live sites. It was just failing on customer sites.
BRAD: Yeah. We’ve had a lot of problems with local cert verification failing, so we actually, in Migrate DB Pro, it’s disabled by default. It’s a checkbox in the advanced settings, so you can easily enable it. But, you know, we had to make it the default because it was just like–
PIPPIN: It was too much support.
BRAD: It was probably like one in five people who were running into that problem.
BRAD: And so, although it’s not secure, the optimal security to have it disabled by default.
PIPPIN: We used to have it disabled by default in our software licensing add-on for installing plugin updates because we had the same exact problem. Then the problem actually ended up going away because of a change in WordPress for the positive, which was nice.
BRAD: Yes. Yes, I’ve heard that. I don’t remember what version it was.
PIPPIN: Remind me sometime, and I can dig up the Trac ticket for you. It was a couple versions back, but I think Zach Tollmanz pointed it out to me, and that was a huge help. I added the exact same option, the toggle to my MailChimp add-on for Ninja Forms because of the exact same problem.
BRAD: Right. Yeah, the plan right now, I think, for us is to enable it for all new installs going forward and then, in a future version that we release, and see how that does. Then, if that’s okay, then we might enable it for everyone else. Then you’d only be able to disable it with a hook in the code. But, we have to do it very carefully because otherwise we just get hammered with support.
Anyways, should we wrap it up?
PIPPIN: Yeah, let’s do it. A lot of great things in WordPress 4.4, and other updates, so if you have any questions or comments, or anything else that you guys would like to throw out or tell us anything that we got horribly wrong, let us know. You know where to find us: Twitter, the show comments, or anywhere else.
BRAD: Awesome. Talk to you next time, guys.
PIPPIN: All right. Thanks, everyone.