Monday, March 01, 2010

More Fun With My Local Drupal Laboratory

I was very happy yesterday when I edited my settings.php file and a normal-looking copy of my Spice Ridge home page appeared at http://localhost/spiceridge. I posted my step-by-step directions here, and marveled that I had completed my cloning project before the wee small hours of the morning, and without weeping or cussing. Then, I sat down to tweak, modify, and update the local installation, and discovered to my dismay that the only thing that worked as intended was the front page, the page generated by index.php

The course of true upgrades never did run smooth....So I turned to Community Plumbing for Drupal advice:

  • Copy your live site to a test site (GUI). OK, that's what I'm trying to do...but these things aren't working.
  • How to copy a Drupal site from server to local? Here's a forum question from someone who's having the same problems I am, and who has tried a bunch of the same things I have. One helpful person points to this:
  • How do I unset the clean URLs? There were three things to try, and I tried them all. when I tried logging in by adding ?q=user to the end of the localhost URL, I got a 404 error as usual; while the msql commands to clear the cache files in the database had syntax errors that I couldn't work out. However, when I added $conf['clean_url'] = 0; to the end of the settings.php file I was back in business.
  • But only for a minute. This lets me log in, but I still can't find my image files, and I get "Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 40961 bytes) in /var/www/spiceridge/projects/includes/theme.inc on line 1010" when I try to navigate to the admin page. The Drupal.org advice was quite confusing and probably not applicable to my situation: Increase PHP memory limit.
  • It seemed to me that the thing I should do (since the installation on my hosting provider's server runs like a top) is to fiddle with my newly-installed PHP stuff.
  • Ubuntu Documentation--Drupal has this to say:

    You should increase the default PHP memory limit value (the amount of memory dedicated to running scripts), since the default 8 Mb is not sufficient. Use 96 Mb (or even 160M) if you intend to use graphics (although for simple uses 32 Mb may be sufficient).

    In newer versions of Drupal6, you can simply edit the settings.php file and add the line:

    ini_set('memory_limit', '96M');

    In older versions of Drupal5, or if using PHP for many different uses, it is best to increase the amount of PHP memory using this method:

    Edit the /etc/php5/apache2/php.ini file and increase the memory_limit value to 96M (or another value of your choice).

    Of course, you have to do all this as root, and then you restart apache2: /etc/init.d/apache2 restart (also as root).

  • All right! now I can log in and access my Administration page, and start playing with the core and module updates. However, I notice that all my pictures are missing. What's an image gallery with no photos? Well, I know where they're supposed to be:

    rebecca@hecate:/var/www/spiceridge/projects/sites$ ls default/files/images
    ls: cannot access default/files/images: Permission denied

    Permission problems? This is really weird...I can't navigate into the default/files directory, even after I chmod the files as root. So I delete them, and ftp the originals from http://spiceridge.com, where the permissions are normal. OK, these are fine; let's see if the browser can get to them now....

  • OK, I'm seeing some images, but I'm also getting lots of copies of this error: warning: unlink(sites/default/files/images/1908Xmas001.preview.jpg) [function.unlink]: Permission denied in /var/www/spiceridge/projects/includes/file.inc on line 435. OK, I read in the comments in includes/file.inc that directory permissions might be the problem....I chmod a+w for the involved directories, and this brings in some, but not all of my images. About half of the thumbnails are gone.

Well, I never liked that image gallery anyway....This permissions issue is the inelegant and rather haphazard way Drupal handles an aspect of security. That's the down-side of having an automated installation, I guess. They say all this will be much improved in Drupal 7.x, but of course, that will be its own "learning experience."

I'm going to say, "Good enough for government work," and start messing around with the updates now.

No comments: