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.

                  Shrike wrote:

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

                  Yeah. I've found out what happens when you do and it goes horribly wrong. :eek:

                    I've also found out what happens if you go directly from your development machine to live and then realise 'oh god i didn't run that SQL script' or 'oh so the live server doesn't have cURL enabled' etc etc etc 🙂

                      6 days later

                      [edit]
                      Looks like I missed the second page of posts when I replied :o
                      [/edit]

                      UltraEdit reads a file into memory for edit whether via ftp or local. Click save and it saves to the original location. You can configure UE to automatically create a backup copy of the original file before overwriting it with the edited copy, and specify whatever directory you want for the backup files.

                      Personally, I always work via FTP to and from the server cos that is the only way to test the code. However I also always have a parallel development directory structure where I do this. Only once the changes have been fully tested do I copy the files to the production directory.

                      You can never have too many backups so once a version is stable I make backups locally, remotely, on CDs and as zips in my gmail account. This is quite apart from any backup system for the clients and their data.

                        Don't use FTP for anything ever. It's not fast and it's not secure.

                        When you're doing development normally, you should be working on your development server which should be sufficiently close that you can either work on it directly (i.e. it's your desktop) or it's on a local or secure LAN, so you can use whatever protocols your OS provides to directly edit the files in your working directory.

                        Whether you use SVN or not, you still need to edit files in a working copy on your development server which is not production (likewise use a separate database which contains only junk data). Editing files in a production server is a recipe for disaster - even if you're working on a separate copy, a mistake could cause unnecessary server load or do Bad Things (think accidentally sending out emails to real users).

                        Once you've got a thoroughly tested local development version (committed to SVN if you're using that, say), you can then think about deploying it to production.

                        A change almost always involves editing more than one file, so you will need some way of atomically (or at least quickly) getting your changes to production. FTP wouldn't do this as it's achingly slow.

                        It's typical to have a configuration file - the deployment system needs to either ignore this or take it from a different location - your development config file won't work in production (and must not be accidentally deployed to production where it would create havoc).

                        I normally write some kind of script to deploy things to production - for instance, upload (or get via SVN) your tested, working application to a staging directory in your production server, then have a script which copies the relevant files into the live site directory, ensuring that config files and other files which don't need to be copied are left behind as necessary.

                        I find this to be the best way of working.

                        Mark

                          So we're all working in different environments with different types of sites with very different loads.

                          'Development server' - well personally all I've worked with since the turn of the century is hosted sites, so trying to create a development server that mirrors the production server would just be one of those impossible dreams.

                            A development server should mirror production as closely as possible - but need not do exactly.

                            For example, running the same OS with the same versions of web server, PHP and database is advisable - keeping all other factors the same is desirable.

                            I prefer to use the same build of PHP if at all possible (which clearly isn't possible during PHP upgrade cycles).

                            There are many reasons for a dev server NOT mirroring production, e.g. if you have a £10,000 raid storage system on production, you may choose not to deploy one in development for cost reasons 🙂

                            Also a dev server sometimes needs software which isn't on production (e.g. debugger, profiler)

                            Mark

                              Write a Reply...