 So I'm Brian Steiner. I own No Ventum Customs software. And the title of this talk should be in the future tense. Sam, one of the organizers, was so excited for me to have a pull request submitted to core. In some of the printed material, it looks like it's in the past tense. So I have not patched core yet. So where are we gonna go? Today, we've already done the introduction. I'll give you an example. Then we'll go over some code. In the general case, with things that I like about WordPress core, we'll talk about my plugin and then the UI considerations, a lot of the boilerplate. For what I'm gonna show you guys, there's a lot of code duplication, a lot of boilerplate, and I think there might be a better way to accomplish that. So that's where we're gonna go. And then the questions, comments, criticisms at the end. And like Tim said, if you have a clarifying question or something I said doesn't make sense, just raise your hand, let me know and I can go into it a little bit deeper. Okay, so let me show you the actual plugin that we're going to be dissecting. So this is a reseller form that we created for Pete Oakley right over there, a webmaster located here in Albuquerque. And what this plugin does is based upon the reseller agreement. When I bring one of my customers to Pete and they become one of Pete's hosting customers, he needs to spin up a WordPress site for them. So we accomplish that. So we collect all sorts of DNS information. We say there's an existing site to migrate. It's gonna be 80 bucks to get this going with Pete. This is all using gravity forms. These are forms that Pete customized. And then my plugin is grabbing the data that it needs. And his password prompt requires a pretty strong password. So, and if I can type it in correctly, that would help. I was thinking about asking you to disable this Pete for the, okay, it's testing 123 exclamation with a capital T in case I forget. So we've submitted this form and hey, look at this. We have a new WordPress site. So this site didn't exist before we submitted the form. And we've got a number of non-standard plugins which are installed on the site already. So how is this being accomplished? We use the get option and the add option on the backend. And these are pretty good. So for getting options, you can either get individual options and you can update options with new values. So if you've written a plugin before, you're probably used to this mechanism. And I stole this example from these guys below. Also, you can do this in an array-based way. You can set all of your options in an array and then you can update them all at once. And I like this. Why have a bunch of individual options, right? Like let's have an array of options and you can also intersperse them. Sometimes you'll have a single scaler, sometimes you'll need an array. So what does this actually mean? Like, so how is this important? So if we look at the plugin configuration page and Pete, I added these as password fields so I wouldn't be exposing your secret keys to the whole world during this presentation. But what this means is that for these form IDs, these are the forms that I'm hooking into, that I'm processing the data from. And then these are the plugins that we're installing. And these are zip files that exist within a URL. And the specific versions are interesting. Hopefully these are the latest. And you can just really specify this as a URL and then the new sites will contain that plugin as long as the zip file is available in a valid WordPress plugin. And then we can add new ones. And this is the part that I've worked on recently is this dynamic ability to add and subtract plugins from the array that we're using for the variables. Because these things are always the same, these things can be of varying length. So how did we actually accomplish that? On the core end, I like that. But on the UI, it's kind of a pain, right? Like we have to have this dynamic JavaScript adding and removing things, a lot of boilerplate. See, this add another form, add another plugin, remove last, we generalize that so we can just remove the last thing when we click the remove button, that way we can't remove all of them. You have to have at least one. But the add ones are, if I added another type of thing we'd have a lot more code duplication there. So I don't really like that. So wouldn't it be cool if instead of this kind of thing, we have all of these, this HTML that's for the plugins and we have the remove another, add another, all this duplication is rows in our table, we had something like this. And we have this magic type, right? Or whatever you wanna call it. I mean, if you know Angular, you've seen this type of notation before. Where I create a document on load, I search for this and then I create the add and the subtract button dynamically and then all of the options are set based upon the parent. We could get the size, we could get the type, we could get everything else and then you wouldn't even have to write any of that JavaScript code, you just have to include this magical annotation and then the onload would run through, would look for these, would create the add and subtract button and then it would modify the DOM dynamically. So this would be like entirely in JavaScript, right? This would be totally front end. This would not be a backend modification. The backend using the form variable open bracket, close bracket is like totally fine. You just process that stuff inside of a loop in your PHP, in the PHP end, it's just, and that's great, right? That's like the standard way of doing this. Everybody does that for processing multiple like variable length array things. But on the front end, maybe it's not quite so standard, it's not so cool and there's a lot of code duplication. So this is my general idea. Maybe if other people are interested in this, if you've ever had these kind of problems where you're like, hey, I need a dynamically, like a dynamic list of options for my plugin, how am I gonna do it? This is how we did it and I think that there might be a general solution here. And that's pretty much all I've got. I'd like to give a shout out to Alonzo from 11 Online. He showed me his site spinner upper script which was a bash file and that gave me the initial idea for this. Pete Oakley paid for it. This is part of his reseller plan for his hosting business. I think 11 Online's in talks with him. Once you guys get resellers, you'll probably be using this form to spin up new customers for him. The WordPress Albuquerque community. Jamie back there, I remember when I knew nothing about WordPress, the work alongs were very helpful. Just being able to come and work on WordPress and learn about things was extremely awesome. And then my parents have always been very supportive of any of my crazy business ideas and quitting my well-paying job to start up a software company. So what do you guys got? Oh, and then we've got the GitHub for the code. So I don't wanna get a lifetime ban from WordCamp. So I have to show you guys and provide the code. So that's here under my GitHub. So that's it. Mark, you look like you might have one. A question? Yeah. See the existing JavaScript? Yeah, it might be better for me to bring this up here. Is this readable? So grab this, grab this. I really didn't like this. Add the handlers, remove the last, populate. I don't like this either. It's like I added an extra one and then had to delete it or something like that. Yeah, and then we'd use the WP and Q script to handle that and generalize it a little bit more, right? Like I think the remove has been generalized well enough but not the add, so. Yeah. Yeah, you could just install this on your, so one thing that, yeah. Yeah, exactly. And right now, so this plugin needs to run on the same system that's actually spinning up the sites but you could just go in and you could install this and then you configure your gravity press form or yeah, your form to have these fields. And then as long as it has the fields like the client name, the site name, the different things that you need, then this would just, you'd submit a form and then you'd have a new site. If you want to add this to core, the idea that generalizeable, what are some of the other problems you were managing to provide? So it would just be this, right? This is what I'm talking about right here. Inside of a template file, how do you quickly and easily get this dynamic nature, right? So that's all I'm trying to solve. I wanted to give you guys an example of where this is useful. But all that I care about is having this ability to click a plus button and a minus button easily, right? You shouldn't have to know a ton of JavaScript to get this to work, I don't think. Like this is pretty, pretty basic stuff. And, but it's not easy. Like it took a while to get the JavaScript for this working and I don't think it needs to. I think this is an attribute of making a plugin that should be easy. I mean, it's really easy for these single scalar values, like super easy to get these in here and modify a plugin and say, hey, I want my plugin to take this or I want it to take that, but what if I want it to take a variable number of them? Then it's not so easy. So that's what I'm thinking is my idea. File system or did you actually put another plugin to integrate with that? So we're actually using the WPCLI, the WordPress command line interface to do the plugin installation on the resulting host site. So we make WPCLI calls to grab these plugins and install them after the form's been submitted. So. Well, from that perspective, it's on the host, right? Like, so WordPress fires off these processes and then the host is responsible for the WPCLI calls. So it's like a bash script almost. So yes, 100%. It would be pretty easy to generalize it to Ninja Forms or to any other form, but right now I'm not sure how we would do that, right? We have this gravity form hook and then we hook into the forms based on this form ID here. So we could do the same thing as long as Ninja Forms had the, you know, they have hook mechanisms as well, but right now it's just gravity forms. Is it dependent on that? That is a very good point. There are certain things such as this server pilot. So server pilot creates the initial site, right? We're not actually using WPCLI for that and that's a PIT requirement, right? So server pilot is this sort of like a single click installer and a way to manage your WordPress applications. We could do the whole thing using WPCLI, but then PIT server pilot instance wouldn't be aware of that. What we've tried to do is to put things as user configurable variables. There are some specific server pilot and some specific AW stats paths that are hard coded in here, right? So if you didn't use server pilot and you unchecked this box, that would be okay, but it's not quite ready for just, hey, let's spin this up on any site because of server pilot and because of AW stats. Exactly. Yeah, it's like bandwidth utilization, log watching, what's the current health and status of my WordPress site, mostly from a server level, parsing Apache logs and that sort of thing. It's another third-party tool which PIT uses for managing his installs, so. Do you see that you could probably add either things or even just the zip files of the WordPress sites themselves if you were to get a certain packaging system where you say they fill in the form and you're like, I want to migrate a site and you just add a section where they put their zip files? Yeah, we could make the migration a little bit easier, but realistically, with the work that you've done for Updraft and Duplicator, there are a lot of migration plugins that do a pretty good job, right? Yeah, I'm just using one of those. Like calling it? The thing of, it would depend on its WPCLI integration. I mean, we could, we could just have a, execute this arbitrary code section and then you run through, but I don't think that would be really in line with what we want to accomplish, which is the clean WordPress install with a bunch of plugins and some monitoring configured. So, so what else we got? You guys got any more for me? So you're suggesting, I mean, this whole business is about getting the, getting the cordial, that would be that your distribution may have a special jQuery library to handle, which you're using jQuery. Yeah, so I mean, I would write that and submit it as a pull request. Yeah, so it would be all jQuery. And because I really like the WP, get options and WP set options. Like those are perfect on the, on the server, on the backend, those are great. Nobody needs anything else, but on the front end, it's kind of a pain. So, what do you mean? Also, I have a lot of things for you. Oh, you mean like where they could put in comma separated values? Oh, I see what you mean. Yeah, yeah, like, yeah, I know what you mean. Yeah, yeah, yeah, that would be interesting. Right now, I mean, they're pretty standalone though, right? Like if you add a new form that we want to handle, you just do the plus or the minus, but I can see how those more complicated data type issues could arise. All right, you guys got anything else from me? Well, thanks for being in the audience and listening, hopefully that was interesting and you got a code review in.