WordPress core updates on Pantheon can occasionally stop with a Git merge conflict even when the site has no customizations inside WordPress core. In one support case, a Pantheon upstream update failed while applying a WordPress 7.0.2 patch because wp-admin/about.php had drifted from Pantheon’s version.
The conflict was not caused by custom site functionality. The file still contained an older WordPress changelog fragment from a previous Git state, and each WordPress release rewrites the same section. After verifying that the conflict involved only stock WordPress code, the conflict was resolved safely and the update was deployed to a Pantheon multidev environment for review.
Issue background
A WordPress site hosted on Pantheon was unable to apply an upstream WordPress core update because Pantheon detected a merge conflict.
Pantheon’s update workflow merges Pantheon’s WordPress repository into the site repository. If the same file has changed on both sides, the merge stops so the conflict can be reviewed instead of overwriting local changes automatically.
In this case, exactly one file conflicted:
wp-admin/about.phpThat file is part of WordPress core and powers the admin “What’s New” screen.
Diagnosis
The developer reviewed the conflicting file and confirmed that it did not contain custom site code.
The local copy of wp-admin/about.php still contained an older changelog entry dating back to an earlier WordPress version and the site’s transition into Pantheon’s Git workflow. Because newer WordPress releases rewrite that same portion of the file, the stale content created a recurring conflict with Pantheon’s upstream version.
The update itself modified 141 files across WordPress core. Those changes were limited to:
wp-adminwp-includes
The update did not touch wp-content, where the site’s custom theme, plugins, and must-use plugins lived. It also did not modify wp-config.php or server configuration files.
That distinction made it possible to treat the conflict as a stock-core mismatch rather than a custom-code collision.
Resolution steps
The documented process was:
- Identify the exact conflicting file. Review Pantheon’s update error and confirm which file stopped the merge.
- Inspect the file for custom code. Do not use an automatic conflict-resolution option until you know whether the local file contains site-specific modifications.
- Compare the conflict with the upstream WordPress version. In this case, the difference was an outdated changelog fragment inside
wp-admin/about.php, not custom functionality. - Confirm that custom site code is outside the affected core paths. The update changed only WordPress core files under
wp-adminandwp-includes, while the site-specific work lived underwp-content. - Use Pantheon Auto-Resolve Conflicts only when appropriate. Pantheon’s Auto-Resolve Conflicts option resolves conflicting files in favor of Pantheon’s upstream repository. That was considered safe here because the only conflicting file was stock WordPress core with no custom changes.
- Deploy the resolved update to a test environment. The conflict was resolved and the WordPress update was deployed to a Pantheon multidev environment for review rather than pushed directly to production.
- Review site-specific configuration separately. The task documented one custom object-caching line in
wp-config.php. This update did not affect it, but future updates should still include a quick verification because Auto-Resolve favors Pantheon’s copy of any file it resolves. - Be aware of removed default themes. The site had unused bundled WordPress themes removed. A future core release that updates one of those removed themes could create a different conflict that Pantheon Auto-Resolve would not fix automatically.
- Consider realigning drifted core files permanently. The developer recommended resetting the remaining drifted core file to match Pantheon’s copy so routine future updates could apply without the same merge conflict. The task documents this as a recommendation, not as completed work.
The important safeguard is to treat Auto-Resolve as conditional, not universal. It is appropriate only after confirming that the conflicting core file does not contain legitimate custom changes.
Final outcome
The Pantheon merge conflict was resolved successfully, and the WordPress 7.0.2 update was deployed to a multidev environment for review.
The investigation confirmed that the conflict came from stale content in wp-admin/about.php, not from the site’s custom theme, plugins, or must-use plugins.
The team also documented a safer long-term path: keep custom work out of WordPress core, verify any conflicts before using Pantheon Auto-Resolve, and realign drifted core files with Pantheon’s upstream repository when appropriate.
If your Pantheon-hosted WordPress site is blocked by a core update merge conflict, contact Freshy. Our WordPress team can review the conflicting files, distinguish core drift from real customizations, and help resolve the update without overwriting site-specific code.
