Nov 23, 2006
It was at 11:30 this morning I decided it wasn't going to work.
I got into the office a bit late today because I had to sign some papers related to my new gas furnace. First thing, I went to Google looking for information on how to install new modules in Drupal 5.0.
It's very simple. Modules have a name, say, 'foo'. There is a .module file associated with that module, 'foo.module'. There can be (but doesn't have to be) a directory with that same name, 'drupal/modules/foo'. Drupal, when it lists the modules that can be installed, checks the 'modules' directory and any subdirectories for a file called '.module'. That's it.
So why wasn't this working on my website? Why were new modules, uploaded and very carefully checked for permissions and all that, simply not found? I have no idea. The core modules were loaded OK because they are all listed in the 'modules' table in the database, no problem.
Once I was comfortable I fully understood the module loading, installation and initiation process, I was also comfortable in saying, my installation of Drupal 5.0 is borked. Which left me two choices: I could either delve into the code that loads the list of modules for admin/modules and try to fix the bug, or I could give up on Drupal 5.0 and try to use an earlier version.
And that's when I decided 5.0 wouldn't work. I poked around in the code for a while, looking for exactly where the script scans the directory structure looking for .module files, but I couldn't fine it. I did find this very nice way to navigate the Drupal fuctions, which helped a lot (I have linked to the source for index.php, and you can pretend your a computer and navigate all the functions yourself), but I wasn't really prepared to root around looking for it (and you have to root around, PHP allows variables to be valled as functions, something that makes coding more flexible but is just miserable to debug, at least to me).
But more to the point: it was very possible that Drupal couldn't find the list of modules because the current version of PHP didn't support it. Drupal might be trying to do some sort of crazy strsub on the directory names, for example. Who knows? So I decided to try Drupal 4.7 because that would also tell me whether it was a PHP problem, as opposed to a Drupal problem (verdict: it's a Drupal problem; Drupal 4.7 read the directories just fine).
So I installed Drupal 4.7. It took me about 10 minutes. Here's what I did:
- Deleted database 'downes', then recreated a new and empty database called 'downes' and gave my user access to it, just like before
- Downloaded the Drupal 4.7 package to my home machine and uploaded it to my website using gftp
- Opened a console window, used SSH to access my website, then used 'cd' to navigate to the 'www' directory
- removed the previous installation of Drupal using the command 'rm -r drupal' (note: be extremely careful using 'rm -r' because it wipes out directories recursively)
- then I executed the command 'tar xzf drupal-7.7.tar.gz'
- Executed 'mv drupal-7.7.tar.gz drupal' to move my software into a nice clean drupal directory
- removed my symbolic link from fallacies.ca to the drupal directory, then recreated it by typing 'ln -s drupal fallacies.ca'
- used gftp to download /drupal/sites/default/settings.php to my desktop, used gedit to change the username, password and database name for access to the database, save it, then uploaded it back to the computer
- created the new Drupal database structure by typing: mysql -u username -p databasename foaf module to my desktop, then uploaded foaf.module into the 'modules' directory. Now for the test: I navigated to admin/modules and... yes, there it was. I selected 'enable' and updated the page, and the new module loaded just fine.
Good. Then I decided to try the flexinode module. Same process, only the flexinode module got its own directory. With all the files loaded, I went to admin/modules again, and... there it was. I enabled it and then gave it a test run.
The idea of something like flexinode is that you define a new data type and then assign to it the fields you want for that data type. So I went to 'content types' and defined a new data type, 'Post', and then gave it fields for 'url', 'description', 'author' and 'publisher'.
Once done, I went to 'Add Content' and saw my new content type there. Great! But when I opened up the form to create some content, it was mangled. I had to play with the content types editor several times, but the form never did display. Ah, whatever, I could always define a new form.
Once I have created a test entry, I went into phpMyAdmin (which really lurches and complains on this installation of PHP - either this installation is really bad or (more likely) phpMyAdmin has overreached and now demands as 'required' PHP functions that are very optional and not typicall installed). I needed to see what a 'post' record looked like in the database before I could consider porting the data over.
I was disappointed. It was a very ugly hack. It was sort of like microformats, done badly. All the different fields were placed into the 'body' field, and the script used 'div' tags to delineate them. Well, OK, but the classes used to name the 'div' tags were not descriptive at all - they were 'flexinode.1', 'flexinode.2', and so on. So. basically, the flexinode script did the minimum to put the data in there, but that was it. Even worse, the names of the fields actually were in the data, delineated with
I got into the office a bit late today because I had to sign some papers related to my new gas furnace. First thing, I went to Google looking for information on how to install new modules in Drupal 5.0.
It's very simple. Modules have a name, say, 'foo'. There is a .module file associated with that module, 'foo.module'. There can be (but doesn't have to be) a directory with that same name, 'drupal/modules/foo'. Drupal, when it lists the modules that can be installed, checks the 'modules' directory and any subdirectories for a file called '.module'. That's it.
So why wasn't this working on my website? Why were new modules, uploaded and very carefully checked for permissions and all that, simply not found? I have no idea. The core modules were loaded OK because they are all listed in the 'modules' table in the database, no problem.
Once I was comfortable I fully understood the module loading, installation and initiation process, I was also comfortable in saying, my installation of Drupal 5.0 is borked. Which left me two choices: I could either delve into the code that loads the list of modules for admin/modules and try to fix the bug, or I could give up on Drupal 5.0 and try to use an earlier version.
And that's when I decided 5.0 wouldn't work. I poked around in the code for a while, looking for exactly where the script scans the directory structure looking for .module files, but I couldn't fine it. I did find this very nice way to navigate the Drupal fuctions, which helped a lot (I have linked to the source for index.php, and you can pretend your a computer and navigate all the functions yourself), but I wasn't really prepared to root around looking for it (and you have to root around, PHP allows variables to be valled as functions, something that makes coding more flexible but is just miserable to debug, at least to me).
But more to the point: it was very possible that Drupal couldn't find the list of modules because the current version of PHP didn't support it. Drupal might be trying to do some sort of crazy strsub on the directory names, for example. Who knows? So I decided to try Drupal 4.7 because that would also tell me whether it was a PHP problem, as opposed to a Drupal problem (verdict: it's a Drupal problem; Drupal 4.7 read the directories just fine).
So I installed Drupal 4.7. It took me about 10 minutes. Here's what I did:
- Deleted database 'downes', then recreated a new and empty database called 'downes' and gave my user access to it, just like before
- Downloaded the Drupal 4.7 package to my home machine and uploaded it to my website using gftp
- Opened a console window, used SSH to access my website, then used 'cd' to navigate to the 'www' directory
- removed the previous installation of Drupal using the command 'rm -r drupal' (note: be extremely careful using 'rm -r' because it wipes out directories recursively)
- then I executed the command 'tar xzf drupal-7.7.tar.gz'
- Executed 'mv drupal-7.7.tar.gz drupal' to move my software into a nice clean drupal directory
- removed my symbolic link from fallacies.ca to the drupal directory, then recreated it by typing 'ln -s drupal fallacies.ca'
- used gftp to download /drupal/sites/default/settings.php to my desktop, used gedit to change the username, password and database name for access to the database, save it, then uploaded it back to the computer
- created the new Drupal database structure by typing: mysql -u username -p databasename foaf module to my desktop, then uploaded foaf.module into the 'modules' directory. Now for the test: I navigated to admin/modules and... yes, there it was. I selected 'enable' and updated the page, and the new module loaded just fine.
Good. Then I decided to try the flexinode module. Same process, only the flexinode module got its own directory. With all the files loaded, I went to admin/modules again, and... there it was. I enabled it and then gave it a test run.
The idea of something like flexinode is that you define a new data type and then assign to it the fields you want for that data type. So I went to 'content types' and defined a new data type, 'Post', and then gave it fields for 'url', 'description', 'author' and 'publisher'.
Once done, I went to 'Add Content' and saw my new content type there. Great! But when I opened up the form to create some content, it was mangled. I had to play with the content types editor several times, but the form never did display. Ah, whatever, I could always define a new form.
Once I have created a test entry, I went into phpMyAdmin (which really lurches and complains on this installation of PHP - either this installation is really bad or (more likely) phpMyAdmin has overreached and now demands as 'required' PHP functions that are very optional and not typicall installed). I needed to see what a 'post' record looked like in the database before I could consider porting the data over.
I was disappointed. It was a very ugly hack. It was sort of like microformats, done badly. All the different fields were placed into the 'body' field, and the script used 'div' tags to delineate them. Well, OK, but the classes used to name the 'div' tags were not descriptive at all - they were 'flexinode.1', 'flexinode.2', and so on. So. basically, the flexinode script did the minimum to put the data in there, but that was it. Even worse, the names of the fields actually were in the data, delineated with
