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 80. This time Pippin and I will be going over updates on what we’ve been up to and, if we have any extra time, we’re going to answer a couple of listener questions.

Pippin, would you like to start us off? What have you been up to, man?

PIPPIN: Sure. It’s been a while. It’s been at least a month since our last episode. And I believe it’s been three to four months since we last gave updates, so there’s a number of things that we’ve been working on. I’ll start off the top.

First, this whole year, 2017, really, we decided that we’re going to focus a lot more on two areas of the business, and this was largely what I’m working on and what a couple of my team members are working on with me. That is business growth and polishing all of the products.

We have a habit of working very fast, pushing out a lot of new things, pushing out updates a lot. We are going to rein that back a little bit and focus primarily on polishing things. We want to make things a lot smoother. We want to make things work better for people. We want to make the onboarding better. So there’s a lot of focus in that area, and that’s going to be throughout the rest of the year as well. There are some initial results coming out of that already.

Then the other one is focusing on business growth, and we’re really starting to do a marketing push for our products, which is something that we’ve never really done before. I mean I like to tell people that I’m a terrible marketer, which is completely true. We are trying to actually take a new look at how we can utilize a really good marketing effort for the company.

Then there’s two little things that we’ve done recently that have had some pretty interesting results. The first one is I played with retargeting ads for the first time. I don’t know why it took me so long to play with them because it took about five minutes to set up. The results are pretty fascinating. If you haven’t done it and you have a product, I would definitely recommend at least testing them out.

BRAD: Are you using Facebook’s retargeting or are you using Perfect Audience?

PIPPIN: We are using Perfect Audience.

BRAD: Okay. Yeah. AdRoll is the one we use, but it’s very simple. I’ve tried Perfect Audience, and AdRoll and Perfect Audience are almost the same.

PIPPIN: Yeah, that was my understanding as well. I chose Perfect Audience just purely based on a recommendation from somebody else.

The biggest issue that we’ve had with it so far is being able to accurately determine how much revenue does it actually generate because here’s the problem. Let’s say that you serve a thousand impressions of your ads and that generates $500 in sales. Then you spend $100. Okay, so you have a 5:1 ROI.

Well, that’s awesome, but did you actually make $500 because of the retargeting ads, or did some of that revenue come from customers that were going to purchase anyway, but just happen to see the ad somewhere in between? This is something that we’re trying to come up with a good way of measuring. Right now we’re doing it through an experiment of turning the ads on; turn them off; turning them on; turning them off; turning them on; turning them off. For like a week or two at a time, so on for a week, off for a week, on for a week. Then, over time, be able to look at a graph and see, okay, are there definite spikes when the ads are on versus off? If that’s the case, perfect.

BRAD: That’s the best way, what you just mentioned. That’s the best way to test any ads that you’re running are working. But you have to do — that’s all you can do. You can’t change your website at that time. You can’t change any. You know what I mean? Because if anything else changes, then you’re not — it’s not a controlled experiment, right?

PIPPIN: Right.

BRAD: Other things could be affecting it.

PIPPIN: Though, even with some changes, if you do it long enough, like let’s say that you do — you alternate weeks for a year at a time. If it is a significant result, that should be pretty clear over the course of a year, even if there are other changes with it. But it’s a long game.

BRAD: Yeah. It depends on the magnitude of those changes, though, too, I think.

PIPPIN: So like our first week of retargeting we had — according to Perfect Audience, we had a 2000% ROI, which was awesome. But we’re like, is this actually accurate? I’m not really sure. But anyway, that’s been one thing that we’ve been having fun with.

The other one is we recently started A/B testing with Google Optimize. Optimize is a new product from Google. I think it’s new in the last, like, six-ish months, at least in terms of like a public product. It is stellar.

If you want to go set up an A/B test on your site, go check out Optimize.Google.com. It is super easy to set up and works incredibly well so far. It’s also super tightly integrated with Google Analytics, which makes it even better. That’s been a pretty fun little project.

BRAD: Very cool.

PIPPIN: All right, so beyond that there’s one big thing that we worked on over the last four months, and this is a price increase. We’ve talked about this a couple of times. I know we’ve mentioned it in previous episodes.

In March, I published a big blog post on a reflection of our price increase for EDD. Our price increase for EDD went live on December 12th. Then we had a price increase for Affiliate WP and Restrict Content Pro that went live on March 1.

I’m not going to talk too much in depth about that because we could — I could easily talk for an hour or more on it. If this interests you, you should go check out the blog post, which is linked in the show notes. But I want to give you a couple or more like ten quick stats on how this has affected our three products.

Since December 12, the support tickets, the number of tickets submitted to EDD have gone down 3%. Not a huge change. However, the number of tickets handled per day, so this is like the number of tickets you reply to, that you close, that you open, tickets are opened and closed, et cetera, has decreased by 46%. The number of customers that we interact with has gone down by 36%. The number of tickets that we touch per day has gone down 47%. And our revenue for EDD is up 18+% in that time period.

That was the ultimate goal here was to decrease our support tickets and raise our revenue. At minimum, decrease support and keep revenue steady. It’s been a pretty stellar result so far.

Affiliate WP and Restrict Content Pro had some similar results. Now these ones have not been live quite as long, so Affiliate WP and Restrict Content Pro had their price change go live on March 1. They also had a much less drastic price change. EDD, for example, had some pretty significant increases in price. The other two plugins was a flat $50 increase across the board and that was it.

But here’s the quick stats. For Affiliate WP, tickets submitted has gone down 5%. The number of customers that we interact with–and by customer interactions that is purely in a support capacity–has gone down 8%. The number of tickets that we interact with per day has gone down 5%. And our revenue is up 56.8%.

For Restrict Content Pro, the number of tickets submitted is down one percent. The number of tickets that we interact with in support is down 9%. The number of tickets submitted per day has not changed. But our revenue is up 32.6%.

Those are the quick stats. It really comes down to, at least for EDD, a very significant decrease in support with an 18% increase in revenue. Affiliate WP, a small decrease in support, but a 56% increase in revenue. And RCP, a small decrease in support and an increase in revenue of 32%. That’s the effect of our price change, and you can read more about that on the blog post that I published, which will be in the show notes.

It’s been a pretty interesting last couple of months because of it. It’s something that I would definitely recommend business owners consider. I think we need to be careful, though. We don’t — we don’t just increase prices just to increase prices. There’s a reason for it.

For example, our reason was support was too much of a burden, and we had done everything that we could think of. We had attacked it from every angle to decrease that burden. Raising prices was the last one that we went with, and it was very, very effective.

BRAD: Yeah. Surely another reason to increase prices is that, I mean, you guys have been iterating on all of your stuff for how many years without changing the price?

PIPPIN: Yeah.

BRAD: You know?

PIPPIN: A lot. Well, and that’s an important point. We would get comments from people that say, look, this is not. This thing is way too good for the price that it’s at. And it’s because of that iteration, because we had built something very simple early on, and now it was something very powerful, after three to four years.

And so with that eventually should come a natural change or progression in price. And so we took a little too long to get to it. And so when we did get to it, it was a little more drastic than I think some people expected. But it’s been a pretty positive experience so far.

If you own a product or a business of any kind, go check out the blog post. If you have any thoughts or reactions to that price increase or anything that you’ve done or anything else you’ve heard, I would love to hear your thoughts. Then I have four other quick little updates I’m going to give, and then, Brad, I’d love to hear what you’ve been up to.

In the EDD world there’s a bit of news for us. As of a couple days ago, we acquired a large set of EDD add-ons from a developer that has been around in the ecosystem for a long time. We actually bought seven of his plugins from him and have brought them into the company so that they are owned, maintained, supported, and developed 100% by our team.

These are add-ons that have been pretty instrumental in a lot of EDD’s presence and growth over the last four years. But unfortunately, due to various obligations, have not been able to have some of the attention that they could really use. And so we’ve brought them into our team, and so we’re hoping to breathe a bunch of new life into them, and we’re pretty excited to see what comes out of those.

Then we recently hired Kyle Maurer, who joined us full time for helping out with EDD support, marketing, and various other things that we throw at him. He’s actually been working with us for about two years now, but in a part-time capacity just in his spare time, his evenings, his weekends. And he agreed to come on with us full time about a month ago, which has been pretty exciting.

Then we also brought on a new person for Affiliate WP, Ginger Coolidge, who has been around the WordPress and Genesis community for a long time. Has come on to help us out with Affiliate WP support. She’d actually been working with us part time since December. But, about a month ago, also decided to come on with us full time, and that’s been awesome so far.

That’s what we’ve been up to. Brad, how about you? What have you and your team been working on? You guys are always releasing new things.

BRAD: Yeah. Yeah, so I’d say, in the last four months, I’ve spent about 20% of my time on hiring. I track my time, and it’s pretty much — it’s exactly 19%, so I mean that’s pretty crazy. I couldn’t believe it, actually. I thought I was making a mistake.

But the results of that have been excellent. We hired a new developer to work on WP Offload S3, so we have three developers on that team. We also hired a marketing manager, so this is the first non-developer hire that we’ve had. That’s been excellent as well.

We actually have a developer on trial right now as well. The idea there is that they would put in 20 hours a week to work on our site, which is pretty neglected because all the other developers work on the products, and it’s hard to justify stealing away their time from working on the products to work on our site. But sometimes it has to be done, right?

That’s Evan Mattson is our developer on Offload S3. Liz Lockhart is our new marketing manager, so it’s pretty exciting. It’s a huge change for us to have someone helping us out with marketing because that’s an area that’s been on my plate, solely on my plate, and I’ve really been dropping the ball with it.

PIPPIN: Yeah. That sounds all too familiar.

BRAD: Yeah. Yeah, that’s how it is. I mean when you’re the founder, you have so many different hats. I mean you can only wear one for so long at a time, right? And usually the hats that you don’t like to wear, those are usually the ones that you wear the least often. For me that was marketing.

PIPPIN: How did you go about finding Liz? You’re very much a developer. I’m very much a developer.

One of the things I’ve always told myself about why it took me so long to really, like, get a hard look at marketing, whether it’s with a team member or me, is that I have no idea what a good marketer is. I don’t know how to hire that person. I don’t know how to find that person, so let me ask you how you did it.

BRAD: It was a very difficult process. I felt like I was, you know, stumbling around in the dark. That’s what it felt like.

I’m 100% onboard with everything you just said. The reason I put it off for so long is because it scares the hell out of me. I don’t know how to hire that person, and so I never did even try, right?

But once I wrote, sat down and thought about what they would do and defined the role, it just made so much sense because you have a list of, like, this is what you’re looking for. This is the type of person that you need for this role. It just made it a lot easier.

Now, I mean, I’m not going to say that it was super easy. Oh, I just went out and Liz just showed up, and it was a perfect match. You know I went through like 300 applications or like a really time-consuming process to find Liz. It was tough. It was tough, I guess is the answer.

PIPPIN: Well, cool. I’m excited to hear how that works out.

BRAD: Yeah. It’s already — we’re already seeing awesome stuff, so it’s been going great.

PIPPIN: Wow, that’s great.

BRAD: We’ve also been working on Mergebot in the last four months. We’ve had some minor releases here and there, and kind of just knocking down some of the barriers that have been in place since we launched the beta, just some limitations that we decided, you know, you know what? Let’s just get this out there even though these limitations are in place.

We’ve knocked down pretty much all of them now and so we’re getting really close to being able to launch. We’re closing off the beta, so we’re not accepting any new beta customers right now.

One thing about the Mergebot beta, I’ll say, is that the feedback has been pretty light. We haven’t gotten a lot of, like, feedback where we’re like, oh, yeah. We definitely have to do that. There hasn’t been surprises, I guess, and the usage from our customers hasn’t been through the roof. On a day-to-day basis we’re getting like one or two customers using the app.

I’m hoping when we launch it, we start to get more feedback. We start to see more usage and that kind of thing so that we can start to refine it more and deal with the problems that people are having.

PIPPIN: That definitely sounds like one of those cases where you pretty much just have to launch it if you ever want to really start learning about what works well, what doesn’t, because you have to get more users on it.

BRAD: Yes. Exactly. Yeah, and that’s kind of the stage we’re in right now. The next step there is just to define the marketing sites, clean up a few things with our registration process and, you know, just minor stuff and marketing stuff. That’s kind of the big one. The big block right now is just writing copy and stuff, you know.

We’ve released WP Offload S3 1.4. That gave people the ability to remove all the files on S3 that they had offloaded if they wanted to wipe them off S3. Also, if you decided I don’t want any of the files on my server any more, there was a tool. There’s now a tool in it to wipe out all the files that have already been offloaded to S3 from your server to free up disk space and whatever.

Then Offload S3 1.5 is just about ready to go as well. That one is going to have the ability to move attachments to another bucket. When I say attachments, I mean media library files. Like when you change a bucket right now in Offload S3, it just changes the setting and then any new media that’s uploaded goes into the new bucket. But all the old media just stays in the old bucket. Anyway, the new version will prompt you and say, do you want to move all your existing media to the new bucket or just leave it where it is?

PIPPIN: Cool.

BRAD: Yeah.

PIPPIN: I imagine for people that do a lot of file organization, it’s something they’re going to love.

BRAD: Yeah, so one of those use cases, actually, if you’re working in a staging environment and need to move that staging environment to production, you might change the name of your bucket in that case. We’ve had a few people request it for that reason. Yeah, so there’s that.

Then Migrate DB Pro 1.5 is getting close. It’s going into testing. The big feature there will be to import an SQL file.

PIPPIN: Ooh.

BRAD: Yeah.

PIPPIN: Is that just any SQL file, or is that one supplied by WP Migrate DB Pro?

BRAD: Any SQL file. Any SQL file, but if you do use Migrate DB Pro to export the SQL file, you get some extra benefits because we add some metadata to the header of that file that we can read, and it helps with, like, showing….

PIPPIN: Okay, so walk me through how that works. Do you — you upload a file and then do you just say, I want to import it into this database? Are there controls to say, I want to import these columns or only rows that match this? What does that feature look like?

BRAD: Yeah. Once the file is uploaded, it reads the header. Then, based on that information, it shows you different controls. For example, you could exclude certain tables from importing. You can exclude certain post types from being imported. There’s all kinds of different controls.

PIPPIN: Can you do search and replace during import?

BRAD: Yep. Yeah, exactly.

PIPPIN: Nice.

BRAD: You can do search and replace as well on that file. Yeah, pretty much all the controls. I’m not going to say all the controls. There are some that we can’t support for imports. But most of the controls that you are familiar with, with Migrate DB Pro, are going to be available for the import as well. That’s something that’s been — that I’ve personally been rejecting because I felt like it was — like why do you need that? Why do you need to import SQL files if you’ve got push and pull? Why do you need that? But there’s a bunch of reasons why people need it, and so, yeah, I’ve admitted that I’m wrong.

PIPPIN: Yeah, I can definitely see the use for it.

BRAD: Yeah. The other things is conferences. I went to a couple conferences in the last four months. I went to PressNomics. I went to Big Snow Tiny Conf in Vermont, MicroConf in Vegas, and then this June I’m headed to WordCamp Europe in Paris as well. My wife and I are going to travel for a week afterwards. Neither one of us have been.

PIPPIN: Hey. If you’re going to fly across the ocean, you might as well enjoy it for a few extra days.

BRAD: Yeah, exactly. And you know my wife and I haven’t traveled since over a year, and we haven’t done France, so why not, right?

PIPPIN: Yeah, it sounds worth it to me. We were planning to originally go to WordCamp Europe and then just decided it wasn’t in the books this year and decided to take a smaller trip just up into the mountains a few hours away from us.

BRAD: Nice.

PIPPIN: But it still looks like a whole lot of fun.

BRAD: Yeah. Cool. You went. So you were at PressNomics.

PIPPIN: Yeah.

BRAD: What other conferences have been to in the last four months?

PIPPIN: There was, I went to WordCamp Kansas City just two weeks ago, so that one is kind of my local WordCamp. That’s just about three hours away from me. It’s the closest one that I have. It’s kind of my home WordCamp too. It’s the first one I ever went to when I was first getting into going to WordCamps.

Then, yeah, I think that’s really the only one because it was PressNomics and then WordCamp Kansas City. Then I’ve got one coming up in August, I believe, and then perhaps one in October, and that’s pretty much it. I’m taking the summer pretty light.

BRAD: Yeah, nice. Yeah, the same here. I think we’re doing a company retreat in August, I think, and that’s it besides Paris for us.

PIPPIN: Great.

BRAD: Yeah. Should we answer a couple questions?

PIPPIN: Yeah, I think we’ve got time for at least a couple of them.

BRAD: All right. Okay, I’ll read the first one. It’s from Josh Eby. He says, “I was wondering if you guys might be able to talk about the proper way to give attribution when borrowing GPL licensed code. For example, say I wanted to start a database base class, but rather than starting from scratch, I want to copy Pippin’s EDD_DB class into the project and rename it. What all should be in the header of the file to give Pippin proper credit for his work? Thanks.”

Hmm. What do you think, Pippin? It’s your class. What do you say?

PIPPIN: I think it largely depends on are you basically forking a class. Are you forking one file? Are you forking an entire project?

If you fork an entire project, for example, there’s generally a couple of rules. Number one is that you should leave copyrights intact. Then two is that you should try to give attributes. You should give attribution, and whether that is in the code itself or on your product page, on your project page, or wherever it is. In some form or other, give attribution.

I don’t believe attribution is in any way legally required. It’s more of just the nice thing to do. With Josh’s example of the EDD_DB class, for that what I would recommend is, number one, copy it, rename it, make any adjustments to it that you want, and then, in the header, you could just say inspired by, forked from, based on, and then give the URL to the GitHub project for the EDD class.

BRAD: Yeah.

PIPPIN: And I would think that’s more than sufficient.

BRAD: Yeah. The way I would think about this is, like, if you were seeing this code for the first time as a developer. What would you want to know about it? Would you want to know where it came from and maybe check out the original project? I think most developers would like to know that information, right? I think it makes sense.

PIPPIN: I think it’s a great way to look at it.

BRAD: Yeah. I think it makes sense.

PIPPIN: Another way is think about if, as a developer that builds open source projects, put yourself into a scenario where you stumble onto somebody else’s code and realize that it’s yours. It was based on your code.

This has actually happened to me a couple of times. And so stumble on it and then think, hey, that’s my code. That’s cool because they use what I wrote and what I release as open source, and hopefully they made it better and, at minimum, they used it within their project. Put yourself in that scenario and think, what would you like to see?

In my case it’s really nice to see attribution. It’s not something that you should get mad at if they don’t give it to you. But it is a nice courtesy. It’s a nice hat tip to whoever worked on it last.

BRAD: Yeah. I could just picture you, like, reading that code. You’re like, oh, I like this guy’s style. Is this–? Wait a minute. That’s funny.

PIPPIN: Yeah, well, sometimes it happens on code that you’re really not proud of, which is then kind of funny because you’re like, man, this code is not good.

BRAD: Oh, crap. It’s mine.

PIPPIN: And then you’re like, oh, crap. I wrote that.

BRAD: Yeah. It happens.

PIPPIN: Yeah, that’s happened too.

BRAD: One other note I’ll make on this is about trademarks because there’s often confusion between–

PIPPIN: That’s a good point.

BRAD: –GPLs and trademarks. If you fork some code or a project and it has a UI and there’s trademarks in that UI, you have to take out the trademark stuff, right? For example, I think CentOS, the flavor of Linux, they had to strip out all of the RedHat Enterprise Linux stuff when they forked RedHat Enterprise Linux because they couldn’t just distribute RedHat Enterprise Linux as CentOS, but then when people booted it up it said RedHat Enterprise Linux everywhere because that would be a violation of the RedHat trademark.

That’s probably a bad example because RedHat has purchased, like they bought out CentOS at some point. Whenever they bought them out, then it would have been fine for CentOS to use RedHat’s trademarks. But I think that you guys — do you get the idea, Pippin? Does that make any sense?

PIPPIN: Absolutely. Yep.

BRAD: Okay.

PIPPIN: Since the example given was the EDD_DB class, which is a class used inside of Easy Digital Downloads, EDD itself is not trademarked, but the name Easy Digital Downloads is trademarked, and we own the trademark to that. If you were to fork something that has Easy Digital Downloads in the name, you would have to change that name.

All right, I think we’ve got time for one more. This one also comes from Josh Eby. He asks, “How important is it to have a blank index.php file in every director within your plugin? The idea is that it will prevent someone getting a directory listing. Is that correct? Should I try to ensure every single directory has such a file?”

BRAD: Yes.

PIPPIN: Brad?

BRAD: Interesting. It’s an interesting question. If you’re in complete control of your server and you don’t envision your project going anywhere other than your server, then I would say no. It’s not necessary at all because, as long as you control your Web server config files and you’re never going to enable directory listings and you’re confident of that, then I don’t see the point of adding index.php files to a bunch of directories to avoid people spying on your directory listing.

But for a project like WordPress where who knows what server configuration it’s going to be installed on, I think it’s absolutely necessary. Why wouldn’t you take that extra security precaution to avoid people spying on directory indexes? Yeah, that’s my thoughts on it.

PIPPIN: I would agree completely. I would like to expand on it a little bit as well. There’s another very similar practice that a lot of people use, especially inside of plugins and themes, and that is at the top of every single PHP file of adding something like “if not defined ABSPATH, exit” with the idea being that you are trying to prevent direct access to your PHP files.

What that does is if somebody tries to load that PHP file directly into the browser via the URL or through a cURL command or anything like that, it will actually kill execution on the file instead of allowing them to potentially exploit. Like if there was a weakness inside of the file, it just blocks it completely because, if you access that file directly, WordPress itself hasn’t loaded, and so the ABSPATH constant isn’t going to be defined. That’s a pretty similar tactic.

I heard one good argument against doing this. I don’t actually think it’s really an argument against it. It’s more of a cautionary tale.

This came up in a discussion–I don’t know–a year or two years ago. I have no idea who it was with, but I just remember it happening. They were actually advocating against putting in blank index.php files and advocating against doing like an ABSPATH defined check at the top of their PHP files. Their reason being is that it was a false sense of security.

Basically, there was the claim that when people do that, a lot of people who are maybe not as well rounded a developer or maybe not as familiar with how security vulnerabilities work, they put those in and think, oh, well, that’s all I have to do, and they just rely on that. Whereas, that’s definitely not the case. Yes, this is one aspect to keeping snoopers out and preventing people from exploiting vulnerabilities inside of your PHP files. It’s not. It’s not the only thing that you do, and so it’s a caution of, yes, it’s a great idea to do, but don’t let it make you believe that your files are secure because of it.

BRAD: Right. Yeah. The ABSPATH define at the top of a file, I’ve seen that lots of times, and it makes complete sense when you’re talking about a PHP file that is, on its own, executable. Like if you just access that file directly, it would actually execute some code. But I don’t — when it’s just a class file, so the PHP file just has a class in it and the only thing that would happen when you access that file directly would be that the class loads into memory, where is the vulnerability there? Am I missing something?

PIPPIN: Well, I think it applies to big projects that end up having a lot of different files. I mean maybe we’re talking ten. Maybe we’re talking dozens, maybe hundreds of files. I do it. I do it as just a generic, this is part of our process we put in every single file because, when your project gets large enough, you end up doing things in a lot of different ways.

For example, there are classes that get instantiated automatically when that file is loaded because there is an instantiation at the bottom of the file outside of the class itself. And so if you were to load that file, the class would be instantiated. That’s not something we always do, but there are definitely cases where we do.

There’s other times when a file has request parsing directly inside of it that doesn’t have any reliance on, say, the WordPress plugins API. And so if you were to access that file directly, that request parsing might fire.

I think it’s just, as projects evolve and as they grow, you’re going to have tons of different ways that you could do it. And so are the majority of files going to be susceptible to direct access? Probably not. And hopefully they’re not, honestly. I think theoretically there should be very, very few files that are ever susceptible. But it’s just one of those, like, make it. If it’s a standard within your process, that rare case when it does happen is less likely to happen.

BRAD: Right. Another kind of thing that’s related here is the fact that we have to even have these files in a Web accessible directory. If you work with something like Laravel, like Laravel’s app structure, it has a public folder and all of your classes and everything are outside of a public folder. Right? The classes are not accessible at all by the Web server. When you configure your Web server, you make that public folder accessible and that’s it.

This is kind of like a remnant of the kind of shared Web hosting architecture where you had a public HTML folder and that’s it. You had to dump everything in there when you were hosting your site. That’s how WordPress is set up, right? That’s what that used to be like the only option for most Web hosting. But ideally your app would have your class files completely not accessible from the Web. Yeah, so this is — again, I guess, this is like another — as kind of a last resort security measure to add that absolute path defined at the top of the file.

PIPPIN: It’s a very, very low level security measure.

BRAD: Yeah.

PIPPIN: Let’s be clear on that.

BRAD: Yeah, exactly. I guess there’s probably ways also that you could, from the Web server level, protect whole directories of PHP files from direct access.

PIPPIN: Oh, for sure. I was actually at WordCamp Kansas City. There was a security presentation there. One of the examples that he gave was using your HD access file if you’re on Apache to disallow any access to PHP files directly inside of all of WP Content. That use case was basically saying, look, something like Tim Thumb, back when that big vulnerability happened a few years ago, disallowing access to that file is a preventative measure against that kind of vulnerability.

If you have a lot of plugins on your site, code from all sorts of different developers, everybody has different ways that they do things. You can just say, blanket across the board, nobody can access PHP files. Now you have to be careful with it because you might be — there’s times when accessing a PHP file directly might actually be very useful and very well needed. But it was an example.

BRAD: Yeah. You would have to be very careful doing a blanket like that. It would definitely have impacts. For example, you would have to exclude admin-ajax.php from that because that one is directly accessed.

PIPPIN: Yep. That’s a great point.

BRAD: Then there’s all kinds of plugins that directly access PHP files, too. I’m sure of it. Yeah, it would be — to just do it across the board, I wouldn’t recommend. But you know there’s definitely certain files in WordPress Core that you could definitely say, like, hey, all these files, don’t allow direct access to these. You can definitely do something from the Web server level.

All right.

PIPPIN: All right. Josh, thank you for the questions. Anybody else, if you have questions you’d like to submit, you can go to the website, applyfilters.fm, and there’s a submission page there. You can also ping us on Twitter, email us directly. However you want to get in touch with us, we would love to hear your questions. I’m sure we’ll get to more in the following episodes.

BRAD: All right. Thanks, everybody.

PIPPIN: Cheers.