iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
If a WordPress edit uploaded over FTP appears to do nothing, the usual cause is not WordPress ignoring the file. You are generally looking at the wrong installation, editing a file that does not generate that page, uploading an incomplete or unchanged copy, viewing a cached response, or hitting a permissions or ownership problem. Check those in that order: confirm the site directory and active file, verify the remote upload, clear every relevant cache, and then inspect access settings. Keep a backup so each replacement can be reversed.
Start with the quickest diagnosis
Use the symptom to narrow the search before changing more files. A distinctive, harmless test marker—such as a temporary HTML comment or a clearly named CSS class—makes it easier to tell whether the server is returning the file you changed.
| What you see | Most likely explanation | First check |
|---|---|---|
| The FTP client reports success, but the old code is still visible in the remote file | The upload went to another directory, another server, or did not overwrite the old file | Recheck the domain, server, document root, remote timestamp, size, and a distinctive line in the file |
| PHP changes have no effect, while a test file elsewhere works | The edited theme, child theme, plugin, or template is not the code path used for that request | Identify the active theme and the template or hook that renders the page |
| The remote file contains the new code, but visitors see the old page | A browser, WordPress, host, CDN, reverse proxy, or PHP/application cache is serving an older result | Purge the applicable layers and retest in a private window |
| The site shows a fatal error or a blank response after upload | A syntax error, truncated transfer, incompatible change, or incorrect file permissions broke execution | Restore the backup, then inspect the complete file and the server’s error log with the host |
| You can list files but cannot replace or read one | The FTP user and web-server user do not have the required owner, group, or mode access | Ask the host to verify ownership and read/write permissions rather than forcing a broad mode |
1. Make a reversible backup
Download the original remote file before replacing it. Give the backup a dated name outside the live web directory, and keep a copy of the site files and database when the change is significant. A backup lets you restore the previous working version if the transfer is truncated or a PHP edit causes a fatal error.
Do not edit a file with a word processor. Word processors can replace straight quotes, alter characters, add formatting, or inject content that is invalid in PHP, CSS, JavaScript, or HTML. Use a plain-text code editor and preserve the file’s original encoding and line endings where practical.
2. Confirm the installation and document root
One hosting account can contain a production site, a staging copy, an old migration, or several domains. FTP opens a server account, not necessarily the directory that answers the URL in your browser. Uploading a perfect file to the wrong copy produces no visible change.
- Confirm the domain you intend to change and the server or hosting account shown in your FTP connection.
- Find that domain’s document root—the directory from which its web server serves files. The host’s control panel or support team can identify it if the FTP account opens above or beside it.
- Look for the WordPress installation markers, including
wp-admin,wp-content, andwp-includes. A second set of those directories is a warning that you may be in a staging or legacy copy. - Check whether the domain redirects to another hostname or environment. Follow the URL that actually serves the page, not merely the directory name that looks familiar.
After locating the live root, note its full remote path. Use that same path for every subsequent check so a second FTP tab or saved bookmark cannot quietly send the file to another site.
Free tools Windows power users keep installed
One-click scans. No signup required.
3. Identify the file WordPress actually uses
A filename that sounds relevant is not necessarily part of the request that generated the page. WordPress chooses templates through the active theme and its template hierarchy; plugins can add or replace output, and a child theme can override a parent theme file. A source stylesheet may also be transformed into a built asset before the browser receives it.
Theme and child-theme files
Confirm the active theme in the WordPress administration area, then check whether a child theme is active. If it is, a parent-theme edit may be ignored by the child’s override. Conversely, editing a child file that is not part of the template used for the requested URL will not alter that page.
Plugin-generated output
Shortcodes, blocks, widgets, custom post types, and security or performance plugins may generate the markup or headers you are trying to change. Inspect the plugin that owns the feature and determine whether its PHP file, a hook, or an administrator setting controls the output. Do not assume that a similarly named theme file is responsible.
Templates versus assets
For a layout change, identify the template that renders the URL, not just a file with a matching word in its name. For CSS or JavaScript, identify the asset actually enqueued on the page. Modern themes and build systems commonly serve a compiled file from a distribution directory while the editable source lives elsewhere; changing only the source has no effect until the project’s documented build process produces a new asset.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →4. Upload the complete replacement safely
Once the correct file is known, replace it with the complete edited copy. A partial transfer can leave valid-looking but old content, or can cut a PHP file off in the middle and trigger a fatal error.
- Close the file in any editor that might still be writing it, and save the final plain-text version locally.
- In the FTP client, navigate to the confirmed remote directory and select the exact filename.
- Upload the full file and wait for the transfer queue to report completion. Do not disconnect while a queued overwrite remains.
- If the client’s overwrite behavior is unreliable, retain the downloaded backup, delete the old remote file, and upload the replacement. This is safer than repeatedly assuming that an overwrite occurred.
- Refresh the remote listing and compare the remote size and modification time with the local copy. Open the remote file, when the client supports it, and search for a distinctive marker from the edit.
Deleting before uploading has a short window in which the file is absent, so use it only when you can restore quickly and the site can tolerate that interruption. Never delete a production PHP file without a verified backup.
Rank #3
5. Prove whether the server received the new contents
Do not infer a successful upload from the client’s green status message alone. A successful connection can still target the wrong directory or fail to replace a protected file.
- Compare the remote byte size with the local file size. A large unexplained difference suggests truncation, a different encoding, or the wrong copy.
- Compare timestamps, allowing for the server’s timezone and any host-side timestamp policy.
- Search the remote content for a temporary marker that cannot occur in the old version. Remove that marker after testing.
- Refresh the FTP listing or reconnect so the client is not showing a stale directory cache.
If the remote file is old, stop troubleshooting browser caches. Return to the path, account, and transfer checks until the remote copy is demonstrably the one you edited.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
6. Clear every cache that can hide the change
When the remote file is new but the page is old, the response may be cached at several independent layers. Clearing one layer does not invalidate the others.
| Layer | What it can retain | What to do |
|---|---|---|
| Browser cache | CSS, JavaScript, images, and sometimes cached page responses | Hard-refresh, then open the URL in a private window or a separate browser profile |
| WordPress cache plugin | Generated HTML, minified assets, page fragments, and preload copies | Use the plugin’s purge or clear-cache control, including any separate CSS/JS cache |
| Managed-host cache | Server-side page or object cache maintained by the hosting platform | Use the host’s cache-purge control or ask support to purge the site and identify the cache scope |
| CDN or reverse proxy | Edge copies of HTML and static files; Varnish is one example of a reverse proxy | Purge the affected URL or the required cache zone, then allow propagation before judging the result |
| PHP or application cache | Compiled PHP code or application data retained by the server | Use the host’s supported PHP restart or OPcache reset procedure; do not delete server cache files blindly |
Test with a new query string only when your cache configuration treats it as a separate resource; otherwise it can give a misleading result. A private-window request plus a distinctive marker is a better confirmation than repeatedly refreshing the same cached tab.
7. Check permissions and ownership without opening the site
FTP access and web execution may use different operating-system accounts. The FTP user must be able to upload or replace the file; the web-server process must be able to read it, and WordPress must have the access required for any operation it performs. If the owner, group, or mode does not grant that access, an upload may fail silently, create a file the server cannot read, or be blocked from replacement.
Ask the host to inspect the file and directory owner, group, and read/write permissions for both the FTP account and the web process. Hosting environments vary, so there is no universal permission number that is safe to apply everywhere. Never solve an unknown ownership problem by setting 777 indiscriminately: broad write access can expose the site to unauthorized changes and can also conflict with host security controls.
Recommended Free Tools
If the host reports that the FTP account created a file with the wrong owner, have support correct ownership or provide the supported deployment method. Re-uploading the same file under the wrong account will not fix an ownership mismatch.
8. Use encrypted file transfer
Plain FTP sends credentials and file data without encryption. 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.” Use SFTP when the host provides it; FTPS is another encrypted option. Confirm the port and authentication details with the host, and verify the server identity on the first connection according to the client’s instructions.
Changing the protocol does not correct a wrong document root or an inactive template, but it prevents credentials and code from being exposed while you perform the troubleshooting.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why common WordPress edits appear to fail
A functions.php change is in the wrong theme
Only the active theme’s functions file is loaded for that request, and a child theme can change which code runs. A parent-theme edit may be bypassed entirely. Confirm the active theme and use a temporary marker or a controlled log entry to prove that the expected file executes. Remove diagnostic code after testing.
A CSS change is hidden by an old asset
The browser may still hold the stylesheet, while a cache plugin, host, or CDN holds another copy. A build system may also require compilation before the browser receives the edited source. Verify the stylesheet URL loaded by the page, purge the relevant caches, and check the generated asset rather than assuming the source file is served directly.
A template edit affects another URL
WordPress’s template hierarchy selects different files for the front page, posts, pages, archives, and custom content. A file can be valid and active yet unrelated to the URL being tested. Compare the requested URL with the template hierarchy and test a page that the file is known to render.
The upload changed text but not behavior
Another plugin, a hook with later priority, inline styles, or a more specific CSS selector may override the line you edited. Inspect the final HTML and computed styles in the browser, then trace the competing rule or callback. This is a code-path issue, not necessarily an FTP problem.
Recovery when the edit breaks the site
- Use the FTP connection to restore the dated backup of the affected file.
- If the backup does not restore the response, check whether the transfer itself was incomplete and upload a known-good complete copy.
- Clear the caches that may preserve the error page or old PHP result.
- Review the host’s PHP and web-server error logs for the first reported file and line number. Syntax errors often identify an unmatched brace, quote, or delimiter.
- If FTP cannot replace the file because of ownership or permissions, contact the host rather than changing broad permissions on a live site.
Once the site responds normally, reapply the change in a staging copy or in small, independently testable edits. Keep the working version until the replacement has been exercised on the relevant URL.
A repeatable checklist for future FTP edits
- Back up the file and, for substantial changes, the site files and database.
- Confirm the domain, server, environment, and document-root path.
- Verify the active theme, child theme, plugin, template, or generated asset.
- Edit with a plain-text code editor.
- Upload the complete file and wait for transfer completion.
- Verify remote size, timestamp, and a distinctive content marker.
- Purge browser, WordPress, host, CDN or reverse-proxy, and applicable PHP caches.
- Test in a private window on the exact URL, then remove any test marker.
- Ask the host to correct owner, group, or access settings instead of applying
777. - Prefer SFTP or FTPS so credentials and file data are encrypted in transit.
When to stop using FTP and involve the host
Escalate when the document root is unclear, the server redirects to an unexpected environment, ownership cannot be changed by your account, cache purges are unavailable, or the site remains broken after restoring a known-good file. Provide the host with the domain, exact remote path, file name, transfer timestamp, and the error message. That information lets support distinguish a path error from an access-control or cache problem without asking you to expose credentials.
Quick Recap
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.
