Hi everyone, I have a very strange problem here. I just can't seem to get rid of the imagecache module, no matter how hard I try. I have disabled the module, and uninstalled it, deleted all the relevant entries from the system table, made sure the cache table and my browser cache are all cleared, and run update.php but 'imagecache' still shows up in admin/build/modules every time I refresh it. Whats worse, when I load sites/all/modules it puts an imagecache entry back into the 'system' table. I delete it and reload the page and the entry comes back again. I have not been able to figure out what is causing this and I have no idea how to solve it. But hopefully someone here does. Thanks.
Delete the imagecache directory. If you still see imagecache then listed in modules you have probably in a subdirectory of another module another copy of imagecache.
If there is nowhere a imagecache.info filein the modules or sites/all/modules directory imagecache cannot show up.
Hans
2009/2/14, cooper Quintin cooperq@cooperq.com:
Hi everyone, I have a very strange problem here. I just can't seem to get rid of the imagecache module, no matter how hard I try. I have disabled the module, and uninstalled it, deleted all the relevant entries from the system table, made sure the cache table and my browser cache are all cleared, and run update.php but 'imagecache' still shows up in admin/build/modules every time I refresh it. Whats worse, when I load sites/all/modules it puts an imagecache entry back into the 'system' table. I delete it and reload the page and the entry comes back again. I have not been able to figure out what is causing this and I have no idea how to solve it. But hopefully someone here does. Thanks.
-- Cooper Quintin Freelance Programmer, Indymedia Journalist http://CooperQ.com (510) 827-5382
-- [ Drupal support list | http://lists.drupal.org/ ]
I have used the unix find command and searched and the imagecache directory doesn't exist anywhere in the filesystem. Yet it still shows up. (I checked this before I sent my initial email. ) This is really preplexing. KOBA | Hans Rossel wrote:
Delete the imagecache directory. If you still see imagecache then listed in modules you have probably in a subdirectory of another module another copy of imagecache.
If there is nowhere a imagecache.info filein the modules or sites/all/modules directory imagecache cannot show up.
Hans
2009/2/14, cooper Quintin cooperq@cooperq.com:
Hi everyone, I have a very strange problem here. I just can't seem to get rid of the imagecache module, no matter how hard I try. I have disabled the module, and uninstalled it, deleted all the relevant entries from the system table, made sure the cache table and my browser cache are all cleared, and run update.php but 'imagecache' still shows up in admin/build/modules every time I refresh it. Whats worse, when I load sites/all/modules it puts an imagecache entry back into the 'system' table. I delete it and reload the page and the entry comes back again. I have not been able to figure out what is causing this and I have no idea how to solve it. But hopefully someone here does. Thanks.
-- Cooper Quintin Freelance Programmer, Indymedia Journalist http://CooperQ.com (510) 827-5382
-- [ Drupal support list | http://lists.drupal.org/ ]
Does nobody have any idea on this? I have checked my filesystem extensively using grep and find and have not found any trace of imagecache left in my filesystem. I have deleted it several times from the database but it always comes back and is listed there in the modules page. I really just don't know what to do any more.
cooper Quintin wrote:
I really just don't know what to do any more.
Perhaps you should also post a Support Request on the Imagecache project issues page:
http://drupal.org/node/add/project-issue/imagecache
That, at least, may get more eyes on your situation.
Thanks, I will try that, also I noticed an additional problem, any modules I put in sites/all/modules aren't showing up on the admin/build/modules page. So I think it may be some weird problem with my installation. Earl Cooley III wrote:
cooper Quintin wrote:
I really just don't know what to do any more.
Perhaps you should also post a Support Request on the Imagecache project issues page:
http://drupal.org/node/add/project-issue/imagecache
That, at least, may get more eyes on your situation.
On Wed, Feb 18, 2009 at 8:18 AM, cooper Quintin cooperq@cooperq.com wrote:
Thanks, I will try that, also I noticed an additional problem, any modules I put in sites/all/modules aren't showing up on the admin/build/modules page. So I think it may be some weird problem with my installation.
This probably means that you are looking at the sites/all/modules directory of a different Drupal installation.
Earl Cooley III wrote:
cooper Quintin wrote:
I really just don't know what to do any more.
Perhaps you should also post a Support Request on the Imagecache project issues page:
http://drupal.org/node/add/project-issue/imagecache
That, at least, may get more eyes on your situation.
-- Cooper Quintin Freelance Programmer, Indymedia Journalist http://CooperQ.com (510) 827-5382
-- [ Drupal support list | http://lists.drupal.org/ ]
Quoting Cog Rusty cog.rusty@gmail.com:
On Wed, Feb 18, 2009 at 8:18 AM, cooper Quintin cooperq@cooperq.com wrote:
Thanks, I will try that, also I noticed an additional problem, any modules I put in sites/all/modules aren't showing up on the admin/build/modules page. So I think it may be some weird problem with my installation.
This probably means that you are looking at the sites/all/modules directory of a different Drupal installation.
To control this for my multisite setup I always remove the sites directory in the drupal install and then create a symbolic link to a common sites directory.
Something like: /usr/local/drupal/6.x/drupal-6.0 mv /usr/local/drupal/6.x/drupal-6.0/sites /usr/local/drupal/6.x/ ln -s /usr/local/drupal/6.x/sites /usr/local/drupal/6.x/drupal-6.0/sites
/usr/local/drupal/6.x/drupal-6.9 rm -rf /usr/local/drupal/6.x/drupal-6.9/sites ln -s /usr/local/drupal/6.x/sites /usr/local/drupal/6.x/drupal-6.9/sites
cd /my/web/directory/mysite-1 mv htdocs htdocs.orig ln -s /usr/local/drupal/6.x/drupal-6.0 htdocs cd htdocs/sites mkdir mysite-1 cp default/default.settings.php mysite-1/settings.php
cd /my/web/directory/mysite-2 mv htdocs htdocs.orig ln -s /usr/local/drupal/6.x/drupal-6.9 htdocs mkdir mysite-2 cp default/default.settings.php mysite-2/settings.php
If you're using Windows XP or better then instead of ln -s source link use junction link source
Another thing you might consider for multisites is to create a tmp directory in each of the sites/mysite directories and change the temporary directory setting in the files admin page.
-- Earnie http://r-feed.com Make a Drupal difference and review core patches.
Thanks, I will try this. It's weird that it would be reading from the wrong directory though. Is the modules directory cached in drupal somewhere or something? I find it very odd that it would ever read from a different webroot. Earnie Boyd wrote:
Quoting Cog Rusty cog.rusty@gmail.com:
On Wed, Feb 18, 2009 at 8:18 AM, cooper Quintin cooperq@cooperq.com wrote:
Thanks, I will try that, also I noticed an additional problem, any modules I put in sites/all/modules aren't showing up on the admin/build/modules page. So I think it may be some weird problem with my installation.
This probably means that you are looking at the sites/all/modules directory of a different Drupal installation.
To control this for my multisite setup I always remove the sites directory in the drupal install and then create a symbolic link to a common sites directory.
Something like: /usr/local/drupal/6.x/drupal-6.0 mv /usr/local/drupal/6.x/drupal-6.0/sites /usr/local/drupal/6.x/ ln -s /usr/local/drupal/6.x/sites /usr/local/drupal/6.x/drupal-6.0/sites
/usr/local/drupal/6.x/drupal-6.9 rm -rf /usr/local/drupal/6.x/drupal-6.9/sites ln -s /usr/local/drupal/6.x/sites /usr/local/drupal/6.x/drupal-6.9/sites
cd /my/web/directory/mysite-1 mv htdocs htdocs.orig ln -s /usr/local/drupal/6.x/drupal-6.0 htdocs cd htdocs/sites mkdir mysite-1 cp default/default.settings.php mysite-1/settings.php
cd /my/web/directory/mysite-2 mv htdocs htdocs.orig ln -s /usr/local/drupal/6.x/drupal-6.9 htdocs mkdir mysite-2 cp default/default.settings.php mysite-2/settings.php
If you're using Windows XP or better then instead of ln -s source link use junction link source
Another thing you might consider for multisites is to create a tmp directory in each of the sites/mysite directories and change the temporary directory setting in the files admin page.
-- Earnie http://r-feed.com Make a Drupal difference and review core patches.
Quoting cooper Quintin cooperq@cooperq.com:
Thanks, I will try this. It's weird that it would be reading from the wrong directory though. Is the modules directory cached in drupal somewhere or something? I find it very odd that it would ever read from a different webroot.
Yes, the system table contains the paths to modules. If you've copied the DB from one site to another then the you'll likely have the wrong paths to all modules.
-- Earnie http://r-feed.com Make a Drupal difference and review core patches.
On Thu, Feb 19, 2009 at 2:32 PM, Earnie Boyd earnie@users.sourceforge.net wrote:
Quoting cooper Quintin cooperq@cooperq.com:
Thanks, I will try this. It's weird that it would be reading from the wrong directory though. Is the modules directory cached in drupal somewhere or something? I find it very odd that it would ever read from a different webroot.
Yes, the system table contains the paths to modules. If you've copied the DB from one site to another then the you'll likely have the wrong paths to all modules.
... which normally are automatically updated in the database whenever you visit the admin/build/modules page.
-- Earnie http://r-feed.com Make a Drupal difference and review core patches.
-- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
I thought about this and checked it out in the database. The database only holds relative paths, i.e. modules/taxonomy/taxonomy.module so it can't be the wrong absolute path in the system databse thats causing this problem.
I have a new problem now too though, I tried to create a symlink to the modules directory like one user suggested, I put the symlink outside of the webroot, this didn't work out too well for me, so I moved them back, but now when I go to sites/build/modules it changes the file path in the database to point to modules/modules/taxonomy/taxonomy.module (this is the relative path of where the symlink was). I can import a clean copy of the database, (where the file pointer is at modules/taxonomy/taxonomy.module) but when I visit admin/build/modules again, it changes back to modules/modules/taxonomy.module. Cog Rusty wrote:
On Thu, Feb 19, 2009 at 2:32 PM, Earnie Boyd earnie@users.sourceforge.net wrote:
Quoting cooper Quintin cooperq@cooperq.com:
Thanks, I will try this. It's weird that it would be reading from the wrong directory though. Is the modules directory cached in drupal somewhere or something? I find it very odd that it would ever read from a different webroot.
Yes, the system table contains the paths to modules. If you've copied the DB from one site to another then the you'll likely have the wrong paths to all modules.
... which normally are automatically updated in the database whenever you visit the admin/build/modules page.
-- Earnie http://r-feed.com Make a Drupal difference and review core patches.
-- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
Also, just to note, I have made sure that all of the cache tables are cleared out. cooper Quintin wrote:
I thought about this and checked it out in the database. The database only holds relative paths, i.e. modules/taxonomy/taxonomy.module so it can't be the wrong absolute path in the system databse thats causing this problem.
I have a new problem now too though, I tried to create a symlink to the modules directory like one user suggested, I put the symlink outside of the webroot, this didn't work out too well for me, so I moved them back, but now when I go to sites/build/modules it changes the file path in the database to point to modules/modules/taxonomy/taxonomy.module (this is the relative path of where the symlink was). I can import a clean copy of the database, (where the file pointer is at modules/taxonomy/taxonomy.module) but when I visit admin/build/modules again, it changes back to modules/modules/taxonomy.module. Cog Rusty wrote:
On Thu, Feb 19, 2009 at 2:32 PM, Earnie Boyd earnie@users.sourceforge.net wrote:
Quoting cooper Quintin cooperq@cooperq.com:
Thanks, I will try this. It's weird that it would be reading from the wrong directory though. Is the modules directory cached in drupal somewhere or something? I find it very odd that it would ever read from a different webroot.
Yes, the system table contains the paths to modules. If you've copied the DB from one site to another then the you'll likely have the wrong paths to all modules.
... which normally are automatically updated in the database whenever you visit the admin/build/modules page.
-- Earnie http://r-feed.com Make a Drupal difference and review core patches.
-- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
I have solved this problem, (and I feel a little stupid). The problem was that I had the securepages module enabled. This was forcing https for all admin pages. Unfortunately I had the https webroot set up as the same webroot for all the sites. So in a word, I misconfigured https. Once I set up https correctly, everything fell into place. Thanks everyone for your help, and I'm sorry I didn't more thoroughly check things out on my end first.
cooper Quintin wrote:
Also, just to note, I have made sure that all of the cache tables are cleared out. cooper Quintin wrote:
I thought about this and checked it out in the database. The database only holds relative paths, i.e. modules/taxonomy/taxonomy.module so it can't be the wrong absolute path in the system databse thats causing this problem.
I have a new problem now too though, I tried to create a symlink to the modules directory like one user suggested, I put the symlink outside of the webroot, this didn't work out too well for me, so I moved them back, but now when I go to sites/build/modules it changes the file path in the database to point to modules/modules/taxonomy/taxonomy.module (this is the relative path of where the symlink was). I can import a clean copy of the database, (where the file pointer is at modules/taxonomy/taxonomy.module) but when I visit admin/build/modules again, it changes back to modules/modules/taxonomy.module. Cog Rusty wrote:
On Thu, Feb 19, 2009 at 2:32 PM, Earnie Boyd earnie@users.sourceforge.net wrote:
Quoting cooper Quintin cooperq@cooperq.com:
Thanks, I will try this. It's weird that it would be reading from the wrong directory though. Is the modules directory cached in drupal somewhere or something? I find it very odd that it would ever read from a different webroot.
Yes, the system table contains the paths to modules. If you've copied the DB from one site to another then the you'll likely have the wrong paths to all modules.
... which normally are automatically updated in the database whenever you visit the admin/build/modules page.
-- Earnie http://r-feed.com Make a Drupal difference and review core patches.
-- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
Στις 19-02-2009, ημέρα Πεμ, και ώρα 22:18 -0800, ο/η cooper Quintin έγραψε:
I have solved this problem, (and I feel a little stupid). The problem was that I had the securepages module enabled. This was forcing https for all admin pages. Unfortunately I had the https webroot set up as the same webroot for all the sites. So in a word, I misconfigured https. Once I set up https correctly, everything fell into place. Thanks everyone for your help, and I'm sorry I didn't more thoroughly check things out on my end first.
cooper Quintin wrote:
Also, just to note, I have made sure that all of the cache tables are cleared out. cooper Quintin wrote:
I thought about this and checked it out in the database. The database only holds relative paths, i.e. modules/taxonomy/taxonomy.module so it can't be the wrong absolute path in the system databse thats causing this problem.
I have a new problem now too though, I tried to create a symlink to the modules directory like one user suggested, I put the symlink outside of the webroot, this didn't work out too well for me, so I moved them back, but now when I go to sites/build/modules it changes the file path in the database to point to modules/modules/taxonomy/taxonomy.module (this is the relative path of where the symlink was). I can import a clean copy of the database, (where the file pointer is at modules/taxonomy/taxonomy.module) but when I visit admin/build/modules again, it changes back to modules/modules/taxonomy.module. Cog Rusty wrote:
On Thu, Feb 19, 2009 at 2:32 PM, Earnie Boyd earnie@users.sourceforge.net wrote:
Quoting cooper Quintin cooperq@cooperq.com:
Thanks, I will try this. It's weird that it would be reading from the wrong directory though. Is the modules directory cached in drupal somewhere or something? I find it very odd that it would ever read from a different webroot.
Yes, the system table contains the paths to modules. If you've copied the DB from one site to another then the you'll likely have the wrong paths to all modules.
... which normally are automatically updated in the database whenever you visit the admin/build/modules page.
-- Earnie http://r-feed.com Make a Drupal difference and review core patches.
-- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
-- Cooper Quintin Freelance Programmer, Indymedia Journalist http://CooperQ.com (510) 827-5382
.
ok, I had a big breakthrough on this. I have a multisite installion. Running off of one codebase. In other words I have a test, development, and produciton enviroment, all with different webroots, but all being checkouts of various revisions of an svn repository. I have a sites/foo/settings.php directory for each of the sites. I noticed when I put a module in the sites/all/modules directory of the production site, it shows up in the admin/build/modules listing for the dev site and so on. So obviously drupal is doing something weird only looking for modules in the production site. Earl Cooley III wrote:
cooper Quintin wrote:
I really just don't know what to do any more.
Perhaps you should also post a Support Request on the Imagecache project issues page:
http://drupal.org/node/add/project-issue/imagecache
That, at least, may get more eyes on your situation.
On Wed, Feb 18, 2009 at 2:43 AM, cooper Quintin cooperq@cooperq.com wrote:
Does nobody have any idea on this? I have checked my filesystem extensively using grep and find and have not found any trace of imagecache left in my filesystem. I have deleted it several times from the database but it always comes back and is listed there in the modules page. I really just don't know what to do any more.
Find the entry of the module in the system table in the database. Look at its path there. You will know exactly where Drupal found it.
-- Cooper Quintin Freelance Programmer, Indymedia Journalist http://CooperQ.com (510) 827-5382
-- [ Drupal support list | http://lists.drupal.org/ ]
-
Cog Rusty -
cooper Quintin -
Earl Cooley III -
Earnie Boyd -
Giorgos Komninos -
KOBA | Hans Rossel