#225 – Milan Petrović on the Risks of Legacy PHP in WordPress and Why Upgrading Matters for Security

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, the risks of legacy PHP in WordPress and why upgrading matters for security.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players. If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you or your idea featured on the show. Head to wptavern.com/contact/jukebox and use the form there.

So on the podcast today we have Milan Petrović. Milan has been deeply immersed in the WordPress ecosystem since 2007, developing an array of plugins, especially for expanding bbPress forums, and running his own company, creating plugins before joining the Freemius team as a full stack developer. With nearly two decades of hand-on experience, Milan has witnessed firsthand the evolution of both the WordPress and PHP landscapes.

Many WordPress users may be only partially aware of PHP. Perhaps they’ve noticed version numbers in their hosting panel, but few of the millions of WordPress users understand the real impact that PHP versions have on the security and performance of their websites. Milan is here to shine a light on why embracing newer versions like PHP eight isn’t just good practise, but a crucial step for security and efficiency.

Milan begins by recounting his journey through WordPress development. The conversation gets into the heart of his recent WordCamp Europe presentation, which tackles how legacy PHP code exposes sites to thousands of open bugs and vulnerabilities. And why relying on old versions is, as he describes, an active invitation for automated exploitation.

The discussion explores the contrast between running legacy code, and using the native shields of modern PHP, and highlights how PHP 8 not only closes security holes, but also delivers major performance boosts, reducing memory usage, and accelerating speed.

If you’re wondering why you should care about the PHP version your site is running on, or you’re a developer interested in practical ways to harden your code, Milan unpacks both the existential risks of outdated PHP, and the step-by-step benefits for hosts, agencies, and plug-in developers alike.

He introduces his Vulnerability Lab plugin, designed for developers to see firsthand how code exploits play out differently across PHP versions, and makes the case that modernising can happen gradually, one update, one plugin at a time.

If you’ve ever questioned how your hosting choice, or plugin stack, could affect your site’s future. Or you’re ready to take the first steps towards building more secure and future proof WordPress products, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Milan Petrović.

I am joined on the podcast by Milan Petrović. Hello Milan.

[00:03:58] Milan Petrović: Hello Nathan. Thank you for having me here.

[00:04:00] Nathan Wrigley: You are very welcome. We’re in a beautiful, beautiful media room at WordCamp Europe. And I know that you have already done your presentation because we just had a little chat about the fact that you’ve done it and it went well and all of that.

Do you want to tell us a little bit about you and your background working with code and developing and security and all of that kind of stuff? And then we’ll talk about your actual presentation and how it went.

[00:04:25] Milan Petrović: So I started with WordPress almost 20 years ago, so way back in 2007. And I created a lot of plugins for WordPress, and I especially have a lot of plugins for bbPress for expanding forums. Yeah, people still use forums these days. So that was, I really like bbPress and all the stuff I did with that.

I have been working as a freelancer for a lot of years. I have my own company that was doing plugins, it’s called Dev4Press. But in 2024, I joined the amazing team at Freemius. So for almost two years I am a full stack developer at Freemius. And that was a really nice change of pace for me and the work I usually do before that. So yeah, that’s a short of it.

[00:05:13] Nathan Wrigley: Yeah. That’s great. Thank you. And so the presentation that you did that is now over, goes like this. I’m going to read the entire blurb because it’s short enough to read, and it says, secure by design, hardening plugins with PHP 8.x. In the WordPress ecosystem, we’re often forced to choose between supporting the lowest common denominator of hosting and implementing modern security. But in 2026, writing legacy PHP 7 code isn’t just a bad habit, it’s an active invitation for automated exploitation. It’s time to stop playing whack-a-mole with sanitisation, and start building products that are secure by design. This talk isn’t just another slide deck on security tips. Through comparisons of a Vulnerability Lab plugin, you will see how common exploits like authentication bypass, and server side request forgery succeed on legacy code, only to be neutralised by the native shields of the latest PHP. You learn how to leverage the modern PHP patterns to ensure your plugins are resilient to a wide range of exploits.

Now into the show notes I will put Milan’s wordpress.tv presentation so that you can go and watch the entirety of it. I guess basically if at any point you get confused, that would be a good idea, pause this podcast and go and check that out. But, how did it go? How well received was it?

[00:06:33] Milan Petrović: For me personally, I’m very satisfied with how how it went. I don’t know, it’s a bit overwhelming to be honest, but I am very satisfied and I got a lot of questions after the talk. I met a lot of people that liked what I had to say. And I think it’s good feedback to have, for something that is more technical like this was.

[00:06:52] Nathan Wrigley: Well touching on the fact that it’s more technical, I have to confess that I think you are going to have to shepherd me through this, because a lot of the content that you I think probably got stuck into is beyond my pay grade. But hopefully we’ll get through it.

Now at WordCamp Europe, where we are now, I don’t know what the ratio is, but I’m guessing that a significant proportion of the people out there are not developers. They kind of know that PHP is a thing. They realise that WordPress is built on that, but they don’t really have an understanding.

They’ve probably heard of PHP 7. They’ve probably heard of PHP 8, because somewhere in a control panel that was shown to them. But maybe there’s not much of an understanding of the fact that it gets better over time. It gets secure over time. I think there’s probably a notion of, well, my website works. Why do I need to change anything?

So let’s get into that. What were you talking about in your presentation? What’s changed in the landscape of PHP more recently that you brought to the fore that you shared with your audience?

[00:07:51] Milan Petrović: Yeah, I think that PHP 8 was a big milestone for a lot of things. And I’m not sure, but I don’t think that the wider communities are kind of aware about the impact of the PHP, or the server environment in general, on how the websites work and how secure they are. Maybe the WordPress in itself needs to spread more awareness about that.

Because right now we get a notice in the dashboard that maybe the PHP needs to be updated. But for a lot of website users, that can be too much and too little information at the same time, because they may be not aware of how to do things on their hosting site.

We need to spread more awareness about how important the changes in the code are when it comes to the newer PHP versions, and what they can do to improve the security. And how developers should be starting to use more of those new features and the new things that PHP provides on a language level nowadays.

[00:08:49] Nathan Wrigley: WordPress has got this real legacy, I suppose is the right word, of supporting legacy code. So WordPress itself is supported way, way, way back. You can keep using versions of WordPress, which are many, many, many years old. And I wonder what your stance is in terms of PHP, whether or not WordPress runs versions of PHP which are far too old, in your opinion.

So in other words, should WordPress have a policy of, I don’t know, 8.x only? Or is 7 okay. And I don’t know what other CMS platforms, you know, Drupal, Joomla as was. I don’t know what they do, I don’t know what their posture is.

[00:09:32] Milan Petrović: I think that one of the most important decisions that, it was done with WordPress early on, is that backwards compatibility, because it opened the doors for a wider adoption. Because you don’t need to change server every year, or you don’t need to upgrade your software that often. And that helped a lot of hosting companies to provide WordPress hosting very cheaply, because they didn’t have to have the latest PHP, they didn’t have to invest much more money into all that. So WordPress got a lot of adoption from backwards compatibility policies.

But in the same time, that also proved a bit of a problem. Because even the WordPress Core code is kind of stuck because of that policy of backwards compatibility. And it’s not only compatibility with old versions of WordPress, but the old versions of PHP. And we are running now maybe six years behind end of life PHP versions. Because PHP 7.4 end of life was four and a half years ago. And we still support it in the Core.

[00:10:33] Nathan Wrigley: Yeah, I guess it’s a nice thing to support it. And it, as you described, it was a great way of onboarding the millions of people that came along. But things have moved on.

What would be some of the top level items? And I’m inviting you to open the scary book and sort of give out the worst case scenarios basically of running legacy code. So really, go to town, frighten us all. What are some of the horrors that await if you’re quite willing to, as a hosting company, support seven point whatever or beyond, six or five, or dare I say it, four, who knows? What are some of the terrible things that await us?

[00:11:08] Milan Petrović: To be honest, when I was researching some of the statistics and things like that, I was kind of scared when I saw that there are 3 or 4,000 open bug reports for PHP 7 and PHP 5, which are still in use today, and there are WordPress websites running on both of them in the millions. And there are 3 or 4,000 open and confirmed bags that are never going to be fixed. Never. So PHP 7 has thousands of bugs, and I’m sure that not everything security related, but a big chunk of those bags are related to security.

And there are open exploits that run on the PHP level. They don’t care really about if you are using WordPress or using something else. It’s more like a exploit on the level of a, on a server side that can be quite scary because you, even the technical people are not really sure what are all those bugs. Who is going to go through 3,000 or 4,000 bug reports?

[00:12:05] Nathan Wrigley: Yeah, so just to sort of describe that, the fact that there is no more updates to the 7 branch of PHP means that all of those bugs which are publicly available, anybody can go and read great detail about what they are. Well that then means that any hacker can do that, and probably did like a dozen years ago. And so really you are painting a picture there of you are asking for trouble.

[00:12:30] Milan Petrović: There are hosting companies that maybe do things a bit differently because you don’t need to run PHP as it was created. You can build your own version of PHP. You can patch bugs on your own. And a lot of hosting companies are doing that. But in the same time, that also poses a problem. You are going to run WordPress in your own plugins on a platform that is not actually officially PHP supported. It can have some different quirks that make your code run a bit differently.

A while ago we had the Facebook running their own PHP build, that was quite different from the public PHP. But they used it, and other people started using it. So I don’t know. Still I think that the official PHP is the one you should be on because you never know what other issues. Even when hosting company patches the PHP they’re using, maybe they’re opening doors to something else that is not quite documented on that level.

I think that the best policies, I don’t expect for WordPress to adopt the latest PHP or only supported PHP versions, but to kind of move quicker on the adoption of the newest version. So maybe we should be quicker to adopt PHP 8.0 or 8.1 is a next minimal required version for WordPress.

[00:13:50] Nathan Wrigley: When you say you don’t expect WordPress to do it, is that simply because it doesn’t have a history of doing it? Is there a technical reason why WordPress could not keep up with the latest version? I know we’ve got this plugin architecture where there’s thousands and thousands of developers who are all doing their own thing, and there’s all of that. Is there any technical reason why WordPress couldn’t be on the cutting edge, most up-to-date, latest version?

[00:14:15] Milan Petrović: There are two factors in all that. First one is you can declare, PHP 8 is the minimal version we support. We don’t support PHP 7.4 anymore. And that means that you don’t need to make any changes in WordPress at that point. You can declare it because WordPress is compatible with all PHP versions. It works on 8.0 and 8.5. That’s no problem. But say that branch 7 is no longer supported, you’re kind of pushing other developers and hosting companies to improve their support for newer versions.

And you don’t need to make immediate changes to WordPress. But at that point, you are open to modernise the code because now you can have more stricter typing across the board. There are some strict typing things in older PHP versions, but with 8.0, you can do all of that. And it doesn’t have to be a process that is done immediately. It can be done gradually. You can update parts of the WordPress Core over time. And it’ll take a few years, to get up to date, but at least you are closing doors to some older versions of PHP, and you are pushing developers as well for plugins to have that policy.

Right now, each developer can have their own plugins supporting any version of PHP you want. For my plugins, I have policy of 8.0 as a minimal version since this year. And, I’m updating the code as I go along. I don’t do it, it’s impossible to do it all at once. And for WordPress, it’s going to be even worse to make it all up to date. But declaring PHP 8 is a minimal required version, would be a great step in the right direction for wider adoption.

[00:15:51] Nathan Wrigley: Yeah, I think the problem is simply one of the user base, isn’t it? There’s just millions of people, thousands of developers all doing their own thing. And casting 8.x, 8.0 and above as the new minimum, there’s going to be a moment where some things do go wrong.

So that calendar plugin that you’ve been using for ages, which just works. And sure, you’ve never really received any updates from the developer, but it just works. Everybody’s booking on my calendar and we are all good. And then suddenly PHP 8 is required and it turns out the calendar plugin now no longer works.

You can imagine those kind of stories a million times over coming to the fore. But equally, we got to move on. There’s no way of, you know, because we can’t in 10 years still have sites on 7.4.

[00:16:43] Milan Petrović: We have sites on five point something. I recently checked the official WordPress tracking. 7.4 is on 20% even now. So we are far away from WordPress ditching the 7 branch. And I think there are still few percent of PHP 5 in all that so.

[00:17:01] Nathan Wrigley: Yes, I regularly look at the, it’s like a little donut chart, isn’t it? That is often produced and you gradually see the eight point x whatever section of the pie getting bigger as they produce the next survey. But you’re right, it’s still a significant chunk that’s on 7 and below.

And whilst when I look at that chart, it doesn’t really bring any alarm bells to the fore, I just think, oh, that’s a shame. But now that you are presenting this talk, and giving me this information, I realise that that attack surface is worse.

When you gave that talk, who is your target audience? Were you directly sort of aiming at the hosting companies who presumably can do a lot of work very quickly? You know, they could take a million people onto 8 with a little bit of development work and on the back end of their platform. Or are you really encouraging the general WordPress user, like me, to take a bit more interest and make sure that I am going into the cPanel or whatever it is and updating myself? Or is it a bit of both?

[00:17:59] Milan Petrović: For everyone actually. It’s for developers to be more aware of what they can gain with the new PHP versions. It’s for hosting companies. Because it’s not only about security when it comes to the newer PHP. The PHP is faster and faster. So each new version gets you 5 or 10% more performance without doing anything. So PHP 8.5 is more than 50% faster than PHP 7.4. So that’s a significant update.

And I have even, one slide was showing how much less memory PHP 8.5 used to run exactly the same piece of code. So it’s pretty wild to see that hosting companies are maybe the biggest factor in all this. They will gain a lot more because they’re going to free a lot of resources to run more websites because PHP is going to use less memory and it’s going to be faster.

So I understand they need to invest a lot of money to do all that. But, I don’t know, I think that gains from that are very significant, on that level alone.

[00:18:57] Nathan Wrigley: Yeah, so you described there are really compelling scenario. You know, it’s quicker, it uses less memory, you’ll save money. I mean what else do you need? You’ve just presented the entire argument.

However, it hasn’t happened. So technically speaking, why do you think it hasn’t happened? Is there an acquisition of new knowledge that is difficult to take in? Is it that simply you would have to, I don’t know, retrain your staff? How do you understand that it hasn’t happened? What are the reasons people are digging their heels in and not making these updates?

[00:19:25] Milan Petrović: I kind of make the group of two or three types of hosting companies. One, and that’s usually more expensive managed hosting solutions. They are forcing the updates. They’re not maybe on the latest version, but they are forcing their users to use at least three or four versions of PHP back. So maybe 8.2 or 8.3, which is a great step in the right direction.

There is also a problem of support. If something starts breaking, they’re going to be the first one to be asked about that, because they made the change to the server. So why now website that was working yesterday is no longer working today because of some change made on a hosting level. So there are a lot of factors to play into that adoption.

But on the other hand, there are a lot of developers that have moved on with supporting PHP 8. A lot of plugins are very much updated and, especially popular plugins. They invested a lot of time to do the update. It’s getting easier to support it. But on the other hand, you have very old websites that are simply cannot move without proper testing, without updating the plugins. And there are cases when you cannot simply update one plugin because something else may break, or you made some changes that will make some other thing break. So it’s a big puzzle that is definitely not easy to solve, but maybe we should start some work on that as a community to do it, and to move people along.

I don’t want to say force the change, but make people aware of the benefits. Make people aware of the risks if they continue to run the old and outdated software. And the same goes for not updating plugins, not updating WordPress. No matter how much work is done in that regard, there are still most likely some exploits on a WordPress level for very old versions that at some point someone is going to find out about and exploit.

[00:21:16] Nathan Wrigley: I mean I guess the motto of WordPress was democratised publishing, which means basically make it available to everybody. No matter your level of expertise, make it available to everybody. And I’m sure that if you were to grab the CEO of any hosting company and say, I can save you money, I can save you resources, and all of those things that you outlined earlier, they would, yeah, we know, we know. But we’ve got thousands of non-technical people using WordPress.

I kind of have this analogy in my head, and it goes a bit like this. Several years ago, I bought a bike. And it sits in my garage and there is my bike. And I expect my bike to work tomorrow in the same way that it did four years ago. And in 10 years, I expect my bike to work. I don’t expect there to be an update to wheels or gears or the saddle. It doesn’t need an update. It’s just a bike. And I need my bike to be a bike and nothing more.

And I get the impression that many people treat their WordPress website as the same thing. This sort of static commodity that, sure enough, they pay a monthly fee for it, but it’s this website. It’s a thing, and it doesn’t need changing. And so what I’m trying to say is, I’m fairly sure that the hosting companies are met with that an awful lot. The customers who just, it’s a bike, it’s a website. Do you know what I mean?

[00:22:37] Milan Petrović: Yeah, but you need to maintain your bike. If you don’t do it, it’s going to, your belt is going to rust, your wheels are going to be deflated or whatever. A lot of things can happen with it if you don’t maintain it. So, we don’t need to upgrade everything all at once, but we can start from someplace. We can do it gradually. But still, WordPress needs to be the platform that leads the charging that, because it’s going to force other developers to do it. It’s going to force hosting companies to start doing it. And it’s not a big jump on moving just that one version, but it’s going to help to move things along faster. Let’s see how it goes in the next few years. But I really don’t expect for WordPress to drop 7.4 for at least a year or two, maybe even more.

[00:23:24] Nathan Wrigley: I loved your rebuttal of my bike analogy there. That was perfect. That’s exactly right. The bike will rust, the wheels will be deflated and all of that, yeah. So we need to drag the WordPress users along.

Now, in your presentation, you mentioned something that I have never used, the Vulnerability Lab plugin, which you used to demonstrate the attack. Can you just tell us a little bit about that? Because I’d be curious to follow that up, and maybe some people listening to this would too.

[00:23:47] Milan Petrović: I started it for, created for this talk specifically to add few examples and to run the code that is going to show those things if you run the plugin on the old version and the new version of PHP. And I do plan to expand on it because there are a lot more PHP security elements that can be demonstrated in that way.

So it can show you, you have like a, in many cases the same code, but if you run it on one platform, you’re going to get one result. And if you run it on the newer one, you will get something different. So it’s useful to show, and some of those changes are quite small, those attributes that you can add to the code are very, very small, but they can really help you to improve security of your plugin.

And there are more complex security measures that can be implemented, but the format of the talk wasn’t really suitable to mention everything. But this was like something to get you started on the path of discovering what else PHP 8 can offer, when it comes to improving the security of the plugins and what possible exploits and vulnerabilities are there.

I try to use some obvious things that are very easy to spot. And I’m sure I did made some of those errors myself in the past. So some of those examples are something that I dealt with when I was upgrading my code. So I’m sure that a lot of people can see similar problems in their own code, and similar kind of solutions that can help them to overcome those and to make them much more resilient in the future.

[00:25:17] Nathan Wrigley: So is your plugin designed primarily, would you say for developers in mind, or is it something that just a typical end user may get some mileage out of?

[00:25:26] Milan Petrović: No, it’s more for developers that they can see, they can run that code and see how it behaves on the old version and the new version to demonstrate some of those things. And I will definitely expand it to include more examples in the future. Even for myself to like a document, what can happen if you run something in the old version, and the new version?

I had some suggestions coming to me like, maybe like a pattern library that is going to show what is the pattern that we use with old PHP and how to improve it with a new one, and document which version of PHP is going to support it, and how it’s going to improve the code.

[00:26:01] Nathan Wrigley: So is the idea then that you would instal it on various different, let’s say that you’ve got a live site and you’ve got, I don’t know, a development site and another development site, is that you would put it on each of those, different PHP versions, and just sort of compare and contrast what.

[00:26:16] Milan Petrović: Yeah, that can be used.

[00:26:17] Nathan Wrigley: Yeah, in that way. And what’s the reporting that you get? Is it kind of error logs, you know, that only a developer would be able to understand, or is it in plain language that somebody like me could understand?

[00:26:26] Milan Petrović: Right now it’s a bit technical because if you run a certain part of the code, some of those elements do have a visual component in the admin section. You will see, one of the examples, if it’s run on PHP 7.4, it’s going to result in a fatal error for sure, depending on the server settings. And if you run it on the new version, you will get a full code running and executing as expected.

So it’s a bit of a development thing that developers can use themselves to show maybe to potential clients or to website owners what is going to happen if they continue to run the outdated versions of the PHP. So it’s not just, yeah, the PHP 7.4 is bad, but here it is, why it is bad actually.

[00:27:12] Nathan Wrigley: Okay, that’s a really interesting use case, isn’t it? So if I’m an agency owner and I’ve got, I don’t know, a client over here who is absolutely wedded to this plugin, this calendar plugin say, and we know that the development of that plugin has ended years ago, then trying to persuade that client to find something new, or have something new built is difficult.

But with the capabilities of the plugin that you’ve created, you’ll be able to show in a sort of readable human way, okay, right. That’s all very well, but we’ve got to get onto PHP 8.0. And when we do that, this is going to happen.

So that’s actually quite a useful tool for agencies to be able to dangle things in front of the noses of their clients. Potentially, I don’t know, get some new work out of it as well, because there’s this extra work that needs to be done to bring it up to the modern standards.

[00:28:01] Milan Petrović: Yes. And one example especially demonstrates not only security, it demonstrates the performance. It shows you how much memory that piece of code is using on old version. Almost half the memory is going to be used less with a new version. So that’s very on the nose demonstration on security, and the performance in the same time. So things like that can help. And I will definitely try to invest more time in showing more examples and anyone can contribute.

It’s a plugin available on GitHub, so any contributions in that regard are welcome. And we can maybe all work to create like a list of patterns that are something that a lot of people can use, and show different people how the PHP can help them move along.

And again, I don’t want to sound like we don’t need whatever WordPress is doing. We still need to use all the security enhancements that WordPress has built in the Core. Escaping, sanitisation. All that is still very important because you cannot solve everything by upgrading PHP and upgrading your code to use some of the PHP features. There are still a lot of security elements in WordPress itself that are very important and should not be replaced, or removed, from the code. There are patterns that are crucial to ensuring the security is on a top level. So combination of what WordPress already has, plus everything we get with the newer PHP is something that we should strive in the future, and to make things better.

And it’s not that complicated to start with the process. You can start upgrading small things. You can start with stricter typing. You can start with very small changes, and then gradually you can add those new attributes. You can replace some of the functions that you may be used with old version of PHP, but there is something better in the new version. So that’s something that everyone can do. Do a bit at a time so not everything at once. Spend time and make some gradual upgrades, and that’s going to help moving along.

[00:29:57] Nathan Wrigley: You are obviously here to talk about where PHP meets WordPress, but presumably you, yourself are gaining intel from the PHP community. Is there a resource, like a central PHP resource that you would direct people to, or would you rather steer them towards kind of WordPress resources? The things that people are doing in the WordPress space and the hosting space. There’s not really a question there, but it’s more where do you find your information? Where’s the most reliable place?

[00:30:25] Milan Petrović: You need to check everything. PHP website is a really good resource to find the information about what’s coming in the next version of PHP, because the preparations take up to a year to release a new version of PHP. So they’re now on a cycle that every December we get a new feature version. So in December this year, there is going to be PHP 8.6. And you already know most of the things that are coming to that version. You have the detailed list of changes for every PHP version. And that’s something that any developer should look at, and to see maybe something that will drive them to upgrade.

In the current usage of third party libraries, there are a lot of libraries used in PHP that have moved on beyond 7.4. There are a lot of libraries that now require 8.1 or 8.2. If you depend on some library for, I don’t know, parsing URLs, or doing something else, something for security, something for whatever. You may face the problem that if you want to use the latest version of that library, you will need to have the newer PHP version. So you are kind of forced to upgrade your plugin requirements to meet with the requirements of the third party libraries.

And outside of WordPress ecosystem, those libraries will move much faster with the adoption of newer PHPs versions than WordPress itself, because they don’t deal with millions and millions of websites that are affected. They are creating the library the best way they can. And they want to ensure that their library is secure, that their library has access to the latest features. So they are going to bump requirements for those libraries on their own. And if you are depending on it, you need to do it yourself for your plugin. So it’s kind of, those libraries are kind of forcing the hand of some developers to upgrade, even if they maybe are not ready at this point to do it.

[00:32:15] Nathan Wrigley: Yeah, it certainly sounds like there’s no lack of information out there. If you make your business to find the information, then it’s all there. You’ve just got to make the effort to go and find it.

I’ve kind of run the gamut of everything I wish to ask. However, I’m very conscious, as I said at the beginning, that this conversation is a little bit above my pay grade. Is there anything that I missed that you wished you had been asked that you wanted to get across?

[00:32:38] Milan Petrović: No, I think we covered a lot of stuff in that.

[00:32:42] Nathan Wrigley: Well I’m glad to hear it. That’s great. Yeah, thank you.

In which case, I’m assuming, given that you’ve come to an event like this and you’ve put a plugin on GitHub, you are sort of semi available, or very available, to have conversations with people around this. And if that’s the case, where’s the best place to find you online? A website or an email address or a Twitter handle or whatever.

[00:33:00] Milan Petrović: We included the slide with the contact information. So even the email, if someone wants to get more information, they can do it on various social networks as well. So any input about all that is welcome. And I’d be happy to help if someone needs, some pointers or additional information to get started with all this.

[00:33:21] Nathan Wrigley: Well, thank you. That’s very much appreciated. As always, if you go to the show notes on the WP Tavern website and click on the episode involving Milan, you’ll be able to find, buried probably towards the bottom, all the different bits and pieces, the wordpress.tv video that will go with his presentation and various other links that have been discussed during the course of this episode.

So with that said, Milan, thank you so much for chatting to me today. I really appreciate it.

[00:33:47] Milan Petrović: Thank you. It was really great, and I appreciate your invitation for the interview.

[00:33:52] Nathan Wrigley: You are so welcome. Thank you.

[00:33:53] Milan Petrović: Thank you.