Hi FlyWP team,

I want to share feedback on a critical limitation in the current cloning and site transfer functionality.

The problem: FlyWP only transfers wp-content/{plugins,themes,uploads,mu-plugins}. This approach assumes all WordPress sites follow the default structure — but in practice, many don't.

What's being left behind:

Custom upload directories: WordPress allows changing the upload path (e.g., /images/, /contents/, /media/). These are defined in WordPress settings, yet FlyWP ignores them during transfer. Root-level control files: robots.txt, ads.txt, .htaccess customizations, search engine verification files (google*.html, BingSiteAuth.xml), uptime monitoring endpoints. Custom directories: /docs/, /downloads/, /assets/ — manually created folders containing PDFs, legacy content, or resources linked from posts.

Security configurations: Custom files for WAF rules, redirect maps, or authentication.

Why this matters: When migrating a site, users expect a complete transfer. Losing files means:

Broken links and missing resources Lost SEO configurations (robots.txt, ads.txt) Failed domain verification (Google Search Console, Bing) Hours of manual recovery work

I experienced data loss during a recent migration. The site appeared to transfer successfully, but essential files were silently omitted. The expectation: Other panels (RunCloud, Plesk, cPanel) transfer the entire document root by default. A site clone should be an exact copy — that's the whole point of cloning. Suggested approach:

Transfer all files and directories within the site's document root Respect WordPress custom path configurations At minimum, offer a "full site transfer" option alongside the current selective method

I'm invested in FlyWP's success and want to use it for more sites. This limitation is currently the main blocker.

Best regards, David Carrero