![]() ![]() I think there are other approaches to this that would work, but I ended up with wordpress_data in my repo, which is mounted to the top-level of the server's below. One of the key things I needed to figure out is what exactly I need to push to WPEngine, and how much I want to version control. It lets my configuration for how the local site runs be code that is stored in my repo, and I like that kind of thing. Local also lets you push the site up to your WPEngine environment with a single button click, which might be nice for many use cases, but I wanted to silo all the changes to the site's code through a git-based deployment workflow. Local didn't really feel to me like it was intended to work with git, although I'm sure it's not too hard to make work. I prefer Docker to using WP local because I get more control. So instead, I have things set up so that a Github Action runs which deploys to WPEngine when I merge a PR into master. ![]() I found it to be too rigid for my liking, especially because I wanted some semblance of CI that let me lint code, run tests, bundle and build JS stuff, and that kind of thing. I'm not actually using Git deployment as WPEngine's documentation describes here. For months now, I've been using Docker to run my site locally, and pushing it to WPEngine using their Github Action. I'm new to the Wordpress world, but it doesn't sound right to me that there isn't a common workflow for developing locally and pushing changes via git.Ĭan I just pull the site using Local, develop, and push changes via Git? What do y'all recommend? I reached out to their support, and they said that it's kind of an unknown to them, and that using one or the other is what they expect. If there's a better solution to this than Local, I'm interested. I know about Local, and have reviewed WPEngine's documentation on using Git, but I'm unsure of how to get a local development environment and version control my site through WPEngine's git interface.Įdit: Due to dependency on legacy page builder nonsense, I need to have a local and up-to-date copy of the live database, which is why Local seemed to make sense to me, as you can pull down changes easily without having to export the entire site. ![]()
0 Comments
Leave a Reply. |