If WordPress stops loading immediately after you edit functions.php and the log says Parse error, restore the last known-good version of that exact file. A syntax error prevents PHP from reading the code normally. Clearing caches or increasing memory does not repair a missing delimiter, malformed string, or syntax unsupported by the server's PHP version.
Before replacing anything, preserve the broken file outside the public web directory so the developer can compare it. Confirm whether the path belongs to the active parent theme, child theme, or a different installation. Do not overwrite a child theme with the parent theme's functions.php; they are different files with different jobs.
Recover Access With the Smallest Change
Use your host's file manager, SFTP, or the established deployment process. Avoid continuing to edit through a dashboard page that is already failing. Restore a trusted pre-edit file, preserving its ownership and permissions. Do not change permissions to 777 to get around an upload failure.
If no known-good copy exists, download the broken file and examine the small change that triggered the failure. Ask the host or developer to make a controlled correction. Replacing the entire site database to repair one source file risks losing newer business data without addressing why the syntax was invalid.
The WordPress debugging guide explains logging controls. Prefer existing private hosting logs during recovery. Do not display PHP diagnostics to visitors or leave a public debug file containing sensitive paths and request data.
Read the Line Number as a Starting Point
The line PHP reports is where parsing became impossible, not always where the mistake started. A missing quote several lines earlier may cause the parser to complain about the next function. Review the complete changed statement and its surrounding braces before deleting the line named in the message.
Common editing mistakes include pasted typographic quotes, unbalanced parentheses, an omitted semicolon, a second opening PHP tag inside an existing PHP block, and language features unavailable in the production runtime. Compare the file before and after the edit instead of replacing punctuation throughout the theme.
Explanatory worksheet. Fill in your own evidence; no customer results are represented.
Lint Before Uploading Again
PHP provides a syntax check that does not execute the file. Run it on the corrected local copy with a PHP version matching production:
php -v
php -l functions.php
The PHP command-line manual documents the -l option. The command above assumes your terminal is in the directory containing the file you intend to check. A successful lint result says the syntax is acceptable to that interpreter. It does not prove the functions exist, hooks run correctly, or WordPress will load successfully.
| Check |
What a pass means |
| Matching PHP version |
The syntax test uses the relevant language support |
| Lint succeeds |
No syntax error detected in that file |
| WordPress loads |
Startup passed for the tested request |
| Edited feature works |
The intended behavior survived the correction |
Check the Feature, Not Just the Homepage
After uploading the corrected file, reload the original failing page and inspect the newest log entries. Then exercise the feature the snippet was supposed to change. A checkout filter needs a controlled checkout test; an editor customization needs the editor. A homepage pass cannot validate either.
If the log now reports a different runtime error, do not label the remaining problem another parse error. Follow the critical-error diagnostic path using the new message. Keep the edit in version control or a maintained customization package so the next theme update does not silently remove it.
Request a targeted WordPress code fix with the redacted error, PHP version, changed file path, and intended behavior. Send the smallest relevant diff, not a public archive containing your entire site.
Sources and release details checked September 24, 2026. Diagrams are explanatory; examples are synthetic.