FTP or File Manager - Which one do you prefer?

[Cedric]

When it comes to managing your website's files, there are two primary options - FTP and File Manager. Both options have their advantages and disadvantages, but which one do you prefer to use?

FTP (File Transfer Protocol) is a standard protocol used for transferring files between a client and a server over the internet. FTP clients, such as FileZilla, allow you to connect to your web server and manage your files remotely. FTP is known for its speed, reliability, and versatility, making it a popular choice among web developers.

File Manager is a web-based tool that allows you to manage your website's files directly from your hosting control panel. It provides a user-friendly interface that allows you to create, upload, delete, and modify files and folders on your website. While it may not have all the advanced features of FTP, it's a convenient option for those who prefer to manage their files within their hosting account.

So, which one do you prefer to use - FTP or File Manager? Do you find one to be more user-friendly or efficient than the other? Are there any specific situations where you prefer to use one over the other? Let's discuss and share our experiences with each other.

 

[Arantor]

FTP is also insecure and shouldn't ever be used, since it leaks your password unencrypted during connection; either FTPS or SFTP should be used instead (and no, they're not the same thing despite having the same letters)

cPanel's File Manager is also not recommended, it's clunky at best for anything beyond trivial use.

Though I'll be honest, for any non-trivial use... I set up something to push from my version control repositories automatically so there's nothing to manage directly on the server, or if I do have to do a big move, rsync is the tool for the job every time.

 

[Shortie]

I have always used FTP and have never had any issues with it when I have used it. At the moment, due to my PC being a little older now and it sometimes can randomly restart, my other half now attends to any files that need to be uploaded. If I was still able to do that though, I would more than likely use FTP again as that is what I am used to.

 

[Ravenfreak]

I utilize both, if I need to delete files from my site, I delete them from my file manager on my hosting since it's much faster. Of course if you're uploading numerous files, it's best to use a FTP software like Filezilla to upload everything. So I like both honestly.

 

[fords8]

Most use Filezilla for FTP. I tend to use both for different reasons. Depends on what I am doing.

 

[Mamberroi Jr]

Depending on the task to be performed. To upload/delete/save large amounts of files I use FTP FileZilla for small things File Manager

 

[Tyrsson]

I use none of the above these days. I use Git as source control and deploy via github action to Azure cloud. Which means that any time I run a push to a public facing project, once all test have passed, PhpUnit, PhpStan, Phpcs then it deploys and I do not have to worry with uploading a new build. Pretty much the same thing can be achieved with the new version of Cpanel since it has Git support. You should write a deployment script and not have the repo in the host/vhost path though.

 

[Cedric]

I use none of the above these days. I use Git as source control and deploy via github action to Azure cloud. Which means that any time I run a push to a public facing project, once all test have passed, PhpUnit, PhpStan, Phpcs then it deploys and I do not have to worry with uploading a new build. Pretty much the same thing can be achieved with the new version of Cpanel since it has Git support. You should write a deployment script and not have the repo in the host/vhost path though.

This must be more a developer thing as I have no idea what this all means, haha.

 

[Tyrsson]

This must be more a developer thing as I have no idea what this all means, haha.

It's not as complicated as it sounds. Say for example you have a top level site at /public and your forums are at /forum, if you keep the entire public facing site in a Git repo and your hosted server support Git deployment, then you could write a simple script to be triggered any time you push to the Git repo on your server. Which means while you're doing local development on site (your dev site on your computer) you make changes that you then want to push live. First you would run a push to your remote (github for example) then run a push to your remote on the hosted server. When your server detects that a push has occurred the hook would run the copy (from the checked out copy of the repo) which is basically the deployment phase. In the process the script will overwrite the current files and your new version would be live. The bonus is that if you find a bug you can roll back on your local (check out the branch prior to those changes) and run another push to the hosted repo effectively restoring the site until you have time to fix the bug on your local (the version on your computer) then you push that version back

[edit]
@Arantor uses the same approach

 

[Cedric]

It's not as complicated as it sounds. Say for example you have a top level site at /public and your forums are at /forum, if you keep the entire public facing site in a Git repo and your hosted server support Git deployment, then you could write a simple script to be triggered any time you push to the Git repo on your server. Which means while you're doing local development on site (your dev site on your computer) you make changes that you then want to push live. First you would run a push to your remote (github for example) then run a push to your remote on the hosted server. When your server detects that a push has occurred the hook would run the copy (from the checked out copy of the repo) which is basically the deployment phase. In the process the script will overwrite the current files and your new version would be live. The bonus is that if you find a bug you can roll back on your local (check out the branch prior to those changes) and run another push to the hosted repo effectively restoring the site until you have time to fix the bug on your local (the version on your computer) then you push that version back

That indeed makes more sense. Thanks for the explanation!

 

[Tyrsson]

I should also mention, since this is Git driven, you will need to setup public/private key (TLS/SSL) auth with your server. Another side benefit, is that you are only sending the changes, not every file

 

[Arantor]

Mine's actually more gnarly than that - GitHub Action checks out the code, sometimes pulls in one or two dependent repositories (parent themes, Composer dependencies, etc), does a SCSS and JS compile for minification/stripping out things we don't need, pushes the result to the relevant server and if possible, does a near downtimeless switchover.

Most of our stuff sits on regular ol' hosting so no fancy container shenanigans for actual downtimeless switchover (starting new containers, then draining containers via the Kubernetes control plane, or ECS or Azure equivalent as you begin to reroute traffic), but because I prepare the deployment as a complete bundle, push it to the server into a folder outside webroot and do a folder-level move/rename, it's *very* fast. Usually see more downtime from flushing caches etc. than the actual switchover.

It's also more funky because I have the ability to toggle feature branches being merged into staging environments; push any branch that isn't master/main, a staging build occurs. Master/main is checked out, any other branches on the repository are merged unless their name has 'no-merge' in it (so can toggle feature branches), result is pushed to staging server automatically. Production deployments are manual triggers with limited ability to ever actually touch.

I get precise control over when things make it to production and they never get there accidentally: you have to merge the branch then manually run the action.

I find this whole setup very convenient for all the projects we have, whether it's WordPress, Laravel, or some of the more exotic things we have like the folks who wanted to use Prismatic with Gatsby.

 

[Tracy]

I ONLY use SFTP on my site, and it's secured by by an SSH key (lengthy).
In fact, the ftp server is present, but doesn't have any logins set up.. it's a honeypot more than anything.