Welcome to Press This, the WordPress community podcast from WMR. Here host David Vogelpohl sits down with guests from around the community to talk about the biggest issues facing WordPress developers. The following is a transcription of the original recording.
Powered by RedCircle
David Vogelpohl: Hello everyone and welcome to Press This the WordPress community podcasts on WMR. This is your host, David Vogelpohl, I support the WordPress community through my role at WP Engine, and I love to bring the best of the community to you hear every week on press this as a reminder, you can find me on Twitter @wpdavidv, or you can subscribe to press this on iTunes, iHeartRadio, Spotify, or download the latest episodes at wmr.fm. In this episode, we’re going to be talking about the backwards compatible compatibility connector with WP CLI. And joining us for this conversation is someone who knows quite a bit about WP CLI. We contributor for WP CLI of XMPP I’d like to welcome Alain Schlesser. Alain, welcome to Press This.
Alain Schlesser: David. Hello. Great to be here.
DV: So glad to have you. This is least your second time on this show. We’ve been asking you questions about WP CLI over the years and I really enjoy having you on. For those listening. WP CLI is a critical part of the WordPress ecosystem particularly around automation and workflows and other aspects of WordPress builds and what we’re going to be covering today is alongs thoughts on what has been accomplished with the BPCL AI over the last year. What backwards compatibility changes lay ahead. You know backwards compatibility is a huge part of the benefit of WordPress but also the challenge of software developers and of course, how those challenges are being addressed and the lion’s share a little bit about ways you can contribute to WP CLI towards the end. So I’m really looking forward to the interview. So on I’ll ask you the same question I ask every guest and I’ve asked you this before but I want you to tell it again if you could. Could you tell me about your WordPress origin story? When was the first time you used WordPress?
AS: Um, yeah, so my origin story is like most WordPress stories starts with with a smaller detour. I worked as a government agent in Luxembourg. And at one point I really got fed up with the politics of everything. I wanted to do something else with my life and trying a different career. And I decided to do freelancing development, because I had already done development before but never never did it as a freelancer. And when it was time to actually decide on what to focus on, I just looked at what was out there and what had had the biggest market share at a time. That happened to be WordPress as we all know. And I just started with WordPress development because I thought that it would be the easiest one to get clients as a fresh freelancer who starts from 0.
DV: I chose WordPress as the platform of choice for the same reason I remember a great my agency between Drupal and WordPress and I think at the time Drupal was the correct choice, but it wasn’t what people were calling about stuff like Oh, but this was 2010 You know, right at the cusp of custom post types and meta fields. And I’m just wondering when you were making this decision what year roughly listeners
AS: um, that was 2014 some of 2014 and I think WordPress was around version 332 or something like that. I’m not sure to be honest.
DV: So for you as a freelance developer, the benefit of custom post sites had already been released. And so you were kind of walking into this ecosystem and seeing those capabilities. A WP CLI was still another two years away though. So I’m guessing it didn’t fully answer everything you needed as a developer, but it’s great to see you managing that project now. Now, understand you do work with XMPP. And we’re tell me what XMPP does and what you do there.
AS: So X Delta P is an agency focusing on high performance enterprise grade WordPress projects. The main focus is on performance but non not only in terms of how fast the site loads, but also how well it meets your business. I’m working with XWP for two and a half years now approximately And during that time, I have been working on the amfa WordPress plugin and then the page experience for WordPress plugin together.
DV: they sound like MIDI projects. I’m definitely familiar with them I haven’t for WordPress, I haven’t played on page experience yet and I know you know XMPP we’ve had a few folks from XMPP actually on press this. They do some really really cool projects. It sounds like you’re getting to work on some of the coolest ones. And that’s awesome. Relative to our topic for the show, though, today, WP CLI from the high level, assuming there’s going to be some listeners that have no idea what WP CLI is I was wondering if you could frame it up so they can understand what WP CLI is.
AS: Yeah, sure. So WordPress has its admin back end where you do all the maintenance of the site where you make the changes where you configure the options. And WP CLI is a different interface for controlling your WordPress site. It is an interface that you can use from the command line. So you type commands in text form to control your site. It allows you to do everything the admin backend does and more. And by using the command line that happens to be a much more expressive interface than the admin backend you can solve for a lot of problems that are very specific to your to your use cases where there is no pre made user interface element in the admin back end. You can just mix and match the WP CLI commands to solve these problems anywhere. And then as a step further, anything you can do with WP CLI you can also put it into a script and ultimately, so you can automate all of your management processes and you can even execute them remotely. So there’s a lot of power by going to a text based interface and WP CLI allows you to do that with WordPress.
DV: Wow, that was really elegant. I think you have another career in marketing alone. That was a very nice way of framing VCI and remember to describe though it’s very good. Okay, so in my view, and I have, you know, a little cheat sheet for the timeline of key moments in WordPress history that I use when I hear people’s origin stories to like ask them about when they entered and what was going on at the time. And WP CLI is actually one of the key moments in WordPress history that I call out here. Back in 2016 in the timeline view, I maintain it so I think it’s super important. And I know that you know there’s this push to get more and more features and capabilities released but I’m just curious relative like to say the recent batch of releases relative to features or refactoring or whatever, what were you most excited about in recent releases?
AS: So one very exciting feature is the addition of global contexts which we have for for since YouTube was built there was always discussion about the context in which the tool should execute, if it should execute as a front end process or admin process or something in between. And all of the approaches always came with their own set of problems. So there was never really a clean solution. And the way the CLI executes by default is this weird mixture that is neither an admin process nor a front end process. For for historical reasons, but that means that some processes that check whether the current request is an admin request, for example, they will then automatically fail. This happens most notoriously with premium plugins and themes when you run to run the updates. So usually, you will see those updates they work in the admin backend. But with WP CLI, the admins are not the updates on visible or they don’t work as expected. That is because the custom logic that that manages these updates for each plugin, they check for the admin process to not slow down the front end of course, and that automatically executes WP CLI. So now with this new context flag, we can choose the context in which to run through and that allows you to switch the context into an admin context. For example, when you do a plugin update, and then all of a sudden all of the premium integrations they work just just as expected. This is very exciting. Sorry, this is not very exciting new feature that was it. It was built in collaboration with cloudways in that we’re currently testing in a phase where it is not on by default. So you need to manually this auto provision will become the default in the next iteration.
DV: Excellent, excellent. I can see why you would be excited about that. And I think it’s really clever that you were thinking like, Okay, is there going to be front end or admin, but really, by giving the developer the choice gives you the ability to kind of solve for, or at least the developer to solve for multiple use cases at once. I can see why you’d be excited about that. particularly thinking about that hero use case and not being able to render updates for premium plugins. It’s a pretty common use case. And imagine many others cascade out of that. I do have some questions, though, kind of about, you know, kind of breaking into the roadmap and thinking about backwards compatibility considerations. But we’re gonna take our first break. We’ll be right back. Time to plug into a commercial break. Stay tuned for more pressing this in just a moment. Everyone welcome back to press this the WordPress community podcast I’m giving Omar, your host David Vogel. Paul. I’m in the middle of interviewing a launch lessor about WP CLI and some backward compatibility connectors. Alone right before the break you were sharing about your favorite feature, or WP CLI recently which was the global context switching the the flag for whether it be a front end or admin process. And I thought that was really clever. Anything you wanted to add to that before I got to go into the kind of future roadmap and backwards compatibility.
AS: Yeah, I wanted to add I’m really looking forward to that because that is probably one of the most frequent support requests that WP CLI is getting. Why are the updates working in WP CLI when they do in the admin bucket?
DV: Yeah, that that premium plugin repo process thing rears its head and a lot of different places I find in WordPress but yeah, I can see where that being a core capability where people are like, Why the heck doesn’t it do this? It’s so basic to WordPress. That’s amazing. As you think about the future of WP CLI, I want to I want to bring in backwards compatibility considerations in a second but what we like the top two or three features you’re excited about for the future.
AS: So what I have been planning for quite a while now is to completely overhaul the scaffolding of WP CLI. The scaffolding command is a command that uses templates to let you generate code like generate an empty theme generate an empty plugin. And I wanted to complete the Super Bowl it to be less of an Getting Started tool and more of a constant development help like it is in the Laravel space with the autism command where every concept that is used in WordPress development would have its own command to generate the canonical version of it. And that would not only drastically accelerate development, it would also be a tremendous learning tool and help shape the overall quality in the WordPress space.
DV: That one does sound really nice and I can also start to imagine where backwards compatibility might be playing friction for Is there any other like roadmap features? That was a pretty good one any other Do you want to add?
AS: There’s also work currently being done on a rewrite of the Profile command which is still a third party command. It is not bundled yet. But as soon as that rewrite is finished, I also want to bundle that command so that everyone has an easy way of profiling. The website requests and seeing in what actions I need watch what filters the main performance bottlenecks are stuck.
DV: That’s another good one. Okay, so you’ve got two juicy roadmap items. I’m sure more than just that of course is you’re thinking about the future and other contributors are thinking about the future. But obviously, backwards compatibility is a big thing in WordPress. So what considerations are weighing on your mind as you think about your ability to deliver on that roadmap?
AS: Yeah, WP CLI is the way it works, its internals work is directly tied to the backwards compatibility policy of WordPress core. Right now WordPress Core is still supporting a minimum of PHP 5.6 WP CLI does so as well. And there is a policy for WP CLI that whatever the minimum of WordPress is, whenever that changes. WP CLI will delay that change for at least a year to give everyone the chance to use WP CLI to migrate from the old sites. To the new sites. And because WP CLI is usually the tool that’s used for migrating away from old sites, it needs to still work on exports folks. So WP CLI can never lead the the approach in supporting newer versions of PHP and things like that. Because it would then fail its main purpose which is to get access to the old sites and allow you to put the move. So in that regard, it’s really tough to to do the development in WP CLI in a way that keeps the code fresh and maintainable but still sticks to this very low PHP minimum requirement with WordPress core, which is causing more and more troubles
DV: when they will or do you know when core would raise the minimum version number of 5.6. Next you have A B is it because 5.6 is quite a few variations past and it’s difficult to maintain that far back do you have a bead on when more recent versions would would be the minimum?
AS: I honestly cannot tell I invested a lot of work into the sub happy project where I have a lot of mechanisms to make it technically feasible for WordPress code to move quickly towards newer versions of PHP at this point all all of the technical prerequisites are there. It’s just a matter of taking the decision. And I cannot say when that will happen. Because it was already planned for quite a while but so far nothing has happened yet.
DV: And so from the moment it happens though you have a year after that when WP CLI can raise its minimum supported PHP version. Are there other parts of the software stack or languages or whatever that also kind of weigh down as you think about your ability to deliver on the roadmap, or is it mainly PHP
AS: is it in terms of backwards compatibility? It’s mainly mainly php. The WP CLI is built in PHP and in gherkin and in a shell scripts. So gherkin is a testing language that is not really an issue and the shell scripts they haven’t changed for 20 years. I don’t think there will be problems anytime soon.
DV: What is the impact like obviously, keeping software compatible with very old versions of PHP is challenging but like help me understand like, how is it challenging? What is it trade offs you have to make because of sticking to support for 5.6
AS: supporting five on six by itself is not that big of a deal. It’s just one version of language and it was an uglier language. At that time, but still a very usable one. Problem is if you also want to be able to run on the newest version of PHP as well. So you need to cover that entire spectrum. And as long as we’re not raising the minimum version, we’re just adding more and more versions that you need to support and with PHP, but now the cadence is that every year there’s a new major version that comes out so they calling it minor versions, but in terms of features they are major versions, and the last few releases have seen bigger and more radical changes in the language. And right now it’s really hard to build more low level, more low level constructions in a way that it works both on five, six and on eight two at the same time and it will only get worse over time. And what what adds to that is that the tooling that you need to work in PHP, you need to run unit tests, you need to run functional tests, and so on and so forth. All of this tooling, it sticks it sticks to the PHP cadence for something with PHP unit. For example, it is very hard now to write your tests in such a way that the tests themselves work across all of the versions of PHP unit. You need to use to cover all of these PHP versions.
DV: Okay, so it’s the weight of all these multiple cohorts, if you will, PHP types unit TAs, and then I’m guessing you’re also probably struggling with you know how you’re using functions in different versions as new functions become available and are deprecated. And it sounds like the collection of all that extra work is is friction that weighs down your ability to deliver new features does that sound fair?
AS: Yeah, um, there’s also PHP is getting more and more strict. So where before when you needed to map multiple versions of PHP, and you could just keep your code vague so that it didn’t hit any of the problems from one version or the other. That is getting harder and harder now, because HP throws loads of notices and warnings and deprecation issues for the most. For the tiniest details by now, and sometimes that means you create a function that you need to run build multiple times and have a mechanism to pull in the right version of that function, depending on which version of PHP you’re running it, which exponential increases to the maintenance effort of everything.
DV: Yeah, that totally makes sense. All right, well, I want to kind of start to explore a little bit about, you know, how you dress it and maybe even your thoughts on how WordPress in general can do better and, you know, dressing backwards compatibility, but we’re gonna take our last break, and we’ll be right back. Time to plug into a commercial break. Stay tuned for more pressing this in just a moment. Well everyone welcome back to press this WordPress community podcasts on W EMR. We’re in the middle of talking to a launch lessor about the backwards could habitability conundrum with WP CLI I should have chosen a less tongue twister title for this show. But here we are. A long it’s a good book. Yeah, like it I have to say three times fast before it’s over. But okay, so before the break you were talking about kind of this exponential maintenance issue as you start to deal with with multiple versions of PHP and I don’t know if this makes you feel any better alone, but like 100% of WP engines customers are patched in modern versions of PHP we forced those updates, but obviously not everybody does. Right? Not every host does not everyone that hosts a website does this things and so this creates just oshin set asides out there and out of date, soft PHP versions or even WordPress certainly plugins. And so, this this nature of WordPress you know, in this this idea of backwards compatibility is part of WordPress is strength in its popularity does matter if I do set it yourself. WP CLI has to lag because it’s doing a job for people that need to upgrade. And so that’s that’s a good thing, right? That’s a good part of that dynamic. But I’m just wondering on what your thoughts are around how either WP CLI or WordPress as a whole could improve on keeping those good parts and maybe avoiding more of the bad parts like the exponential maintenance requirements of backwards compatibility. What are your thoughts on that writ large?
AS: Yeah, I think right now we’re at a point where WordPress is doing its user base a disservice by sticking to that very extreme backwards compatibility approach that it has right now regarding PHP, because all signs seem to be pointing towards the fact that we will slowly enter the phase where we cannot possibly keep WordPress running on the latest versions of PHP anymore, which is a real problem. And we we would need a lot of time to work on the compatibility because the changes there as many more changes happening in PHP nowadays. And the only way to solve this is to have a continuous approach of adapting to the PHP cycle it can lag behind PHP, but it cannot possibly be having lower velocity than PHP that will just make the problem worse and worse. So it needs to match the velocity of PHP, even if it hasn’t all two year lag behind it. And then we need to ensure that we, we can keep everything to the tooling, the testing, tooling, and so on, up to date enough so that we can always work on supporting the latest version of PHP, because as it looks right now, PHP nine will probably be the first version as it looks now that WordPress will not be not be possible to adapt to if we don’t change the approach. Hopefully, okay, yes.
DV: I was gonna say it sounds like this exponential problem that you’re dealing with on WP CLI is kind of compounding, if you will, throughout WordPress, and it’s kind of rearing its head if you will, with like the challenges you mentioned for PHP nine. And so that makes sense in terms of like this, this force kind of moving WordPress to have to be better about maintaining are matching that velocity so they don’t fall too far behind services and fall too far behind in PHP versions. In the last couple of minutes here, I know that there’s a lot of challenges with backwards compatibility. I know you’ve been delivering great features and you want to deliver more. And like I’ve seen a rush of contributors to Gutenberg and like, I just feel like this I would not do a service unless we did WP CLI a little love in this podcast for contributors. How can people contribute to WP CLI to help keep this really important part of WordPress alive and driving?
AS: So first of all we have on the main wordpress.org Slack team. We have a CLI channel. So you can just hop on that channel and say hi and ask questions. And if you want to get started, there’s always people that are happy to help you onboard into into WP CLI contributions. There’s also the website make wordpress.org/cli which is the entry point for all of the documentation and links to a good first issues and so on and so forth. And then ideally, you would join one of the webcam contributor days that are happening now again. I’m really glad about that. Because during these contributor days, people can actually help you get set up with your own machine to do proper local development. This will stop the piece live is because sometimes the onboarding is the most difficult hurdle that people have to install.
DV: Yeah, I can attest to that. A few friends who had gotten into contributing and what they overcame. I know there’s quite a few people out there that have little courses and instruction, of course make that WordPress has stuff around that too in terms of documentation, but that’s a really good point and contributor days helping with that aspect of that. I also liked how you called out joining the Slack channel. It kind of reminds me of how Mike Liddell got involved with WordPress answering what I’m commenting on a Mac Mullenweg blog posts, but that notion of contributing in a social context leading to something greater. Well, this was super cool along. Thank you for joining us today.
AS: Thank you for having me.
DV: So glad to have you here. If you’d like to check out more about what Alon does that too. Please visit make wordpress.org and look up the WP CLI site or find him in wordpress.org slack and the WP CLI channel. Thanks everyone for listening to press this the WordPress community podcast on WMR. Again, this has been your host David Vogelpohl. I support the WordPress community through my role at WP Engine. And I love to bring the best of the community to you here every week on Press This.
