Moving files without an FTP client and when you still want one
Screen walkthrough with on-screen captions, no narration. Plays on this page, muted, no sign-in needed. Every name, address and figure on screen is an example.
When you run one site, an FTP client is fine. When you run thirty, the client becomes the bottleneck: a saved profile per account, passwords that drift out of date, and a connection you have to open before you can answer a question as small as "is that file still there".
The file manager in your dashboard answers those questions without a connection. The FTP account still has its place, and knowing which job belongs to which tool saves a lot of clicking.
What the file manager is faster at
- Looking. Checking whether a plugin folder exists, when a file was last written, or how big an uploads directory has grown.
- One file. Creating a
robots.txt, editing an.htaccess, or pasting a snippet into a template. - Fixing a permission. Changing the mode on a folder a script cannot write to.
- Working across accounts. You are already in the account list; opening the next account's files is one click, not a new profile.
Creating a file is the panel's own action: name it, say which folder it belongs in, and it appears in the listing. There is no upload step and nothing to keep in sync.
What still wants FTP
- Bulk. Pushing a theme with four hundred files, or pulling a full site down for local work.
- Resume. Large transfers over a connection that drops. A client retries; a browser upload starts again.
- Automation. A script or build step that runs without a person watching.
Creating an FTP account is a short form: a login, a password, a directory and a quota. The quota is the field people leave blank and the form will not submit without it, so decide the number rather than reaching for unlimited.
Point the FTP account at one folder
The directory field is the whole security story. An FTP login rooted at the account home can reach every site on that account. Rooted at public_html/clientsite/wp-content/uploads, it can reach exactly what the person needs.
This matters more on a network than on a single site: one over-scoped FTP login handed to a contractor is access to every domain sharing that account.
A habit that pays off later
Name FTP accounts after the person or the process, never after the site. designer and deploybot can be removed individually when the work ends. ftp1 and ftp2 get shared, outlive the job, and cannot be revoked without asking who is still using them.
The same logic applies to where you keep credentials. An FTP password in a shared document is a password you cannot rotate without breaking someone else's workflow, and on an estate of sites that means it never gets rotated at all.
If you are deciding how much file access a person needs at all, scoping a user to one service is usually a better answer than another FTP login.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.