I have just installed Drupal on my go daddy account. My first order of business was to install the backup and migrate module.

I have uploaded to the 'sites/all/modules' path.
I have cleared cache and restarted browser.

However, the module just won't show up in the modules list. In fact, there isn't even an "other" section on the modules page. Very frustrating. Any help would be most appreciated....eerrr

Comments

m_sabal’s picture

Did you install the module directly in the modules directory (in other words, are the php and css files directly under modules) or did you create a subdirectory?

Make sure you have followed all these steps carefully:
http://drupal.org/node/70151

weblance’s picture

As I said earlier in the post I placed the file in 'sites/all/modules'. Not in the core modules directory. This problem is not so simple. I have been working on this for 2 days. I assure you, I have followed the directions. I have also installed a theme that does not show up either. Can I do something to get these new installations to show up?

bfitzgerald’s picture

Have you run update .php?

Are there possible name conflicts drupal does not like modules or themes having the same name so check that check the name in the .info file I have run into problems like that when messing about with different versions of the same theme and forgetting to change the name of the theme in .info file

In a case like this I would take all the new things out and start again.

I would take a module that you know works and place that in the folder then see if that is seen by drupal

If that does not work is it possible that the folder is in the wrong place?

is is possible that the hook that scans these folders has been switched off?

is it possible to uninstall the version of drupal and install it again easily?

weblance’s picture

In a case like this I would take all the new things out and start again.

Jeff: 4x already

I would take a module that you know works and place that in the folder then see if that is seen by drupal

Jeff:I have tried many modules

If that does not work is it possible that the folder is in the wrong place?

Jeff: I believe I have this right, I have gone over it a thousand times

is is possible that the hook that scans these folders has been switched off?

Jeff: GREAT QUESTION, HOW DO I CHECK THAT?

is it possible to uninstall the version of drupal and install it again easily?

Actually this is godaddy version of drupal... if I had issues, many others would too

WorldFallz’s picture

If by "godaddy version of drupal" you mean one installed by fantastico or some other non-drupal installer the very first thing you should do is start over with a manual installation. These types of installs do nothing but cause these kinds of weird, esoteric, difficult to diagnose problems.

m_sabal’s picture

Each module needs to be in its own subdirectory, as do themes.
The structure should be something like this:
sites/all/modules/ubercart/{lots of files}
sites/all/modules/backup/{lots of files}
sites/all/themes/genesis/{lots of files}

update.php is generally used when taking an existing module to a new version; but it won't hurt to try if nothing else is working.

weblance’s picture

I run that and nothing......

folders are as you described as well

Jamesroughton’s picture

Make sure that you do not have a duplicate module. One in the drupal module folder and one in the sites/all/module. I had this same problem and this was my solution.

http://www.drupalus.com

teaberryblue’s picture

Did you check the permissions on the folder? Make sure you gave it universal read access! Some FTP programs default to making things invisible.

erahbee’s picture

Jeff, I have the same problem now with one of my new installations. Did you solve your problem and how?

erahbee’s picture

I solved the same problem I had by just re-installing Drupal from scratch on my HostGator hosting. (I used this fantastico or whatever it may be called / now I just did it myself).
All works very fine now.

tomallan’s picture

I had the same issue after copying a /sites subdirectory from my local machine to the server. I finally realized that the local (test) site had the first letter of the "modules" & "themes" folders capitalized. My hosted linux server didn't like that. I changed the folder names and drupal instantly recognized all the contributed modules.

michaeljw’s picture

I'm using Drupal 6.17. I have the same issue. I've checked all posts above. Newly uploaded modules and themes are not recognised at /admin/build/modules and /admin/build/themes.

1. Folder permissions are correct;
2. I'm uploading modules the same way I've done it many times before - to the sites/all/modules folder;
3. Drupal was installed manually.

However this is the first new module I've uploaded after changing hosting company - so that might be a factor.

Please help! I'm banging my head against the wall here!

Thanks in advance
Michael

Codeblind’s picture

Are the file permissions correct on the remote machine? Some servers will change the permissions and ownership of files and directories automatically.

michaeljw’s picture

Thanks,

The file permissions are set to 755 on the remote machine. This is the same as all other module folders in the sites/all/modules directory.

Any other ideas?

aphroditehathor’s picture

Hi,
I'm a newbie. I updated from 5.23 to 6.19. The new installation showed that most of the contributed modules were incompatible with 6.19, so I had to update almost all of the contributed modules I had in the installation. The first 5 or 6 updates went well. However, at some point, the system stopped recognizing the new module updates. The new module versions reside in sites/all/modules, but the system does not appear to see it.

It is doing this with FCKeditor, cck, image assist, and advanced profile, among others.

I see that mysql database actually has entries for some of those modules, but the status was set to 0. I changed a few of the status to 1, but it didn't help.

manitoba22’s picture

I was bitten by a similar problem. It was caused by wrong SElinux attributes. So, if you run SElinux (default on Redhat, Centos and the like), you could do a quick check with "getenforce", if enfocing is enabled. If so, turning off SElinux temporarily with "setenforce 0", in my case the problem was gone.