 Welcome to Don't Bake Live, using a staging site that can make your life easier. A lot easier. Jamie Schmidt has been a part of a particular passion for creating excellent content experiences. Originally from Milwaukee, Wisconsin, he has been working as a WordPress freelancer and consultant since 2012. He regularly takes sites from conception to a well managed build process that encourages communication, planning, and smart use of content. He has a background in information architecture and content strategy, and a big old enthusiasm for all things WordPress. Now looking at Portland, Oregon, Jamie is a community evangelist for SiteLock, traveling the country and helping build awareness over websites security, best practices, and solutions. Let's give a big hand to Jamie Schmidt. Yes, it's true. My name is Jamie Schmidt. I am a community evangelist for SiteLock, and I've been doing development since 2012 for clients of all sizes. From freelance, very small business, to working in enterprise. In that time, I have seen sites get hacked, I've seen sites go down, I've caused sites to go down. I've been exposed to those things, and I've worked in a lot of different development environments. I pretty much learned, as many of us eventually do, that having an intermediary site in between you and live is a good idea so that you can have a great life. That's what this talk is about. First, you need to get your site updated, but making updates and changes is dangerous. If anybody has ever made an update online, then cause sites to go down. It's a very bad moment for you or your clients, but you need to keep them updated. Updating on a staging site is the ideal way to do it, and especially with 5.0 coming down the pipes, or relatively soon. We're going to be doing a lot of updates for clients. We're going to be updating a lot of our own sites. Knowing how to do something like this is going to come in handy very soon. First of all, there's two different directions you can take. One is the user implementer, and one is a developer. I just wanted to ask who in here considers themselves either a user or somebody built your site for you, or an implementer, which would be maybe you build sites for others, but you don't necessarily do very much code. Who is more of a developer? Actually, that's pretty much even. I'm going to be doing both. For the development side of things, that's a very personal opinion and decision that you have on development. I'm not going to go into every single option, but I'm going to go through and hopefully get something for you thinking in your own staging site. What is a staging site? It's a private copy of your site that you can test updates, you can do development on, you can do things like install new plugins and themes and all kinds of things in your own private environment where the public doesn't see it. So you don't have to worry about, in case you do break something, it's not going to affect your life. So when I say staging or when I say maybe like a development site or anything like that, I'm talking about the site nobody sees and when I say live or production, that means your site that's on the internet that your clients are going to and using every day, the one that you really don't want to break. So how does a staging site work? There's pretty much three things that it really has to do, make an exact duplicate of your live site. And that's because you want to make sure that you can predict any sort of issues that's going to happen with your live site. You don't want to have different WordPress versions. You don't necessarily want to have different content, different plugins, different themes. You want it to be as close to the live site as possible. And then you make your changes, maybe you make updates, features, whatever. And then when those changes are all good, you push it up to the live site knowing that it's probably not going to break. Those are just three very basic simple sounding steps, but it's not necessarily that easy. And I know that this talk is how using a staging site can make your life a lot easier. And that's true, but it does take a little bit of a time investment upfront to get that whole workflow set up. So there's a couple of reasons that it's not that easy. And understanding these reasons is going to help you make decisions on what your solution is going to be that, you know, that you're going to try out and depict the one that's right for you. So when you do changes in WordPress, WordPress has physical files like index.kp and then they also have database files and that would be sitting in your MySQL database on your server. But when you make changes, the changes can include both physical files and database changes at the same time. Sometimes it can be just files. Sometimes it can be just database changes. So databases are hard to sync. That's a very important thing to know. For lots of different reasons, WordPress has some specific reasons why it's difficult. WordPress uses static URLs in its database. That means when you start the new site, it literally will say www.mysite.com in your database. So if you want to take that exact database and plop it into another location like maybe staging.mysite.com, those URLs aren't going to work. You need to go through and change those URLs so that they match the new location. And it's not even that simple either because WordPress also uses serialized data, which means basically encoding some of the database entries in a way that you will also need to update those in a more involved process. And then also different environments. The development or the staging of WordPress you're using is not necessarily exactly the same as your life site. Maybe you're using a local development kind of solution. That's not necessarily going to be the exact development and the server setup that maybe you have on your GoDaddy or WP Engine or whatever you're using. So those are sort of the main things that make this a little bit of a difficult solution to put into place that you have to figure out your own answers to those issues as you go. So understanding what is required, getting down to the real basics of what you need in order to accomplish this. You need to have a replica of your life site. You need to put it someplace that it can run as a website where WordPress uses a database, it uses MySQL, it uses lots of different software that you need to basically a server to run. And then you need somehow to get those changes to your life site. So those are things in mind. I'm going to talk about setting up a staging site for users and implementers. And so I try to introduce this in a way that if you are just a user, I don't mean to say just a user, but you have limited development knowledge or an implementer, I want to present these in a way that someone doesn't necessarily need to know coding in order to achieve. So the first thing, this isn't really necessarily a step to creating a staging site, but it's very important. So you need to audit your site. You probably should audit your site regardless. And if you've recently done it or you're very intimately familiar with everything that's on your site, if you're very familiar with your hosting and what kind of access your hosting gives you to the various things that they're using to run your site, what service level do you have? Do you have a subscription that is going to give you access to creating a staging site? Is it going to give you access to creating your own some domain? Or is your company maybe limiting your access to doing these things? Thinking about how busy your site is? Because one of the things that we're going to be doing is we're going to be taking a copy of our live site and putting it somewhere else. So depending on how long it's sitting somewhere else, you might have live things happening in your site. People could be adding comments. They could be making purchases if it's an e-commerce site. They could be just adding user contributing content. So all those things could be happening. Meanwhile, you're still on your staging site with a copy that's now somewhat updated. So you have to think about that when you think about how you're going to process change them. Are you using version control? If you don't know what that is, is your developer using version control? Because if they are, they might have a process already in place. And that'll also sort of give you something to follow when you're thinking about a development workflow or just a workflow for doing this. The size of your site? If you're creating a staging site on your existing hosting, minimally you'll have to have enough space to host two versions of that website, the live and the staging. Some staging solutions actually require that you have enough space to host three because they sort of set up a temporary website while they're moving them across. So make sure you know how big your site is and how big your hosting space actually is. Another important one is are there any automations on your site? So for example, there are some plug-ins or services that do auto-emailing where they will send out some automated messages to your users and that will include maybe a link back to your site. So if that comes out on your staging site, it will automatically have your staging URL. You don't want to send that out to your clients. So get really familiar with what's all going on your site, what you have access to, what your environment is, is really important for setting up a staging site. So yeah, what are your actions? The first one is one that I really like for clients where I do a lot of volunteer work and I don't necessarily have time to do a lot of support for them. And I want to put something in place where they will be able to take it and update it themselves with minimal work from me. So a lot of postings offer something called one-click staging. And this is going to be in your CPAL or it's going to be someplace in your hosting account or your dashboard that's going to allow you to click a button to create a new staging site. And it's going to duplicate live, automatically build that sub-domain or whatever the new URL is and then give you separate access to it. It's easy and fast but it's also more expensive because hosts that include that sort of integrated solution, that takes a lot of support and it takes a lot of constant work. So they're going to be a little bit more expensive. But you can see that this is WP Engine. When you're literally logged into the WordPress admin, you see a section in there called staging. And you see the button that says copy site from live to staging. Like that's super simple, you push that button. And then you see the right button, which is deploy site from staging to live. And it's red because they want you to think about the things that I sort of went over when you're doing the audit of your site. Making sure you know what you're overwriting, making sure everything's definitely working right before you go ahead and push that button. There's a good amount of hosts that offer one-click staging. This is not a comprehensive list. But depending on what your host has, look into it. See if they offered a lot of them do. If you're a client or you do not have hosting, maybe consider one of these because it's the easiest solution and it's the fastest solution. And that maybe you only have, maybe you don't have the level of access to be able to create that from the staging panel. Maybe you don't have the budget. There's also a staging plugin called the vp staging that you can use. The vp staging, you install it right into your live site. And what it does is it automatically spins up when you WordPress install. That's sort of sitting inside your live site, but it's completely separate. It's free in the plugins right now. I believe it does have a premium version that gives you a lot more options. And then it also migrates the changes to your live site. So sort of like the doing engine where it's pushing the run button, this one will push your changes over. And it can do content changes. I think the free version will just push content changes for you. The pro version can allow you to do a full migration of your site. So that would be if you're doing a WordPress update and you're updating a lot of things in WordPress core that you don't necessarily have the ability to cherry pick and push them over, you can do a full migration. And then a standalone site. So this would be something that sits in a subdomain or subfolder. But the difference between this and the plugin is that this is manual. So you're going to go ahead and create a subdomain on your hosting manually, go through and set up your DNS and all that kind of thing. And if you have a firewall, you know, you can do that. So you're going to be creating that subdomain. And then you're going to duplicate your live site yourself. And you're going to put it up onto that subdomain. And then you're going to use another solution to take your changes and migrate them or push them to your live site. So this one is a bit more hands-on. But it's a good solution for people that are maybe have a more limited budget or they want to have more direct control over exactly what they're moving and exactly how they're moving it. So this involves using a couple plugins. One plugin that's going to package up your live site into an archive so that you can take that archive and basically republish it onto your staging site. So that's one. And the reason that we need that plugin is among other things because of that URL issue. So I'm going to make your changes. That part is pretty simple. And then so we have the issue of how do you get those changes back into your live site. One of the more manual ways to do it, probably the most manual way to do it is to literally just go to your live site and make those changes again. So this would be maybe you were doing an update of your theme and you're like sometimes when I update the theme things break. So I'm going to just push the update button on staging and then everything's good, nothing broke, that's awesome. I'm just going to log into my live site and push the update button. So that one is as easy as it can be more time consuming. But there are also plugins that allow you to basically push your site or part some of your site to the live server. And then so I'm just going to go through some of the plugin solutions and just some of the general solutions for this. So for duplicating your site. So this is one of the manual things that you have to think about if you were going to be moving it yourself. So basically what's involved here is you create an archive of your site. This will include database one and then all the files that are necessary to completely rebuild that so you know WordPress is using database. You need to package up that database and include it with your site files and then have another plugin on the other side that's going to open up that zip file and create your database run all your files to that. So I think I have some examples at the end of this. So then migrate your site. That is reinstalling your site onto another server. So when we're talking about duplicating this is actually sometimes called archiving. So if you're creating a backup solution in place maybe creating an archive check and see if it's saving the database and also check and see if it's saving your full full site. I'm not really going to talk about backups in this talk but you should be backing up your site regularly and you should be also testing those backups to make sure that you can reinstate them. If you do have a full backup including the database including everything you need you can use that backup to you know to rebuild it onto your staging site. So in the migrating that's actually pushing it to the new place. Reinstall it on another server make sure the database works, make sure the URLs are all updated. So serialized data that you need to find in the place. There is a config.hp file, WP config.hp and that thing that has stuff like the database location the database password, the database user those are going to change with your new staging site because you're going to have a different database essentially. So those things have to be updated if you have robots.txt If you're a developer and you're using any developer tools removing those developer tools changing the error reporting that you know you've been maybe using a troubleshoot, any kind of notifications that you don't want on your public basing site if that's your version. And then any cachings, security, email automation you don't necessarily want to have caching enabled on your staging site because sometimes caching won't show you exactly what's going on because it's going to be caching. So disabling caching, remember that you disable the caching and re-enabling the caching when you push back to live. So I've been saying sync there's also another word called word there's a difference between those two and that difference is important when you are thinking about how you would like to overwrite your live site. So syncing is basically you're overwriting your live site with your staging you've created a staging site, you've made all the updates you're pretty sure nothing has changed on the license so you're free to go ahead and overwrite the entire install basically with your staging install, that's all updated. So that's overwriting everything. Merging is a situation where it can be really useful if some things have changed on your live site like comments, like order and you've made changes that don't affect those orders and you just want to push those changes. So this is difficult because of you can't really merge a database easily so there are some solutions where you can merge parts of it where you can decide what files you want to use and merge those but it's very complex. There are some solutions that are sort of doing it well pretty well and it's sort of an ongoing thing that even developers are looking for a really good solution to. When you have a development environment when maybe you have three different people working on a site and maybe they're all making their own updates to a database you would like to ideally have all of their updates go into the new database and all not compete with each other and all go into exactly the right places. It's not that easy to go. So tools here that you can use a lot of them are plugins. So there's Duplicator. It allows you to just create an archive of your site right from your WordPress dashboard. It has a free paid version. The free version can do if you have a not so big site it can pretty much do everything you need to do. If you have a very big site you probably want to go with the paid version. It basically archives it in a little bit different way. Backup buddy. It does backups. You can automate backups with that. It's a good backup solution but it's also a good way to create your archives if you want to go with the staging. WP migration. This is four more larger sites. I don't believe that there's a free version of this. Yes, sorry. But the paid version has obviously more options in it. It also has WPCL integration. So if you're a developer you're able to access it from this panel. And then up drop class. Same thing. Backups. You're saving it to cloud. You can do WPCL. A lot of these do the same things. They're at different price points. Some of them do slightly different things. So really just looking at name-trying a lot. Looking at the one that works best for you. And then we have MigrateDV which does the database migrations. And this is something where it allows you to do more complex database migrations. So if only a few things change in your database and you really want to push those few things, this plugin can help you do that. And there's WPCL SightSync. So WPCL SightSync is a plugin. It's a free version. The free version pretty much only syncs up content. But the paid version it's kind of expensive. It's $130 a year. But it allows you to do very granular sort of picking and choosing what kind of things you want to push to your website. And they've got support for a lot of different plugins, custom post types, ACF, that kind of thing. So this is just going to play. So this is just going to play. I think it's a quick demo that they have on how it works. So the staging site is on the right and they are moving some changes from the website to the staging site. So it happened pretty quickly but there's two buttons there that say pull in and then there's another one that says push. So it was really quick. But basically what you kind of saw was that it's changes and then when you refresh you could see those extra pieces of content on the staging site. So that's pretty cool. And another solution which is really it's sort of a development solution but you can also use it if you are a more of an implementer is having a local WordPress install. There's a couple solutions that are out there right now that will set up a custom local development environment that's specifically for WordPress. Desktop server I believe is a very fresh one that offers something like this and they've been around the longest. These are your installed software on your computer that allowed it to run as a server. So that now you can run your WordPress site right on your computer as if it was a server like your host. Desktop server is not the only one there is local by flywheel has one but I'm pretty sure you need to have a flywheel hosting to use it. You don't? No? Okay, so local by flywheel is also an option regardless of your host. And there's some other solutions that I've heard are in the works for various hosting companies. So this is a situation where you can make those changes on your laptop or your computer. I'm like okay cool, well it actually works so I imported my live site into this development, a local development and the thing works. So now I can go ahead and do it on my live site. And the nice thing that desktop server does and I believe local also is a direct deploy. It basically connects to your live site via plugin and it can overwrite your entire live site with your staging site. So if you've made those changes you can push it straight up there or if you have the sub domain solution where you have your staging site is in a sub domain maybe you can push this to the sub domain. So now you have it on the same host in the same environment and you can better evaluate if this is going to cause any issues now that you're in your server environment. And then you can also push it to live. It's not a solution that I would put in place for just any of my clients because it was a little bit confusing but honestly like desktop server is really super easy to use and if you're looking into maybe local WordPress development they have a free version you can just install it and get it up and running pretty easily and you can just plan on with it. What is a local site? It's running on your own computer using software that allows your computer to run as a server. So all those different solutions there's a lot of different parts to it and I gave different solutions for each one. Every one of those solutions kind of depends on what your own situation is and if you're doing a lot of sites for clients maybe they have different hosting, maybe they have different budgets, maybe they have different needs that's the fun of free of hands, that's the fun of being an agency. You can always necessarily pick what your clients are using. So what make a schedule for doing updates? It's really going to be very useful for you if you at least commit to once a month going in looking at your site, making the updates and then pushing them to your live site. Using a service maybe to track your updates there are services out there that allow you to basically monitor all the sites that you have and it'll tell you when you have a plugin that needs updating. When there's a new WordPress version out and only these two sites are updated to it and these two are. Make all your updates on staging first and then never break life. So that is basically the solution that is good for users and good for implementers. So now oh sorry so evaluating your options. I kind of went over this when we were talking about in the beginning how much time and resources you have for maintenance. If you're an agency that's going to be starting up a maintenance plan and you haven't done it before thinking about how much you actually have to do this maintenance is going to help you inform you of what solution you're using for this. Your budget how often you're going to be checking for updates how often you're going to perform the updates and who is performing the updates. Knowing all these things is going to make it a lot easier for you to put a process in place. Having a process in place is really the best way to minimize the amount of time you're spent doing these things and to automate what you can. Then just some more things. How many sites people that are governance like how many people are verifying the changes those kind of things. Okay so we're going to look at just some quick basic workflows here. I don't know what I have on time. Okay well we're good. So I'm just going to kind of go over some examples. We don't have to really go over all these but I do have the slides that are going to be up and I believe that WorkCamp has these slides up available too. Did I page in confirm the user rules tell your user number update live we have a staging site for that update schedule you know move the staging live to staging make your changes push staging to live. If you're going to do the duplication the same with the doing okay duplicate make your changes push it to live some domain duplicate it using you know whatever plugin you want make your changes and then pushing that live with any one of the solutions that we talked about and then look at local where you can push it to staging or you can push it to live or you can make the changes again on the staging of live. So the developer and developer work is I'm not going to get very deeply into this because developer workflows are very personal thing and the decisions you make are very much reliant on what your entire developer workflow is so I can't tell you an exact staging solution because it really depends on how you're developing your site there's a lot of factors involved here and the things I'm going to be talking about is not anywhere near exhaustive I don't even know about all the options that are out there if you talk to a developer any developer here they're probably going to tell you a very different development workflow every single one unless maybe they work with the same company everybody does kind of something different and that's because everybody works a little bit differently everybody has different requirements and different limitations and different preferences on how they like to work so not extensive but I am going to go over the things that you need to think about when you are making a plan for how your workflow is going to go and because staging is really part of your development workflow this is not a development workflow talk I'm only going to kind of glance over those things okay main things to consider so they're pretty much the same as with the users only I'm using some fancier dove words provisioning the staging site to match production basically this just means you have a way to look at all of your server settings all of your maybe your WordPress settings all your configurations you have a way to package that up and push it on to your maybe your staging site so instead of manually going through me like do I have the same PHP version do I have all of these permissions the same you can actually push that up and it will automatically do that so when we say provisioning that's pretty much what we need another thing to keep in mind sharing keys and configurations across environments and developers things like keys API keys anything like that that's something that you don't necessarily want everyone to have access to but if you have a lot of developers they do need to have access to them so thinking about that all of the configuration settings that you have is also really something that you need to evaluate the time and content gap between staging and production again that's just what's all happening on staging during the time that I've been what's all happening on live during the time that I've been in staging and then deploying your changes getting staging to match production there's lots of different ways and solutions to do this a lot of the solutions require that you have integrated into your development workflow but I'm just going to go over a couple so blueprints are one solution this is where you can create an ideal environment that you're going to be using and reusing over and over again and basically grabbing that thing and using it every time you start developing a new site so that means there's a lot of benefits to that one of which is now you have a predictable workflow so you can work on making that more efficient, you can have more people contributing to it because you know exactly what you're doing hosting companies like Pantheon what I say like Pantheon honestly there's not too many that offer the sort of integrated development that Pantheon offers Pantheon has something called a custom upstream which is their sort of service that you have access to when you host with them that allows you to basically create this sort of blueprint you can pull that blueprint down to live when you're printing in the site you can push it back up so that's really useful if you're using Pantheon WPCI is a command line interface and plugin that you can use for WordPress it allows you from the command line to you know create maybe download a blueprint of your site that has so-and-so plugins configured has so-and-so settings in place all those kind of things so the WPCI is a development tool also but it can be used for doing some sort of provisioning DCW that is a more advanced developer tool I'm curious to know there's a bunch of developers in here does anyone want to share what they're using? totally fine if you don't there's a lot that goes into it so knowing the word provisioning if you're a beginning developer is going to get you pretty far with Google though to be able to figure out what you want to use so the sharing keys in can fade across the environments in developers so like I was saying key is not necessarily something you want to be for example saving into your immersion control in a naked to the highway where somebody can just look at it and config WordPress has a lot of different configurations in it and the configurations that are WP config.php are very minimal compared to the amount of configurations that are saved in the database and the way that WordPress saves a lot of it to configuration is in the table WP options and it's not super easy to be able to just go through and pick and know all of these database entries that are only related to configuration that are in the WP options table so that's something to think about that is the poor solution things like ACF custom fields, those are saved in the database you can also export it in a way so that it saves as a file too things like sending emails, caching all those kinds of things you can turn that on or off WPcfm is a solution walker.io the guy from walker.io is here he gave a talk earlier the solution that his company offers is actually pretty cool they do cloud basically hosting any version for your keys so that anybody can access it without actually having to see what the key is itself if you're using Ansible or something like maybe Trellis if you're using Trellis for your development workflow Ansible Vault has a way of storing that and in another way that various opinions on how how well this works, storing the WPcfm thing in the directory above your site root, it's debatable whether this is really a great security solution or not but it could be a way for you not to include that maybe in your version control. So the time and content gap this is, we're talking about syncing things, syncing databases when you have developers all working on their own version of the database all the databases have different things on them now including maybe content maybe the options table it's really hard to know what everybody is going to be contributing to that database and like I said merging the databases is not super easy doing something like continuous deployments holding our talk minimizes what is all going to be happening on your live site while you're doing staging. So continuous deployment is basically working on very small pieces of your project maybe very small features and pushing them up on a regular basis so now instead of having this entire suite of products you're maybe trying to get out, maybe you push one at a time because it only you know it didn't take it only took a couple days to develop it syncing your files is something you need to think about when someone uploads an image to WordPress it not only saves that actual image in the DOE content folder but it also creates a database entry for that image so you can't just grab all of your images and FTP them up into your DOE content because WordPress isn't going to know that they're there because you didn't upload it through WordPress WordPress didn't assign an ID to it it doesn't know it's there and one of the emerging issues with that is because it's assigning an ID to it if you have three different databases uploading three different files they're all going to have different IDs for their files two files might have the same ID one of them is going to win out so that's sort of an issue Lando is a new tool that is being used and a lot of people really love it I know that Pantheon integrates pretty well with it this is not a Pantheon I don't know if I can pay to say this but if you're doing more advanced development it's worth looking into and then for deployment changes up there and deploy straight from your version control you can give a bit pocket account if you are just one developer you maybe don't have a huge complex workflow bit pocket is nice because it allows you to have private rebuilds for free you can deploy your changes straight to life from bit pocket so now we can sort of talk about a version control talk but if you wanted to create another branch for staging and you make all those changes on staging then you merge them once they're ready you merge them into maybe your production and now you can take those new updates from production and push them up to your life site some hosts offer an integrated development environment a lot of hosts offer git integration right into the hosting not all of course but take a look it's good to have a hosting company that will allow you to have git integration so you can do those pushes more easily lots of deployment tools out there again anybody this is anything wants to talk about what they're using when you are a developer for a long time and you find a workflow that works for you you get very enthusiastic about it and you want to share it with the world so if you just google development workflow with WordPress there are a bunch of people out there that have published all their different workflows and they're very excited about it they're really happy to share with people because when you come up with a workflow that really works for you it's really exciting and it can save you tons of time it can really save a lot of hassle so people are always enthusiastic to share that and there often times are willing to sit down with you and tell them like hey this is super cool see how it works and not the people that created that tool you still get a sense of pride for finding an awesome solution because you know it takes a lot of work to be able to find the one that works for you five minutes left that is actually the end of my talk so thank you but I also do blogging for site lock and I've done some blogging on staging sites so the blogging app up there is really only on the user and user name is on your site I'm working on doing this more developer kind of blogging blog posts so please take a look up there it gets much more in depth so I'm wondering does anybody have any questions yeah if you've set up a standalone staging site on say a subdomain how do you recommend the best way to keep it out of the eyes or out of reach of web crawlers like using maintenance mode or something so I mean you can at least set up like an htaccess kind of level thing where you're having a login to that a lot of the one click hosting they will automatically do it for you so it can't be found you can find maintenance mode but ideally you don't want anyone to ever go to that site at all so maintenance mode is sort of a solution updating your your robots so your site is not being crawled things like that if you have another idea that you use but that is important and that is something that I didn't really talk about is you want to make sure that your staging site is not going to be crawled by google so making sure that it's not findable is definitely something that you need to put in place yeah have you ever used word move word move that's a ruby gem oh no I have not is that something that you use or is it awesome I don't know I've just found it and I haven't actually played it yet but you can post to staging introduction and pull push okay so there's a ruby there's a ruby gem I've never even heard of it I don't know but I bet somebody that's using it successfully is very happy to talk to you about it is there anything else when you're using local by flywheel because I'm looking at using it I do all of our hosting behind the scenes of domain but with something like local by flywheel is there a way that other developers from other locations can work concurrently or do you have to zip it up share and loop around do you know there was someone in the back that corrected me on local being available to outside of their own hosting is that person still here can they answer that because I personally don't know I haven't used local but I do know people that use it and they love it it does it provides a lot more developer tools and desktop server provides some and I know that they're working on coming out with a major version upgrade so I don't know what they're offering but local does have more solutions for development they're here you can yeah that can be something that you can ask someone I don't know exactly I also know that if you open it up to invite other people to get up to your machine but one thing that local does do I think desktop server maybe isn't the worst of doing it or they just recently started is that you usually want to have your site locally no one else can see it but you because it's not on the internet local has a solution that allows somebody from another remote location to look at your local site not really answering your question but that's what he was kind of mentioning that maybe if you're doing development for a client and you want to say hey here do you want to take a look at this you don't have to push it up to like you know a desktop server or something like that desktop server has that too desktop server has that too desktop server has it too desktop server has it too no thank you