If a WordPress edit uploaded over FTP appears to do nothing, the cause is usually one of five things: you changed the wrong installation or document root, edited a file WordPress is not using, the upload did not fully overwrite the remote file, a cache is serving an older response, or permissions prevented the web process from reading the replacement. Trace those possibilities in that order instead of repeatedly uploading the same file.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Back up the original, verify the active file and remote path, confirm the transfer by checking the remote file itself, purge every relevant cache, and then inspect ownership and permissions. Use SFTP or FTPS rather than unencrypted FTP whenever your host supports it.
As an Amazon Associate I earn from qualifying purchases.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWhat to check first
An FTP client showing “transfer complete” does not prove that the browser is receiving the edited file. WordPress may be running from another directory, another theme or plugin may generate the page, an intermediary may return a cached response, or the web server may be unable to read the file you uploaded.
| Symptom | Most likely explanation | First verification |
|---|---|---|
| Every page still looks exactly as before | Wrong domain, staging copy or document root | Confirm the site’s document root in the hosting panel and compare it with the FTP path |
| Only one template or feature is unchanged | The edited file is not the active theme, child-theme, plugin or template file | Identify which component renders that URL |
| The remote timestamp or size did not change | Upload failed, went to another directory or was blocked by permissions | Inspect the remote file properties and contents |
| The remote file contains the new code but the page is old | Browser, WordPress, host, CDN, reverse-proxy or PHP/application cache | Test in a private window after purging applicable caches |
| PHP changes cause an error or are ignored | Syntax error, wrong execution path or unreadable file | Check the PHP error log and owner/group permissions with the host |
Do not assume that an FTP client’s local “modified” time represents the server’s copy. The remote file, its contents and the response delivered for the URL are the evidence that matters.
Why WordPress can keep showing the old file
You uploaded to a different installation
One hosting account can contain a production site, a staging site, an old migration and several domains. Each can have its own document root. A familiar-looking wp-content directory is not enough proof that it belongs to the domain you are testing.
Check the domain-to-directory mapping in the hosting control panel, then open that exact directory in the FTP client. Look for the same WordPress installation files and the active wp-content directory. If the host uses separate directories for an add-on domain or subdomain, do not infer the path from another site in the account.
The file is not the one generating the page
WordPress chooses files through the active theme and child-theme configuration, plugin hooks and the template hierarchy. Editing a parent-theme template has no visible effect when a child theme supplies an override. Editing a plugin file has no effect if another plugin or the theme supplies the markup. A CSS file with a similar name may be an unused source file while the page loads a generated or minified asset.
Before transferring anything, identify the component that owns the output you want to change. Confirm the active theme in the WordPress dashboard, check whether a child theme is enabled, and trace the relevant plugin or template. For a style or script, determine whether the page loads a built asset rather than the source file you opened.
The replacement did not overwrite the remote copy
Transfers can be interrupted, directed to the wrong folder or affected by an overwrite prompt that was dismissed. An editor can also save a different local copy than the one selected in the FTP client.
After uploading, compare the remote file’s size and timestamp with the local file. Open the remote copy in the client’s editor, or download it and search for a distinctive marker you added temporarily. If the old content remains and overwrite behavior is questionable, retain your backup, delete the old remote file and upload the complete replacement. Never delete first unless you have a restorable copy.
A cache is serving an earlier response
Several independent caches can preserve the old result:
- The browser may reuse a cached stylesheet, script or document.
- A WordPress cache plugin may store an HTML page or generated asset.
- A managed host may cache pages or objects outside WordPress.
- A reverse proxy, including Varnish, may return a previous response.
- PHP or another application cache may retain compiled or generated output.
- A CDN may have its own object until its cache is purged or expires.
Uploading a file does not automatically invalidate these layers. Purge only the layers that exist for your site, then test again in a private browser window. A temporary, distinctive marker is more reliable than trying to judge a subtle visual change.
The server cannot read the file
The FTP account and the account used by the web server or PHP process may be different. The relevant owner, group and read/write permissions must allow the process that serves the site to read the file; the account performing maintenance must also have the access needed to replace it.
Permissions are host-dependent. Do not blindly set files or directories to 777: excessive access can expose or alter site data, while an incorrect change can take the site offline. Ask the host to confirm the owner, group and required permissions for both the FTP account and the web process.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
Safe troubleshooting procedure
- Back up before touching the remote copy. Download the original file and name the backup with the date and purpose. Where the host allows it, back up the site files and database as well. A backup makes a failed PHP edit or accidental deletion reversible.
- Confirm the target site and document root. Verify the domain, server account and environment you intend to change. Match the hosting panel’s document root to the path open in the FTP client. Check for staging, development and duplicate installations before editing.
- Identify the active source. Confirm the active theme or child theme and the plugin or template that produces the page. For CSS and JavaScript, determine whether a built, concatenated or minified asset is generated from another source. Do not keep modifying a visually similar but inactive file.
- Edit in a plain-text code editor. Word processors can replace quotation marks, add formatting characters or insert unwanted code. Preserve the file’s encoding and extension, and make the smallest change that demonstrates whether you have the right file.
- Upload the full file and watch the result. Wait for the transfer to finish and read any error or permission message. If the client asks whether to overwrite, choose the intended remote file only after confirming the path. Do not upload a partial fragment when the application expects the complete file.
- Verify the remote copy independently. Check its size and server timestamp, then open or download it and search for a distinctive test marker. If it still contains the previous version, remove the old remote copy and upload the backed-up, complete replacement. Keep the original backup until the change has been tested.
- Invalidate caches in scope. Clear the browser cache or use a private window, purge the WordPress cache plugin, clear managed-host caching, purge the CDN or reverse-proxy cache and clear PHP/application caches when the host provides those controls. Reload the exact URL containing the change.
- Check the delivered result. Use a temporary visible text marker or an unmistakable CSS change, then remove the marker after confirming the correct file is active. If the marker is in the remote file but absent from the response, the problem is still in asset selection or caching rather than FTP transfer.
- Inspect errors, ownership and permissions. For PHP, review the site’s PHP or server error log for syntax errors and fatal errors. If the remote file is correct but the server cannot use it, ask the host to inspect owner/group settings and read access for the web process and FTP account.
- Secure the connection for the next transfer. Use SFTP or FTPS when available. WordPress’s security guidance states: “Using SFTP is the same as FTP, except your password and other data is encrypted as it is transmitted between your computer and your website.”
How to prove which layer is failing
1. Prove the remote file changed
Download the remote file after the transfer and compare it with your local copy. A matching distinctive comment, text string or harmless style marker establishes that the intended server file changed. If the marker is missing, stop investigating caches and return to the path, overwrite and permission checks.
2. Prove WordPress uses that file
Remove ambiguity by tracing the active theme, child-theme override, plugin callback or template hierarchy. If two files contain the same function, class or markup, determine which one is loaded for the URL you are testing. For generated CSS or JavaScript, identify the source-to-build step; changing an unbuilt source file will not change the asset currently enqueued.
3. Prove the response is fresh
After purging, open the page in a private window and test a distinctive marker. Clear the browser’s stored data for the site only if needed. If a private window shows the change while a normal window does not, the browser cache is the remaining layer. If both show the old response, continue through the WordPress, host, CDN and reverse-proxy controls.
4. Prove the server can execute or read it
A PHP file can be present yet fail to run because of a syntax error, a fatal error or an execution path that never loads it. A CSS or template file can be present yet unreadable to the web process. Use the error log and the host’s permission checks rather than broadening access indiscriminately.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Cache purge checklist by layer
| Layer | What to do | How to tell it was the culprit |
|---|---|---|
| Browser | Use a private window; clear the site’s cached data if necessary | The private window shows the marker while the regular window does not |
| WordPress cache plugin | Use the plugin’s clear or purge action, then reload | The page changes only after the plugin cache is purged |
| Managed host | Use the host’s cache purge control or request a purge from support | WordPress and browser caches are clear but the public response remains old |
| CDN or reverse proxy | Purge the affected URL or cache zone according to the service’s controls | Origin content is new but visitors still receive an older edge response |
| PHP/application cache | Restart or clear it only through the host’s documented control | PHP behavior remains old after the source file and page caches are fresh |
Do not purge unrelated data repeatedly. First establish that the remote file and active source are correct; then invalidate the narrowest cache layer that could contain the old response.
PHP, CSS, JavaScript and template-specific traps
PHP and functions.php
Editing the wrong theme’s functions.php is common, especially when a child theme is active. A PHP syntax error may prevent the file from loading or trigger a fatal error elsewhere. Keep the backup, make one small change, and check the error log immediately if the site displays an error or the expected behavior disappears. Do not use a visible test marker that would itself break PHP syntax.
CSS
Confirm that the stylesheet is actually enqueued for the page. Themes and plugins may serve a generated or minified file instead of the source stylesheet. Purge the browser, WordPress and edge caches after changing it, then use a deliberately obvious but temporary style to verify the active asset. Remove that test style after confirmation.
JavaScript
Check whether the page loads a bundled or minified script. A source edit may require the project’s build process before the browser can receive it. If the browser receives the new script but behavior is unchanged, inspect the browser console for a JavaScript error that stops execution.
Free tools Windows power users keep installed
One-click scans. No signup required.
Templates and markup
WordPress’s template hierarchy can select a more specific file than the one you edited. A page template, taxonomy template, or child-theme override may win over a generic template. Confirm the actual URL and content type, then trace the selected template before changing another file.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Permissions and ownership without making the site less safe
Permission problems are not limited to failed uploads. An FTP client may report success for a transfer that leaves the file owned or grouped in a way the web process cannot read. Conversely, the web process may be able to read a file but not write generated caches or assets in the same directory.
- Tell the host which account performs FTP transfers and which account runs the web or PHP process.
- Ask the host to verify owner, group and read/write access on the file and its parent directories.
- Change only the minimum access needed for the intended operation.
- Retest the page and the WordPress function that depends on the file after any permission correction.
- Keep a record of the original settings so a rollback is possible.
Because server configurations differ, a host-specific correction is safer than copying a permission value from another site.
Recovery when the edit caused a problem
- Stop making additional edits so the failure remains diagnosable.
- Use the FTP client to restore the backed-up file to the same verified path.
- Purge the same cache layers used for the test.
- Check the PHP or server error log and confirm the site loads normally.
- Reapply a smaller change only after the original behavior is restored.
If deleting the old remote file was necessary to overcome an overwrite problem, restore the backup first and then upload a complete, validated replacement. Keep both the local backup and a record of the remote path.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →When FTP is the wrong maintenance method
FTP is useful for a controlled file replacement, but it is easy to lose track of active paths, generated assets and cache layers. For recurring changes, use a deployment process or the host’s file manager that records the target environment and preserves rollback points. Whatever method you choose, the same checks still apply: correct installation, active source, complete transfer, cache invalidation, permissions and recoverability.
Plain FTP also exposes credentials and transferred data in transit. Prefer SFTP or FTPS, and verify that the client is connected to the intended host before entering credentials. Secure transport protects the transfer; it does not by itself prove that the file belongs to the active WordPress installation.
Quick Recap
A compact decision path
- Remote file unchanged? Recheck the domain, document root, local file, overwrite result and permissions.
- Remote file changed but page unchanged? Confirm the active theme, child theme, plugin, template or built asset, then purge caches.
- Marker appears but the feature fails? Inspect PHP or JavaScript errors and verify that the code path runs for the URL being tested.
- Only some visitors see the old page? Check browser, CDN and reverse-proxy caches and test from a private window.
- Still unresolved? Give the host the domain, exact remote path, transfer time, remote file details and error-log evidence so it can inspect ownership, permissions and server-side caches.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
