The same can be said for when you are just tweaking around with various things that don't necessarily have to do with choosing and installing a module. Last week is when I found myself experimenting with a migration of a site on a new install.
I would be importing the database from the file that Tom sent me. I had changed the first few lines of the SQL file so that it would create a db with a different name. In my case, it would be 'inoberlin', his of 'tom_inoberlin' seemed too lengthy. Of course I created a database specific user for this.
Tom also let me have his site files (images that appear on the events calendar, logo, INC files, PHP, etc..), so I copied almost all of them over to the new folder that I had set up on localhost for this install. Part of me was skeptical that by copying these files, that Drupal install might be more apt to errors and be quite a "dirty" installation. Still, sometimes you gotta try.
With the Drupal install chowned and chmodded appropriately, I ran an install. After entering in the database name, password, and username, I pressed on. That is when Drupal gave me an error:
I chose to merely run the update script and see what happened. Of course, this means I got the access denied error since my settings.php file always has $update_free_access set to FALSE (secure). Changing it to TRUE I ran the update script again.
Suddenly I found myself at the front page sans all styling information and header/logo images. The front page read "Page not found". It was quite scary and I feared the worst. My suspicions that this install method was too dirty seemed to be confirmed.
At Tom's suggestion via email, I tried to do this with a cleaner method this time. There was a bit of trickery thrown in since I created a fake database with a chintzy username/password, granting that dB user with just privileges specific to that database.
Using that empty database, I did a clean Drupal install, which was successful. Back in the SQL, I would end up dropping the fake database (and user). Then I imported Tom's database again, creating a database-specific user as seen before in Method 1.
Inside settings.php I would make more changes, both to the database settings and to the $update_free_access section, changing that to TRUE again. I ran the update script, changing $update_free_access back to the secure setting of FALSE when done.
The same problem came up with the missing styles, theming, and prescense of header logo image. I figured there had to be something wrong with it beyond just a "dirty install" so I did a bit of research, finding this jewel of info. I did as instructed, running this command in PHPmyadmin: UPDATE system SET status=1 WHERE name = 'garland'; then UPDATE variable SET value='s:7:"garland"' WHERE name = 'theme_default'; TRUNCATE cache; It worked so I breathed a sigh of relief.
Another thing that was tugging at my suspicions is that the cause of the "page not found" on my front page was that Tom set his front page to something different than the default "node". Since I had not installed any of the modules yet (I wasnt that ballsy), it was likely that if this was the case, it would be set to a page that was specific to one of these not-yet-installed modules. Sure enough, it was set to "upcoming_events" which I knew was tied to a calendar module that I had on my "modules to install" screencap provided.
The night was filled with an install of 15+ modules and a couple themes. It got daunting since I had a few module projects that had recently been updated. I was up for the challenge. At some point, I would periodically check the site after a bit and see how the site was coming back together, now being able to actually call up the database tables created for that module. I even installed the theme that InOberlin uses called Acquia Marina. The site was pretty much ready to go. I cant wait to finally theme some stuff. Not sure which theme set I should base mine on but people are all aflutter about Zen and Studio.
0 comments:
Post a Comment