😕 Hi All,

This is a debate that is going on in our offce about the benefits and drawbacks of modifying your source code in a linux machine via FTP or SFTP directly instead of changing the code in your local machine and then uploading it using one of many ftp tools available.

What do you guys think, which is the better option?

    Ok, I'm confused. Can you rephrase the question please, because it looks like you're asking the same thing twice...

      Hope I read it right...

      I have never tried editing files serverside using FTP or SFTP, though I have done so via SSH. I would say that if you are talking about source code, then it would be better to download to your local machine. A few reasons come to mind:

      1. If you edit on the server, you must be connected to the server. If by some accident you are disconnected, there may be trouble (e.g., changes lost). Code editing may be a lengthy process, so the chances of this happening (or you needing to take your laptop elsewhere, if you are coding from a laptop) may be higher than that of say, editing a server configuration file.

      2. A local copy is effectively a backup copy.

      3. You can place the local copy under version control. Actually, this is more like: you can use version control properly. If all the editing is done on the server, then the benefits of merging code and other features designed to make teamwork easier are lost.

      4. Using your own computer allows you to maintain religious preferences. A quick look at our "Editor used for PHP" and "Elect the best PHP Editor" threads can confirm that. Not only that, but chances are it will be faster than using an editor over the network.

        Okk sorry abt the confusion. let me rephrase the question

        Which method is more effective / recommended

        1) Editing files on serverside directly using FTP or SFTP (using the ftp feature in editors such as UltraEdit, ZEND, etc..)

        2) Edit the local copy (for ex. in notepad) and upload it to the server

        laserlight you read it right.

          See, I see the two points above as exactly the same thing, except that UltraEdit download it to a local place then re-upload it. So it's doing the job for you.

            yes it does download the copy for you, but once you close the file or the editor you will not have a local copy. If you need a local copy, then you will have to download the file manually again.

              I personally like to edit the files directly and take backups every now and then. Its much more hassle free, specially with large projects where you have to edit files scattered around the directories(I usually have 10 or more files open at the same time). It would take too much time to copy the changed files invidually. I have also a (bad) habit to do small changes and test it instantly. So its usually Edit->Save->Test,Edit->Save->Test and so on.

                When your server dies in a hard drive crash, you're going to wish you had a copy locally.

                If it's a simple change (like you're fixing the spelling of a word), then it's easy to remember what change you made. If you are editing a config file and after two dozen tries, you finally discover that you need to use code: 0xffea13ab, and then the server gets wiped out, you're going to have to do that work all over again. And that becomes even harder when you edited 5 settings in each of 40 config files - your site could be down for a day while you try to re-create the environment you had working.

                There are many levels of developers: (a) beginners, learning html, (b) part-timers making some money building web sites, (c) full time coders, and (d) professional, formally trained, standard adherent, programming teams.

                The professionals write their code in a development environment, submit their code to a QA staff, have formal implementation procedures, and full backout plans in case the changes don't work right. Making a change on the fly usually works out fine for a mom-n-pop web site that gets 50 hits a day but Amazon and Ebay would never code like that. There's no reason not to learn to do the job right - it builds good habits so that when your 50 hits per day becomes 50 hits per second, your entire staff will already be making site updates in a safe way.

                My Mac friends use BBEdit with an FTP editor built in and they laugh at me for doing it the "hard" way. I've seen too many cases where they are scrambling around looking for backups that don't exist. Editing with FTP is just lazy.

                  Yup .. i agree on the difficulties in recovering when the server crashes. Recovery takes a loong time if you do not have the necessary backups.

                  Making changes on the live system directly is not be the most appropriate solution, but what about on the development platforms. With svn added to the linux boxes on the dev platforms anyone can commit the code from the commandline if needed. Editing with FTP should not be a major concern in this scenarion would it?

                    With svn added to the linux boxes on the dev platforms anyone can commit the code from the commandline if needed. Editing with FTP should not be a major concern in this scenarion would it?

                    The centralised model of Subversion has a working copy for each developer and a central repository. If you modify the working copy, then it implies that either each user has a working copy on the server, or there is a shared working copy. For the latter, the teamwork benefits are gone. The former is akin to having a local working copy, except that now you have to be connected to the server, thus losing out even on the few disconnected operations that Subversion provides.

                      Okk ... so the final conclusion is that editing the local copy and then FTPing it to the server is the best best way to go. This way you will have a local copy and it will be easier for versioning as well.

                        When your server dies in a hard drive crash, you're going to wish you had a copy locally.

                        This is what backups are for 🙂

                        @
                        Do what you like best. Editing with FTP is not a bad way. And its not lazy, its practical 🙂

                          Editing with FTP is not a bad way. And its not lazy, its practical

                          Just some clarification: piersk described editing with FTP as "(the editor) download(s) it to a local place then re-upload(s) it". If this is true, then it does not really seem to be editing on the server (as I had in mind with SSH access), but rather editing a temporary copy on the local machine. I do not see how this has any advantage over actually downloading the source (or changes to the source) to a more permanent location, and then having the editor upload from that location. You can still have a dozen files open from different locations, but now they are not temporary copies.

                          cahva, how would you handle version control when "editing with FTP"?

                            This is what backups are for

                            The OP's question was about increasing efficiency by saving about 6 clicks. On my system, I do this:

                            Open FTP, Connect to server, download fresh copy, open text editor, make changes, <ctrl>-S to save the file, switch to FTP, upload file.

                            My Mac friends do this:

                            Open text editor, open remote file, make changes, and press <ctrl>-s to save the file.

                            That's half as many steps. While a local copy exists in RAM, it disappears when their text editor is closed.

                            In my experience, people who are interested in reducing 8 steps down to 4 don't do backups. I'm not exaggerating. Maybe that's an unfair or unscientific generalization... but it really is what I've experienced in 25 years of programming.

                            I'm not making any suggestions to the OP. I'm describing how I've seen "edit with FTP" used and what the dangers are and then he or she can decide for themselves. By understanding the dangers, the OP can choose a model and make sure to arrange for automated daily backups or something.

                            But laserlight's question is (as usual) more relevant than mine: When you use the "edit with ftp" model, you tend to avoid version control unless you develop a specific plan for it.

                              Ok, correct me if I'm wrong, but I'm pretty sure that the FTP protocol does not, nay cannot edit files. Therefore, no one can "edit via FTP". Not using the FTP protocol.

                              With Dreamweaver (I know it's there on version 8, but not sure before that you can "edit remotely" which does what I said earlier. As does Crimson Editor. I suspect that your mac friends do something similar.

                              Whichever way you look at it, you're still downloading to a local copy.

                                Correct, FTP cannot edit files. He's talking about a local text editor with and FTP client built in so that you can edit remote files.

                                Whichever way you look at it, you're still downloading to a local copy.

                                Nope. These wacky FTP-Text Editors only download the local copy to RAM and the local version disappears when the text editor is closed. Dreamweaver saves a local copy and then uploads the saved copy. The FTP-Text Editors don't do that by default - they were designed to simulate using a text editor through SSH.

                                  etully wrote:

                                  These wacky FTP-Text Editors only download the local copy to RAM and the local version disappears when the text editor is closed.

                                  But you're still downloading one. And who's to say that it's downloading it to RAM? Most of the ones I've looked at download to a temp file then delete it. Either way, you're still downloading it.

                                    Either way, you're still downloading it.

                                    Agreed, from a bandwidth perspective, there's no question, you're definitely downloading it.... but when the server has a hard drive crash, that temp file is usually gone. Even if it's not gone, relying on backup files created by a text editor isn't what I would call best practices. If I have a hard drive crash on the server, I certainly don't want to have to examine 200 files to determine whether the foo.php is newer or older than foo.php.bbeditbk7. (Sometimes, that could be difficult to determine.)

                                      There is too much danger I think in just editing a file "using FTP" (which has been worked out what that actually means so far in this thread) or over SSH (which is how I'd prefer to do remote edits).

                                      If its just a line, like a configuration variable, I'll work right on the file while its on the server.

                                      Typically however I'll download the file, make edits, then rename the existing file (the old version) and upload the new version and make sure everything works before deleting the old version. Also I'll archive the old version on my development box too. This is especially true when I work on live sites with lots of traffic.

                                      So to answer your question: work on the source and move the changes up to the server, keep a back up of the old file.

                                      Now I've seen lots of ways to rename files that are 'old' versions. I like to put the date in the file name like index-20070715.php.

                                      Happy editing 🙂

                                        If you work on high traffic servers you would not ever consider editing the live files directly.

                                        The servers I work with are not high traffic but still I wouldn't ever edit live files. I work on a local copy of a Subversion project. Changes are checked into svn, the whole project then built on a staging server for testing. Then and only then does code make it to live. Still this is not ideal, so I've been playing around with Phing - the goal being to have it export from subversion, run unit tests then build the project on the live servers.

                                        As an aside, I am working at home today. Rather than FTP-ing to and from my work machine, I just svn update here and away I go.