WP 6 and Full Site Edited site not properly uploaded to Flywheel

[vaporboy]

Issue Summary

I’m in preliminary development of a Wordpress 6 site using full site editing (FSE). When pushing the site to Flywheel. My FSE template changes are. not reflected. Changes I made to the header, footer and page templates are not on the remote Flywheel Server

I am pushing the files and the database to Flywheel. I’m trying to work with Flywheel support but they are not having any luck with a solution.

I’ve spun up a new site on flywheel as well and deployed to it and I get the same results. I thought that when you make FSE template changes that those changes get saved in the DB. I would expect to see those changes up on Flywheel. I’ve never had this issue before but I’ve not developed on WP6 and FSE until now.

Troubleshooting Questions

• Does this happen for all sites in Local, or just one in particular?

• Just this particular site.

• Are you able to create a new, plain WordPress site in Local and access it in a Browser?
  yes

Replication

Create a WP site using the Frost theme from the Wordpress them repository. Then edit the frost templates within Wordpress changing the header and footer.

Deploy the site to Flywheel using Local

System Details

• Which version of Local is being used? 6.4.0+5927

• What Operating System (OS) and OS version is being used?

  • macOS Monterey 12.4

• Attach the Local Log. See this Help Doc for instructions on how to do so:
  -local-lightning-verbose.log (264.8 KB)

Security Reminder

Local does a pretty good job of scrubbing private info from the logs and the errors it produces, however there’s always the possibility that something private can come through. Because these are public forums, always review the screenshots you are sharing to make sure there isn’t private info like passwords being displayed.

[brandonjp]

Geez… thought I was going insane. Locally, I’ve got a custom template and template parts HJC template parts local vs production · CleanShot Cloud and the same issue that they are not showing up once pushed with Local hjc local vs prod · CleanShot Cloud

An additional note that I’ve tried changing settings inside Local to turn MagicSync OFF CleanShot 2022-06-03 at 14.17.52 - local magicsync off · CleanShot Cloud - which made no difference whatsoever.

[vaporboy]

Brandonjp, thanks for the input, i’m continuing to work with the great Flywheel team to find out what the deal is, I’m sending them screenshots, logfiles and the actual site right now. I’ll post any solutions they propose.

[ben.turner]

Thanks for opening this topic – it’s certainly a new frontier of dev’ing with FSE! I’m still newish to how FSE changes should be migrated between environments, but let’s see if we can figure it out!

I’ve been able to replicate the issue, but I’m not 100% sure of a fix yet. One thing I saw while testing was if I made FSE changes to the remote site and pulled it down, those changes where present in the Local site. @vaporboy @brandonjp – in your testing, did you try testing that workflow of pulling down FSE changes?

To recap what I’m seeing:

Replication

1. Create new site in Local
2. Open WP-admin
3. Navigate to “Appearance > Editor (beta)”
4. Click the “WP” icon in upper left, and navigate to “Template Parts”
5. Add a new Header template part
6. Click the “WP” icon in upper left, and navigate to “Site”
7. Select the header section and click “Replace” to use your new template part
8. Save the updated templates
9. Push to FW
10. Note that the remote site hasn’t been updated

Observations

• Pulling an FSE change from remote to Local works as expected

• Pulling an FSE change, the wp_template_part post types exist in both environments, but the remote site isn’t using the update template part.

• Pushing an FSE change from Local to remote doesn’t work

[brandonjp]

@ben.turner Thanks for working on this. Because my initial site is now in production, I’ve only been able to test on syncing a Flywheel Staging site with a new/fresh Local site. However, as of today at 5pm Central, strangely everything seems to be working!

Specifically, regarding creating/editing/deleting Templates, Template Parts and selecting Site Headers/Footers, I can confirm:

• Pulling from a Flywheel Staging site to a new Local site - works as expected!
• Subsequent push/pull between that same Flywheel Staging and Local site - works as expected!

Note: I have MagicSync turned off. I am always selecting “include database” when pushing/pulling. And I have noticed that it might take up to 2+ minutes after a push completes before I am able to see the new Templates & Template Parts on the remote staging site.

Not sure what changed, but definitely seems to be working as expected on my staging site.

[vaporboy]

Ben, I was able to replicate what you found in that, I can make FSE template changes on the remote server and pull them in locally, but definitely not the other way.

[bradhogan]

Any update on this? Still seeing global styles in my header and footer templates as well as fonts not being moved from my local environment to Flywheel production.

[austinwendt]

Hi all, we’re actively working on this one; this one has been a little bit more tricky to track down than we had hoped. We’re trying to determine if the issue is in Local or if it is somewhere in the Flywheel service that we use to push/pull files.

I’m hoping we’re close, I’ll post here as soon as we’ve got a fix!

[ben.turner]

Thanks for your patience everyone! I think we have a fix that should be included in an upcoming release (probably 6.4.2)

In case you’re curious about why this was happening as well as a workaround, keep reading!

The Bug

The basic issue was that by default, Local creates new WordPress sites with the wp_ table prefix. Also by default, Flywheel creates new sites with a table prefix that’s different, and looks something like wp_xxxyyyzzz_.

The problem was that during a Connect Push, Local was incorrectly updating some option values that WordPress was relying on to find those FSE changes.

As a concrete example, for a remote site with a table prefix of sassy_ and a local
site with a prefix of wp_, we were changing this sql:

INSERT INTO `wp_term_taxonomy` VALUES (2,2,'wp_theme','',0,2); 
INSERT INTO `wp_term_taxonomy` VALUES (3,3,'wp_template_part_area','',0,1);

into this sql:

INSERT INTO `sassy_term_taxonomy` VALUES (2,2,'sassy_theme','',0,2); 
INSERT INTO `sassy_term_taxonomy` VALUES (3,3,'sassy_template_part_area','',0,1);

when the correct replacement should look like (note the table prefix is
updated to sassy_, but the option has the original wp_ string):

INSERT INTO `sassy_term_taxonomy` VALUES (2,2,'wp_theme','',0,2); 
INSERT INTO `sassy_term_taxonomy` VALUES (3,3,'wp_template_part_area','',0,1);

Workaround

You can get around this in a couple of ways.

1. Pull the site down before making any changes. This will ensure that the table prefixes are the same between the local site and the remote site.

2. If you’ve already made changes that you want to deploy, you can still push those changes up to the FW site and manually update the two values in the remote database using the FW db manager. Here’s a screenshot that highlights what options need to be updated remotely:

[vaporboy]

Thanks for looking into this and fixing it for us! I look forward to the Local update so that I can get back into my normal workflow!

Thanks again for your support of your developer community!