Talking Drupal #369 - PHP End of Life

• PHP End of Life (EoL)
• Why does PHP go EoL
• When will php 8.0 EoL
• How are dates scheduled
• Who is in charge
• How do you prepare as a developer
• How do you prepare as a platform
• Acquia is supporting for one more year
• Pantheon has no forced upgrades
• How do you find edge cases
• Do you speak with PHP maintainers
• What are the changes to be excited about 7 > 8
• For D7 this is challenging, any tips?

Transcript are generated with AI and lightly edited, therefore will not be 100% accurate.

John  0:06  
This is Talking Drupal, a weekly chat about web design development from a group of people with one thing in common. We Love Drupal. This is episode 369. PHP End of Life. Welcome to Talking Drupal. Today we're talking about PHP end of life with Josh Waihi  and Matt Glaman. Josh was introduced to Drupal 5  and 6 in 2007. He helped maintain the postgres SQL database driver in Drupal 7  before joining Aqua from New Zealand in 2014. He specializes in large scale Drupal deployments across news and media, public sector and international sporting events. Definitely going to have to ask you about that. Today, Josh focuses on Drupal 7 end of life and Acquia's headless strategies. Matt has been using Drupal since 2012. He currently maintains PHP stand Drupal, and is the primary contributor to the Drupal Rector. Two tools which are used in the in Drupal is major version upgrade process. Josh and Matt, welcome back to the show. And thanks for joining us.

Josh  1:24  
Glad to be here. Thanks for inviting me.

Matt  1:26  
Thanks for having us.

John  1:29  
I'm John Picozzi a Solutions Architect from EPAM. And today, my co hosts are Nick Laflin, founder of enlightened development.

Nic  1:38  
Good afternoon, everybody a little bit later in the day. So you might you might hear is slightly different energy from John and I  today

John  1:46  
A slightly more bubbly energy in my case, apparently. Joining us for her second appearance Tearyne Almendariz a developer advocate at Pantheon and lead of the Drupal Diversity and Inclusion Initiative.

Tearyne  2:02  
Hey, y'all, good to be back.

John  2:05  
Alright, we didn't scare you away. So that's always that's always a plus. So this week, we have some an update from Ned camp from Steven.

Stephen Cross  2:20  
Hey, the New England Jubal camp is happening on November 18 and 19th in Providence, Rhode Island. Nick camp is a two day event. Friday is our training day with half and full day trainings. Saturday is our session day with 20 sessions and a keynote. Our keynote speaker is Kaleem Clarkston. He is a remote work expert. And we'll be talking about career contributions and how they and how community can change your life and it did it for him. I training sessions, our training and sessions cover a variety of topics, including accessibility, Drupal, 101, front end decoupled career development, and much much more. We also have some extras here. So if you come to Ned camp, we have a social event on Friday evening, hosted at booth, our event sponsor. We also provide breakfast, lunch, and an after party on Saturday. And yes, we have some T shirts. So come get your T shirt. We also have a contrib day on Friday, so don't miss that as well. You can visit Ned camp.org to register and learn more register for training and register for sessions. Hopefully we see you there.

John  3:38  
Stephen, thank you for that update. And we are looking forward to being in New England in November. Let's move on to our module of the week. Josh, you can tell us all about HTTP cache control.

Josh  3:52  
Yeah, so this is a little bit of a shameless plug. Since I wrote me love those yearr. But it kind of came out of a need to have finer grained control around case instruction to the CD ends and varnish layers in a case strategy. By default, Drupal will just publish a max age cache control header, and a varnish a CDN and a browser will all obey that instruction. And they'll all have the same amount of cache lifetime in the same locations. Now, if you've ever used something like the purge module before, it will tell you that the best practice is to have a really long case lifetime, something like a month or maybe even a year. The problem with that is if you tell a browser to cache for a year, then it won't come back to your website for new content within that time. And so if you're a news and media site, for example, that business depends on having fresh content multiple times a day. You can't invalidate the cache at the browser that quickly becomes a real problem. So the HTTP cache control module allows you Do still sit long case lifetimes, at places where you can control purging like a varnish layer, or even a CDN layer, while giving the front the browser a much shorter cache lifetime, something more akin to the session lifetime, like five minutes or something like that. So it also supports S max age, which is a part of the HTTP RFC standard, but also proprietary instructions, like for specifically for fastly, or CloudFlare, or Akamai. So you may want to check it out. You can also cache add caching headers to non 200 requests, like redirects, and 404s and things like that to give some extra application performance to your Drupal site.

Nic  5:45  
I will definitely have to check that out. That has been something that's been slightly same issue on a lot of sites in the past. So it'd be nice to be able to say, hey, you know, browsers should only cache this for x amount of time. But varnish, you can cache this as long as possible. I mean, this, this might become so become a personal favorite utility module for some of these sites that you have to have that long cache time.

John  6:15  
Kind of makes me think, like, we may need another show about caching. I feel like caching is happening at so many levels nowadays that you got to kind of control it everywhere, right?

Josh  6:28  
Yeah, it's a it's a whole subfield for sure, I actually built the caching strategy for the Australian Open, Grand Slam tennis event. And so that has a lot of traffic, especially at the beginning, they also want to push very fresh content. So as plays happen on the court, that data is propagated out to the website. So we have to have a combination of both WebSocket data being pushed, but also purging capabilities, we want to have very high control. So we have something like a 99.99% cache hit rate. Even though Drupal 7 this content, and the contents change very regularly. But what a part of that strategy is actually having very strong control around varnish, which I would consider the local cache, and then having a short lifetime, actually at the CDN, so that it revalidate at the global nodes more regularly. Because one thing that most people don't think about when you think about purging with a CDN is you can't test that all of the nodes in the CDN have actually purged. So you kind of trust that that's the case, but you don't actually know it. And that's really important, or it really matters in a global sporting event. So we, we came up with strategies, and we're happy to talk about this on a different show about revalidation at the at the CDN, and then purging at the local cache at the varnish side and using that as a way of maximizing your performance.

Nic  8:05  
Interesting.

John  8:07  
imagine I just had this like idea in my head of like going to a page or sporting website and having like the score be like in your favor on one page and then not in your favor on another page and just being like, what happened.

Josh  8:22  
It's crazy what we were up publishing updates on the score faster than they were broadcasting them on TV. So have their apps open and watching the game at home and get updates on their phone faster than they would see the place. They'll know like the point was scored before the server was made.

Nic  8:43  
pretty hilarious.

John  8:45  
So make sure your caches are in check people, Words To Live By here. So let's move into our primary topic. Now. The title of this show, PHP End of Life is a little alarming. To be clear. PHP itself is not end of life, right? We were all aware of that. Somebody's going to send a message like go God. Now you're okay. PHP. 7 is end of life and to be more specific, its end of life at the end of Well, next month, right? November, I think 28th is the date. Josh, can you can you correct me if I'm wrong? And then kind of explain a little bit more about PHP 7 end of life? Yeah,

Josh  9:35  
I mean, it's, it's pretty much right. It's most of PHP 7. Already is end of life. When you think about it. Like it's really like the last release, right? Like, which is 7.4. And more specifically, is reaching its end of life. And that is, I guess, the end of life of community support. So yeah, they've already finished feature development. sent to a bug fixing addressing that long time ago, about a year ago. And it's really just been doing security fixes by the community. That's the part that's reaching end of life in end of November.

John  10:12  
And that's kind of like an important thing, right? Like security updates will not will not continue after November. So like, if you're still using it, you're pretty much on your own to kind of like, forage for those security issues and patch them and update them yourself. Right?

Josh  10:28  
Yeah, that's right, you're at risk. So today, if there is a security vulnerability, identified in PHP, 7.4, or in PHP in general, right, so often, vulnerabilities are reported to the community. And there's a Drupal, by the way, has the same kind of workflow. So the vulnerability will be published to the community or disclosed, perhaps the better word to use to the community, the security team will review that, and then they will address it. And they will look at that typically, across all of the supported versions of PHP, they operate at any given time. So obviously, they at some point, they have to limit how much effort they had costs, and then providing security support to all the different versions that are available at any given time. So they have the security coverage for supported versions, which basically means when that vulnerability comes in, they will look to only apply, or at least review the security vulnerability as it pertains to those supported versions. If that supported versions affected, it will also get patched. And then a new point release of that version of PHP and its context will be made available. So when it falls out of support, now, if a vulnerability is reported, that community won't check to see if it's, if 7.4 is affected by that vulnerability, and so what can happen is like, if you're a malicious attacker, you can do that checking yourself, you can check to see if a report of vulnerability at a point release of say 8.0 is also a vulnerability of version 7. And then you can go and look for all the applications that have PHP 7  and use. And then you can look to exploit that vulnerability and attack them. And that's kind of a risk that you you run. So a way that attackers would do this a real easy way, right as HTTP headers, nothing. So quite often PHP applications will disclose the version of PHP they're using in the response headers. And then that becomes something that is easily detectable and applications can become vulnerable to that if they don't keep up to date with their versions of PHP.

Nic  12:46  
And so So the definition is similar to the way that the Drupal community uses it, you know, Drupal 8, one end of life last year, it's no longer supported the security releases. I think one of the big differences, though, is is the size of the footprint, I guess you'd say, you know, PHP is used by way more sites than Drupal is used by sites, right. So the attack surface or the benefit for somebody malicious going after something in PHP versus something in Drupal is much higher. So when when this is going to end of life, you know, it's I think it's much more critical for you to look at upgrading that. I mean, it's always critical to update anything that's end of life, because it's no longer a security coverage. But the amount of time it takes for somebody to find that type of vulnerability is going to be lower for something like PHP.

Tearyne  13:38  
So Josh, why does something like PHP go end of life? Like, why are we not going to like PHP? 7.5? Like, where are we going to 8? What determines the end of life? Sounds like security's involved, but can you give some more details?

Josh  13:53  
Yeah, I think, you know, PHP, I think follows a similar semantic versioning system as Drupal does. So the major version releases represent brand new features that are being introduced, that aren't necessarily backwards compatible. So maybe it's a little bit different to Drupal, where we actually do have a backwards compatibility roadmap. So in PHP, one major release will like your announced deprecations. So 7.4, had a series of deprecated features from 7.2 or 7.3. But they would still work on 7.4. When you move to PHP 8, they're not going to be working anymore. They're now removed functions from the framework. And so you can't just necessarily switch your application to PHP 8, because if you're using those deprecated features, then you know your your site's going to break. So a major version change represents breaking changes, and I guess in that way, Drupal has the same thing, right, we have deprecated APIs are deprecated in Drupal 8 and no longer available. For the Drupal 9, we have deprecated API's and Drupal 9, they will no longer be available with Drupal 10. So the same kind of paradigm exists in PHP. And so that that major version shift represents a bunch of deprecations. And so you need to, you need to make sure that your code is ready to support that. Fortunately, for all of the Druple  supported versions, so that's Drupal 7 ,Drupal 9, and Drupal 10, and when it's released, or have PHP 8, compatibility built into its core. So yeah, that means it's kind of one checkbox checked off in terms of your readiness to go to that next version. But that's not it doesn't end there. Right, there's contrib mod code that you use, and you need your maintainers to help you get up to PHP 8. And then there's custom code that you wrote. So if you wrote a custom module for the for the customer, if you wrote a custom theme, those sorts of things needed component as well.

Nic  16:03  
So, Matt, when you've done a lot of work in the community around kind of preparing for end of life for Drupal itself, I'm curious about, you know, you've done any of that work around PHP, end of life. And once we move to PHP, how much time do we have before the next, the next release?

Matt  16:25  
So last year, I spent about two months on this because PHP, a compatibility was a big deal, like, I was using PHP 8, but most of the Drupal modules are still like on PHP 7, because they're always targeting the minimum Drupal, PHP version. PHP Stan has a way to set your target PHP version. So you could be on PHP 7.4, and configure PHP y, and say, I want PHP 8. Now, there's a caveat here, because that's based off of known like function signatures and PHP internals, not necessarily what your code runs. And as I said, I spent two months on it, I looked at a lot of Gabor and made a list. And I went through a lot of that list. And compared to what PHP, Stand could detect, I opened issues, the maintainer was nice enough to help go through that giant mess I made and identify what could be detected or not. And I'd say about 50% of things could but that was like core internal functions. And there's really weird ones about passing closures too. I call user func array. And I spent three weeks trying to figure out how to do the static analysis on the closures there to find for compatibility issues. But it's not perfect. But luckily, there's a solution to that. And it's run your code on PHP 8 itself with your tooling, instead of trying to do it on 7.4. But let's say your small dev shop, the one benefit there is let's say you don't have a robust continuous integration environment, and you just have PHP 7 on your local, you could try to get PHP Stan to do some basic analysis of PHP 8, and find out where it crashes before you actually try to run it on phb 8.

Nic  18:06  
Well, that actually brings up one of the big questions I have, because I have a client that approached me maybe four months ago and said, We're looking we're looking to move the server to php 8 to prepare for the end of life. Can you do an analysis? And so the first thing I did is run the PHP standard, like, will this run on PHP? And the short answer is it comes back and says, No, this will not run on PHP 8                                                                                                                                                                     and it gives you a giant list of issues. But I what I found is especially with composer with all the dependencies in Symphony is that a lot of the things that it would say, like this project won't run on PHP are dependencies that are three levels down, that are imported by core, and just code pathways that never get hit. So I'm curious when you're when you're looking at this, how do you determine I mean, and we upgraded the site locally to PHP 8, run a bunch of tests, everything works like the site doesn't break. But we're also not like able to invest in fixing, you know, sometimes use third party libraries. It's hard to get them to talk about that. How do you handle that?

Matt  19:13  
So I had this because before I joined Acquia, I was on my own for a year doing independent consultant and I had a handful of sites that I upgraded from PHP 7.4 to 8  like Laravel and Drupal. And one of the things I added to our CI is a literally the Job said "composure, why not php 8"? That was it. Same thing, like if you're using if you're preparing for your Drupal 10 upgrade, you should do the same thing for guzzle, like why not? guzzle 7. So that way, my CI we would allow it to fail, but we could just go back and let you know, the remote machine tells us why we can't upgrade to PHP 8. And as we start working through dependencies, we gotta identify why does this just like how in Drupal we have the this module doesn't say it's ready for Drupal 10 yet because it hasn't been verified. And that info yml updated. Guess what the entire PHP community does the same thing for composer.

JSON. So it's not a unique problem. Like, when we do this major upgrade, it's a software engineering problem. Like it's everywhere all the time.

Nic  20:17  
Yeah, absolutely. Well, and it even goes a step further. For example, I know that when I ran that, that test in this specific instance, it showed some, some functions that were deprecated in PHP 5.6, and were removed in PHP 7, and the site had been on PHP 7 for four years at this point, something like that. So. So it's like, it's like, how much does... I guess the question is, you know, should you be aiming for a clean PHP standard bill of health before you upgrade? Or are you trying to fix some of the major stuff, you know, we rely on from that report.

Matt  20:56  
I treat it like a treat code coverage. I love to do code coverage, and I shoot for whatever makes sense, right? Like, does 60% Makes sense? Why looking at the coverage and like that hits the code? Oh, well, my my edge cases and exception catching didn't get caught? Well, I don't care about getting 100% coverage of that. But like, look at the report. In that case. There's, there's like functions deprecated in PHP 5, and they didn't crash and PHP 7, you have dead code? Do you need to worry about ripping out that dead code right now? No, don't, you don't have to, you can just make a note of it like, alright, write it take it? Well, obviously, something's not running here. That's either a bug or a refactor it away. Just Just look at it. And that's what I always recommend when you're starting run it PHP 7, level zero, it's got zero through 9, a lot of different configuration options. But basically, level zero says, do I run? And if it runs without throwing any errors? That's a thumbs up, right? Because it's not doing actual, like analysis of your code to see like, how well things are written or if there's bugs. But at that point that the question is, Can PHP Stan run on your code? And if it doesn't crash or throw errors? That's a good sign like you're the next step there.

Nic  22:08  
Interesting. Okay.

Tearyne  22:12  
I have another question about end of life and all these dates, they can feel kind of arbitrary. If you're on the outside looking in or at a small local government where you're self hosting your server? How do they determine the end of life dates? Are they following the schedule? throwing darts at a board somewhere? Like how does that get picked?

Unknown Speaker  22:31  
Yeah, so there is a structured schedule for PHP. And they've been doing that like scheduled release system for way longer than Drupal has. So it's very well defined when the releases will happen. And they've been doing that really consistently. Basically, from the point of a release, it will go to years four through a, like a supported system, that's where like, they'll do active support. So if there are bugs in that version, they'll also fix the community, the PHP community will release fixes to bugs in that pit version of the PHP language after that two year cycle, and then moves into security fixes only, and that's extended for a third year. So a version of PHP that you adopt, you can expect to get a few adopted at the very beginning, you can expect to get three years usage out of that out of the standard PHP community support model of it, two years of bug fixing, stabilization. And then a third year for security fixing the release schedule for versions of PHP happen every year. So even though there's a three year lifecycle, there's a new version every year, which means at any given point in time, there are three versions of PHP you can choose from. So depending on where you are in your project lifecycle might predetermined, but the best practice would be like, if you're on a Drupal 9 project, right now, you really want to be trying to build that in PHP, 8.1 Because then when that goes into production, you've got two years of PHP 8.1 before you have to get off of PHP 8.1. And that's just where we are in the lifecycle. If you're going to launch like next year or something, and maybe like PHP 8.2, you know, if you're to start a new project, you might want to be looking at that so that you can maximize the amount of time that you get around with it. The flip side of that, right is like anything is released new that has bugs and so the earlier you adopt it, the less stable it could be. But of course, people are still on PHP 7.4. It's the last of those three versions that are available right now. PHP 8.0 is nearing its end of active support in PHP 8.1 is halfway nearing halfway through its active support period. So what we see some happens sometimes is customers will We'll be on one version, and then they'll wait. They'll skip what the next version and then they'll jump to the one after. So PHP 7.4, users might want to think about going to PHP 8.1 straight away. That way, they're not jumping to a version of PHP that only has a life, one year of lifespan left. And they have to go through that same work this time next year to get off of PHP 8.0.

Tearyne  25:29  
Via Android phones life cycle, so thanks for that.

Nic  25:36  
I think it also depends on your hosting platform, you know, in general, it's very different. Like if you're an aqua, or Pantheon or Platform sh is, in most cases, it's like, fairly straightforward to change that and you have like a dedicated place to test it. If you're self hosting, or you get something like, you know, you need to sometimes you need to compile PHP yourself, or you need to build it yourself, like that upgrade process can be very different depending on your hosting platform.

John  26:05  
Why don't you have the ability to use like a local environment to test that?

Matt  26:11  
That's not, it's not just testing. Remember, it's deploying it, I kind of I brought up my those clients I worked with, they were all easy two instances on AWS, that somebody built by hand, and then I converted to be managed with Ansible. And still, I didn't trust just changed my Ansible playbook to say, should use PHP 8.1. Like I tested it, like three times on a staging server, and then sat my fingers crossed go into production, because it wasn't even containerized. I just had a hope that sudo apt, blah, blah, blah, whatever Ansible did worked. And everything was okay at the end.

Nic  26:47  
And if you're an easy to, usually people are using AMI is at that point. And, you know, it depends on your platform, it can be a big task, just update PHP, or even if you're

Josh  26:57  
using Docker containers, right, like you're still one way or the other, like most people are dependent on somebody to give them PHP, whether that's a hosting platform, like Pantheon, or Acquia, or its AWS, or it's a Docker container. And so you have to shift the environment that you're around in one shape, or form. And make sure that your hosting provider of choice can can also host that for you.

John  27:22  
I would just like to say I am a firm believer in testing thoroughly. So like test on an environment test locally to test as much as you can. I'm not saying like, Oh, if it worked for me locally, and then just going that's not a good idea.

Nic  27:37  
So So you, you mentioned Josh, that they've been following a schedule of PHP and of life and support for quite some time. Who is day Is there, like there's a PHP community, but is there like a group like the Drupal association that manages it? Is it just a group of couple of people? Is it the community at large? who's managing this support?

Josh  28:02  
Yeah, so the community support really is the community. So the public issue queue bugs.php.net, where you can log issues. And just like we have the issue queues, Drupal, you can the same kind of thing exists except everyone there talks in like C rather than inside PHP. And in that, community bug reports, they'll have maintainers, come along and look at patches, or write patches, and then commit those things to the, to the branches, same kind of paradigm that we would do or see inside of PHP, sorry, inside of Drupal. So the the those maintainers, then maintain the release schedule and release those things. And I believe there is a security security team like similar to how we have the Drupal security team that were released that would manage disclose vulnerabilities that perhaps aren't public on the issue queues just yet. I would also add there is they we have the Drupal Association, the PHP community have a PHP Foundation, which is a little bit different to the association. I don't think they're about maintaining the infrastructure of the community, but more about Ensuring the Continuity of Your development. So they are, you know, they are gonna go to people who are dependent on PHP, like Acquia, and we put money into the foundation. And that pays for maintainers to continue working on the language and ensure that there's a future

John  29:45  
and that foundation is relatively new, right.

Josh  29:48  
Yeah, yeah, It only came up last year. I want to say, like, I don't know, I don't know exact timeframes, but it was, yeah, again, it was just to make sure that these people still you know, were able to focus essentially full time on the language and they didn't have to, they'd always have job security on the sentence to work on work on it because there was so many companies in the world that were dependent on it.

Matt  30:12  
And I want to add one thing, the PHP, like, language has its own release managers as well, like Ben Ramsay, which you might know from like his you UID Library is the PHP 8.1 and 8.2 release manager. So like how Drupal has XJM who's the release manager for Drupal 8 or 9  and 10, they also have release managers that are assigned to each miner release, because I believe there's a different release manager for 7.4. I don't know that whole process, but I know that specific miners even have their own release manager. And they have different ones between them as well.

Nic  30:51  
Interesting. Okay,

John  30:52  
man, that's probably a wicked low stress job, huh?

Tearyne  30:56  
No pressure.

Alright, so we've been talking about the end of life, we've been going around it over and over again, as a developer, how do you prepare for end of life? Is there like a PHP will that gets written up? Like, what, what did we do?

Matt  31:13  
I think there's a first step to this. And it's explaining to your customer, why they should pay for maintenance, right? And the best example I've come up with is homeownership. And a lot of my clients, I was able to like, Hey, do you remember your dad going outside and like painting the siding of your house to reseal the paint, so that way, the wood wouldn't rot, you do maintenance on your home, you have to do maintenance on your software. And I think that's the first step in preparation is explaining that. This is just how you keep things running. And usually the house analogy was the easiest thing.

Tearyne  31:50  
I'm a huge fan of metaphors. I appreciate this. That's great.

Josh  31:53  
I think some sort of.. like you have to convince the customer to prioritize the time, right. And obviously, an impending deadline is a part of an incentive structure. But yeah, if it if it depending on the level of effort as well, they need to make sure they've got budget aside and they're willing to stop other business priorities to address this, like most maintenance, they like to think of as like a a cost of operational expenditure as in something they can forecast that's ongoing annually that they continually to put into so regular point releases happen regularly enough that you can put those things into regular maintenance cycles. But this is like a blip on the on the budget chat for them right there, you need to put a bit more concerted effort into it, maybe you need to, you know, arrange UA T testing. And so it's not just developers that are impacted by this, there's other business impacts that that need to support the upgrade effort. And so making sure that they're prepared for that also comes from giving them lots of lead time to make sure that this is a priority. You know, it's a, it's also an immovable thing for many customers. So they have to orient their business around this logistical challenge and, and moving forward on it. Just gonna kind of go back to the strategies for helping developers prepare for it. So I know like Matt's got some to some tooling around things like PHP, Stan, that can help detect incompatibilities. Obviously we also discussed, a composer has a bunch of built in things that help make it easier by ensuring your dependency libraries are supposedly ready for PHP 8. There's also especially if you can generate track traffic to your solution. So what I've advised customers doing in the past as they would go and do a regression suite test on their PHP 7.4 site, and then have the developer go and look at the Drupal watchdog logs, specifically for PHP logs like notices, deprecation warnings, that sort of thing on PHP 7.4. Now, ideally, you would get rid of all of your PHP notices, warnings and errors. But it's often something that because it's hard to kind of justify doing that to the customer and getting time to do it, it gets left in there and it ends up as operational noise and production. That's really bad for PHP upgrades. Because if you don't listen to that noise, when you switch from one version to the next, you'll get a different type of noise. But if you're used to just ignoring the noise, then you're not going to see them, right. So that's why I like recommend doing a regression test on the current version of PHP you're using and then capturing the noise as a profile. So, you know, given the week it took them to do the testing that generated the Types of notices, warnings and errors. And then you flip your version. And then you go into the regression testing again. Now some things might just start breaking because things aren't there anymore. So that's a like really clear thing that the regression tests will pull out. And so we need to fix the broken stuff. But then you can also see things that are like under like that answer obvious, like the the profile of word warnings, notices, and errors will change. And then you can analyze that noise and say is, is that change in noise, indicating a different issue, you know, like, sometimes is a construct that changes that changes the way that PHP behaves. So now you end up with a different outcome that didn't get picked up in regression testing, but could mean a significant altercation in your business logic. So that's another, like an analytical way of addressing that.

John  35:54  
It's interesting, I got another analogy working through my brain right now, where it's like, you know, you hear that a hearing noise in your car, right? And it's like a little little like ticking noise. And you're like, ah, that'll be all right, we'll just whatever. It's just, you know, kooky, and then all of a sudden, it becomes like a large grinding noise. And now you're now you're in trouble, right? I will say, Drupal watchdog log errors, PHP notices and stuff, drive me nuts. I always look, and I always have them fixed. Because they they drive me nuts. And I know that someday that's going to be a problem. What question to piggyback off the developer preparedness, right. And, Josh, I think you touched on this just a little bit, you know, obviously, routine maintenance is important. But I'm wondering, like, What's the timeframe? Right? Like, if you know, hey, PHP 8 is going to be end of life next November, right? What's the timeframe for your development team to be like, starting to plan to for that? Is it a year before? Six months before two months before? Two years before? Like, what do you what do you think's reasonable?

Josh  37:09  
So I think like, the first thing you need to know is like, what's the level of effort? And you know, maybe you can kind of, at some point, you need to measure that. And so that'll be the first starting point. And then how soon do you need to measure? That is the second question. And that'll depend on, I guess, your hunch of how much work that will be for your team to do make that transition. Every project, it's going to be different, like, you know, maybe they need to bring in additional resources to handle that upgrade path. Or maybe they can just roll it into standard maintenance operations. And it's lightweight and easy. So I don't think there's, unfortunately, a one size fits all strategy for this. But being able to conduct some level of analysis to understand what sorts of things that we need to think about is one step. A second one is like looking at your Drupal module ecosystem, and seeing what is ready for PHP core is very good at, you know, declaring what its PHP readiness is going to be, you know, Drupal. 10 is going to be ready for PHP 8.2, before PHP 8.2 is available, so that you don't have to worry about that so much. But the contract ecosystem really doesn't have a great, strong, reliable way of saying something's got, you know, a PHP or readiness level on it. So there might be some things you can do like composes a little bit better, because you can declare minimum versions of PHP that are required. And so you can change your PHP version and kind of update things and you'll see composer dependencies change, but not necessarily Drupal modules inside there, that will that will change. So you'll is kind of, I guess, a suite of different things that you can do. And some of them are going to be like, what are the composer changes? And what are my modules ready to go? What PHP does, What things does PHP, Stan tell you that you can think no, that you have to figure out and there's a lot of that stuff is existing inside of community modules, then it kind of suggests you might have to wait a bit longer for the community to catch up. And this then kind of goes into the whole conversation around the what type of your module selection that you make, and what are the criterias and things I actually wrote a blog post on depth@acquia.com. A few weeks back now on like, criteria for evaluating a module and things you might like to consider, like, how actively supported it is, and not just does it do the thing that I want it to do? And that's all criteria, I need to use it. Maybe it needs to have a community around that needs to have a certain number of downloads a certain level of commitment from the maintainer, suggest that it's not just like a dead project that's not going to get updated. And then you're left with this dependency. In this module that isn't going to have PHP 8 support, and you need to get to PHP 8 or whatever,

Nic  40:06  
I think that's one of the points to that I'd like to make is that preparing for end of life, part of that happens as you're developing the project. So it's not like, Oh, I know this. And if life is coming, how you architect your project determines how much of a left that is. And I would say, extend what you just said, Josh, a little bit and say that using contrib modules in general, I mean, if you have a choice between two, you want to use the one that's better supported, right. But in general, I think using contributed modules over custom functionality many times means that the effort to upgrade is going to be lower, because other people are going to be trying to solve the same problem. And you can collaborate with other people in the issue queue. If you're building that functionality yourself, well, if it's not compatible with the next version of PHP, that is on you to upgrade. Whereas if you're using a module, like, for example, I did have to wait on a couple of projects update for a couple, for a couple of fixes. But the only one, the only module that I can think of where we actually had a real problem with the PHP upgrade was better exposed filters. And now, that wasn't that better exposed filters didn't support phpa, it was just that we were invert major version three, which didn't, and major version four does. And that was, that's one of the upgrades that takes a little bit of effort to go from three to four, a lot of major version upgrades, and modules really aren't that big a deal. Sometimes, sometimes they are embedded resource filters, is one that is by using that module means like, like you can, you can help out the other the rest of the community on some of the fixes you provide. And you can also benefit from the community fixing fixing bugs as well.

Josh  41:50  
Major release versions of the real kind of gotcha in the space, right? Because, like, if you ask, why would a maintainer create a new major version, if they're following the semantic version, and it's like, well, maybe the architecture and the current version is not as elegant as I'd like it to be. So I need to like redesign it from the ground up. And while I'm at it, I'm just going to use the latest version of PHP, because I don't have to think about backwards support and compatibility. You roll that forward to when that major version becomes a stable point. And now it becomes the solution for upgrading to the latest version of PHP on that module. And it might mean that you enter into a forced upgrade path that you didn't you know, that maybe not not, it's not there yet, or, you know, there could be a number of things that that can be challenging to that. So you're right, like, having a community around that module might give you more options, like it might provide you an upgrade path, or it might provide PHP support for that older major version or something like that, and give you more more things to manage longer term.

John  42:52  
It's interesting, I just recently upgraded my personal website to PHP 8.1 from, I think it was 7.4. But anyway, and I ran into both of those scenarios. One was one of the modules I was using and can't remember which one had a issue in the log. PHP related, right, there was a patch for it. So I applied the patch, everything worked great. Problem solved. The other one was the CKEditor, four to five, update. And like, that's a major, major improvement major update, not necessarily related to PHP directly. But but that was the same sort of thing. And I was actually really impressed with Drupal is kind of trapping around that upgrade, and being able to tell you like, Oh, this isn't going to work. And that's not going to work. And this is what you need to do to fix it. So definitely things to think about when when doing upgrades to your site.

Josh  43:52  
Have you have you had anyone on the podcast for the CKEditor 5

John  43:57  
We are we have a show scheduled for? I want to say early next year, maybe? Yeah, because it's coming Friday. Yeah,

Josh  44:10  
so that is just like, if you if you were around when we like introduced the media module into core, and that upgrade, I think it was like 8.2 8.3, I want to say was kind of nightmarish, but feels like this change of like CKEditor from four to five is way different. It's gonna be it was

John  44:29  
it was super awesome not to go down a rabbit hole here. But it was super awesome to be able to like switch my input format to use five and have it be like, here's what we changed and here's what's gonna break and here's how you might be able to fix it. I was like, okay, cool. All right. And like within an hour I had like my my code coloring fixed and like I was like, on my way to like just using CKEditor five. So yeah, it was pretty awesome. And yeah, look for that show. Coming to you in the next couple of months. So I just realized that we have folks from two of the major hosting platforms, Drupal hosting platforms on the show today. So I'm gonna put Taryn on the spot. After I after I talked to the Aqua guys. About from a from a hosting platform standpoint, right? So we just talked about from a developer standpoint, how you prepare for end of life, but I'm curious from a hosting platform standpoint, how you prepare for end of life, right? It's not just like, hey, flip this switch, everybody's using the new thing. Yay. Right. There's like, a lot of thought and planning, I'm assuming that goes into that. And I'd like to hear more about that.

Josh  45:47  
Yeah. And, you know, I think as long as like the good old days, it was like, we would just hosting, you know, hosting platform where it was just that thing that needed to have a, an end of life. But there's now like a greater ecosystem of things that get utilized, you know, we used to have Dev Desktop, I think would be we end up left out a long time ago. But we now have CI containers that need to have end of life, PHP, 7.4, we have cloud IDs that run. And sometimes these things aren't even about end of life. And they're about like, different defaulting as well, and making sure that there's a good pathway for people to move into. Because if they don't have that pathway, then maybe they don't want to move, you know, they want to stay where they are, because it's the best option for them. Then there's all of the Drupal product integrations that all need to have. Be ready for PHP, 8, and, and then also integrations. So you know, we had New Relic running on our platform, and it had been running on PHP 8 for quite some time, but customers weren't moving. And only when they started moving, that we learned that there was some problems in the agent that needed to be updated. So that PHP 8 would work smoothly with with New Relic. So there's a lot of thinking about PHP, 7.4 end of life actually puts focus on a lot of other areas of the platform as a whole about how you default to the new version of PHP, and then all of the things that are dependent on PHP, and how the, how they all kind of ensure they're going to function and operate with with one another. need to be updated as well. Is that kind of the I feel like there's a part of the question that I'm missing?

John  47:39  
Yeah. So I guess that's super interesting, actually. Because you don't necessarily think right, like of all the other things, right? Like you think like, Oh, my website's on Aquia, but like, depending on what aqueous services you're using, that impacts, you know, the version of PHP that you're running, right. So like, all of the, you know, tools and utilities that you mentioned, I guess the question is more, at least for me is more of like, how does Aquia prepare for that, right? Obviously, like, an aqua customer, like, I get the emails like, hey, PHP is going end of life, like switch site, update yourself, right? And then like, how do you how do you guys kind of plan for that? And then like, what's the, you know, when the day comes? What what do you guys do? I mean, I'm assuming you just shut it off, but maybe not.

Josh  48:34  
Yeah, so I guess we've got like a historical repeat way of that we've done this in the past that I can share and speak to, which was, we, like you mentioned, we would normally communicate with our customers early on and say, yeah, maybe like a year out, sometimes even two years out, we'll issue end of life dates, we even published those end of life date, end of life dates on end of life schedule inside our docks, then, once those end of life deeds are as they kind of near we continue to send out information, and we monitor the versions of Drupal. So the versions of PHP that our customers are using, so we can kind of get like a month on month view of like, what that are people adopting it or they're not and we're allows us to adapt our communication strategy. And how you position to that, historically, as we kind of near that date, we normally end of life about a month earlier than the actual community end of life. And that trust, just a bit of buffer right to kind of because what will happen right is like on End of Life Day, we have to be off right? So all customers need to be off and if they haven't heated our you know, communication and they haven't taken action and they haven't switched versions, then we're kinda like down to the last option, which is to force them on to PHP 8. And so when they do that they might break, right. And if they break, they're going to file a support ticket. And if they file a support ticket, we're going to switch them back, and then be like, Okay, now you guys need to come up with a real solid plan to deal with this. And I should mention as well, you know, like, for Acquia, we have, I guess, a bunch of security, compliances and standards. That mean, like, we can't host unsupported versions of PHP, there's not really like a part of what we can we can offer. So to keep our customers compliant, we need to keep them on a supported version of PHP, so we need to help help them through this. And I should also mention that, like, customers will have like account managers, our account teams and our talking, not just sending, you know, mess, support communications to people and saying in the email, you need to update, and that's all there is to it. But account managers, technical account managers, CSMs, will be engaging with the account teams and also prioritizing and set the business level. So it's not just a developer responsibility to advocate this to the business to go and do these things. And we also provide options like partners or professional service packages to help customers get through this, if they don't have the resources to do it themselves. But if all of those strategies fail, and they're still on 7 and up for on delay, then we'll force them over, that might trigger a rollback, and then we've got a bit of like a buffer to kind of help people get through that last piece of it. So that's how we've done it historically. And historically, that's been a really painful experience. Because, you know, it's noisy for support. And there's a lot of escalations and, you know, very important customers that didn't get things done in time, and now a force of the difficult situation. So this time around, we've taken a different approach and looked at how we could provide long term support of PHP, that means providing a supportive version beyond a period of time that the community is willing to support it. So we can essentially extend that that level of support and ensure that it keeps on going. And I think that has some extra value to Drupal 7 customers because they Well, Cora supported for PHP, a net point one, it's not, you know, it's less likely to get full community support around the contract space to get PHP ported as well. So staying on PHP 7.4, it's something that they particularly are interested in, especially if it means they don't have to invest in that change right now. So this time around, we're looking at extending it and we have extended PHP support.

And then we're looking at potentially using a, like a financial incentive to get off as another like strategy. So rather than, you know, having to get off, you could just choose to pay to stay on PHP 7, but for for longer, maybe that's a better option for certain customers, or maybe that's enough of an incentive for them to get off. Either way, we're kind of the end goal for us is really about getting customers off of PHP 7.4. Because I think the longer that you stay on it, just the harder it is to stay to maintain anyway, like your your costs just increase. So we want to kind of use another kind of carrot or stick to help get people off of PHP 7.4. And on to a actual community supported version. It's it's better for them. And it's, it's better for us to

John  53:44  
write. So, Taryn, I'm wondering, from from the Pantheon standpoint, Now, admittedly, my personal site is hosted on pantheon. And, you know, it's, you know, I went through the upgrade process, like I said, a couple of weeks ago, I'm wondering, what are you guys? Are you guys doing anything really different when it comes to PHP end of life? Or is it kind of much of the same, you know, heavy communication, working with folks making sure they understand like, hey, it's better to be on a supported version than a non supported version?

Tearyne  54:17  
Yeah. So to talk about our process, how we prepare for end of life, right? Because as we've discussed, there's an end of life that comes up every time, the circle of PHP life as it always occurs. And if I can continue to be cheesy here. We have an internal CMS ecosystem team. They have these discussions. There's a weekly internal Friday meeting, where folks talk about the different deprecations that are coming up in the open source communities, which includes PHP, our Eagle, our CMS ecosystem squad has sandboxes where they're testing support, both for previous versions and the upcoming versions. I'm most of the teams in the company actually had their respective sandboxes to be able to do tests on. So we know what's going to come up for our customers. For us, PHP 7.4 will no longer be recommended. It will be available to folks that are currently using it. But we don't do force upgrades. So there's not going to be anybody that's forced to upgrade to PHP 8 for the foreseeable future. We do recommend heavily to our customers that they keep their PHP versions up to date, for all different kinds of reasons, like we talked about, for better security, faster websites, new features and improvements. That's part of not having to deal with the pain point that comes up when you're on 7.4. And everyone else has marched forward. If you're still on a deprecated, unsupported version of PHP on your site, it's going to limit the ways that we're able to help you. So I think that answered your question about differences there.

John  56:01  
Yeah, yeah, I think, overall, for me, I'm hearing a lot of like, communication is key, right? And like, Josh is, like, hey, I can bring that I can, I can bring the horse to water, but sometimes they just can't make them drink. So it's, it's one of those things like, Hey, if you're listening to this, and you're still on 7 for, you know, get get on your horse upgrade to upgrade date, it's in your best interest.

Nic  56:24  
So So Matt, I want to point this next question at YouTube. Because again, you're kind of the face of the Drupal automated upgrade testing process, you know, for the community, I think, because you know, especially with Drupal Rector,

John  56:37  
that's a mouthful, we should get that on a t shirt, though. Facebook, Drupal update on me, anyway.

Nic  56:43  
Yeah. So as you mentioned, a lot of these tools, you know, you're building on top of other tools in the community. But automated testing can only get you so far. You know, there are edge cases, both in the code and implementation. I'm curious how you go about finding some of these edge cases for solving some of these issues. Because sometimes, you know, sometimes you just have to have a site that's running, you know, are you working with some customers and saying, like, Hey, we're gonna take a copy of your site for PHP 8, and see what happens? How are you letting them do it, and then having that waiting for them to come to you.

Matt  57:23  
So I've actually gotten to see the split side of this before, actually, I've seen three sides of this, I guess, one at aka with the issue that Josh brought up with the New Relic agent. In that case, it's like, you need to look at it, and see if they can let you take the code. But I've had it from the maintainer side, we're back with Drupal commerce. When serializing, a plugin, it calls the segfault on PHP 7.3, but not 7.20. And we've I found that via unit testing while working on a feature. So I got lucky to find that. And at that point, it's dig in and figure out like, Oh, it wasn't a PHP issue. It was something in core, you know, you go down the rabbit hole. A lot  of times, like when you're writing your code, and same with a client is it's like, good luck. You have it. But when you're on the platform side, this is where I'm new. And I'll let Josh take this over. But that's where you're kind of like in a black box. Because, like, it's their application code, not necessarily your platform code that's causing it. Yeah, so I'll let Josh take that. Yeah,

Josh  58:27  
I mean, I think the that was a PHP 8.0 compatibility issue. And it was related to making HTTP requests. And so it actually, like, impacted the way that Drupal HTTP request was being captured, and profiled. And yeah, like, these things require testing ultimately, and like, even though we had PHP 8.0, available on the platform for like, a year, before, it wasn't until people started adopting it that, you know, with the issue kind of arose, and our testing didn't didn't pick this up, then it's a, you know, like, there's a matrix of combinations that are hard to know all of the possible permutations. And so we use our support desk in this way, where if we see you know, certain trends in support tickets, then that's, you know, something that's a one off or like, maybe it's something that's custom, a common customer issue, or create a knowledgebase article, tell customers, yeah, maybe they can sort of learn about this issue because they have to deal with it themselves. Other times, it's like common enough where maybe there's something that we can change at the platform level that can help our customers and so that's also not always like a clear distinction or line, because it is as a as a pas, you know, it is a mixed model. Operating responsibility so we can provide the runtime environments, but, you know, the customer has to bring code that is compatible with those runtime environments and they need time To do that, so sometimes the urgency to get off of 7.4 in itself creates escalations because they hit roadblocks that they don't have time to deal with. And now they just need to get it done right. And that time pressure becomes an escalation of itself where they had they started that journey earlier, it may have been something that they could spend more time thinking through and figuring out workarounds for or something. So

John  1:00:28  
back to my previous comment, update your website to PHP 8. Now, people. Now I actually have a question and I'm gonna ask Matt, but maybe Josh can can help here from like more of the platform support side of things. I'm wondering, when folks do upgrade, right? I'm imagining in my, in my Drupal loving brain that you guys are probably seeing more issues with custom code, as opposed to Drupal, like contributed code, right? Like, customers, like, Hey, I have a custom module that does XY and Z. And I'm having problems with it, because we just upgraded from, you know, PHP 7, PHP 8. Is that a true statement? Or am I just being kind to Drupal?

Matt  1:01:24  
I think you're being too gracious to contrib and not client code, because code contributes contributes a, I have spent the past few months trying to get people to get their Ghazal constraint updated for guzzle 7 with Drupal 10. I think the client code is less dangerous than contrib code, by and far when it comes to major version. Okay. Yeah, you've been speaking when

Josh  1:01:51  
so I was gonna say like, you can, if you're like a customer is at least in control of their, of their custom code. So if they need to get off of it, they in the power position to put resourcing into doing so. But if your contrib modules that you depend on aren't ready yet, the best you can do is patch them, and then kind of apply those patches locally, and then hope that they get accepted in the branch system.

John  1:02:18  
Yeah. So I guess that was kind of my, the way I was thinking of it, right. Like, if you have a problem with the control module, hopefully there's a patch for it. Right, that gets you up to date. You know, in my head, I was guess I was thinking more that like, sometimes custom feel like client code, or custom modules that they've built, kind of, languish in the update in the in the maintainer ship, but I guess I could be wrong.

Matt  1:02:46  
Yeah, as I like to say, with upgrades, it's usually fork fork baby, which is really hard to do with Drupal modules. But I mean, when it comes to it, laravel app that was on PHP 5.6, and had packages that were abandoned by agencies, and I had to get it to 7.4. And it was for kit. And now I'm owning a package that can support that, because it's impossible to get to maintainers. Luckily, the Drupal community is pretty good about this, because we have drupal.org, and we have abandoned module processes in place. So that is one benefit compared to the larger PHP community. And even at Drupal con Portland talking to the symphony folks about some composer support, because that's a whole, you can't patch composer dot JSON and make it work. That's a whole other topic. But at least for drupal.org, we do have that community structure that we can say, hey, this module is abandoned, we have processes in place to get new maintainers put in and get the code fixed. We're on GitHub. You don't have that at all.

John  1:03:47  
So let's let's stick with the idea of maintainers here. And, Josh, I'm actually wondering, have you had to work with PHP maintainers to solve issues that like Aqua has found?

Josh  1:04:04  
Most of the time, not. So I mean, we have a team at Acquia called the Drupal integration team. That for short, is the opposite of that, which is the Drupal acceleration team, which focuses on core has we've written that, and that are they work in the kind of, I guess, contract space, but they really focus on modules that that we depend on at Acquia. So like our core set of product integration modules, we have purge the dam module and that site and then we have modules that Aqua CMS has built on and we want to make sure that I've been CMS, as a distribution can be supported on the versions of PHP that we offer on our platform as well. So those are kind of like the two key places where we would look for PHP compatibility and making sure that those versions of PHP are supported across the choices of modules that we use. But when it comes to any other of the community modules, we don't have a outside of what that already does around the Drupal 10 readiness initiatives in the community, we don't have something that's specifically looking at, like broad spectrum, you know, value add to the entire community of all the contract modules that are looking at the PHP 7 assembler for end of life.

Matt  1:05:25  
I would add, I've had plenty of experience of hitting PHP bugs when working on code, but never anything that's around like end of life. It's just like, wow, hit this bug on the PHP issue tracker, it was able to say, Me, too, and eventually it got fixed, but never anything necessarily end of life. Okay, yeah. One thing

Josh  1:05:47  
that is kind of interesting I can think of is we have a command line tool called Acquia. CLI. And it runs on PHP, as you know, it's a PHP Symphony tool. And it now requires PHP 8 to run. And so if you're running on PHP 7.4, it won't, it won't run it kind of like means you need to upgrade. But we have multiple versions of PHP available in our runtime environments. So this is more something that impacts you on Cloud IDE than it would on the hosting environment. But essentially, you can write like a bash alias that says the Aqua CLI routes itself through the PHP 8, binary, while your default PHP runtime remains, PHP 7, not for as like a way of being able to interoperate with both of them. And that's only because you know, out of a, unlike something like Drush, or Drupal console, which can bootstrap Drupal, depends on having a common PHP runtime. Acquia CLI opera, even though it's built on PHP, it operates independently of, of Drupal itself.

Tearyne  1:06:55  
So, I'm gonna worship this a bit here, in my community, did you funerals, but some funerals are homecomings, we'll celebrate the things that a PHP 7 has given to us. Let's talk about what we can look forward to with PHP 8. So y'all, what are the changes from 7 to 8 that Drupal developers should be looking forward to? Like, what should we be excited about with PHP 8.

Matt  1:07:21  
So I got one, like, there's a ton I've been doing PHP 8, since it came out, like I've been taking so many things. But what I think is great is I'm about strict types, which I know some people like, oh, I don't want strictly typed code. But the fact that false is a strict type. And why that's important is Drupal has a lot of patterns of not necessarily returning No, like array or no, but array or false, especially our caching system. So the cache will say, it returns an object or false, but now you can actually have that be strictly typed, instead of just like a PHP annotation, which is super cool. So you can say, like, get parentheses cache ID, colon, array, pipe, false, it's strictly type that are sorry, object, that it strictly will return an object, or false and not some other boolean value. It's like, when that landed, and I think that might have been 8.1. Actually, for the false type, I can't remember. But super cool. Super cool.

Nic  1:08:23  
And for people using the sites, you know, maybe not building such such, you know, projects that you what does that enable, other than, does it just prevent a lot of class of errors, because it's returning something and aren't expecting?

Matt  1:08:40  
Yeah, because you have to have code that speaks truth. And the idea is that if something's going to fail, you want it to feel locally. And by having your strict types while you're working with code, proves that you know, is going to run and not have that weird, we've all been there, right where it works on your local machine, then it gets in production and something happens because you don't have enough like logic checks. The way I see it strict typing like this just removes a lot of your if statements. You write less if statements and you get more truth.

Josh  1:09:14  
Think it's probably also important to call out that like, you won't see a lot of the new features of PHP 8 in upstream code like Drupal core and contrib purely because they maintain backward compatibility with PHP 7. So they can't like implement a lot of those new features just yet. But the stuff will start to appear in the coming years and as support for PHP 7 is dropped, and we're able to focus purely on PHP 8  capabilities. But I also posted a maybe we can add this into the show notes. There's a great site called stitcher.io. And they're always talking about the new features that are coming inside of PHP and they do great blog posts on the specific features that are being introduced. New functions deprecations or that sort of stuff. So anytime there's a new version of PHP released, I like to come to the site and read through the array of different changes and typically get really excited about the kinds of things you can do. And the changes in syntax that are coming. So there are things like attributes and union types. And you know, the just in time compiler is probably is something that should be made a mention that means compiling gets faster and performance gets faster than operating in PHP 7. So yeah, there's a whole bunch of stuff there. Maybe I'll leave it to the show notes to walk through because I can't think of anything sort of specific significance to call out on the podcast.

Nic  1:10:41  
So we've only got a couple of minutes left. In closing, I think we would be remiss if we didn't mention Drupal 7, which hasn't yet, end of life. And the issue isn't core, just like with Drupal 9. But the contrib space is exacerbated, you know, tuple people, there's not very many Drupal 7 modules that are currently actively maintained, and have been updated. Are there tools that we can that you can use to kind of see what your Drupal 7 site is doing? And, and what might need some some attention?

Josh  1:11:18  
Man, do you want to talk about the tools? I can talk about the

Matt  1:11:21  
problems? Yes, more. But yeah, um, so two years ago, I did a quick deep dive on running PHP, Stan against Drupal 7. And I have a sample configuration that we'll put in the show notes that a few people people have been using. You know, the tricky part is just it's not a composer project. In PHP, Stan assumes composer by default. So you just got to configure it to read to know what files to scan. But yeah, so you could use PHP Stan pointed out the same way we would your Drupal 8 site and go to town.

Josh  1:11:56  
Yeah, PHP 7, maybe even a topic of its own. Because you're the PHP 7.4 end of life is just one of many compounding challenges for Drupal 7 owners, but also for us as a as a community or an industry because Drupal 7 represents something like 50% of the Drupal sites that are out there in the wild. So it's still a significant portion of what Drupal runs on. But it's been around for a pretty long time now. Yeah, I think I think that is something to think about is like, how do you like get off of Drupal 7? Or how do you go operate Drupal 7 long enough to build the next thing that you need to you need to build? And those are the strategies, that's sort of a similar reason why we wanted to another reason why we wanted to extend Sif, PHP 7.4. Support on Acquia was specifically for Drupal 7 customers who just needed more time to rebuild their next digital experience, you know, if they built a Drupal 7  site probably a decade ago, probably just upgrading it to Drupal 9 or 10, is not maybe going to hit the mark for the level of effort that's going to be involved, right, like maybe they need to rethink their communication strategy, because the web's moved on a lot from them. I mean, just for context, right? Like, back then you could add, like a Facebook widget to like the page, right? Like, like, nobody does that anymore. So there's probably a bunch of features that are sitting inside of a Drupal 7 site that aren't needed anymore. And maybe some good questions around whether that content is still needed to be retained. And what should you be doing so like, sometimes the Drupal 7 conversation is also a headless conversation, because customers want to think about rebuilding their digital experience in the front end, and they want to continue to use Drupal as a delivery system, because you know, the content teams are familiar with the UIs, and things like that. So that's often a bigger conversation, and they just need runway to keep operating. But if you are trying to get you know, to Drupal 8, there are some tools. But as Matt mentioned, composer, the PHP community has moved on since we were building projects with Drush Make files. So you know, you need to maybe consider adopting a composer strategy and seeing if you can use that to help scan and analyze your site to get to triple to PHP 8. So

John  1:14:33  
there's definitely a lot to unpack there. We will have to put that on the shelf for now and come back to it. And in another show. Josh and Matt, as always, thank you for joining us. It's It's been great having you.

Josh  1:14:48  
Thanks for having us. It's been great to be on the show. Thanks for having me on.

Nic  1:14:55  
Do you have questions or feedback you can reach out to talk in Drupal on Twitter with the handle talking Drupal or by email was show attacking drupal.com You can connect with our hosts and other listeners on Drupal slack in the talking Drupal channel.

John  1:15:07  
You can promote your Drupal community event on talking Drupal. Learn more at talkingdrupal.com/tdpromo.

Nic  1:15:15  
And you can get the talking Drupal newsletter for show news, upcoming Drupal camps, local meetups and chats book corner, as well as much more by signing up for a newsletter at talkingdrupal.com/newsletter.

John  1:15:26  
Thank you patrons for supporting talking Drupal, your support is greatly appreciated. You can learn more about becoming a patron at talking drupal.com and choosing the become a patron button in the sidebar. All right, we have come to the end of our show where you can shamelessly promote yourself or tell people where they can contact you, Josh, if folks wanted to get a hold of you and talk about all things aqueous or caching, where could they do that?

Josh  1:15:53  
Caching you could definitely head over to the HTTP cache control module. Try pinging me on the Drupal slack my user handle is fiasco. You can send me a message on the drupal.org contact forms. It's probably another way of getting in touch. I also in terms of like Drupal 7, or headless strategies, you can definitely contact me directly at Acquia as well at josh.waihi@acquia.com

John  1:16:23  
Cool. Matt, what about you?

Matt  1:16:27  
I can get me on the Twitter's with @nmdmatt . Well, or hit me up at my Aqua email, which is matt.glaman@aquai.com.

John  1:16:37  
Taryn, how about you?

Tearyne  1:16:40  
On LinkedIn and on Twitter, I m, @TearyneG                                                                                                 . And if you want to read to @TearyneG at Pantheon, I'm TearynelAlmendariz@pantheon.io

John  1:16:53  
Nick Laflin

Nic  1:16:55  
You can reach me pretty much everywhere at nicxvan

John  1:16:59  
And I'm John Picozzi. You can find me on all the major social networks and drupal.org at johnpicoaai and you can find out more about EPAM at epam.com.

Nic  1:17:10  
And if you've enjoyed listening, we've enjoyed talking. See you guys next time have a good one everyone

Transcribed by https://otter.ai