Maintaining Legacy Support in WooCommerce and WordPress While Building for the Future

James Kemp:
Hello, you’re listening to Woo Product Chat, part of the Open Makers channel, which is an Open Channels FM production. I’m James Kemp. I’m the product manager at WooCommerce. And with us today we have Katie. As always, Katie, do you want to introduce yourself?

Katie Keith:
Hey, I’m Katie Keith, founder and CEO at Barn2 Plugins. So we do all sorts of plugins mostly for WooCommerce and we have special guest today. Gary, can you introduce yourself? Thank you so much for coming on.

Gary Pendergast:
Thanks, Katie. Thanks, James. I’m Gary. Gary Pendergast. I’m a longtime WordPress core contributor, worked for Automattic for a long time and now currently work on Discourse, the community forum software.

James Kemp:
Amazing. Discourse. Discourse. I’m trying to think, if I use Discourse, is that the same thing that allows you to add like a comment section on a blog or is that.

Gary Pendergast:
Something else Discourse does that has a WordPress plugins for linking it together like that. It’s can be used like that. It’s. There’s a bunch of large communities that kind of just have their discussion forums on there. Everything from like hardware companies, like Sonos, various AI companies use it. I think Google is using it for some of their communities.

James Kemp:
It’s amazing. Yeah, I think I used it in the past as like a commenting solution for my blog and it was good. I liked it. So today we wanted to talk about. I don’t think I introduced the topic of this podcast, but we want to talk about the art of backwards compatibility, which is something that’s quite deeply important in the. The WordPress space and something that we think about a lot at WooCommerce specifically. And Katie, I’m sure you think about backwards compatibility a lot as well in the plugins that you’re putting out there.

Katie Keith:
Yeah, and it’s something we don’t really talk about that much, is it? We just sort of manage it, but as a community we don’t really discuss it. Like think about all the discussions I’ve had on Twitter or whatever. I don’t remember ever discussing how we approach backward compatibility. So, Gary, to get started on the topic, could you tell us what we mean by backward compatibility in the context of WordPress?

Gary Pendergast:
I mean, first kind of to Your point there that we don’t talk about it, I think that’s kind of, in some ways the point of it is that it just works and you don’t need to think about it. So in the case of WordPress, generally speaking, it’s very rare that you will have a. You’ll upgrade a version of WordPress and anything will break. It will just continue to work for WordPress that’s, that’s always been built as having stable plugin APIs and theme APIs where the plugin and theme developers can just build things to work against those APIs and it will continue to work regardless of what’s upgraded behind the scenes.

James Kemp:
Is that like a similar situation at Discourse? I imagine Discourse is slightly different in that it’s a hosted software, right?

Gary Pendergast:
Yeah. So Discourse is both more hosted, it’s still an open source project, but it is. The bulk of Discourse sites are hosted by the Discourse company. However, we still have similar concepts. We have our plugin APIs and whatnot that allow plugin developers to consistently to build consistent and reliable plugins and know that they’ll continue to work as Discourse is upgraded.

James Kemp:
Yeah, because I think there’s many challenges, particularly in the WordPress space with backwards compatibility, because we’re not just talking about compatibility with all of the different plugins and software versions that are installed on a WordPress site, but also we need to consider the compatibility with like the server environment as well. So the PHP version and you know, even, even like serving to old hosts that maybe aren’t as performant as new hosts. So I think there’s many different angles that backward compatibility can take. What would you say is the most common angle? I guess I think the PHP version is something that I see quite a lot and it’s something that I can point to as something that is actively supported. And I believe every year or two we kind of shift that baseline PHP version up. But I know for a long time we weren’t allowed to use like the new array format, for example, in PHP because we had to support older PHP versions in any software we were putting out. Is there anything that you’ve seen come up? Quite a lot that is something that we actively support and again it’s something that we just do. We don’t really think about it.

Gary Pendergast:
But yeah, so I think that’s perhaps an interesting flip side of the compatibility question. In some ways WordPress is taking on the compatibility backwards compatibility burden that PHP doesn’t didn’t want to do. So for a long time there, WordPress supported very old versions of PHP really, because PHP didn’t provide a great upgrade path. It was if you had old code running on an old version of php, then probably wouldn’t work if you upgraded to a new version. And so it turned out that as we were going through that process originally of figuring out how do we, how do we make it so that WordPress can start using more modern versions of PHP, it’s not so much a technical problem as it is a people problem, really. It’s a thing where WordPress, thankfully being such a widely used software package, it’s used everywhere. So the core team had a lot of contacts across the web hosting world and we’re able to talk to hosts and talk to the engineers who are actually managing those hosts and figure out, okay, how can we make it easy for you to upgrade? Are there things that we can do that can make it easy? Are there things that we can do to make it an obvious business case that you can then put to your management to do?

Katie Keith:
Yeah, I really like that, particularly for big software, because it’s so frustrating when you can’t add shiny new things because some like 5% or less of your users are on something so old they shouldn’t be using it anyway. So I really like that strategy, if you’re big enough to do it, of working with the host to make it in their best interest to upgrade. I suppose that’s probably not available for smaller products because they wouldn’t have that influence. But for the big players like WordPress, WooCommerce, whatever, I think that’s really good.

Gary Pendergast:
Yeah, and I think that’s perhaps not so much a question of influence in some ways. It’s a. It’s an issue of responsibility. And realistically, the most widely used PHP software in the world, despite not really having strong context with the core PHP community, does still have a responsibility to the broader PHP world to use its power as we could, for want of a better term.

James Kemp:
Yeah, I was just looking at the requirements now for WordPress and it feels like it has. I think there was a long time where we supported very old versions of PHP and it’s more recently we’ve been able to keep up a lot more. So we’re recommending at minimum php version 8.3 or greater. But there is a note that says it does still work with PHP 7.2. Yes, but those versions have reached the official end of life. So even though those versions aren’t supported anymore officially by php, we still support them in some way. And I expect as time goes on, this will shift as well.

Gary Pendergast:
Yeah, and WordPress has always taken that approach of the recommended version is the most recent stable version. As long once WordPress supports everything. I recall there were a couple of PHP’s PHP releases that we had to make some modifications for, but it generally will recommend the latest PHP version, but then we’ll support back as far back as it needs to and we try to encourage people to upgrade as regularly as possible.

Katie Keith:
Yeah, you can make a distinction between something optimally working with the latest version and something that works but maybe doesn’t work as well. I think the phrases degrade gracefully where it will still function as early as possible, but you can’t necessarily use the latest new features. But even that is work for the developers, isn’t it? They need to code it to detect the version and then perhaps remove certain functionality based on the older version. So it’s very tempting to not support older versions. As a smaller plugin company, it’s in a way easier for me at Barn too because we follow WordPress and WooCommerce for our minimum versions. So if WordPress and WooCommerce don’t even support say a version of PHP or something, then there’s no reason for us to, so that makes it a lot easier. So as soon as WooCommerce withdraws support for something, then we’ll update our own minimum versions and processes and everything. So I suppose we’re following the bigger players in that.

James Kemp:
Yeah, I think that makes sense. I think there’s some sort of like line to draw in the sand. At what point should we stop supporting super old versions of things, whether that’s PHP or you know, legacy coding techniques and things like that. So I think it makes sense for if you’re building on top of a software like WordPress or WooCommerce, it makes sense to follow their structure for sure. So Gary, you mentioned being a longtime contributor to cool WordPress, I assume. I have two questions. Are you still contributing to WordPress Core? And the second question is, are there any backward compatibility stories that you maybe have from your time contributing to Core?

Gary Pendergast:
Yes, yes, I did mean WordPress Core when I said that. I I’m not actively contributing at the moment. I think learning or discourse is all Ruby on Rails and whatnot. So learning, learning that has been taking up my, my headspace of late. I do try and chat, drop in and chat to people when I can and give thoughts on issues or pull requests when when someone pings me, but haven’t had a chance to write much WordPress code. Recently though, to your other question about backwards compatibility stories, there are, there are a lot, I mean probably the biggest one that, that I had to work on and I gave a WordCamp talk about this is what we call the, the Trojan emoji bug, which was a extremely severe security issue in WordPress where someone could take over a site by submitting a comment with an emoji in it. The way that, the way that we stored things in the database or the way that MySQL in fact worked is that it would if it encountered a emoji or any multi byte character, the kind of getting into esoteric character encoding problems. But if it, for an emoji is a good example of a multi byte character, if it encountered one of those characters, it would simply cut off the string there. And so WordPress of course does a lot of checks on. If someone submits a comment, then it checks, okay, make sure there’s no invalid HTML, make sure there’s nothing that could be used to as an exploit in there. But it assumes that the entire comment is then going to be stored in the database. That wasn’t the case with this issue. It was chopped off then, which meant that a person could submit a seemingly innocuous comment crafted in the right way and then a second comment after that, which would effectively complete that. Both of those comments individually looked innocuous, but together they were able to create an exploit. The it was a difficult problem to solve. I believe we went through, I think about 150 revisions, maybe three or four complete rewrites of the solution to figure out a way that we could do this. You know, we could fix this in a backwards compatible fashion because the simplest solution would be to force everyone to upgrade their MySQL version, which at the time really wasn’t an option. So we instead had to figure out a way that we could patch WPDB, which is the WordPress database class. It’s the interface between WordPress and the database. And we had to figure out a way that we could make it that, that would detect any of these kind of issues and stop them from being a problem.

James Kemp:
That’s interesting. That’s a very tricky thing for someone to figure out that they can do that.

Gary Pendergast:
Yeah, I have a lot of respect for security researchers who come up with these weird ways of getting security checks. And so I think the approach that we took with this is that we could have forced, could have gone, okay, well everyone just needs to upgrade MySQL and that’s it. But you can imagine across the entire WordPress world. It would have been catastrophic. The amount of engineer hours that would have had to go into that, it would have been phenomenal. We’re talking tens, hundreds of thousands, millions of hours would need to go into upgrading every copy of every version of MySQL that every WordPress is connected to.

James Kemp:
Yeah, I mean, it’s unrealistic, right?

Gary Pendergast:
Exactly. And so this is an extreme example, but the thought is that if there’s a way that we can then say, okay, well, instead of that, we’re going to take a handful of engineers and they’re going to spend a few months working on it. Maybe you’re talking about one or two engineering years worth of work. The trade off is clear. It’s like the only responsible thing we can do is put in the work to fix it in a way that will just work for everyone, which, thankfully, it largely did. I believe at the time there were some issues with some Japanese character sets, which our Japanese bug reporters were amazing. Immediately reported the issue with it. We were able to push out a fix the next day, but otherwise it went very, very smoothly. And that was in a big way, thanks to the efforts of the WordPress security team, several of the engineers there who spent a lot of time working with me on that, reviewing it, figuring out ways where it worked, where it worked, where it didn’t work, and just making sure that we took that mindset of how do we build this in a way that it won’t break when people go to use it. Yeah.

James Kemp:
The backwards compatibility aspect there is that we were, or you were able to support these older versions of MySQL without there being that security issue, but also still support the newer versions that didn’t have that issue.

Gary Pendergast:
That’s right. And I believe I did see that there were. There was some work on upgrading MySQL versions as well with aluminum versions of MySQL. So we’re actually nearly at a point, I think, where we can even drop those security workarounds because they’re no longer needed because MySQL doesn’t. Later versions of MySQL don’t have that issue anymore.

James Kemp:
And does that happen? Do you know, do they go back through these older sort of compatibility fixes and drops and like.

Gary Pendergast:
Yes, like some of them are like, that one is particularly intertwined into WPDB. So it’s a little bit more difficult to extract. It can certainly be done. There’s a lot of it, A lot of things where we’d simply write a compatibility function where some A new function exists in PHP that we want to be able to use. It’s not necessarily there. We write a PHP version of that function and kind of just stick it in the compatibility file. If the function doesn’t exist in the version of PHP that it’s being run on, then we’ll define it ourselves.

James Kemp:
Right, got it. And we have a similar mechanism for I can’t remember what they call them, but there’s functions within WordPress that work in a similar way. So we check if they’re defined and it allows plugins or themes to override those functions. Right. I guess that’s kind of the reverse of that. Interesting.

James Kemp:
Any similar experiences with Barn 2 plugins that you know of?

Katie Keith:
Well, fortunately it’s much smaller scale for us, which really helps. But we’re still thinking about thousands or tens of thousands of users rather than millions, and that does affect development decisions. I think one thing to bear in mind is what features you add in the first place and think about future backward compatibility. What’s likely to change in the future? Things like integrating with blocks, for example. Now, knowing that might change. People might use a block as it is, they might customize it, then things might change. There are decisions to be made on something that you know isn’t final, and then there’s obviously decisions to be made where we want to do a major change to an existing product that would break things. For example, we’ve got three table plugins, one for documents, one for products, and one for general tables. And they all use the jQuery data tables library and we want to upgrade the front end completely, completely rewrite the way that they interact with WordPress. Because these plugins were written in 2016. That’s before the REST API even existed in WordPress. So the way that they write, they take data from WordPress is not as performant as it would be if we use more modern techniques. So we want to completely rewrite the front end of these plugins. But we have many tens of thousands of users and we know that they’ve done some quite major customizations with programmatically creating table columns and all sorts of things. So even though we don’t want to, we’ve recently made the decision that we are going to have to keep supporting the old version for the foreseeable future. So then that leads to discussions like, well, what if they report a major bug in an old version that’s going to take ages to fix. At what point is it right to tell them we’re not going to fix this, you need to upgrade to the new version, which might mean redoing their customizations or something like that. So there’s always business decisions to be made as to what’s best for the user versus how long should we spend and supporting older versions.

James Kemp:
Yeah, I think that’s a massive challenge and we touched on it earlier, like knowing how long to support these older versions for, especially like you say, when you’ve got, when it’s something like your tables plugin where they will have been customized. I expect the majority of instances of that, people using that, they customize it in some way and that can be as simple as just like CSS customization. Right. It’s not necessarily even technical, but if you change how it fundamentally works, then I expect the CSS will change there as well.

Katie Keith:
Yeah, you know, a lot of companies get this wrong. They change things like the names of CSS classes and you can’t see why. It’s like, hang on, did you not think about your users? There was no need to rename that and now you’ve broken our customizations or something like that. So I see that surprisingly often in the WordPress process product world and I understand sometimes decisions need to be made, but if it’s just a developer tidying up names or conventions or something, it feels unnecessary. So I think people should be more aware of that.

James Kemp:
Yeah, that can be frustrating. I think there’s a similar issue that arose with the new WooCommerce checkout where some of the hook names have changed compared to what they were in the classic checkout. I don’t know too many details about why that would be, but my understanding is that because it’s block based and hooks kind of work in a different way in that environment and I expect there’s some sort of backwards compatibility aspect to it as well that maybe these two hook the same hook in each environment doesn’t work in the same way.

Katie Keith:
I would hope so. Like if we change a short code parameter, we will always keep the old one in the code.

James Kemp:
Yeah. You map it to the new one.

Katie Keith:
Yeah. You never actually delete things. Hopefully.

James Kemp:
Yeah. And then I wonder though, is there a point where you will delete that mapping or is it just a net win to keep it?

Katie Keith:
We’ve talked about the challenges of WordPress in terms of the fact that we can’t control the environment. So there’s far more backward compatibility issues because we can’t force an update. But another fundamental issue with WordPress is, is exactly that. We don’t know how people are using our software. Most of us don’t have detailed usage tracking, so we can’t tell, for example, how many of our users are using that shortcode parameter that we stopped using three years ago. So we can’t make an informed decision on when to delete it.

James Kemp:
Yeah, especially not at that level. Like that’s a very specific piece of data if you’re using a shortcut parameter. I mean, even shortcodes in general are becoming, you know, a backwards compatible thing.

Katie Keith:
Yeah. We’re meant to be using blocks.

James Kemp:
They’re still being used, but yeah, slowly replaced by blocks. And I’ve seen if not implemented blocks that kind of utilize the shortcode behind the scene and you know, that’s how they render.

Gary Pendergast:
Yeah.

James Kemp:
An interesting. Obviously at WooCommerce we have tons of stuff that we have to think about when rolling out new features or trying to modernize how certain things work. And there’s two scenarios that I can think of. One is the high performance order storage that we rolled out.

Katie Keith:
Oh, that was a nightmare.

James Kemp:
Yeah, yeah, exactly. And it’s still ongoing and it’s far more performant than the existing solution. But actually getting people to migrate to the new solution is a challenge because there’s a migration path there. It’s not as simple as you just turn it on and it works. There’s chances that the migration, you know, might fail, although we haven’t really seen many reports of that. But it’s something that you need to manage and take care over as the merchant or as the user when you’re migrating. So at the moment we have like this H. There’s three different scenarios. You have the old version where orders are just stored in the post table and many existing stores still run that, which can become slow because the post table is used for many things, particularly when you Have a busy store and you’re getting tons of orders and they’re all going into this post table alongside all of your products and all of your pages and all of your posts that like all in this one table. And I think actually the post meta side of things is what really slows everything down. So high performance order storage is its own table structure. But there’s obviously a migration that has to happen there. So new sites use the HPOS as we call it, but there’s also like a middle ground where you can use HPOS and still map it to posts. And I, yeah, there’s challenges there. I think we need to have some sort of tool that helps people migrate more easily and you know, kind of confirms that there’s not going to be any issues once you click migrate or presents potential issues before you actually do the thing. Because at the moment we have this now mix of people using the older, people using the newer and then people using like a merge of both. So that’s definitely a challenge. And I wonder if, if an approach that should be taken with backwards compatibility is to have an end of life for the classic versions or the older versions of things. As long as the tooling is there to be able to migrate with something like this where it requires a migration. What do you think about that? Just putting out in one year’s time, we’re not going to support this older version. If you want to keep using that version, you’ll have to stay on that version of WooCommerce to, you know, utilize the post table. But from version, I don’t know, 15 onwards, we’re only going to support HPOS. Is that a valid approach to take or is that questionable?

Gary Pendergast:
I think this is really not too dissimilar to the challenges that WordPress core faced with Gutenberg, where it is this new way of doing things that is has compatibility issues with the old way of doing things. It’s a struggle to, to find the right way for people to upgrade, to actually make it make a compelling argument for people to upgrade. It’s a struggle to figure out how much we put into making the old way of old ways of working old ways of doing things work. In, in Gutenberg we put a lot of work into meta box support in original versions or the original version of Gutenberg that was merged into Core because it was despite really being the old way of doing things, there were so many sites that had massive, customized, massively customized metabox based interfaces that they built. They needed time to be able to upgrade advanced custom fields is A great example back when it was just Elliot working on it. But I worked a lot with him on figuring out how we can make it work properly with Gutenberg, and he did amazing work on that. But the problem is, at some point, WordPress face the problem of saying, well, okay, well, we’ve got Gutenberg, it has this metabox support, but we really need to deprecate it at some point because it’s not. It actively makes Gutenberg worse. If you enable this metabox support because of the way it has to render within the React virtual DOM, it kind of made a mess of things. So the challenge was to make sure that there was a compelling reason for plugin developers to move to doing things with blocks. And then there was a compelling reason for end users to upgrade, upgrade those plugins and upgrade WordPress to the new way of doing things. And again, going back to the start where I was talking about these issues being a people problem, that’s what it is in a lot of cases is you can’t just make a technical solution to this necessarily. You have to be talking to end users, you have to be talking to plugin developers, you have to be talking to the people who are actually directly impacted by these changes and figuring out, okay, what is it that we can do to make your life easier? What is it that we can do where we can take. Put in 100 engineering hours, that’s going to save you a thousand.

James Kemp:
I think blocks are especially challenging because you’re going from an ecosystem of developers that have traditionally built with php and I think Meta, you know, post meta was the way to do that as well, with customizing post types and then moving to blocks into this, like, completely new coding language as well that many developers did not have any experience with.

Gary Pendergast:
Yeah, it was a, it was a big move. Gutenberg was such a huge project that it was really the kind of thing where we couldn’t cover everything in the first version. And that’s why we also had the option of, okay, well, install a Classic Editor plugin and you can just keep doing things the same way. And ultimately that was deprecated. That was the saying, okay, well, Gutenberg’s got to the point where you can do everything that you need to be able, that you want to be able to do within Gutenberg. So Classic Editor is not really going to be supported anymore. But it took some time to get there, and it took a lot of work from the Gutenberg engineering team to get there.

James Kemp:
Was the Classic Editor a product from the Gutenberg team?

Gary Pendergast:
It was in a Roundabout way. It was, it was a core, core project. WordPress core project. It was. I think it was Andrew Oz, who. And he was the original developer of a lot of the WordPress editor before Gutenberg. So he was able to manage a lot of that classic editor work.

James Kemp:
Yeah, because it’s an interesting way to kind of separate that legacy technology from the core code base, but still maintain some sort of backwards compatibility. So it’s an approach that could be taken like even in this HPOS example, maybe, you know, the core plugin shifts to this new mechanism of storing orders, but there’s a supported add on that allows you to use the old version, but even then there’s gotta be like some sort of time where that’s no longer supported.

Katie Keith:
Yeah, it’s kind of the same decision, isn’t it? Because you’ve got to maintain it. So it removes a bit of bloat from the main plugin, but that would have been disabled anyway if they’re not using it.

James Kemp:
Yeah, it does.

Gary Pendergast:
It really though, like, it does it really need much in the way of maintenance, like the classic editor plugin certainly didn’t once it was up and running, it largely just worked by itself. The WordPress hook system is extremely performant. That was another project I spent a lot of hours on. It is basically free to add a hook if it’s. Or to add a filter if it’s never run. The cost is nanoseconds, it’s very, very fast. So it’s very simple then to add whatever hooks you need to the code base to say, okay, well this is going to be a hook that’s really just there for compatibility, for backwards compatibility sake, for something to be able to hook into and keep doing things the old way. And then you have a plugin that will go, okay, this is where it needs to load some data in. And it’s going to load it in a slow fashion if it’s loading it from the old format, but it will load it in place and then the data will just appear in WooCommerce in this example, as in the format that it needs to, and it can chug along as it goes.

James Kemp:
That makes sense. Do you think we could attribute a lot of WordPress’s success to the hook system making it, you know, so possible to be this backward compatible?

Gary Pendergast:
Absolutely. Without a doubt it is.

James Kemp:
Yeah. I think largely that’s the reason why.

Katie Keith:
Right, yeah. And people talk about open source, don’t they? But actually it’s the hooks that allow you. Nobody modifies WordPress Core, do they? It’s the fact that they can customize it from outside, which makes it unique. Actually, you can do that with sasses and things as well. So it’s the work from people like Gary that have made WordPress so extensible, isn’t it?

Gary Pendergast:
And that’s. That has always been, I think, certainly from my perspective, I’ve always considered to the Hook system to be one of WordPress’s greatest strengths. Like it’s the thing that has enabled the fantastic plugin ecosystem that exists around WordPress today. So I keeping that, keeping that highly maintained, keeping it performant is critical to WordPress’s continued success. And it also kind of goes back to that. How do you manage. The question of how do you manage backwards compatibility is you have a defined plugin interface. You have a defined interface, whether it be a plugin API, whether it be a REST API, whether it be a set of CSS classes I consider to be a programming interface. It’s something where you say, this is my promise to whoever’s going to be using it, to the plugin developers, to the app developers, to whoever’s going to be hooking to this. If you access or if you connect to WordPress in this way, if you connect to the software in this way, it will continue to work as you expect. And even if we need to do a whole heap of rewriting behind the scenes, whether it be for a new data storage format, or it be to do something in Gutenberg instead of the classic editor, or whether it be to rewrite how we handle emoji in comments, we can say as long as the programming interface that people interact with or that developers interact with continues to work as normal, it doesn’t matter what we change behind that.

James Kemp:
Yeah, I think that’s a really nice point. It also feels like a good wrap up to the conversation, I think. So I’m wondering, Gary, if you have any final advice to any developers that might be struggling with where to draw the line with backwards compatibility?

Gary Pendergast:
I think I always look at it as do I really need to break backwards compatibility here? Is there a fundamental need where there is no reasonable option that I could take? Actually if I put in an extra half hours work, I put in an extra day or two of work even, it would just keep working for everyone else. There’s an old filter that we need to deprecate, but we can always. Or an old short code that, that we need to deprecate, or even a parameter that we need to deprecate, but we continue to support it because it can just be Moved to the new way of doing things. It can just be what if we’re going to tell developers, hey, you need to change your software. So it sends us this, we can just do that, we can do the do the processing ourselves and nothing needs to change. Yes, we can recommend a new way of doing things, but the old way can kind of just keep working. So it’s really a question of if you can do something. If you make it backwards compatible, if there’s no real cost to doing it, or if there’s minimal cost and it would help your end users, it would help your developers immensely, it’s worth taking the time to do it.

James Kemp:
What do you think the cost would be? A measurable cost? Would it be like development time, performance? Like those kinds of things are the things to look out for? I guess. Maintenance.

Gary Pendergast:
It’s a hard thing to quantify because it could be a case of, well, we want to change our CSS classes so that they match our naming scheme. If we keep the old classes in there so that people who style things differently can keep styling it that way, then it will increase the HTML size by 0.5%, 0.3% point nothing really. So yes, it’s a slight performance loss, but it’s a clear win for people who’ve customized their things, whether it be plugin developers or site builders or site owners who don’t have to wake up the next day and go, why is my site looking busted? It seems like there’s always a scale of how long will this take us to make backwards compatible versus how much time and how much stress and how much frustration will it cause the people who are going to be affected by this backwards incompatible change. For every company it’s going to be different. It’s a case of figuring out what works for you economically. You obviously can’t spend thousands of engineer hours on the tiniest backwards compatibility bugs. As much as some engineers, not thinking of anyone in particular, like myself, would love to dive into those bugs and just do it. Even if it only helps one or two people. You do have to draw a line. I don’t know that there is a solid line though. Unfortunately, as much as I’d love to give it’s very much a case by case. Is this going to be easy to fix? Is this going to be hard to fix? Is it going to affect lots of people? Is it going to affect a few people? Is it going to be horrible for them to work to fix? Is it going to be fairly straightforward? Will they need to do ongoing work to fix it? Will it be a one time fix? Is it a thing that’s going to affect just only plug in developers or is it going to affect a whole bunch of site builders and site owners as well? Trying to figure out what that figuring out who’s going to be impacted and how much is probably going to give you the answer for whether you need to put their work into that backwards compatibility issue.

James Kemp:
Yeah, I think that’s a great summary. Well, thanks Gary. It’s been great having you on.

Gary Pendergast:
Thank you.

James Kemp:
Where can people find you online?

Gary Pendergast:
I am Pento. Basically everywhere. P E N T O or pento.net is my website and my blue sky and I will. I do need to blog a little more. I’ve been a bit lazy about that lately. But I’ve got a few ideas coming up that I hopefully should publish soon.

James Kemp:
Awesome. Thank you Gary. Thanks Katie.

Gary Pendergast:
Great. Thank you.

Katie Keith:
Bye.