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 66. This time Pippin and I will be talking about what we’ve been up to and dig deep into WordPress 4.6. But first–

PIPPIN: This episode is sponsored by WP Pusher. WP Pusher is a pain free deployment for your WordPress themes and plugins directly from GitHub or Bitbucket. With WP Pusher, you’ll never have to manually copy files over FTP again or manually create zip files. If you enable automatic updates, your client websites will automatically be updated every time you push a change to one of your GitHub or Bitbucket repositories.

Right now, for a limited period of time, as an Apply Filters listener, you can get 20% off your purchase of WP Pusher by using the discount code APPLYFILTERS. That’s all one word.

I’ve got to say, I think this is a really slick system. Not too long ago we turned on GitHub deployments for all of our plugins, so any time that we released a plugin update for EDD, Affiliate WP, Restrict Content Pro, et cetera, it gets deployed directly from our GitHub repositors. And I’ve got to say, it is probably one of the best timesavers we’ve implemented in a long time. Our releasing an update, no matter how big or small, went from a 20-minute process of carefully making sure that we build the zip file and all those things and upload it to 30 seconds. We simply tag, select, and we’re done. It’s awesome.

BRAD: Yeah. When you go from something like that taking 20 minutes to not at all, you really appreciate it.

PIPPIN: And you realize how much time, especially if you release a lot of updates, that those updates actually take. It was interesting. When we switched over to using get deployments, I originally had always thought about, like, you know that that’s cool, but not really a big deal. It’s just a couple minutes. It doesn’t matter.

Oh, my gosh! No. I was so wrong. The amount of just stress that it removed from not having to do all of that, and it suddenly made pushing the smallest point release pain free that you don’t even worry about it at all.

BRAD: Yeah, exactly. Yeah. We actually reviewed WP Pusher on the Delicious Brains blog a few months ago. If anyone missed that, go check it out.

PIPPIN: That’s for kind of like a companionship between WP Migrate DB Pro and WP Pusher, right?

BRAD: Yeah. Yeah, they do. They do complement one another quite a bit. They’re both in the realm of deployment. They work well together. There’s no seamless deployment with them both. It’s not like you could push your database and it would automatically deploy your code or something like that.

Although, there are hooks in Migrate DB Pro that you could do that, I’m sure. I think Jeff gets into that a little bit in our blog post. Anyways, check it out.

PIPPIN: Very cool. Thanks, Peter, for sponsoring. It’s a great looking product. Go check it out. Remember, it’s APPLYFILTERS as a coupon code to save 20% off your purchase.

BRAD: Yeah, thanks, Peter. All right, so what have we been up to?

PIPPIN: Well, just in the last two weeks or so, we’ve been doing some more Restrict Content Pro updates. That’s kind of where some of our, the majority of our focus. At least the focus that we’re telling people about so far has been.

As I’ve mentioned a few times in the past, we’ve been really working over the last four months to rebuild RCP as a product, bring it back to life, and do cool things with it. And so we’ve released two plugin updates for it, two new professional add-ons. The first one is WooCommerce member discounts, and so if you want to run a club site of any kind with WooCommerce, or you want to give paid subscribers an additional discount or something like that, you can now do that.

You can simply go, create a coupon code, and say, “I want to automatically apply this to any subscriber of my gold plan.” And so if you go and you are a paid gold subscriber, you can have the discount automatically applied to your purchase, so of anything that you purchase through the WooCommerce store. That was actually released just yesterday and it’s pretty sweet.

Then we also released another add-on called Restrict Past Content. Certain membership sites sometimes want to limit the content that subscribers have access to and make it so that you only get access to content published on or after your registration date. So anything that was published in the past, you don’t get access to. There are some kind of unique scenarios on when people want to be able to do this, but we released an add-on that now supports that. And so if you publish content all the time, but you want to make sure the subscribers only get access to the content published after their registration date, that’s what this add-on does.

BRAD: Cool. For the WooCommerce add-on, I’m curious. I think some people might think, “Why is Pippin peddling WooCommerce add-ons for Restrict Content Pro instead of trying to push people towards Easy Digital Downloads?” What’s your answer to that?

PIPPIN: Well, there are a couple of answers. First of all, we’ve had the EDD version of this member discounts plugin for two years.

BRAD: Right.

PIPPIN: If we wanted to think about it that way, we’ve been ignoring WooCommerce for two years.

BRAD: Right. Okay.

PIPPIN: Which is not the truth. We’ve just finally got around to building the Woo version as well. The real answer, though, is that it’s good business. Look. There’s a huge number of people running WooCommerce out there, there are a lot of people running Restrict Content Pro, and there’s a lot of people running them both at one time.

For us to say we’re not going to support WooCommerce just because we build our own e-commerce plugin would just be playing favorites, and that’s not something that we’re here to do. So we want to not only take advantage as a business of the customer base that WooCommerce provides us, but we also want to make sure that our WooCommerce users are taken care of.

BRAD: Right. Well said. Cool.

PIPPIN: How about you? What have you guys been up to over there?

BRAD: We had a big release of the assets add-on for WP Offload S3, so that add-on allows you to offload your CSS, JavaScript, font files, pretty much all your theme assets, including anything else that’s enqueued by WordPress, so JavaScript libraries, CSS, or whatever. And anything enqueued by plugins, it scans for all that stuff, puts it on S3, and serves it from S3 or CloudFront depending on how you configure it.

Anyway, we’ve had a big release of that add-on. We updated the user experience to be a little bit nicer. It now gives you better feedback, so like when it’s scanning for those files, it’ll show you. It provides a UI that gives you the progress of how much has been scanned and how much is left to go, and how much has been uploaded and how is left to go – that kind of thing. It gives you a status of what’s happening right now with this add-on, like is it scanning, is it serving files, you know, what’s happening. We’ve done quite a bit to expose all of that information, so it’s a little bit more friendly for users.

We’ve added a feature to exclude files from Minify. We had a filter for this, but we found that there’s quite a few CSS files that Minify screws up, and then it screws up their site.

PIPPIN: You know that’s always been my experience with any plugin that minifies scripts and styles is that there’s always some file that just breaks. I don’t know why, but it always seems to happen.

BRAD: Yeah.

PIPPIN: So that’s a great feature.

BRAD: Yeah, so we just have a switch, on/off switch, and you can just punch it in.

PIPPIN: I’m curious.

BRAD: Yeah.

PIPPIN: Since you guys probably have quite a bit of experience, like seeing those conflicts on certain files that don’t minify right, do you have any insight into what causes it? Is it a syntax error in the CSS? Is it something else? Why doesn’t it work?

BRAD: I don’t know, man. I wish I knew. I wish I could tell you.

PIPPIN: Okay. I’m glad I’m not the only one.

BRAD: Yeah, I don’t have a silver bullet answer. I remember at one point we were looking. We used to get CloudFlare’s minifier would screw up our CSS, like the CSS of our plugin, and we knew that our plugin CSS was fine. It was fine running it through the standard Minify gem or whatever – the grunt task or whatever. We just chalked it up to CloudFlare’s minifier sucking. That was our explanation for that. Yeah, I don’t know. There’s no rhyme or reason to it, I don’t think.

Some other features: Force HTTPS, we added that option in there. And another option: Until this release, there was really no way in your theme to ask for an asset.

Let’s say you had an image in your theme, hard coded, like an image tag hard coded into your theme. Well, what you would normally do there is you would put in echo get_template_directory_uri and then the path to the image in your theme files, right? Well, that’s where it’s going to get served from because we’re not going through and doing a find and replace on any of that stuff, right? That would just be too taxing on the server to do output buffering, finding and replacing, and all that. We just didn’t bother doing it.

But now we have a filter that you can pass in the URL of your asset, like the URL of your image, and the filter will switch that to the CloudFront URL. We specifically made it a filter, so there was some debate about whether we should have a template function to get the URL or not. We decided on a filter.

Ian Jones actually brought this up, and I thought it was pretty clever. With a filter, let’s say we disable or someone disables our plugin. WP Offload S3 gets disabled or deactivated. The theme will still work, right?

PIPPIN: Right. Yeah, that’s smart. That way you can use the filter without the plugin being active. And so anybody who wants to just natively support your plugin can just pass the filter in and never have to worry about doing a function exist check.

BRAD: Exactly. Yep.

PIPPIN: Smart.

BRAD: Yeah, nice and clean. Yeah, I thought that was a nice way to do it. It would be even nicer if there was a standard filter that WordPress encouraged people to use for that kind of thing.

PIPPIN: I think that goes into the discussion of standard action hooks in themes as well.

BRAD: Right.

PIPPIN: Which, if you want to go read a long history, go find a track ticket on that and it just goes and goes and goes and goes and goes.

BRAD: Is that right?

PIPPIN: Yeah.

BRAD: Oh, man. Good times. Track can be fun and exhausting.

PIPPIN: Yep. Yep.

BRAD: What else did we do? We published a new blog post. Matt Shaw did a nice blog post about where he compared the WordPress REST API to–

PIPPIN: I really like this post.

BRAD: –to admin-ajax.php and the performance gap between them. I was actually surprised by the results of this that there wasn’t a bigger gulf in the results.

PIPPIN: I have a couple comments on that. I was initially surprised too. I thought it was going to be more substantial. I think there was a comment on the post that mentioned this as well that I think you need to test it with a few more plugins to be sure.

Here’s just an example. I checked the other day. The EDD website has 108 plugins active. I bet you our admin-ajax is significantly slower than the REST API.

BRAD: Right.

PIPPIN: And so I think your guy’s test compared zero plugins compared with a site running ACF, Askismet, Black Studio TinyMCE, WP Migrate WP Pro, WP Super Cache, and Yoast SEO, which is a pretty common set of plugins that most sites are going to see. But I do wonder if once you get in a lot more plugins in there and plugins that are adding things to admin-ajax and doing various things, I wonder if there’d be a bigger gap in performance.

BRAD: Yeah. Yeah, it would be interesting to see at least an e-commerce plugin in there with some extensions to that e-commerce plugin.

PIPPIN: Yeah. For example, if we could prove that using the REST API endpoint was twice as fast as admin-ajax, like for us in EDD, and on a bigger site that has a log of plugins, has a lot of data, et cetera, then that would immediately be beneficial for us to do that because it could be a substantial improvement for big sites and a small improvement for everybody.

BRAD: The gap here is like 40 milliseconds, and that is actually still significant, right?

PIPPIN: Oh, yeah.

BRAD: It seems like a little, but when we’re talking about milliseconds in the lifecycle of a page load, 40 milliseconds is a long time.

PIPPIN: Right. Well, and I mean don’t forget this is on a relatively clean site, not just in terms of the plugins and the stuff that are running, but also the database. Take a database that is significantly larger and imagine that you have maybe post lookups or post meta lookups or user lookups that are happening during admin-ajax. If your database has thousands or hundreds of thousands or millions of rows, that might have a very different impact than on more of a clean database.

BRAD: Right. Yep. Agreed.

PIPPIN: I think it’s something I would like to test on our site specifically just to see, like, does it give us a significant improvement. We’re not the largest EDD site by any means, but we’re much larger than average.

BRAD: Yeah, I’d love to see more of these benchmarks done by other people to see. It doesn’t hurt to have a bunch of different data sets to be looking at this.

PIPPIN: Yeah, absolutely.

BRAD: It’d be really cool. Let’s move on to the Meta Environment stuff.

PIPPIN: Yeah. This thing is pretty cool.

BRAD: Yeah, so you posted this in the show, in the planning of the show, and I was like, “What the heck is meta environment?” I had no idea. Meta Environment apparently is kind of like a project within the WordPress community that allows you to contribute to WordPress.org and the other sites: WordPress TV, et cetera.

PIPPIN: Basically, the meta environment is everything WordPress.org and associated websites, so that’s WordPress.org, that’s BuddyPress.org, that’s JobsatWordPress.org. That’s WordCamp.org, WordPress TV, Developer.WordPress.org, Translate.WordPress.org, et cetera. All of those are in the meta environment.

They’ve actually all been open for contributions for a long time. They’ve always had a track. There’s meta track, and you can contribute to them. You can submit patches to it. You can view the bug reports, et cetera. You can view not all of the code, but some of the code. There are some things that are still hidden.

But anyway, so this announcement that was made is pretty sweet because a lot of people want to be able to contribute to meta. For example, if they find a bug on the plugin repository, on the forms, or somewhere like that, they would like to be able to contribute and help fix it. It was a little hard to do, number one, if you didn’t like SVN or, two, you didn’t know where to go. And so they have switched it over.

I’m not 100% sure if it’s a switch or if it’s just they’re both running side-by-side, but you can now contribute to the meta environment with get. There is now a GitHub repository where you can go check everything out. They have the issues log on there. You can submit pull requests, et cetera, and it’s pretty sweet. They also apparently have it all set up in a vagrant, and so I think, anyway, you can clone the meta environment and have a local version of all of meta, so you have a local WordPress.org, basically.

BRAD: Yeah. We’ll link it up in the show notes. But if you go, there’s a GitHub repository. Yeah, that’s what it is. It’s a VVV kind of setup, and it should be fairly straightforward to just fire it up, so it’s really interesting. I had no idea.

PIPPIN: One more way to contribute to WordPress.

BRAD: Yeah, for sure. Should we talk about WordPress 4.6?

PIPPIN: Yeah, let’s do it. When is this happening? When is WordPress 4.6?

BRAD: Well, right now, while we’re recording here on August 4th, it’s in release candidate one, and the target launch date, the release date is August 16th.

PIPPIN: Cool.

BRAD: Who is leading this thing?

PIPPIN: This is Dominik Shilling or ocean90 is his user name.

BRAD: Right. Dominik. I met Dominik for the first time in Vienna at Contributor Day, actually. Yeah. He’s a young guy. I think he’s like 20.

PIPPIN: Crazy.

BRAD: Which I wasn’t sure. You can’t tell very much from people’s avatar’s, right?

PIPPIN: Yeah.

BRAD: I don’t know. I was just expecting — he was here, like, oh, I was expecting you to be taller. And it’s so irrational, like why would you expect someone to be taller from their avatar.

PIPPIN: Right. What about seeing somebody’s face online has said you’re tall, or you’re short?

BRAD: Yeah. It’s weird that you have these expectations and you don’t even know it until you actually meet someone in person.

Aaron Jorbin wrote an excellent kind of summary post of what’s new in 4.6.

PIPPIN: The field guide.

BRAD: The field guide, yeah. We’ll link that up in the show notes. That is pretty much what we’re going to go through right now and just kind of dig into a few things.

PIPPIN: The first thing is the changes to register meta. Register meta has been around for awhile. I’m not 100% sure how long it’s been around. I learned about it for the first time at WordCamp New York, I think. Andrew Nacin gave a presentation explaining how you should register your meta keys, and I had this reaction of, “What the F? Like, what are you talking about?”

BRAD: Yeah. What is that?

PIPPIN: I didn’t know there was such a thing as registering your meta keys. And so basically there is a function called register_meta that allows you to let WordPress know about specific metadata that you store. It lets you register your meta key, and then basically it puts your meta key into kind of a standard WordPress metadata API so that certain filters and things, and sanitization hooks and such can run specific to that metadata, and so that WordPress knows about it.

BRAD: It’s been around since version 3.3, so that’s a pretty long time. That’s like a couple of years, at least, because we’re on 4.6 right now.

PIPPIN: Yeah, so wow.

BRAD: That’s crazy. Yeah, I had no idea about it either.

PIPPIN: In 4.6, they’ve made some changes to it. There’s a blog post that is linked from the field guide that details the exact changes. The real reason for these changes, and now that I have a better understanding about why I would tell you you should use it, is because of the REST API.

Register_meta is used by the REST API in order to know what metadata should potentially be revealed in, say, the post’s endpoint, the user’s endpoint, your custom post type endpoint, because WordPress cannot just assume that all metadata is public, nor that all metadata is private. So one of the things added to register meta is the ability to define whether your metadata should show up in the REST API, so there’s a show_in_rest parameter, and you can define it as either true or false, so if you are registering.

Let’s just say for example you have a database of users, like you have a members directory, and you show what state they’re from, what country they’re from, or what city they’re from, and you have that register in a piece of metadata. You could register that metadata through register_meta on the user’s object and then define show_in_rest is true. Then when call the WordPress REST API, the value of the country field, the state field, or whatever you have registered will automatically show up in the REST API in the future. That’s what it’s for. I don’t believe that actually happens quite yet, but it’s going to.

BRAD: I’m seeing show_in_rest in the new register_meta function. So if you turn that to true, then it’s public. Otherwise false. What happened before this? Everything was public?

PIPPIN: No, everything was private. I believe metadata just didn’t show up.

BRAD: Oh, wow. Okay.

PIPPIN: Now I could be wrong on that.

BRAD: Yeah.

PIPPIN: I know that in the REST API project, there’s been huge discussions about what to do with metadata.

BRAD: Right.

PIPPIN: And I’m not 100% sure on where it was prior to this.

BRAD: Okay. Huh. I see there is protected meta. There’s a function in there. It just looks to see if the first character is an underscore and then determines that it’s protected, but I don’t see anywhere where that’s — like it’s not setting any show_in_rest thing or anything like that. Yeah, I guess this is a big deal then for the REST API.

PIPPIN: It is, and it’s also more than just the REST API. It also allows you, and it did this before, but now it works a little bit differently. It allows you to go ahead and define sanitization methods that run automatically when the metadata is updated.

Usually what most people are familiar with, like let’s say that you add metadata to a post, a page, or something like that. Then you hook into the save_post action, and you sanitize your data and then you call update_post_meta. That’s the normal way that almost everybody is used to doing it.

Well, with register meta, because it has sanitization callbacks, you can actually define the callback functions that sanitize it, and then you don’t even have to sanitize it. You can just pass the data directly to update_post_meta, update_user_meta, or whichever objects you’re using. Then during that call of update_object_meta, it will call the sanitization callback, which also means that your values will be sanitized no matter where they’re coming from. If another plugin calls update_post_meta on your meta key, your callback functions will run, which is really, really nice. It allows you to standardize the sanitization for your metadata across the board.

BRAD: Right. I like this update. So there used to be four arguments to this function, and it deprecated the fourth one and changed the third one to be an array of arguments. In the future, they can add as many default arguments to be passed in to this. They’ve already added some that are really good information. For example, there’s an argument that you can pass in to tell if the data is just one value or if it’s an array of valves. That’s a nice feature. Prior to that, you would have to check, I guess, if something is serialized or not. You’d have to detect whether or not it’s serialized, so yeah, a good step forward here.

PIPPIN: Indeed.

BRAD: Yeah.

PIPPIN: The blog post that talks about it also mentions a specific backwards compatibility for pre-WordPress 4.6. Basically there’s a filter that you have to re-add if you want to maintain compatibility with 4.6 and sanitization stuff. If you do anything with metadata, especially register meta itself, go check it out.

BRAD: Yeah. If you didn’t know about it, go check it out.

PIPPIN: Yeah, agreed. All right, what’s next?

BRAD: Persistent comment cache. This is pretty cool. I didn’t even realize that comments weren’t cached persistently. Comments, like when you load a page, the first time they would be loaded, they would be cached so that if they were accessed again later on in the page, then it wouldn’t have to query the database again for that data, but that’s it.

As soon as you navigate to reload the page or browse to another page and then browse back, it has to query the database on every page load. Now it doesn’t. If you’re using an object cache, it’s going to put the comments in there, so it’s not hitting the database.

PIPPIN: It’s really a pretty nice improvement.

BRAD: Yeah. Yeah, that’s huge.

PIPPIN: I’m kind of excited to see how this affects, or if it does affect at all, performance of any e-commerce site that uses custom comment types. For example, both EDD and WooCommerce use a custom comment type for order notes. If an admin wants to store a note on an order, it gets stored into the comments table with a custom comment type. That means that large e-commerce stores potentially have tens of thousands or even millions of comment rows that are payment notes.

BRAD: Right, I think that wouldn’t be that big a deal unless you had a lot of admins in the backend.

PIPPIN: Well, but they also usually store automated notice, so if the status of an order changes, it’ll store a note to record that change.

BRAD: Oh, okay.

PIPPIN: And so, for example, in EDD, every single completed purchase has a minimum of one payment note on it recording…. Then if that status changes again, it records another note. If something else happens on it like let’s say that a referral from Affiliate WP is created for that order, it stores a note on the payment. If there is a commission record recorded for another vendor, it stores a note on the payment.

BRAD: Right. I think WooCommerce uses them for reviews as well, if I’m not mistaken.

PIPPIN: I believe so. So does EDD.

BRAD: Oh, you both do. Okay. Yeah, so that would be a front-end impact as well. If someone is running WooCommerce or EDD and using reviews, and those are loading on the front end, that would be a nice optimization for that.

PIPPIN: Definitely.

BRAD: Yeah.

PIPPIN: Let’s see.

BRAD: What’s next?

PIPPIN: WP post type is a new class that’s been introduced, and it’s basically just an object for post types. It’s a post type object.

BRAD: Right. Yeah, I was taking a look. I dug into the code just to see what it looked like, and it’s pretty nice. They’ve basically refactored the register_post_type function, so register_post_type has gone from 194 lines of code down to 36, and then basically everything in register_post_type has been broken up into methods inside the WP post type class, so it’s nice and neat and tidy, so pretty nice.

PIPPIN: I like it a lot. It’s just one more step towards standardizing all of the WordPress code base and the various APIs. For example, the WP post object, you interact with that a lot when you call get_post or when you call functions like to get the title or the content. Those are all referencing the WP post object. Well, now if you do things like post type supports, is_post_type_viewable, or get_post_type_labels, things like that, it’s all now referencing that one post type object.

BRAD: Yeah.

PIPPIN: Which is nice.

BRAD: Previous to this, the WP post types global just contained an array of standard objects. Now it’s going to contain an array of WP post type objects, which is a nice thing. I hate the standard class objects. It’s like a dog with no name or something. It hasn’t been given the luxury of a name. Anyways–

PIPPIN: Another reason why I like the WP post type class–and this goes for all of the classes that are being introduced, and there are several others in 4.6 as well–is discoverability. For example, now if you want to go understand what a post type is and the various pieces of information tied to a post type, now you can go to one place and look at the WP post type class as opposed to trying to explore all of these global functions that are spread all over the place and then eventually discovering, finding yourself in the WP post types global and just looking at this dump of data. Now you can go to one place and you have everything.

BRAD: Yeah. Good point. All right.

PIPPIN: What’s next?

BRAD: Ooh, this is my favorite, I think: native fonts. If anybody uses GitHub, you may have noticed that the font changed on GitHub recently, and that’s because they switched over. Well, actually, I don’t know exactly what they switched over to, but if you’re on a Mac, you will get the Mac system font, for sure. I don’t know if they changed things on Windows or not.

But anyway, WordPress is going to do something similar. They’re using system fonts. So if you’re on a Mac, you’ll get San Francisco. You’ll get, I think, Segoe UI on Windows, et cetera. The reason for that is that system fonts load quicker. It has better support for other languages or multiple languages, and it just makes the Web app of WordPress look more like the operating system that you’re working in.

PIPPIN: Suddenly it’s not as much of a jarring experience to go from, say, some app on your phone to WordPress inside of your mobile browser. They look the same.

BRAD: Yeah, exactly.

PIPPIN: At least in terms of the font. I like this a lot. I do have a concern with it. Now, it’s a concern that honestly I don’t think you can get away from, and I think you just have to bite the bullet and do it. That concern is simply for the support teams because I guarantee you when 4.6 drops, WordPress.org will be flooded with people saying, “Everything changed. My admin looks ugly. What have you done? Stop breaking WordPress.”

BRAD: I hope — I really hope not. I hope people will see it and say, “Oh, nice. That’s a nice little update they made.”

PIPPIN: I hope so.

BRAD: Yeah.

PIPPIN: Yeah. That’s my speculation. Honestly, it’s going to be one of those things that people forget after a week. The day that GitHub changed, Twitter exploded with, “Oh, my gosh! GitHub looks butt ass ugly now!”

BRAD: Oh, really? Wow!

PIPPIN: Now, it jarred me the first day too. I thought something had broken because, now, there was something weird with my system fonts at the time that it really did look terrible for me. It looks fine now, and I don’t know if that was something on my local system changing or something that GitHub did as well, but it was just people just bitch and moaning about it, and I think the same thing is going to happen. But it’s going be, like, for two days. There’s just going to be a flood of moans, and then no one is going to care; no one is going to remember.

BRAD: Yeah.

PIPPIN: And it will be better.

BRAD: Just shut off Help Scout for two days – everything. Bounce all the emails.

PIPPIN: Yeah.

BRAD: Yeah. Honestly, when GitHub changed it, it’s almost like a weight was lifted off my shoulders. I think the San Francisco font is just so much nicer than Open Sans.

PIPPIN: I do like it a lot.

BRAD: It’s like there’s more breathing room. I don’t know how to explain it, but I literally felt like, yeah, that I was lighter.

PIPPIN: There is a note that we should make for anybody that’s a plugin or a theme developer on this is that if you have admin interfaces and you are writing, and you have CSS that affects those, and you are defining a font face. I’m going to throw this out there, and don’t hate me, but honestly for silly and maybe possibly stupid reasons because I don’t think this is something you should be doing in an admin interface because it should just inherit what WordPress uses. But, if you do, you should pay attention to that because it’s going to suddenly — your fonts, if you were defining it and you were just assuming, like you were defining even to the same thing that WordPress was using, your text will now look different than the WordPress, and you should remove that font face.

BRAD: Right. I see what you mean. If, for example, in Migrate DB Pro, in the style sheet for Migrate DB Pro, we had font face Open Sans, right? Yeah, so that would break, actually.

PIPPIN: Yeah, so my personal opinion is that there’s no good reason you should ever be doing that within the WordPress admin. But if you are or just because you put it in there not even realizing it just because it didn’t make any different, but it just got in there, pay attention and get it out. That way it’ll all look good.

BRAD: Yeah. Do a find for font face in your CSS.

PIPPIN: Yeah. All right, what’s next?

BRAD: What is next? Shiny updates, oh, yeah.

PIPPIN: I like this one a lot.

BRAD: Yeah. What exactly is shiny updates, I guess is the question.

PIPPIN: Well, there are a few things. Number one, it was to get rid of what is called the bleak screen of sadness, which I think is kind of a funny name for it, and I never thought it was that bad. But a lot of people really dislike it. That is the screen that, when you install a plugin or you install an update, it just goes to this gray screen, and then it just has lines of text that show you what’s happening. It says, like, downloading update for WordPress.org, installing update, copying files, update completed. They want to get rid of that screen completely.

BRAD: You know why you don’t mind it? Because it’s very, very similar to a CLI.

PIPPIN: Yeah. I love it. I like to know what’s happening.

BRAD: Yeah, exactly. Then all the designers are like, “Ack!”

PIPPIN: Yeah, I’m pretty sure that’s exactly what it is. But it is not a wonderful experience. It takes extra time, and so shiny updates was a feature plugin project led by Constantine Oberland to basically rework the update system so that updates don’t require a page load. You click “update.” There’s a little spinner. It installs the update, and then it says, “We’re done.”

Now correct me if I’m wrong, but I believe the first half of this was implemented in WordPress 4.5. So if you went to the plugin’s page and you click “update,” it actually did the update in line there and did not actually show you that big screen of sadness. That’s already been around for a while. Basically this was the second half of the project that implemented it not only on plugin updates, but bulk plugin updates. So if you update five plugins at once, it will do the spinner for all five of them and show the updates. It won’t reload the page.

And also has implemented for installs, so if you go to the “Add New” screen, you search for a plugin on WordPress.org, and you click “Install Now,” that page doesn’t reload any more. It just stays right there, gives a little spinner, and then says, “Installed,” and then gives you an option to activate it, which is pretty slick. It’s really fast too, so now honestly I would say it cut the install time of a new plugin a minimum in half.

BRAD: Right. I like that. I didn’t realize that, for new plugin installs, it was going to do that. I remember when they were working on it. They did yank that part out. They were going to include it in a previous release, and they had to backtrack on it or yank it out. I think that was quite a while ago, though. I don’t think it was 4.5. I think it was like, you know, a year ago or something, wasn’t it?

PIPPIN: I’m trying to see if I can find the version — 4.2.

BRAD: There you go. When was that?

PIPPIN: Yeah. Also, it’s not just plugins. It’s also themes. It is also plugin deletions. And so if you delete a plugin, it doesn’t go to that screen any more. It just stays right there on the page.

BRAD: Right, so this is like finishing it up kind of thing.

PIPPIN: Yeah. It basically does everything. There is also some updates under the hood obviously to the JavaScript. It required a lot of JavaScript. And so if you do anything with the updates handle in the underlying WordPress JavaScript that handles plugin updates, you’ll want to pay attention to it. Specifically, the WP Updates update plugin method, those have changed.

BRAD: Yeah. Yeah, I think they’ve renamed that function, but I don’t know why you’d be using that. But in case you are.

We ran into a few UI issues with this because we do modify the plugin row. I don’t know how to describe it. The row underneath the plugin that says there’s an update. What we do is if you don’t have your license activated yet for the plugin, it adds another line underneath it that says, “Please activate your license so that you can update,” because you can’t. For the pro versions, you can’t get the zip unless you have your plugin activated. Do you guys do something similar to that?

PIPPIN: We do.

BRAD: Yeah.

PIPPIN: Yeah. We only show it if there’s an update available. If there’s no update available, we don’t show anything. But if there is an update available, which will show no matter what your license status is, like if your license is either invalid or not there, it will say, “You need to have a valid license in order to install this update.”

BRAD: Right. That’s exactly what we do. Cool. Yeah.

PIPPIN: We tested to make sure it still works with shiny updates, which is awesome. We didn’t have to change anything.

BRAD: Okay. Nice. Yeah, ours was just like a padding thing or something.

PIPPIN: Sure.

BRAD: Just a styling issue, a pretty minor thing. It still works.

PIPPIN: It made me happy just to see that the shiny updates do what they did and work … and actually not break anything.

BRAD: Yeah.

PIPPIN: Because it would have been very easy to break things with it.

BRAD: Yeah. Well, I think that’s one of the reasons they rolled back a year ago. Congratulations to those people that have been working on that.

PIPPIN: Yeah.

BRAD: That’s been like two years at least in the making.

PIPPIN: Yeah. I’m pretty happy to see it, for sure.

BRAD: Yeah.

PIPPIN: Next is resource hints. Can you tell us about that?

BRAD: Sure. Resource hints are optimization of the browser. You can add a link tag to the head of your HTML document. You define rel= and then a string, so the strings that you can put in there are DNS pre-fetch, pre-connect, pre-fetch, and pre-render. For example, maybe you want to load an image maybe after the page has loaded so that, on any subsequent pages that they browse, that image would be automatically loaded already in the browser cache. So there’s no wait time.

Anyway, WordPress is going to automatically add these resource hints. What does it say here? By default, WP resource hints prints hints for S.W.org, so I’m guessing that’s the CDN for WordPress.org, so like when you’re browsing the directory within WordPress. And for all scripts and styles, which are enqueued from external hosts.

Huh. So I guess if you’re enqueuing a Google font or something, so it’ll add the appropriate resource hints to that to optimize it. I haven’t really played with resource hints. Have you?

PIPPIN: I have not.

BRAD: Yeah.

PIPPIN: It looks cool though.

BRAD: Yeah. It can be really powerful. If there’s a resource that you have on your site that’s kind of inside your site and most of your traffic hits, like let’s say most of your traffic hits the features page or something of your product, and then on the pricing page you have a big diagram or something. You could preload that diagram before they even click through it to the pricing page.

PIPPIN: Right, to help that specific page load faster.

BRAD: Yeah, so that the pricing page loads almost instantly. The browser support for resource hints, I guess, is kind of patchy. I think it’s pre-fetch that’s fairly well support, but some of the others aren’t so well supported. Yeah. Anyway, we’ll link it up in the show notes, so you guys can dig into it if you’re interested.

What’s next? WP term query is a new class, it looks like. Have you looked at that?

PIPPIN: Just enough to kind of know what it is. I have not actually used it yet, but it’s basically a similar class to WP query, WP comment query, and WP user query, but for terms. It’s just kind of once again standardizing all of our different internal APIs within WordPress to use their relative classes. And so now if you want to retrieve certain terms from the database, and you want to include meta queries, date queries, or what have you, you can do those through WP term query.

BRAD: Right. That’s cool.

PIPPIN: Yep. Very handy. Next is translation improvements.

BRAD: Okay. I don’t know much about this. Can you tell us a little bit?

PIPPIN: All right, this one I’m super excited for. When I first learned how to write WordPress plugins and then some time down the road, a few months, maybe a year or so, I learned about this thing called internationalization that magically allowed my plugin to be translated into other languages. I thought that’s really cool. I don’t understand how it works. I don’t know what I need to do.

Where I think we see a lot of plugins suffer from is a lack of internationalization support because they don’t know how to properly load things like the text domain. They don’t know how to use the translation functions, et cetera, and so we have a lot of plugins that unfortunately cannot be translated into other languages because they’re not internationalized.

Well, there is a big improvement in 4.6 that makes every single plugin and theme automatically load the text domain, and so now if you want to internationalize your plugin, the only thing you have to do is pass your text strings through translation functions. The double underscore function, the underscore X, underscore E, underscore N, and a variety of others, you don’t have to load your text domain. WordPress does it automatically.

BRAD: Ah!

PIPPIN: Now the hurdle that you have to get over to learn how to internationalize your plugin is dramatically simpler. It’s lessened because you don’t have to learn about: What is a load plugin text domain? What’s the file path that I pass to it? What are these various parameters? How early do I have to load it? Do I have to load it in a hook? Does it have to be in it? Does it have to be plugins loaded?

I don’t know, one, because there are a lot of different tutorials out there that show different things. And so now you just don’t even really have to worry about it. It still works perfectly fine if you do load it yourself, but WordPress core will handle it.

BRAD: Right. I think there’s a caveat though.

PIPPIN: I’m not 100% sure. Let’s double check.

BRAD: It says: If you distribute your theme/plugin via WordPress.org.

PIPPIN: Ah! Yes.

BRAD: If you’re doing a commercial plugin, you’d still have to use the load plugin text domain or load theme text domain. Yeah, keep them in there for commercial ones.

PIPPIN: I don’t know the technical reasons for that, and I’d be interested to know what they are. But, yes, you’re absolutely correct.

BRAD: Yeah.

PIPPIN: If you sell a commercial plugin, you still need to load your text domain.

BRAD: Right. Cool.

PIPPIN: You know what? It might just be that because WordPress.org has a database of all of the text domains through the translation system, and so they can just use that.

BRAD: I think that’s what it is. Yeah. It seems like a plausible explanation.

PIPPIN: My best guess. It’s probably wrong.

BRAD: That’s what this show is all about: educated guessing.

PIPPIN: That’s right. Isn’t it like most of development and anything we do?

BRAD: Yeah.

PIPPIN: You know I think that’s a performance improvement.

BRAD: Yeah. We’ll measure it later.

PIPPIN: All right, speaking of improvements, there were some improvements made to the customizer API. Do you know anything about these?

BRAD: Not really, no. I didn’t dig into this one. Did you?

PIPPIN: I’m just going to read this basically off the field guide post because I don’t know anything about them either. But apparently there were four major changes in WordPress 4.6 for the customizer. The first is a new collection of APIs for the validation of setting values. I believe when you set values inside of the customizer, now there is an actual API for validating those.

There have some changes been made to the WP customize media control class, and there were some additional changes as well. The main thing is basically if you have custom controls, CSS, or JavaScript related to the controls inside the customizer, you will want to probably go ahead and test those to make sure that nothing has affected those.

BRAD: Huh. Good stuff.

PIPPIN: All right. We’ve got, I think, two left.

BRAD: Yeah.

PIPPIN: What’s next?

BRAD: Bootstrap/load updates in 4.6. Loading the plugin.php earlier in WP settings. SSL is now located in WP include/load.php. And ABS path can now be safely defined before WordPress is loaded. Whoa. Yeah.

PIPPIN: That’s actually pretty slick.

BRAD: Yeah, so I think this is just reorganizing the boot kind of load process a little bit.

PIPPIN: Right. It will allow people, if they want to kind of change where WordPress lives or the main WordPress files are loaded compared to the config. You can now change that through the apps path construct.

BRAD: Right. This is not something to worry about for almost all situations.

PIPPIN: Right. This is very specialized stuff.

BRAD: Yeah, so if you maintain a drop-in, though, I think that’s when you might want to take a look at it, like if you have a caching drop-in or something. I think those are the ones that could be affected by this. Yeah.

All right, one more thing, I think. Multisite changes: Have you looked at this at all?

PIPPIN: Just a little bit.

BRAD: There are a lot of changes.

PIPPIN: There are. Jeremy Felt has been working on this, and he’s been pushing some really good multisite changes, along with the rest of the team that works on multisite for the last several major versions. And so here’s another set of changes, and there’s a new WP site query class. Kind of like we just mentioned, there’s a WP term query class. There’s now a WP site query version that allows you to easily query sites. Then there’s also a WP network query that allows you to query networks in a standarized way.

There have been some improvements made to the lazy loading in WP site and WP network that should help improve some performance. Then there’s also some helper functions for getting things like network ID. And they have also deprecated wp_get_sites, and so I believe now instead of using wp_get_sites, you should use wp_site_query. Then there are also plans to deprecate get_site, get_sites, get_network, and get_networks, I believe.

BRAD: No, it looks like get_site, get_sites, and get_network, and get_networks are the future, apparently.

PIPPIN: Those are going to be introduced in the future.

BRAD: Oh, okay. They’re not in WordPress right now?

PIPPIN: I don’t — it’s funny. I use multisite all the time. I use it in all of my development, and I love it. What I don’t do very much, however, is actually developing specifically for multisite, like building custom multisite features. We’re doing it a little bit more with one of the add-ons that we built for Restrict Content Pro. We built this add-on that allows you to create a new site within a multisite when somebody registers an account, so we’re going to start getting into a lot of this kind of stuff.

BRAD: Right. Those are actually wrappers for wp_site_query and wp_network_query.

PIPPIN: Yes, you’re right.

BRAD: Yeah, use those, I guess, is the short of it.

PIPPIN: Ignore me when I said that they were getting deprecated. That’s very wrong.

BRAD: Yeah. Yeah, that’s what I’m here for to keep you accountable.

PIPPIN: Right, fix all the things that I screw up.

BRAD: All right, cool, man. I think that’s about it for WordPress.

PIPPIN: Yeah, I think that’s it.

BRAD: I think that’s enough. That’s a lot.

PIPPIN: That is a lot, so this is WordPress 4.6. Remind you it’s coming on August 16th. And so if you haven’t tested now, please get testing. It’s about time. And if you are like myself, and I’m sure Brad as well, you probably received an email that said you need to update all of your plugins. Hopefully you have not done what I did and mostly ignored it because your list is 80,000 plugins long.

BRAD: Yes, I always update three or four, I think it is.

PIPPIN: Yeah. I get through the main ones, but a lot of the little one-off plugins that will never change and should work until WordPress is in the grave. It’s just so time-consuming to go through those.

BRAD: Yeah. I don’t bother with those. Some of my plugins should probably be terminated. Yeah. I don’t know. What’s the protocol on that? I know that the plugin team does remove plugins upon request.

PIPPIN: We remove plugins every single day.

BRAD: Right. That’s just a standard day at the office.

PIPPIN: Yeah, it’s pretty standard. It happens all the time. It’s entirely up to the author, so anybody who wants to, like if you have a plugin and you don’t want to do it any more, and you want to close it, you can. You can just ask, and it will be closed immediately. It’s your plugin, and so we won’t persuade you otherwise.

My personal recommendation, like if it’s still a good plugin that’s actually used, is put it up for adoption. There are some blog posts on the WP Tavern about how to do that. Let someone else take it over. Then if no one wants to take it over, close it.

BRAD: Right. I have a plugin on there, for example. It’s called LinkedIn hRésumé, and it pulls; it scrapes the content off of your public LinkedIn profile, parses it, parses using hRésumé micro format. It parses all the data out into a PHP array and then allows you to do whatever you want with it, but it doesn’t work any more at all. And so I don’t want to fix it, and I don’t care about my résumé any more. What’s the point of having that on there? It’s just another plugin in the repo that doesn’t work and probably shouldn’t be on there, right?

PIPPIN: Email [email protected]. It’ll get closed if you want it.

BRAD: Yeah, I guess that’s what I should do.

PIPPIN: All right. Well, thanks for listening, everybody. WordPress 4.6 is coming soon. And thanks again to Peter for sponsoring with WP Pusher. A reminder that you can get a 20% discount on your purchase using the discount code APPLYFILTERS at the WP Pusher website.

BRAD: Talk to you next time.