When a recent functions.php edit or pasted “snippet” breaks the site, WordPress may show a parse error / syntax error (often unexpected … in functions.php on line N), a blank page, or a “There has been a critical error on this website” screen. A syntax error can appear as a parse message, blank page, or critical-error screen. Check the recovery email or ask your host for the PHP error naming the file and line. If normal login and recovery mode are unavailable, use the host file manager or SFTP. The usual cause is one bad character, missing bracket, or copy-paste fragment in a theme’s functions.php (or a file it loads)—related checklists for white screen and site down still help when the log points elsewhere.
Work this checklist in order. Prefer a staging copy when you can reproduce the failure there. Take a backup of the current theme files before you replace anything on production. Do not try to “fix” the syntax by editing live functions.php on production until the site boots again. Restore a known-good file first; improve the code later on staging. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix after you can authorize access.
Define what failed
- A syntax error can appear as a parse message, blank page, or critical-error screen. Check the recovery email or ask your host for the PHP error naming the file and line (for example
functions.php on line 42).
- Note when it started: right after a theme edit, a pasted snippet, a “custom code” plugin save, or a child-theme change.
- If normal login and recovery mode are unavailable, plan on host file manager or SFTP for the steps below.
- Write down the exact error text, file path, and line number before you change files. That is what the host or a fixer needs.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
Parse message, blank page, or critical-error screen after a functions.php / snippet edit | Bad PHP in a theme or snippet file | Recovery email or host PHP log for file + line; then restore a known-good copy |
| Recovery email or log names a snippet / “custom code” plugin file | Snippet plugin | Disable that plugin folder via SFTP/file manager if login and recovery mode are unavailable |
| Log names a plugin or mu-plugin, not the theme | Plugin PHP | Restore or disable that file/folder from disk; see also plugin not working |
| No recent theme/snippet edit; log unclear | Host / other failure | Site down checklist + ask host for the current PHP error |
| Site recovers in recovery mode but front still fails | Theme/plugin still loading bad code | Use recovery mode to disable the offender, or finish restore from disk |
Safe recovery order
- Identify the file from recovery email or the host PHP log. Prefer the WordPress recovery email when it arrives; otherwise ask the host for the PHP error that names the file and line. If normal login and recovery mode are unavailable, use the host file manager or SFTP for the rest of this list.
- Locate that file on disk. Usually
wp-content/themes/your-theme/functions.php or a child theme path. If the path points at a plugin or mu-plugin, treat that file the same way: restore or disable it from disk when Admin is not usable.
- Save the broken file privately, then restore a known-good copy. Save the broken file privately outside the public web directory, then restore a known-good copy. If none exists, ask your host to temporarily remove the child-theme file and retest; features depending on it may stop working. Prefer host backup or yesterday’s deploy over inventing bracket fixes on production. After restore, reload the homepage and Admin.
- If a code-snippet plugin caused it, disable that plugin on disk when needed. Via SFTP/file manager, rename the plugin’s folder under
wp-content/plugins/ (exact folder name varies) so WordPress stops loading it. Retest. Leave it off until you can edit the snippet on staging.
- Confirm the site boots, then harden the next edit. Once Admin or recovery mode lets you work safely, do not paste the same broken code back into the live parent theme. Prefer a child theme, a maintained snippet plugin with revision history, or staging-first deploys. Keep the private broken copy offline until you know what character broke the parse—do not leave renamed copies under the public web root.
- Retest the full path. Open homepage, a post, Admin, and a page that used the snippet. Purge page cache/CDN if an old error page is still cached.
How to read the error line (after the site is up)
- The line number is PHP’s best guess at where parsing failed—often the first bad token, not always the root missing
} above it.
- Compare the restored good file to your private broken copy with a diff tool offline. Look for smart quotes, a missing semicolon, an unclosed
/* comment, or a pasted HTML block inside PHP.
- Re-apply only a corrected, reviewed change on staging. Never treat “edit live
functions.php until the error moves” as the fix path.
Prevention framing
- Child theme: put custom PHP in a child theme so parent updates do not fight your edits, and so a bad child file can be removed without gutting the parent.
- Snippet plugins: prefer ones that can be turned off from disk and that keep revisions. One fatal snippet takes the whole site down the same way a bad
functions.php does.
- Staging: paste and lint PHP off production. If you lack staging, ask the host for a staging copy before large theme edits.
- Backups: confirm file-level backups exist before theme surgery—database-only backups will not restore a broken
functions.php.
Common causes
- Missing
}, ), or ; after a quick paste into functions.php.
- Curly/smart quotes from a blog post instead of straight PHP quotes.
- Editing the parent theme on production with no backup.
- A “custom code” / snippet plugin saving invalid PHP that loads on every request.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help recovering one site from a clear parse/syntax error after a functions.php or snippet edit—restoring a known-good file, disabling the bad snippet on disk when needed, and confirming Admin and the front load again. Paste the exact error line (file + line number) from the recovery email or host log, and when it started. We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full theme rebuilds, new custom features, malware cleanup, and multiple unrelated outages are outside this offer. For blank-page or critical-error paths that are not tied to a functions.php / snippet edit, see also white screen of death and critical error.
Related checks
If recovery from disk does not restore the site, send your host the exact PHP error text, the file path and line number, the theme slug, and the start time. Suspected compromise needs a security investigation as well as restoring PHP files.