{"id":11310,"date":"2026-07-15T19:30:00","date_gmt":"2026-07-15T14:00:00","guid":{"rendered":"https:\/\/4ksamachar.com\/?p=11310"},"modified":"2026-07-15T19:30:00","modified_gmt":"2026-07-15T14:00:00","slug":"225-milan-petrovic-on-the-risks-of-legacy-php-in-wordpress-and-why-upgrading-matters-for-security","status":"publish","type":"post","link":"https:\/\/4ksamachar.com\/?p=11310","title":{"rendered":"#225 \u2013 Milan Petrovi\u0107 on the Risks of Legacy PHP in WordPress and Why Upgrading Matters for Security"},"content":{"rendered":"
\nTranscript<\/summary>\n
\n

[00:00:19] Nathan Wrigley:<\/strong> Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.<\/p>\n

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.<\/p>\n

If you\u2019d 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\u2019d like us to feature on the podcast, I\u2019m 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.<\/p>\n

So on the podcast today we have Milan Petrovi\u0107. 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.<\/p>\n

Many WordPress users may be only partially aware of PHP. Perhaps they\u2019ve 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\u2019t just good practise, but a crucial step for security and efficiency.<\/p>\n

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.<\/p>\n

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.<\/p>\n

If you\u2019re wondering why you should care about the PHP version your site is running on, or you\u2019re 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.<\/p>\n

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.<\/p>\n

If you\u2019ve ever questioned how your hosting choice, or plugin stack, could affect your site\u2019s future. Or you\u2019re ready to take the first steps towards building more secure and future proof WordPress products, this episode is for you.<\/p>\n

If you\u2019re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com\/podcast, where you\u2019ll find all the other episodes as well.<\/p>\n

And so without further delay, I bring you Milan Petrovi\u0107.<\/p>\n

I am joined on the podcast by Milan Petrovi\u0107. Hello Milan.<\/p>\n

[00:03:58] Milan Petrovi\u0107:<\/strong> Hello Nathan. Thank you for having me here.<\/p>\n

[00:04:00] Nathan Wrigley:<\/strong> You are very welcome. We\u2019re 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\u2019ve done it and it went well and all of that.<\/p>\n

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\u2019ll talk about your actual presentation and how it went.<\/p>\n

[00:04:25] Milan Petrovi\u0107:<\/strong> 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.<\/p>\n

I have been working as a freelancer for a lot of years. I have my own company that was doing plugins, it\u2019s 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\u2019s a short of it.<\/p>\n

[00:05:13] Nathan Wrigley:<\/strong> Yeah. That\u2019s great. Thank you. And so the presentation that you did that is now over, goes like this. I\u2019m going to read the entire blurb because it\u2019s short enough to read, and it says, secure by design, hardening plugins with PHP 8.x. In the WordPress ecosystem, we\u2019re 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\u2019t just a bad habit, it\u2019s an active invitation for automated exploitation. It\u2019s time to stop playing whack-a-mole with sanitisation, and start building products that are secure by design. This talk isn\u2019t 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.<\/p>\n

Now into the show notes I will put Milan\u2019s 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?<\/p>\n

[00:06:33] Milan Petrovi\u0107:<\/strong> For me personally, I\u2019m very satisfied with how how it went. I don\u2019t know, it\u2019s 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\u2019s good feedback to have, for something that is more technical like this was.<\/p>\n

[00:06:52] Nathan Wrigley:<\/strong> Well touching on the fact that it\u2019s 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\u2019ll get through it.<\/p>\n

Now at WordCamp Europe, where we are now, I don\u2019t know what the ratio is, but I\u2019m 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\u2019t really have an understanding.<\/p>\n

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

So let\u2019s get into that. What were you talking about in your presentation? What\u2019s changed in the landscape of PHP more recently that you brought to the fore that you shared with your audience?<\/p>\n

[00:07:51] Milan Petrovi\u0107:<\/strong> Yeah, I think that PHP 8 was a big milestone for a lot of things. And I\u2019m not sure, but I don\u2019t 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

[00:08:49] Nathan Wrigley:<\/strong> 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.<\/p>\n

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

[00:09:32] Milan Petrovi\u0107:<\/strong> 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\u2019t need to change server every year, or you don\u2019t need to upgrade your software that often. And that helped a lot of hosting companies to provide WordPress hosting very cheaply, because they didn\u2019t have to have the latest PHP, they didn\u2019t have to invest much more money into all that. So WordPress got a lot of adoption from backwards compatibility policies.<\/p>\n

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\u2019s 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.<\/p>\n

[00:10:33] Nathan Wrigley:<\/strong> Yeah, I guess it\u2019s 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.<\/p>\n

What would be some of the top level items? And I\u2019m 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\u2019re 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?<\/p>\n

[00:11:08] Milan Petrovi\u0107:<\/strong> 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\u2019m sure that not everything security related, but a big chunk of those bags are related to security.<\/p>\n

And there are open exploits that run on the PHP level. They don\u2019t care really about if you are using WordPress or using something else. It\u2019s 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?<\/p>\n

[00:12:05] Nathan Wrigley:<\/strong> 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.<\/p>\n

[00:12:30] Milan Petrovi\u0107:<\/strong> There are hosting companies that maybe do things a bit differently because you don\u2019t 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.<\/p>\n

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\u2019t 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\u2019re using, maybe they\u2019re opening doors to something else that is not quite documented on that level.<\/p>\n

I think that the best policies, I don\u2019t 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.<\/p>\n

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

[00:14:15] Milan Petrovi\u0107:<\/strong> There are two factors in all that. First one is you can declare, PHP 8 is the minimal version we support. We don\u2019t support PHP 7.4 anymore. And that means that you don\u2019t 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\u2019s no problem. But say that branch 7 is no longer supported, you\u2019re kind of pushing other developers and hosting companies to improve their support for newer versions.<\/p>\n

And you don\u2019t 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\u2019t 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\u2019ll 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.<\/p>\n

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\u2019m updating the code as I go along. I don\u2019t do it, it\u2019s impossible to do it all at once. And for WordPress, it\u2019s 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.<\/p>\n

[00:15:51] Nathan Wrigley:<\/strong> Yeah, I think the problem is simply one of the user base, isn\u2019t it? There\u2019s 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\u2019s going to be a moment where some things do go wrong.<\/p>\n

So that calendar plugin that you\u2019ve been using for ages, which just works. And sure, you\u2019ve never really received any updates from the developer, but it just works. Everybody\u2019s 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.<\/p>\n

You can imagine those kind of stories a million times over coming to the fore. But equally, we got to move on. There\u2019s no way of, you know, because we can\u2019t in 10 years still have sites on 7.4.<\/p>\n

[00:16:43] Milan Petrovi\u0107:<\/strong> 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.<\/p>\n

[00:17:01] Nathan Wrigley:<\/strong> Yes, I regularly look at the, it\u2019s like a little donut chart, isn\u2019t 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\u2019re right, it\u2019s still a significant chunk that\u2019s on 7 and below.<\/p>\n

And whilst when I look at that chart, it doesn\u2019t really bring any alarm bells to the fore, I just think, oh, that\u2019s a shame. But now that you are presenting this talk, and giving me this information, I realise that that attack surface is worse.<\/p>\n

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?<\/p>\n

[00:17:59] Milan Petrovi\u0107:<\/strong> For everyone actually. It\u2019s for developers to be more aware of what they can gain with the new PHP versions. It\u2019s for hosting companies. Because it\u2019s 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\u2019s a significant update.<\/p>\n

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\u2019s pretty wild to see that hosting companies are maybe the biggest factor in all this. They will gain a lot more because they\u2019re going to free a lot of resources to run more websites because PHP is going to use less memory and it\u2019s going to be faster.<\/p>\n

So I understand they need to invest a lot of money to do all that. But, I don\u2019t know, I think that gains from that are very significant, on that level alone.<\/p>\n

[00:18:57] Nathan Wrigley:<\/strong> Yeah, so you described there are really compelling scenario. You know, it\u2019s quicker, it uses less memory, you\u2019ll save money. I mean what else do you need? You\u2019ve just presented the entire argument.<\/p>\n

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

[00:19:25] Milan Petrovi\u0107:<\/strong> I kind of make the group of two or three types of hosting companies. One, and that\u2019s usually more expensive managed hosting solutions. They are forcing the updates. They\u2019re 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.<\/p>\n

There is also a problem of support. If something starts breaking, they\u2019re 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.<\/p>\n

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\u2019s 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\u2019s 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.<\/p>\n

I don\u2019t 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.<\/p>\n

[00:21:16] Nathan Wrigley:<\/strong> 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\u2019m 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\u2019ve got thousands of non-technical people using WordPress.<\/p>\n

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\u2019t expect there to be an update to wheels or gears or the saddle. It doesn\u2019t need an update. It\u2019s just a bike. And I need my bike to be a bike and nothing more.<\/p>\n

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\u2019s this website. It\u2019s a thing, and it doesn\u2019t need changing. And so what I\u2019m trying to say is, I\u2019m fairly sure that the hosting companies are met with that an awful lot. The customers who just, it\u2019s a bike, it\u2019s a website. Do you know what I mean?<\/p>\n

[00:22:37] Milan Petrovi\u0107:<\/strong> Yeah, but you need to maintain your bike. If you don\u2019t do it, it\u2019s 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\u2019t maintain it. So, we don\u2019t 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\u2019s going to force other developers to do it. It\u2019s going to force hosting companies to start doing it. And it\u2019s not a big jump on moving just that one version, but it\u2019s going to help to move things along faster. Let\u2019s see how it goes in the next few years. But I really don\u2019t expect for WordPress to drop 7.4 for at least a year or two, maybe even more.<\/p>\n

[00:23:24] Nathan Wrigley:<\/strong> I loved your rebuttal of my bike analogy there. That was perfect. That\u2019s 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.<\/p>\n

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\u2019d be curious to follow that up, and maybe some people listening to this would too.<\/p>\n

[00:23:47] Milan Petrovi\u0107:<\/strong> 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.<\/p>\n

So it can show you, you have like a, in many cases the same code, but if you run it on one platform, you\u2019re going to get one result. And if you run it on the newer one, you will get something different. So it\u2019s 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.<\/p>\n

And there are more complex security measures that can be implemented, but the format of the talk wasn\u2019t 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.<\/p>\n

I try to use some obvious things that are very easy to spot. And I\u2019m 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\u2019m 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.<\/p>\n

[00:25:17] Nathan Wrigley:<\/strong> 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?<\/p>\n

[00:25:26] Milan Petrovi\u0107:<\/strong> No, it\u2019s 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?<\/p>\n

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\u2019s going to improve the code.<\/p>\n

[00:26:01] Nathan Wrigley:<\/strong> So is the idea then that you would instal it on various different, let\u2019s say that you\u2019ve got a live site and you\u2019ve got, I don\u2019t 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.<\/p>\n

[00:26:16] Milan Petrovi\u0107:<\/strong> Yeah, that can be used.<\/p>\n

[00:26:17] Nathan Wrigley:<\/strong> Yeah, in that way. And what\u2019s 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?<\/p>\n

[00:26:26] Milan Petrovi\u0107:<\/strong> Right now it\u2019s 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\u2019s run on PHP 7.4, it\u2019s 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.<\/p>\n

So it\u2019s 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\u2019s not just, yeah, the PHP 7.4 is bad, but here it is, why it is bad actually.<\/p>\n

[00:27:12] Nathan Wrigley:<\/strong> Okay, that\u2019s a really interesting use case, isn\u2019t it? So if I\u2019m an agency owner and I\u2019ve got, I don\u2019t 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.<\/p>\n

But with the capabilities of the plugin that you\u2019ve created, you\u2019ll be able to show in a sort of readable human way, okay, right. That\u2019s all very well, but we\u2019ve got to get onto PHP 8.0. And when we do that, this is going to happen.<\/p>\n

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

[00:28:01] Milan Petrovi\u0107:<\/strong> 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\u2019s 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.<\/p>\n

It\u2019s 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.<\/p>\n

And again, I don\u2019t want to sound like we don\u2019t 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.<\/p>\n

And it\u2019s 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\u2019s 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\u2019s going to help moving along.<\/p>\n

[00:29:57] Nathan Wrigley:<\/strong> 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\u2019s not really a question there, but it\u2019s more where do you find your information? Where\u2019s the most reliable place?<\/p>\n

[00:30:25] Milan Petrovi\u0107:<\/strong> You need to check everything. PHP website is a really good resource to find the information about what\u2019s coming in the next version of PHP, because the preparations take up to a year to release a new version of PHP. So they\u2019re 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\u2019s something that any developer should look at, and to see maybe something that will drive them to upgrade.<\/p>\n

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\u2019t 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.<\/p>\n

And outside of WordPress ecosystem, those libraries will move much faster with the adoption of newer PHPs versions than WordPress itself, because they don\u2019t 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\u2019s 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.<\/p>\n

[00:32:15] Nathan Wrigley:<\/strong> Yeah, it certainly sounds like there\u2019s no lack of information out there. If you make your business to find the information, then it\u2019s all there. You\u2019ve just got to make the effort to go and find it.<\/p>\n

I\u2019ve kind of run the gamut of everything I wish to ask. However, I\u2019m 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?<\/p>\n

[00:32:38] Milan Petrovi\u0107:<\/strong> No, I think we covered a lot of stuff in that.<\/p>\n

[00:32:42] Nathan Wrigley:<\/strong> Well I\u2019m glad to hear it. That\u2019s great. Yeah, thank you.<\/p>\n

In which case, I\u2019m assuming, given that you\u2019ve come to an event like this and you\u2019ve put a plugin on GitHub, you are sort of semi available, or very available, to have conversations with people around this. And if that\u2019s the case, where\u2019s the best place to find you online? A website or an email address or a Twitter handle or whatever.<\/p>\n

[00:33:00] Milan Petrovi\u0107:<\/strong> 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\u2019d be happy to help if someone needs, some pointers or additional information to get started with all this.<\/p>\n

[00:33:21] Nathan Wrigley:<\/strong> Well, thank you. That\u2019s 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\u2019ll 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.<\/p>\n

So with that said, Milan, thank you so much for chatting to me today. I really appreciate it.<\/p>\n

[00:33:47] Milan Petrovi\u0107:<\/strong> Thank you. It was really great, and I appreciate your invitation for the interview.<\/p>\n

[00:33:52] Nathan Wrigley:<\/strong> You are so welcome. Thank you.<\/p>\n

[00:33:53] Milan Petrovi\u0107:<\/strong> Thank you.<\/p>\n<\/div>\n<\/details>\n

On the podcast today we have Milan Petrovi\u0107<\/a>.<\/p>\n

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 hands-on experience, Milan has witnessed firsthand the evolution of both the WordPress and PHP landscapes.<\/p>\n

Many WordPress users may be only partially aware of PHP, perhaps they\u2019ve noticed version numbers in their hosting panels, 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 8.x, isn\u2019t just good practice but a crucial step for security and efficiency.<\/p>\n

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, \u201can active invitation for automated exploitation.\u201d The discussion explores the contrast between running legacy code and using the \u201cnative shields\u201d of modern PHP, and highlights how PHP 8.x not only closes security holes but also delivers major performance boosts, reducing memory usage and accelerating speed.<\/p>\n

If you\u2019re wondering why you should care about the PHP version your site is running on, or you\u2019re 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 plugin developers alike.<\/p>\n

He introduces his Vulnerability Lab plugin, designed for developers to see first-hand 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.<\/p>\n

If you\u2019ve ever questioned how your hosting choice or plugin stack could affect your site\u2019s future, or you\u2019re ready to take the first steps towards building more secure and future-proof WordPress products, this episode is for you.<\/p>\n

Useful links<\/h2>\n

Secure-by-design: hardening plugins with PHP 8.x<\/a> \u2013 Milan\u2019s presentation at WordCamp Europe 2026<\/p>\n

bbPress<\/a><\/p>\n

Dev4Press<\/a><\/p>\n

Freemius<\/a><\/p>\n

\u200aVulnerability Lab plugin<\/a> on GitHub<\/p>\n","protected":false},"excerpt":{"rendered":"

Transcript [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. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-11310","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"blog_post_layout_featured_media_urls":{"thumbnail":"","full":""},"categories_names":{"1":{"name":"Uncategorized","link":"https:\/\/4ksamachar.com\/?cat=1"}},"tags_names":[],"comments_number":"0","wpmagazine_modules_lite_featured_media_urls":{"thumbnail":"","cvmm-medium":"","cvmm-medium-plus":"","cvmm-portrait":"","cvmm-medium-square":"","cvmm-large":"","cvmm-small":"","full":""},"_links":{"self":[{"href":"https:\/\/4ksamachar.com\/index.php?rest_route=\/wp\/v2\/posts\/11310","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/4ksamachar.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/4ksamachar.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/4ksamachar.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/4ksamachar.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=11310"}],"version-history":[{"count":0,"href":"https:\/\/4ksamachar.com\/index.php?rest_route=\/wp\/v2\/posts\/11310\/revisions"}],"wp:attachment":[{"href":"https:\/\/4ksamachar.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=11310"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/4ksamachar.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=11310"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/4ksamachar.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=11310"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}