Skip directly to content

sFTP

The saga continues... sFTP and Drupal 7

on Wednesday, 22nd June 2011 - 20:27

For updating Core - as stipulated in the previous post - even IF you have a great backup system... you may be stuck waiting 4 hours for your admin to get around to restoring your demolished directories.  My next attempt, I renamed my heavy 'sites' directory to 'zzz' or something of that order and then proceeded to delete the contents of the core directory I had access to.  Then using CyberDuck I copied over the contents of my D7.2 directory and returned my sites directory to its previous state. 

I realised that when updating Drupal 7 (copying all files to your working directory using the likes of CyberDuck) - you need to make sure that you copy the .htaccess file which is hidden on most computers by default (there's also a .gitignore file in D7.2). 

To view the hidden files on a Mac -- open a terminal and type in "defaults write com.apple.finder AppleShowAllFiles -bool true".  You will then need to log in and then log out to reset Finder.  (Ref: http://guides.macrumors.com/Viewing_hidden_files_on_a_Mac, to turn off again replace 'true' with 'false').


In the event of a white screen...(of Death!)

Type the following on the third line of your index.php file.

Echo "Blah"; 

If you see the word "Blah" appear on your site - you know that PHP is working and you've got an internal Drupal problem (not the server, or permissions, etc etc).

What next?  Slow and steady... I plodded along.

Check if your administration pages are working.  I had the interesting case where my frontpage was not working but everything else was!  Knowing that my modules were not up to date - my first job was to update them and then to disable them one by one until I found the culprit that was breaking my frontpage.  (Re-cap: I was working on a site that I created over six months ago and using a pre-release version of Drupal 7 and associated pre-release modules - Views, Link, Ctools, Biblio, acl, forum_access, field_group, wysiwyg). 

When I went to update my modules - I noticed that Forum_Access now depends on both acl and chain_menu_access.  Because of this new dependency, simply droping the new versions in without downloading and enabling chain_menu_access first would surely mess up things on my site.  I suspect that gem, Drush pm-update, does all of this without me being aware - but given that I have to find the cumbersome manual way of doing things... it was quite the revelation.

I also uninstalled any modules I knew that I was not using, in this case Panels.  Becareful about uninstalling modules since this also deletes any data created by the module.  That is the warning it gives you and when you think about modules like Views - you really don't want to delete some things by accident.

So all of the old modules deleted, all of the new modules downloaded to my computer and copied over via CyberDuck.  I ran the update script.  Victory!  My frontpage is working again!  *Insert little dance of Joy!*  I enabled the modules that I had disabled and was prompted to rebuild permissions (for chain_menu_access).  That done, my frontpage was still working.  Satisfied, I took a break.

... it only took three days (the few hours I had to work on it per day).

The challenge of working with strict admins & The importance of backing up your site!

on Wednesday, 22nd June 2011 - 11:22

"I can only use sFTP?" 

What a challenge I faced trying to update my D7 core (modules are still easy) on a recent site that I created prior to the D7's official release and then neglected for 6 months while on mat-leave.  I created the site using SSH which became unavailable due to a change in policy and our strict systems administrators.  So what's wrong? For one, I've never worked solely with sFTP - simply using it as a file transfer tool and for nothing else.  For two, sFTP is unforgiving and backing up a very heavy 'site's directory can seem like a daunting task if you're unfamiliar with what can and can not be done.  I decided to try it out cold turkey since my webserver backs up hourly and monthly - so reverting to an old version is only dependent on when my admin decides to come back from coffee break to handle the request.  Sufficient to say, this is low on his list of priorities.  

My first attempt left my test-site crippled and deformed.  I realised that I have been utterly spoilt.  

Drupal 7 (latest version 7.2) has a lovely update module that updates your modules for you - taking over from using Drush pm-update in the command line.  This is very nice for the amateur web developer - PROVIDED your server allows for ftp updates which mine does not.  Drush on the other hand is equally simple and allows you to do so much in such a short period of time through the command line - but you're dependent on being able to connect via SSH.  For this website I had neither of the two luxeries.

What to do?

CyberDuck became my best friend.  Unfortunately, curious on-lookers/co-workers looking over my shoulder asking questions and Oops! That precious 'sites' directory finds itself deleted.  Now what?  Wait for the admin to reset the folder to what it was.  Now, why was I an idiot-fool enough not to back up the folder locally?  More importantly, why didn't I mirror my site on my computer and make all the relevant changes there?  As I scratched my head, bit my lip, and meditated on my utter lack of caution... I wondered what tools are out there for someone in my predicament.  

Drupal has a module that can come to my rescue! Backup and Migrate.  I will post again later to say how well it worked.

In the meantime, maybe I'll go buy the admin another coffee and dangle it over his head until I get my files restored.