Identify the file and the change
Record the exact message from the recovery email or hosting PHP log. It can name a file such as wp-content/themes/example-child/functions.php and a line number. That line is where PHP detected a problem, not a reliable instruction to delete that line. The mistake can occur earlier in the file.
Write down what changed immediately before the error: a theme-file edit, a snippet, a plugin update or a PHP-version change. If visitors only see a critical-error notice, follow the recovery guide to obtain the error. A broken wp-config.php can stop WordPress before its own debug settings take effect, so use the host's log in that situation.
Restore the edited file through hosting
Sign in to your hosting account, open File Manager and select the affected site's directory. Confirm it contains that site's wp-admin and wp-content folders. Download the broken file privately for reference before replacing it. Keep configuration files secure because they contain credentials.
Use the copy saved before your edit, or ask the host to extract that one file from a known working backup. Check the file's path and date. For wp-config.php, have the host confirm that the backup still has the correct connection details, especially after a migration or password change.
- Upload the working copy to the exact directory and filename identified in the error. Replace that file only; do not restore the whole database to undo one code edit.
- Open the homepage in a private window and test the dashboard. If the error is unchanged, ask the host to confirm the edited installation and clear any stale PHP code cache before making further file changes.
- Repeat the original action and check the host's log at the new test time. Keep the failed version privately until the cause has been reviewed.
Use the right route for snippets and packaged plugins
A snippet saved through a snippets plugin can live in the database rather than in a theme file. If that plugin's dashboard remains available, disable the most recent snippet there. Otherwise follow its official safe-mode instructions or deactivate that snippets plugin through File Manager. This also stops other snippets it runs, so check the affected features.
For an unedited plugin that broke after updating, use the plugin rollback guide to obtain the correct package and check data compatibility. Do not patch random lines inside the vendor's files. If a PHP-version change triggered the error, ask the maintainer and host to confirm a supported combination; an obsolete PHP version is not a lasting repair.
When no working copy exists
Keep the broken file and stop experimenting on the live site. Give a developer the error, the recent change and the relevant file through a private channel. They can review the syntax on a staging copy and test the intended behaviour before replacing it live.
For an affected theme, a controlled theme switch can restore access while the original theme is repaired. The design and theme-dependent features will change. Do not replace a customised theme with a fresh package unless its custom work has been preserved.
Keep future code changes recoverable
After recovery, test the homepage, the affected feature and saving a draft. Restore any plugin disabled only for diagnosis once its failing snippet has been removed or repaired. Turn off temporary diagnostics and record the file or snippet restored.
Make future code changes on staging with a private working copy ready to restore. If you do not need the dashboard file editors, follow the file-editing guide to remove those controls. That does not prevent all code changes, but it removes a route for accidental live edits.
Reference material
WordPress explains parse errors and their reported line numbers. Its troubleshooting guide covers recovering access to faulty components.
Get help with the next step
If there is no working file copy or the error is in unfamiliar code, ask BugShield to assess the recovery. Share the error and what was edited so a developer can confirm the next step and price.