How to resolve WordPress core update conflicts on Pantheon

Pantheon WordPress updates can fail with a generic message even when the real problem is a Git merge conflict in WordPress core. In one support case, multiple upstream WordPress updates could not be applied in Git mode, and retrying with Auto-Resolve Conflicts still failed.

The developer cloned the Pantheon repository locally, pulled the WordPress upstream changes, reviewed the conflicts manually, preserved a required Wordfence vendor file, accepted upstream deletion of obsolete WordPress core files, committed the resolved merge, and pushed it back to Pantheon. Because the site had previously been compromised by the wp2Shell hack, the developer also checked for hidden users and backdoors before the update was promoted through Dev, Test, and Live.

Issue background

A WordPress site hosted on Pantheon showed multiple pending core updates, but attempts to apply them through Pantheon Git mode failed with:

Critical: Error: There was an error applying updates. Please try again.

Retrying produced the same result. Enabling Pantheon’s Auto-Resolve Conflicts option also did not complete the update.

The situation required extra care because the live environment had previously been compromised by a wp2Shell attack. Fake users had already been removed, so the developer also needed to remain alert for hidden users or backdoors while repairing the update workflow.

Diagnosis

The Pantheon dashboard only exposed a generic update error, but the underlying failure was a Git merge conflict between the site repository and Pantheon’s WordPress upstream.

The specific conflict pattern involved two types of changes:

  • Pantheon/WordPress upstream had deleted several obsolete core files under wp-includes.
  • Git misdetected a file move involving a vendored Wordfence sodium_compat file:
wp-content/plugins/wordfence/crypto/vendor/paragonie/sodium_compat/src/Core/Base64/Original.php

Because the local repository and upstream disagreed about whether those files should remain, Git could not resolve the merge automatically.

This also established that the generic Pantheon error was not evidence of a broken WordPress database. The failure occurred while applying the upstream code merge.

Resolution steps

The documented repair process was:

  1. Clone the Pantheon repository locally. Working from a local Git clone made it possible to inspect the actual upstream merge conflicts rather than relying only on Pantheon’s generic dashboard message.
  2. Pull the Pantheon WordPress upstream update. This reproduced the failed merge and exposed the exact files Git could not reconcile.
  3. Review each conflict manually. The developer distinguished obsolete WordPress core files from a legitimate plugin vendor file that still needed to remain.
  4. Keep the Wordfence vendor file. The sodium_compat file under the Wordfence plugin was preserved.
  5. Accept upstream deletion of obsolete core files. Files removed by the current Pantheon/WordPress upstream were allowed to remain deleted instead of keeping stale local copies.
  6. Commit the resolved merge. After the conflicts were corrected, the merged WordPress core update was committed locally.
  7. Push the resolved update back to Pantheon. The corrected Git history was pushed to the Pantheon Dev environment.
  8. Run the WordPress database update through SSH. Instead of relying on the browser-based Database Update Required prompt, the developer completed that part of the upgrade through SSH.
  9. Review the environment for compromise indicators. Because of the earlier wp2Shell incident, the developer checked for hidden users and backdoors. The Dev environment was reported clean.
  10. Synchronize and test environments. The updated state was copied through the Pantheon environments so Dev and Test could be reviewed before the change reached Live.
  11. Promote after validation. After review, the update was pushed through Test and Live and the task was confirmed complete.

This case is also a useful reminder that Pantheon’s Auto-Resolve Conflicts option is not guaranteed to solve every WordPress upstream conflict. When Git cannot safely determine whether a file should be retained, deleted, or treated as a move, manual review is required.

Final outcome

The WordPress core update conflicts were resolved successfully and the updated code was promoted through Pantheon’s Dev, Test, and Live environments.

The required Wordfence vendor file was retained, obsolete WordPress core files were removed in line with upstream, and the WordPress database update was completed through SSH.

The developer also checked the Dev environment for hidden users and backdoors related to the previous wp2Shell compromise and reported it clean.

The broader lesson is that a Pantheon update error may be a Git problem rather than a WordPress runtime problem. When Auto-Resolve fails, inspect the merge locally, separate plugin files from obsolete core files, and resolve each conflict based on what the current upstream actually expects.

If your Pantheon-hosted WordPress site is blocked by upstream Git conflicts or repeated core-update failures, contact Freshy. Our WordPress team can inspect the merge safely, preserve legitimate custom or plugin files, and help restore a clean update path.