October 29th, 2008
Along with goobertech's new look, I've redone how the popular content section works. Previously, I filtered popular content by adding a popular tag to a node I deemed "popular".
Now -- it all runs by itself via the radioactivity module for Drupal. It's mighty clever. When a node (piece of content) is viewed, it adds "energy" or radioactivity to the entry. When an entry is commented on it gets two units of energy. The more energy a blog entry has, the higher in the list it goes. There's even a setting to adjust the half-life of the energy so old popular content decays and is pushed back in the list.
Gonna give it a try anyway and see how it ends up working out. Right now, the content listed has only a few clicks, so initially, the list should be fluctuating a lot. As the module grows older and learns more, the list should mellow out and be a better representation of the truly popular content.
April 2nd, 2008
Jebus H Christ! What a fucking nightmare!
Here I sit for over a half hour listening to the goddamn Comcast muzak waiting for the human to answer. Did I mention how much I hate Comcast? And not only because they've a complete monopoly on DSL service in the Twin Cities.
This all started because I've been busy upgrading everyone's sites from Drupal 4.6 or 4.7 to Drupal 5.X. And we all get a fancy and shiny new look to go with it. As I'm doing one site full of events, I notice that even though MySQL is storing the correct timestamp, Drupal isn't displaying it correctly. A week ago, this kept me up all night trying to figure it out.
Then I learn the issue is really a bug in the way php 4.0.1 (which is what was on my server) dealt with the date() function. Soon I realize that I can't use any of the fancy new php 5 functions either because my server software is woefully out of date. Even online forums were nearly useless, because they're all discussing php 5 as well. read more »
October 15th, 2007
I will cheer loudly the day Microsoft finally goes away bringing the god-awful Internet Explorer down with it. It's been a sinking ship for the last few years anyway. Please people -- for the love of sanity -- abandon explorer and start using Firefox today. You won't even notice the difference (other than you'll have less ad/pop-up/virus/etc issues and things on the net will look better and you'll surf faster and more efficiently.) read more »
June 9th, 2007
Now that's how it's supposed to happen! Works the first time like a charm. With the re-porting of goobertech from Drupal 4.7 to 5.0, I first recreate the entire site on a new location so the original can stay un-adultered and live. After re-doing the new drupal installation (with a few errors and tribulations), I set about duplicating the 1.47 gigs of gallery data on the new location. Here's how I did it:
- First Backup the g2data folder. I did this easily with shell access. The command is...
tar -czvpf gallerybackup.tgz g2data/
This created a tarred zip file of the entire gallery file data. This includes all of the albums and actual pictures/files.
- Then I backed up the gallery database. Since I combine my drupal and gallery databases for some fancy and complex site manuevers, this took a bit more doing. The drupal database already existed and since phpMyAdmin can only handle about 5 Mb without timing out, I had to move most of the gallery tables one at a time. I simply exported them from the original database, and then opened them through sql in the new database.
- Now the fun part -- waiting. It took almost 5 hours to download the zipped gallerybackup file and then upload it to the new location.
UPDATE - with my new shell interface as root on the server (use putty), I can now do all this from shell. Now download/upload. The trick at this step is to copy the backup file to the new user directory. Inside the old user directory (with the backup file) type:
cp gallerybackup.tgz /home/new_user_dir
- Meanwhile, I uploaded the new gallery 2 system files and installed a virgin copy in the new location. I simply let gallery do its own database table creating and gave it a new g2data folder to get a clean install.
- Once the backup file was uploaded, I renamed the g2data folder used by the fresh install to something else, (g2data2), for example. Then I unzipped the backup with this command in shell...
tar -xzvpf gallerybackup.tgz
So far so good.
- Then I recursively chmodded the entire directory with this...
chmod -R 777 g2data/
Now all the files and directories in g2data have read/write permission.
- Without touching the gallery install yet, I deleted all the gallery tables from the new database. Then I used the backed up tables from the original database to recreate them with phpMyAdmin's sql tab.
- Now I browsed to my gallery install (direct link). The gallery wizard did an upgrade and all was well!
- The last step was to copy the original site's .htaccess file (the one in the root directory). Otherwise gallery had login/permissions errors. I also had to update the member data in gallery (the owner, specifically) to match the new owner/admin name in drupal.
And that's it -- a perfect relocation with no links lost. I did have to re-activate the urlRewrite module and the matrix theme. But afterwards, everything simply worked. As it should be!
