viewSource

[00:00:00] **Brian Coords:** You are listening to viewSource, conversations around WordPress and adjacent tech with hosts, Aurooba Ahmed and me, Brian Coords.

[00:00:08] **Aurooba Ahmed:** Last episode of the Next.js series. Are you excited?

[00:00:12] **Brian Coords:** Um, as somebody who is not the biggest fan of crazy JavaScript, uh, applications and is, uh, you know, yeah, I think I'm, I'm excited. It's been real. I feel like I've learned. I feel like I've learned a lot. I don't know who, for people watching, I've definitely getting to see like the backend of all this stuff.

[00:00:33] I've definitely learned a lot, even though I've done this stuff a little bit before.

## [00:00:37] Familar tools are easier to wrap your head around

[00:00:37] **Aurooba Ahmed:** Yeah, you know, something I saw on Twitter from you, I think, and Derek Ashauer the other day, um, was like, or no, not Derek, it was Keanan. It was Keanan and you. Yeah, uh, Keanan was just like, oh my God, all this JS stuff is making me want to wish for WordPress or Laravel about the stuff. And you know what? I get the sentiment totally because I think for the first couple I did, that's exactly how I felt.

[00:01:00] It felt too complicated. The overhead felt like a lot, but now that I'm in it a lot more and I'm dealing with this kind of thing more daily, I'm finding that it's doesn't feel like as much overhead anymore. It feels like. It's still slightly more than WordPress, but it feels similar to like the overhead that I've seen with Laravel.

[00:01:20] So I think a lot of it just has to do with, you know, we get so familiar with certain things and the way and implicitly understand so much stuff about it, that it's super easy to get into it. And then when you go into something new and has these different implicit things that are different from what you're used to, it feels like so much harder than it maybe is once you get used to it.

[00:01:41] **Brian Coords:** Yeah. That's funny because we, I've been having conversations like that, just in WordPress, people who use different WordPress tools. It's like, this is so hard. It's whatever. It's, it's just what you've been using. That's the difference. Um, and I have a Laravel project where the client was like, Oh, I want to be able, I was like, I'm going to go full PHP on this and no JavaScript or like there's JavaScript, there's some Alpine, but like nothing, no Ajax or whatever.

[00:02:05] Yeah. And they were basically like, um, we want to be able to like, check 10 things on this page and then save the data instead of like, I had, like, everything was individual and I was like, Oh, that would have been a lot easier with JavaScript. But now I have to like re architect it and stuff. Uh, so there's definitely trade offs.

[00:02:24] **Aurooba Ahmed:** Yeah, there definitely is. And you know, I think one of the greatest appreciations I have, the more you start to explore different platforms, different spaces, and the way they do things, it not only opens up your options for how you might tackle a new project, but it also opens up how you think about things.

[00:02:44] And then you're able to take like a paradigm from one place and then use it in another place. And I think that's probably the most interesting and most powerful, compelling, maybe reason to try out different types of, you know, like JavaScript or Laravel or fricking Python, which seems to be popping up randomly a lot these days, stuff like that, you know?

[00:03:06] **Brian Coords:** Yeah, I mean, I think, you know, you have to dedicate some amount of your time as a developer to learning and growing and trying other things. It's, that's part of the job. And like, hopefully if you work somewhere or if you're a freelancer, that's just budgeted into your time. Cause it's kind of required.

## [00:03:22] On Deployment in the WordPress space

[00:03:22] **Aurooba Ahmed:** definitely. So today, as we said, last episode of the Next.js series, and we're going to talk about deployment and that's a really interesting product, like topic. And I think randomly as we're like recording this today, you and I have been dealing with just general deployment stuff quite a lot, right?

[00:03:42] **Brian Coords:** Yeah. I mean, I've been exploring some things and I've been getting to see some things. Um, and I've been watching people I work with explore different ways to deploy mostly in WordPress and stuff, um, which is different, but I think a big part of it is that in WordPress, there's a lot of interest at the developer side to bring in some of the cool things you see in Laravel with Forge or with Netlify are for things, or even just like.

[00:04:11] Being able to like use composer on a WordPress site, you know, these are, uh, those are all like baked into how you deploy code and how you like go live and how you do like incremental updates later on in the future and stuff. And so, yeah, there's, there's been a lot of, I think, interest even just in WordPress to like level that game up a little bit.

[00:04:32] **Aurooba Ahmed:** 100%. I think when I first started to look at sort of, you know, the JavaScript space, the static site space, you know, this kind of a JAMstack space, even though I think the term JAMstack is being phased out, the most attractive thing was how easy it was to deploy, for the most part, you know, these platforms are built to take your code and get you live very quickly and when I, I took this project that we've been looking at from code to deployed in 15 minutes of which 10 minutes was just debugging some problems. But the actual setup was five minutes and under and that includes setting up my account, authorizing GitHub, all of it, which was wild because you know, I can't, I've never had a hosting experience for WordPress where in five minutes I've got it all done and it's provisioned and everything.

[00:05:29] **Brian Coords:** Yeah, I mean, there's, there's a big difference too, though, like WordPress comes from the old school of like, I'm going to SFTP onto my server and move some files around and do all this stuff. And like, even just, even just using version control

[00:05:42] **Aurooba Ahmed:** You cowboy coder. What?

[00:05:44] **Brian Coords:** I mean, you can act like you've never done that. Um, it's, it's just the way that it, yeah, it grew, like, that's the way it grew up.

[00:05:52] And all these new things come in their repo first. Like you start with version control and you go from there and WordPress really was never built like that. And you have plugins, you have themes, you have all these other pieces that you don't control and you can do all that in a repo, but it's a lot more work.

[00:06:09] And so there's a lot of, I think reasons you don't see it as much, but, um, this starting with your repo and just saying like, I know from the beginning, I'm going to take this repo and just deploy it. That is, uh, is nice.

[00:06:22] **Aurooba Ahmed:** Yeah. I think that's a really good point. You know, with WordPress, you know, we've seen this, like, some people choose to even version control WordPress itself, like the software. Some people will version control the theme only. Some people will do the theme and maybe the MU plugin. Some people will do all the plugins and all the themes.

[00:06:38] Like, there's so many different ways that you can do version control in WordPress and there's no one like unified understanding of this is how we version control because that was just never how it was from the get go. But you look at a JavaScript project like this because it's repo first like you said, it doesn't matter. All the dependencies everything everything is a version controlled.

[00:06:58] And so it's super easy. You're totally right that makes deployment a lot easier For sure.

[00:07:03] **Brian Coords:** And there's also like a security thing to it too, like, like what you're building, we can log into, but at no point would our user be able to like edit the files on this file system, but in WordPress, like you can log in and literally edit the PHP files if you have like credentials enough, which is sort of insane.

[00:07:21] And, and I've, there was even like a cool security thing coming out. Um, maybe I'll find the link and put it in here, but it was like. Sort of addressing that issue. Like why can users log into WordPress change files? Like that's crazy, you know, but like, that's just the way it was. So it's, it's a different, so there's a, just saying there's a security benefit to, to like having your, your code really controlled separately.

[00:07:42] **Aurooba Ahmed:** Yeah. I agree with that. And I'm really happy to see this kind of thing come from other spaces into that WordPress space for not just those, just not even just those security reasons, but just generally like making our lives easier. I don't know. I think It's a lot easier when you have things version controlled, when you have a process where you say, here's the source of truth for what is correct, instead of a lot of people going in and cowboy coding and you don't know who's changing what, where, when, how, and that, you know, that comes with its own set of nonsense.

[00:08:17] **Brian Coords:** Yeah. And even honestly, even hosting companies that have really good git integration for WordPress don't have that level of what we're going to look at. Well, I haven't looked at Vercel, but I, from our change, the Netlify, which is like very clear history of deployments, of who deployed, what commit it's on all this sort of stuff.

[00:08:36] Like it's just, it just feels so much more like secure and like mentally secure because you can just see exactly what code is out there. And if the deployment failed and all that sort of stuff.

[00:08:48] **Aurooba Ahmed:** a hundred percent. So let's go and take a look at what it took to deploy and for sale. And then we can talk a little bit further about this in general, because I think we have quite a bit to discuss here.

## [00:09:02] First Look at Vercel Deployment

[00:09:02] **Aurooba Ahmed:** All right, so I'm already logged in here, but creating an account is pretty easy with Vercel I just logged in with github because when something is so repo first I don't even see a reason why I wouldn't use github as my login credentials. And as you can see, I already have a project set up. But in order to create a new project project you literally just go add new, and then you add a new project because you have already connected your GitHub account.

[00:09:28] If you use that to log in, you'll have access to all of your repos. So in my case, I have, you know, the organization viewSource podcast, cause that's connected to my account. And then in here I have a bunch of, you know, repos that I can select and say, Oh, I want to turn this into a project. So if I go and I, again, just choose the WPAudit Learn Next.js repository that we have, I click import and literally all the setup you need to do, all of it is on this one page. And it's so nice because I just give it a name, I choose a framework and it's going to try to do its best to detect it. So it's already detected that it's this Next.js. If I haven't done any kind of custom stuff on it, then a lot of it is already going to be detected from my Next.js config file.

[00:10:11] So even my, build and output is being detected and then if I have any environment variables I can literally copy and paste my environment file right here and at one in one go and it'll just generate those environment variables here for me and then I hit deploy and that's it. If you've already got your repo done there's nothing more to do in order to deploy it except for this one thing that I came across come across afterwards

## [00:10:38] Environment Variables

[00:10:38] **Brian Coords:** We, so for the environment variables. You'll import those from your local environment. And then I guess you would go through and for like Supabase, for example, you maybe have a separate database for production and for staging. So once you've imported all your environment variables, you might go and change a couple of things like that.

[00:10:55] Like a couple of integrations or keys or something like that.

[00:10:58] **Aurooba Ahmed:** Well, in this case, what I did was I first, I have an, I have a prod environment variable file, which is not committed to the repo, just like a local one. And I have my prod keys in there because I found that to be easier. Let me set up that file, put all the information there from Supabase and then just copy paste here in one, one go and then grab it here.

[00:11:18] But yeah, this is, this would be different from, say, like a staging version of the, the keys. But in the case of Supabase, though, in this situation, I've chosen to use the same environment, right? I didn't make like a staging version of my database in Supabase, so it's actually the same.

[00:11:36] **Brian Coords:** Okay.

[00:11:36] **Aurooba Ahmed:** In normal situations, they would not be the same.

[00:11:39] And so in that case, what I really like is, I really like env files, and I personally like to have, like, In 1Password, like when I'm in projects with teams, I'll create the entire end file in 1Password that it might be shared with the team and have it as a secure note there. And that way it's just like a one, one time copy paste.

[00:11:59] You're good to go. You don't have to think you have to go find it, make it easy for yourself, for your other people, for future self. You know, that's a, it's a nice trick.

[00:12:08] **Brian Coords:** Yeah. And I think the closest comparison is like the wp-config file in WordPress, where it's like, you're defining all of your, like things that you're going to use later on and stuff like that, like your database and connection credentials and all that sort of stuff. But, uh, ENV files are so, cause it's not PHP or it's not like, it's not logical.

[00:12:24] It's literally just like key values, like all the way down.

[00:12:28] **Aurooba Ahmed:** Yeah, totally. I really love them too. And actually it's really funny because just recently I was on a particular project and they actually kept the config file in a 1Password as well. And I couldn't figure out why, but I'm like, okay. But it was really easy when I had to like reproduce it somewhere else and it was going to be all the same.

[00:12:45] I just grab it, pop it in. I'm good to go.

[00:12:48] **Brian Coords:** Yeah. I wonder if we're, cause like Laravel uses ENV files, like there's theoretically you could, but yeah. Mm

## [00:12:56] Errors on first Vercel Deployment

[00:12:56] **Aurooba Ahmed:** So once you do this, honestly, you get, I'm just going to go back to the other project. It goes directly into your first deployment. So if I go here in the project, there's, you can see these are all the deployments I've done since I first set this up. And you can see the very first deployment had an error. That is, and then the second one also had an error. And then the third one, which you can see are very quickly, they all had errors. So, there are different, in this case these errors were basically typescript errors, where I was just like not putting a particular type on some piece of code, and so I kept fixing it.

## [00:13:31] Using Vercel CLI

[00:13:31] **Aurooba Ahmed:** And then I was like, oh my god. Why am I deploying without checking for these errors? So then what I did was I locally installed the Vercel CLI. Because I was like, okay, uh, you know, I need to know for obviously running it in dev mode, or even just doing a build with NPM was not catching all the correct errors for whatever reason.

[00:13:50] And the easiest way was to just replicate how Vercel was going to build it locally, find all the errors, fix them, right? So I ended up installing Vercel CLI. And you know, you might not necessarily know that, but because I've used Netlify before, I knew that there would be some sort of CLI. So super easy.

[00:14:09] You install it globally, Vercel, and then they have a build command. And how did I know that I had to use the build command? Well, I, let's go back to my, nope, right there. When I was, if you look at the deploys, The really nice thing is it shows you exactly what's going on. So if I were to go and look at the top of the command, you can see it's running vercel build.

[00:14:34] So I download the CLI and then I run that exact same command locally. And then I was able to fix all the errors,

[00:14:41] **Brian Coords:** Did you, I remember with Netlify, you, when you set up their CLI, there's also one aspect of the CLI is sometimes you want to run in that environment. Cause you're also going to use like server, like function or like edge functions that are running or whatever. So you had to authenticate your CLI with your account, like a Netlify, you know, you'd log into the CLI, but you really had to authenticate it because it was kind of also talking to your account.

[00:15:04] And sometimes you connect it to stuff, did you have to do all that? Or did you not

[00:15:07] **Aurooba Ahmed:** I did have to, uh, I didn't have to authenticate because it was able to detect it from the repository I was connected to and use the same GitHub credentials in my local. And so I didn't get any, I didn't get any prompt to authenticate, but it was able to pull up my projects. And because I already had a project, I just gave it the string, the project name, and it was able to connect it, grab all the Vercel settings that I had.

[00:15:29] And it was like, I'm telling you, it was like really fast. It was really smooth. I was, I was pretty impressed.

[00:15:35] **Brian Coords:** Hmm.

[00:15:36] **Aurooba Ahmed:** I imagine if you don't have the repo already set up or something, or if there's no GitHub credentials locally or something, then you probably will have to authenticate with credentials. That's it.

[00:15:45] I was really surprised to not get that, that step. But I was also, I was also like, okay, cool. That was fast.

[00:15:53] **Brian Coords:** So then the way that these work is that once it deploys, it's going to try to build it, like it's going to run, like you're on a server with node, obviously. And it's going to run the build process every single time you deploy to like rebuild all the files and stuff like that. So your error here was, it just wasn't building because they were, Vercel was a little, uh, stricter about what was like types and stuff.

## [00:16:16] How Deployments work

[00:16:16] **Aurooba Ahmed:** Yeah. The stuff that dev mode wasn't catching. It was like, Hey, like this was literally like, I don't understand why dev mode didn't catch this. This was literally a class style that I had not defined, but I was using, I was like, how did I miss this before? So I just like got rid of it and fixed it.

[00:16:33] And then I was able to deploy. And then we had a deploy here and let's go take a look at it. So, obviously, the way it deploys is it's connected to the main branch, the main, which is the default branch of the repository. So, every single time I'm going to push a commit to this, it's going to update. Now, in a proper process that is not a learning repository, I would never push to the main branch myself. There will always be a PR. So then when that PR merges, that's when all the commits come through. So you wouldn't have like deploy after deploy after deploy, which is what would happen if you're committing straight to the main branch. If you were going to commit straight to the main branch, you would not want to have auto deployments because that would be a little wild.

## [00:17:18] Thinking in PRs

[00:17:18] **Brian Coords:** Yeah. I mean, yeah, you, you, once you get into this workflow, you really do start thinking in PRs, um, obviously when you're like solo coding something and you're just like getting an idea out there, it's fine. But also like, if you're going to do that, just don't push all your commits, like individually, like at least like stack up some commits before you push them.

[00:17:38] Because like, that is, you know, that's, you're kind of using energy when you're like doing all these build processes over and over.

[00:17:44] **Aurooba Ahmed:** 100%. Yeah. That's like not, that's the least you can do to help the environment y'all. Just the least.

[00:17:50] **Brian Coords:** Yeah, push, push less often, or just realistically use a, use a, uh, a branch.

## [00:17:57] Exploring the Deployment UI in Vercel

[00:17:57] **Aurooba Ahmed:** But what I really love about those deployment area is one, you get all the logs from like how it's building. You can even filter by errors, right? So in this case, there's no errors because this was a successful deployment.

[00:18:07] I loved that. Yeah. Yeah. That was really nice. And then you have the deployment summary. Once, first of all, it tells you the time it's like, Hey, there were seven functions. There was 41 assets. You can look at exactly what those assets are.

[00:18:23] **Brian Coords:** Mm

[00:18:23] **Aurooba Ahmed:** You know, you can look at all the functions. I mean, I really enjoyed the level of detail.

[00:18:31] It felt like was enough to be, to be really helpful, but not so much that it would be overwhelming. You know?

## [00:18:40] Deployment UIs around the web

[00:18:40] **Brian Coords:** So yeah, it's like the UI on this has been just improving across the board, like whether you're in Laravel, whether you're in WordPress, whether you're here, like you're seeing this a lot more, like you're seeing like SpinupWP is a great example where you're seeing this sort of UI more often. And you're seeing the logs of the build, the logs of the deployment and like all that sort of stuff.

[00:19:05] And it's just kind of great. Like it's, I feel like there's, it's like that thing where there's like an ideal version of what it's going to look like. And everybody's like slowly getting close to that. It's really nice. Yeah,

## [00:19:15] Comparing to Netlify

[00:19:15] **Aurooba Ahmed:** 100%, it really is. And then of course, you see it assigning to a domain, it's currently assigning to a temporary domain . But yeah, you can download it all. You can copy things.

[00:19:23] I mean, overall, I, when I came to this, I found it to be easy to understand. intuitive and not overwhelming, which is something I'm going to directly compare this to Netlify. Even now, sometimes when I look at Netlify's logs and stuff, I find it either confusing or slightly slow or just a little too busy.

[00:19:45] And I liked that when I was doing the deployment, it was keeping the actual build open for me. So the stuff that I was actually interested in was already open, but it's not done in such a way that it's taking over the whole page or making me feel like I'm in this chaotic, confusing space. So I was really impressed by that. And then once, yeah, go ahead.

[00:20:06] **Brian Coords:** I was at the Netlify screen. Sometimes it's a little hard to find stuff and that, that's normal. I think when you're new, but it's not, you've been using it on a project for like weeks and you're like, where's that again? Every single time. But it always felt like,

## [00:20:21] Taking your Vercel Project live

[00:20:21] **Aurooba Ahmed:** 100%. I still feel the same way. And I've been using Netlify for years. Whereas I came into Vercel and I was like, yep, I know where that is. I know where that is. With the grand exception of I couldn't, it took me like five minutes. I had to share my screen with you in order to like rubber duck it and figure out how do I make my deployment public once I've done it.

[00:20:44] **Brian Coords:** And you sent me this link and it's like, create your Vercel account. And I was like, come on, really?

[00:20:49] **Aurooba Ahmed:** Yeah,

[00:20:50] **Brian Coords:** you could not figure out how to turn that off. That's, that's funny. That's funny because I actually spent this morning doing the opposite, like writing custom auth for like a multi site WordPress, where like we want basic auth on some and not on others and stuff like that.

[00:21:05] So I'm deep in the auth weeds today.

[00:21:08] **Aurooba Ahmed:** that's cool. That's cool. But you know, for anyone who might end up in the same situation, in order to take your deployment, your project actually live, you gotta go to settings and then you gotta go to deployment protection and then turn off the Vercel authentication at the top, which will be turned on for you initially.

[00:21:28] So then your project will actually be public. Took me a little while. Cause I was just like, where is it?

[00:21:35] **Brian Coords:** yeah, cause it was like, it wasn't like, it looks like they have a basic auth style password one down at the bottom. Um, but this was like, literally like you have to be logged into a, an account that's like connected to your team. Um, which you would do maybe for staging. Like, so I guess that's, I have a question like staging branches, separate branches and stuff.

[00:21:54] How does it, do they have a good workflow for that? If you have like a staging branch or you want to make like a demo of a PR or something,

[00:22:01] **Aurooba Ahmed:** Yeah, I haven't tested that yet, but they have the ability to create multiple like environments for branches. I think that's something that's a very competitive, almost like required part of these kinds of serverless deployments now. So I have not explored that, but I imagine it would be here in settings, like maybe in Git.

[00:22:24] Let's see. Yeah, so there's like a production branch. And then you can probably add and there's like you could even have like triggers for your deploy hooks Uh, yeah, yeah, so 100% you should be able to do multiple branches. You can see in the project there's like an active branches area so if I had another branch I don't but if I did I would probably have the ability to deploy that and have it have it on its own url And judging by just how easy it was to set this up I would imagine that's it would be pretty easy to get a second branch or even previews like going pretty easily

## [00:22:56] Comparing to WordPress Deployments

[00:22:56] **Brian Coords:** And I would say one difference between this and what you generally see in the WordPress world, and although I have seen some alternatives recently, but generally we've seen the WordPress world is. You don't authenticate with GitHub. You have a, you just, it's not about GitHub. It's about get like, right.

[00:23:20] It's just like, if I have a site on SiteGround or WP Engine or something, I can use Git to deploy, but it's not, has nothing to do with GitHub. It has to do with the actual Git repository, generally from my local machine and what I do for my local machine is I add the destination as a remote and I push, I choose when to push from my local machine to that.

[00:23:41] And that's really the way. Most of them work. I have not looked at spin up. I, if you go through GitHub or not, or if you

[00:23:49] **Aurooba Ahmed:** You do. You can.

[00:23:50] **Brian Coords:** you can't, right? Cause it's a, it's a lot different because you can do stuff like this, where it's pulling in all of your branches. Um, sometimes it shows up stuff on your actual repository.

[00:23:59] Like you see the code checks coming through on that end and, and the, the pull requests have a link from on the actual pull request. So it's a lot, it's, it's, there's a lot more opportunity when you authenticate with GitHub versus just like we have Git, but it does tie you into GitHub. And that, that is a difference.

[00:24:18] **Aurooba Ahmed:** Well, it ties in, ties you into wherever you remotely host your code. And everyone, most of us are going to be remotely hosting our code somewhere. And most of these places and situations, like Bitbucket's usually an option, GitLab is an option, GitHub is an option. We always have one, right? I mean, what's the point of having a git repository if you're not actually going to have a remote of some kind?

[00:24:39] Um, so I feel like that's okay as a limitation.

[00:24:45] **Brian Coords:** that you have to use. Yeah. I mean, I guess if you're at us and I, they, they, maybe this is something they offer for like certain levels, but like, I don't know if you like self host your own Git, cause you're, you have some

## [00:24:56] Prebuilt Deployments with Vercel

[00:24:56] **Aurooba Ahmed:** Well, in this case, something Vercel has is like pre built deployments. So that would fit that scenario where you can literally build it locally and then just send the built files to Vercel so that it never actually ever sees your source code. So that's actually an option that they actually have that I thought that was really cool, you know, for security reasons or whatever reason you may have, or, hey, you're not remotely hosting with a known platform, then you could do it this way.

[00:25:24] And that's definitely an option.

## [00:25:26] Can you get to this level of deployment in WordPress?

[00:25:26] **Brian Coords:** yeah, if you're at that level, then you're probably, um, you know, you're probably like dealing with like a enterprise sales guy who helps you with all this stuff. Um, yeah, I mean, I, it's hard, you know, I don't think you could ever get to this level in WordPress, like, cause there's like plugins, themes, all the other stuff, uh, updating core, you know, but I don't know.

[00:25:53] **Aurooba Ahmed:** Well, I mean, for example, like WordPress VIP, I know they version controlled really heavily. So they version control the plugins, they do the mu plugins, but then WordPress itself is managed separately from your repo, but it's also version controlled on their end on the platform level. I think with like managed WordPress, one of the things we're seeing is that when it's managed right.

[00:26:16] They will version control. In some manner, the WordPress piece for you, they might even offer you the ability to version control plugins sometimes, but outside of the WordPress part, that's when it starts to like, change. It can vary between like, different hosts. You know, some will let you do whatever you want.

[00:26:38] Some will have. The ability to version control one thing, but not the other thing. Uh, that's something that I've been kind of deep in the weeds in recently. Um, but all of this sort of is, I think, pointing towards the concept of just in like deployments and continuous integration.

[00:26:57] **Brian Coords:** Yeah, which I think we should get into, but I just want to add one thing about your thing about VIP or Pantheon or these hosts that are a lot more like they really do manage a lot more things through version control. It's been interesting. And by the time this comes out, I don't think the WordPress 6.5 will be out, but it's been interesting because that's been a big topic of conversation with the idea now that WordPress isn't just going to have plugins, themes and uploads. And I know there's a couple other more substantial ones, but like the idea that fonts and essentially patterns they're saying possibly, and template parts, like all these things that were generally stuck inside of your theme would get their own sort of folders so that your patterns have nothing to do with your theme. Just like your fonts have nothing to do with your theme, all these sorts of things like break apart because WordPress is getting so much more adaptable. And so then it's becoming like these interesting questions. And one of the things that almost stalled the release was like.

[00:27:53] Hey, like we didn't build our file systems for just arbitrary folders where users can upload fonts. Like, you know, we have layers of security here. Like you can't just add a new directory. Um, and so it was definitely a conversation and stuff, but like it, it does add into all the nuances of it. But, you know, if you really want this approach, you know, there's also headless WordPress, you know.

[00:28:14] **Aurooba Ahmed:** Yeah. Well, but headless WordPress still has all of these complications because ultimately the back end is still WordPress. So all of the deployment and all of those situations, that's still, that's still a question, you know,

[00:28:27] **Brian Coords:** Yeah.

[00:28:29] **Aurooba Ahmed:** because think about like the block editor. Yes, you have headless.

[00:28:31] So you need fonts there too, but you also need them in your back end for the block editor to be able to preview and render them correctly. So even if you decouple it, you still have the same problem.

[00:28:41] **Brian Coords:** Well, yeah. Cause I mean, you still have, you still have a WordPress you have to host, like you still have to, and it has to be public obviously, because you need like, you need to fetch all your data from it and stuff like that. I mean, there's probably ways to like get a little crazy with caching your endpoints and stuff.

[00:28:56] But yeah, yeah, yeah. No, I think that's a good point. But I just meant in terms of like building out the front end, you could use this sort of approach for your front end and, and get to do that kind of stuff. Um, and you don't, it's just the front end because it's just the front end. It's, it is, you just don't have to think about those things for that piece of it.

[00:29:13] **Aurooba Ahmed:** Yeah. Yeah. And in a lot of situations that may really work out in your favor and a lot of situations that may introduce way more complexity than you should have. So it really depends from, you know, project to project what, where, what makes sense there. That's for sure.

## [00:29:29] Continuous Integration

[00:29:29] **Brian Coords:** Okay. Talk to me about continuous integration.

[00:29:32] **Aurooba Ahmed:** Well, that's something you and I were talking about right before this episode, right? Like there's so many different ways to deploy and now this is one way to deploy, but within WordPress we're starting to see other things, other ways to deploy, obviously, Git, and like you mentioned you could just push right from your local Git, but you know, there's hosts that have GitHub action integrations, for example, right, which lets you do a lot more complex things than just, Hey, let me upload some themes and plugin files, you know, in order, because you may need more than that to be able to actually run your project.

[00:30:07] Yeah.

[00:30:07] **Brian Coords:** Well,one of the really annoying things about WordPress that no one has a great answer for is the fact that you generally don't build your assets after you deploy. So you generally don't, you know, install all your like composer dependencies and you don't usually run like a node build process.

[00:30:24] And you end up with all of your like scripts and everything's in the repo. Like the one thing I love about these two tabs is like, I'm not worried about merge conflicts because we both built our assets because that's the built CSS isn't in the repo. It's not there, you know? So there are, so then you introduce these steps, but in WordPress, like a lot of times there are these kinds of ways where you could do all that ahead of time with GitHub actions or something like that.

[00:30:48] And like, do all that stuff, make sure it's working, see it all happening in GitHub before you put it on the server. And I think that opens up like kind of a cool window that maybe will be a lot less like bundled, like compiled assets in our repos.

[00:31:01] **Aurooba Ahmed:** yeah, I definitely agree with that. I've been recently working with circle CI, which is, you know, a continuous integration tool, which isn't a lot in a lot of ways works a lot like GitHub actions. So maybe a little bit more advanced than that, but that allows you to do that exact thing. You can do, you know, upload an SSH and FTP upload whatever you need through that tool, but you can also say, hey, run this compo or set up a node environment or set up a PHP environment and run this command to get all these dependencies and then put those dependencies on the server for me because I don't actually have them in my repository and I don't ever want to.

[00:31:39] And figuring out that process has been really interesting because there's so many ways to do that than connecting it to a host and being able to SSH using sort of a tool into a host server, moving all of that stuff. I mean, I learned more about rsync in the last week than I ever thought I would need to know in order to be able to do this correctly.

[00:32:00] **Brian Coords:** So in that scenario, cause I don't fully like know in this scenario, we're running all of that on the server as we deploy. Right? Like we're like, we're kind of running it here. Are you not like, are you not running your build? Like is, is all the build happening in circle CI or like, how does, is it?

## [00:32:19] The Advantage of continuous integration tools

[00:32:19] **Aurooba Ahmed:** So same thing with GitHub Actions andand CircleCI. What happens is, takes your code and it spins up a temporary environment based on whatever settings you give it. It does all of the stuff, it compiles all the assets, and then from that temporary environment it uploads it to the server. So it doesn't actually run any of the build on the server, it just deploys built stuff to the server.

[00:32:38] That's all that server ever sees. Every time you deploy this temporary working space that sometimes you can also persist, make it like last for longer for multiple deployments for whatever reason you might need, uh, it, uh, That's where the actual work happens. If you need to do, say, composer install or an npm run, you know, npm install or something like that.

[00:32:59] **Brian Coords:** And what do you think is the primary benefit of doing that before it gets to the server?

[00:33:05] **Aurooba Ahmed:** Well, because your server may not have node on it or, you know, or have, say, rsync on it or any of those things that you might need in order to actually take your repository and get it to that compiled state. And it shouldn't have to. Right. Uh, technically your server needs for WordPress should have like, we'll have like NGINX on it.

[00:33:28] I'll have like caching stuff on it. We'll have a PHP environment on it, but you know, let's say that you have blocks are you building? You shouldn't really need to run, have a node environment there. You have your temporary workspace. It runs. npm install or npm, you know, build, it builds the dependencies, builds your blocks, like final files, and then you just ship that off the final files to that server.

[00:33:51] Mm

[00:33:52] **Brian Coords:** That would be really nice because like, like an example, right, right now I've been in a project where I have a lot of custom blocks, a lot of custom JavaScript for, you know, using WordPress scripts and stuff and I make it and it's NPM. So like I say, I'm in NPM run dev cause I'm working and all this stuff like that.

[00:34:08] Right. Well, when I'm done and I want to commit everything, I don't really want to commit. Like the, the like not optimized files and everything like that. So then I got to stop the process. I got to run the build command. Cause that's what I really wanted committed to deploy. It's like,

[00:34:21] **Aurooba Ahmed:** Yes.

## [00:34:22] The value of not committing built files to the repo

[00:34:22] **Brian Coords:** what year is it? Like, why am I doing this manually?

[00:34:25] Like it's so dumb. I, and I, I could probably solve this problem now, like with maybe some sort of like pre commit hook something. I don't know, but like, it just is, is definitely, I can see the value of that. And then, and then plus all the other stuff that I don't have right now, which is like seeing the deployment history, seeing everything like.

[00:34:43] I don't have any of that because I'm literally just doing it locally and then pushing, get to a server somewhere. So, I don't know, I'm excited for this next kind of phase. I think that we're going to see a lot more of this.

[00:34:54] **Aurooba Ahmed:** a hundred percent. I think the git hooks thing that you came up with, that you were, you brought up, I think that's a really good point. You know, when you're transitioning into this kind of workflow, sometimes having that middle step of first getting something to do something on a git hook, right? Which, so every time you commit, it's going to run the NPM run build and then that's, that might get committed instead, that kind of thing.

[00:35:14] That's a really good intermediary step, but getting to that point where you're literally not, right. Repository like committing like compiled files of the repository. I think that is the ultimate end goal and it's going to be beautiful when we all get there.

## [00:35:29] Cross-pollination between WordPress and other spaces

[00:35:29] **Brian Coords:** And I think it ties back to what we were saying at the beginning, which is the way these things come into like WordPress is by people. Doing things outside of WordPress. You know what I mean? Like, like not being in the WordPress bubble where we've done things this certain way. And I know a lot of people think like, Oh, WordPress is getting too complicated or getting to whatever and all this stuff.

[00:35:48] But it's like, there's a reason these things do exist and it's nice to see WordPress slowly not always picking things from the wider world of JavaScript and PHP and saying like, oh, okay, here's some good best practices. And, and we should start bringing those in. And you know, even just this last year in like the Gutenberg project, we're seeing a lot of those things start to like, come into play.

[00:36:12] Um, just a lot of, even just concepts like plug dependencies that's coming in to like script, uh, doing like, uh, like JavaScript, like, uh, modules is the word I'm looking for. Um. And all those sorts of things. So it's like, it's kind of nice that they're finally, even though people complain, it's getting too fancy.

[00:36:29] It's kind of cool, you know?

## [00:36:31] Web Development is more complicated now

[00:36:31] **Aurooba Ahmed:** yes, in some ways it is getting more fancy because the world of web development is getting more complicated just in general, you know? We don't live in the world where you could take a paragraph and put the colored property on it and say red. You know, that doesn't exist anymore. You can't do that. Um, that's not to say that we shouldn't simplify where we can, because we should.

[00:36:53] That's a whole other topic almost.

[00:36:56] **Brian Coords:** And that's not to say there's not a time and a place for a piece of HTML sitting on a server. Like there's definitely like, like the first version of this where you wrote it, like it was HTML and it served its purpose and it was a lot faster. And now it's ready to become interactive.

[00:37:10] And that's the, that's where you start getting complicated, you know?

## [00:37:13] The slow modernization of WordPress

[00:37:13] **Aurooba Ahmed:** Exactly. As you need to get complicated, let's get complicated. WordPress is in this position where it needs to get a little more complicated. And maybe one of the greatest things the Gutenberg project has done is, yes, it has moved a lot of the focus to JavaScript, but you can start to see the paradigm shifts that it's causing trickle back into the PHP code base part as well.

[00:37:35] Things like plugin dependencies, which people have been advocating for, for a long time, right? Mm hmm. It's finally getting into the repo. Why? Because people are understanding the value of it in a way that they perhaps never did before. And modernizing is a part of that.

## [00:37:50] Takeaways from the Next.js Series

[00:37:50] **Brian Coords:** Yeah. So what was your like big takeaway from Next.js? have any like final, just like, how did you, how do you feel like it went? How do you, how do you, how do you feel about WPAudit now? JavaScript-tified.

[00:38:08] **Aurooba Ahmed:** I think one of the really interesting things about JavaScript and in doing this series and doing the JS essential series that That is, as I, at the time of recording, it's coming out right now and it's happening every day. What I'm learning is that, because of the nature of JavaScript, because of how it was already was, you know, and it's a really old language, comparatively, it's just inherently a little bit more complicated because of the way it's architected. It's inherently, uh, has these implicit things that you need to understand about it that don't often seem obvious.

[00:38:49] And then when you add even further complications on top of it, like a whole framework in this case, we have react. And then on top of that, we have Next.js, right? So it's like three layers of stuff going on here. And then hi, I added TypeScript fourth layer. Um, so things start to get complicated really, really quickly and ramping up to that. is not a walk in the park. It really isn't. But once you get there, it's pretty nice. It's a nice view.

[00:39:23] **Brian Coords:** Yeah. Mm

[00:39:24] **Aurooba Ahmed:** But yeah, yeah, I think I have gotten there where there are times when I'm just like, Oh my god, this is way too complicated. What the heck? But there are also times where I'm just like, Yeah, this is complicated because it needs to be. And I like that even though it's complicated, I know how much more complicated this would be if I had to do it somewhere else or in some other way.

[00:39:41] And it's not that bad. Bad. There's a lot of trade offs. There's trade offs in anything, but I will, I will say that with Next.js especially like if you want to make something in JavaScript, Next.js is probably gonna be like worth your time to learn. The takeaways from it will go into other JavaScript frameworks as well really nicely because it was a pioneer of its time and a lot of stuff builds on top of the paradigms that Next.js introduced. So it's a really good one to pick and only pick it if you have a complicated project, don't pick it for something that you could accomplish probably with a little bit of something else like WordPress, or even like a really, really tiny HTML with a little bit of Vue sprinkled in kind of situation, you know, like, JavaScript can get heavy really fast, and we've already talked about the environment a little bit, and that matters too, but you know, performance wise, these things get heavy, so don't include things that you don't need, right?

[00:40:43] Just because that's just the one thing you might know. It's probably a better solution out there for a smaller thing, but if you know that it's going to get big, you know it's going to get complicated, or the kind of functionality you're looking for is complicated in that manner. Absolutely go for it.

[00:41:00] **Brian Coords:** Looking back, would you, would you build this project, this WP Audit? Do, would you build it in Next? Or,

## [00:41:09] CSS in JavaScript: a tangent

[00:41:09] **Aurooba Ahmed:** Yes, I would still build this in Next. I would just never use vanilla extract again, ever.

[00:41:15] **Brian Coords:** That's a different episode.

[00:41:19] **Aurooba Ahmed:** I gave it a chance! I even did a whole episode on it. I tried to convince you, I tried to convince myself. I am not convinced. I am not convinced.

[00:41:29] **Brian Coords:** Yeah, there's, I've, I've never been in a Next.js situation where I've enjoyed the way styling works. I think that's a separate issue. I think it's really hard to do. component specific styling and global utility styling to like it. There's really, you just end up having to make a lot of trade offs. Uh, I've never been happy with that.

[00:41:50] I, there must be a, a place where people are. I don't know where it is.

[00:41:55] **Aurooba Ahmed:** I, maybe I just need more education or something, but on that topic, like I, I understand the value of localized tight little components, but you know what? I love global CSS. I love, I love the cascade. It makes my life easier, way easier than localizing and componentizing in an isolated manner. Some something.

[00:42:19] I think that trade off in bigger projects, it's not as worth it as people might think. That's what I think right now.

[00:42:28] **Brian Coords:** would you have, uh, if you could go back in the chosen tailwind, would you?

[00:42:33] **Aurooba Ahmed:** No.

[00:42:36] **Brian Coords:** No.

[00:42:36] **Aurooba Ahmed:** I know people love Tailwind! And I think there's a lot of good reasons for Tailwind. But they don't convince me enough. There's a really cool article from Heydon Pickering just the other day. I'll put it in the show notes. But I was like, YES! All of this! Yes! This is why! No to Tailwind!

[00:42:54] **Brian Coords:** not the one with like, I did this with Tailwind and I did it with like, semantic. Okay, cause that one bugged me because it was like, it just felt, have you seen that one? It felt so forced. It was like, I made the same thing with Tailwind 15 divs and you're like, I don't think that was necessary. Like I, it

[00:43:10] **Aurooba Ahmed:** that's not true. That's forced. 100%. No, I think it's just an architectural conceptual issue. And you know what? If you, here's what I think it boils down to. If you like CSS and you understand CSS well, you're probably not gonna pick Tailwind. If CSS is not a priority to you, you just gotta get some stuff and make it look decent real quick, and that's totally fine.

[00:43:34] You know, not UI and that kind of thing is not everybody's cup of tea. You're going to go with Tailwind and that's cool too. Me, I like CSS enough that Tailwind bugs the crap out of me. And so I, I just can't.

[00:43:50] **Brian Coords:** yeah.

[00:43:50] **Aurooba Ahmed:** Talk about a tangent.

[00:43:52] **Brian Coords:** I know, this was a tangent. I don't like write, I honestly don't, like, I, I value CSS, but I, I don't sit there thinking like, Oh, I can't wait to get to the part where I have to write the CSS for this project.

[00:44:03] **Aurooba Ahmed:** That's fair. I enjoy CSS. That's that, that's, that's the honest truth. I do

## [00:44:09] What's Next?

[00:44:09] **Brian Coords:** so, have we, do we know what we're doing next? Cause I think we've been typically taking a little soft episode break before we start a new series. Um,

[00:44:20] **Aurooba Ahmed:** Not sure what we're going to do next, but whatever it will be, it'll be interesting. At least to us.

[00:44:26] **Brian Coords:** I have some ideas, so we'll have to talk offline about what our next project could be, and what our next one off episode will be.

[00:44:33] **Aurooba Ahmed:** I'm looking forward to it. So I guess I'll see you in that next mystery episode.

[00:44:37] **Brian Coords:** See you there.

[00:44:38] **Aurooba Ahmed:** See ya.

[00:44:39] Visit viewSource.Fm for the show notes and if you're enjoying the show, we would love a review on iTunes or a comment on YouTube.