Integrating Flywheel Site with LocalWP and Git for Team Collaboration

I’ve pulled our live WordPress site from Flywheel into LocalWP and initialized a Git repository to track changes. After pushing this setup to GitLab, another developer cloned the repository and attempted to run the site in LocalWP. However, they’re encountering issues, likely due to missing database configurations or plugin dependencies.

What’s the recommended workflow for integrating a Flywheel-hosted site with LocalWP and Git to ensure seamless collaboration among team members? Any guidance on best practices for syncing databases and managing plugin dependencies would be appreciated.

Hi @chiragt

To help us make sure we’re providing accurate details, could you share the following for you and your team member who was encountering problems?

  • What is your OS/OS version?

  • What version of Local are you on?

  • Please attach a copy of your Local Logs

Keep us posted and we’d be happy to help further!

Hi @Nick-B,

Thanks for the quick response.

I’m using Ubuntu 22.04 LTS with LocalWP version 9.2.4+6788, and my teammate is also on Ubuntu 22.04, using LocalWP version 9.2.3+6776.

Here’s what we’ve done so far:

  • Pulled a live WordPress site from Flywheel into LocalWP
  • Initialized Git inside the app/public folder and pushed it to GitLab
  • My teammate cloned the repo on her system
  • Created a new LocalWP site, replaced the wp-content folder with the cloned repo

The problem:

  • The site crashes locally due to plugin-related fatal errors (like Elementor)
  • After disabling those in the DB, it throws more theme-related PHP errors (e.g., in_array() on non-arrays)
  • It’s becoming hard to validate changes as the site doesn’t boot cleanly after cloning + replacing files

We want to establish a proper workflow so devs can clone the repo, sync the database, and run the site smoothly in LocalWP.

Let me know if you need anything else — happy to share logs too (log from teammate’s localwp).

Thanks!
local-logs.zip (297.5 KB)

Hi @chiragt

It doesn’t sound like your teammate is pulling the site from Flywheel but trying to create a new site which wouldn’t work. After you make all of your changes and push to Flywheel, then the next team member will need to pull that site down from Flywheel to make their changes.

If you’re still having trouble could you elaborate on what you’re storing in git? Are you trying to store the whole site or just the theme, plugins, etc?

Hi Nick,

Thanks for the follow-up!

Yes, you’re right — we’re not pulling the full site from Flywheel each time. We’re only storing and tracking our custom theme (wp-content/themes/bridge) and sometimes plugin changes in Git.

We init Git inside app/public, commit only the relevant parts (mostly wp-content), and then push to GitLab. Our teammate creates a new site in LocalWP, replaces the wp-content folder with the cloned repo, and tries to validate changes — that’s where the DB and plugin issues start.

We didn’t want to pull the whole Flywheel site every time just for small changes. Is there a cleaner way to sync the DB + validate dev changes without cloning the whole thing each time?

Appreciate your help!
chiragt.zip (249.5 KB)

Thank you for the clarifications here @chiragt! Yes at this time even for small changes you will need to do a full pull from Flywheel in order to avoid the issues you’re running into it. We know this isn’t the easiest way for a full team collaboration but could you give that a try and see if you still hit any snags?

Hey @chiragt - just chiming in here too. You are able to pull database only when pulling down from Flywheel - see my screenshot here.

In this case, I think the best workflow would be:

  1. You make changes on your machine. You commit those to your Git repo and push the changes up to Flywheel.
  2. Your teammate can git pull the changes down to their machine. If they need a current copy of the DB (it sounds like this is the case with your setup), they can pull the database only down to their machine from Flywheel. This should be much faster than a full site!

This makes sure that code moves up (machine → git/host) and data only ever moves down (host → local machine) - this will ensure you’re not at risk of overwriting production data with testing data from dev.

Same goes for pushing back to Flywheel when you’re collaborating - be careful and potentially uncheck the database when selecting what to push back up!