By noxel on

I uploaded the ecommerce and token module folder into sites/all/modules, but i can't enable them in the site building -> modules list, as they are not there.

Can anyone help me out? :S What am i doing wrong?

Thanks

⋅ Categories: Drupal 5.x

Comments

cayenne’s picture

cayenne commented

put 'em in the /modules subdirectory of your drupal directory

:)

yelvington’s picture

yelvington commented

The recommended location for contributed modules in Drupal 5.x is sites/all/modules.

If the modules are not showing up, something else must be wrong --for example, the wrong versions of the modules. Drupal 5.x expects to find 5.x modules with .info files.

cayenne’s picture

cayenne commented

It works, but I will look at that. Thanks!

:)

stinkytofu’s picture

stinkytofu commented

Don't put the files into the /drupal/modules folder. They belong inside /drupal/sites/all/modules/.

I encountered this same exact problem too and after some tinkering with permissions settings, I found out that you must enable execute permissions on the /drupal/sites/all/modules folder. Once I changed the permissions for the modules folder, the modules were displayed inside Drupal Admin.

chmod -R 755 sites/all/modules

mtrimble’s picture

mtrimble commented

I seem to have the same issue. In the past I've just put the modules in the drupal/modules directory and it worked. I just did a fresh in stall of FC 7 and installed Drupal. I'm not sure if it is a known issue but I do have SELinux enabled.

I added a couple of modules I've used in the past and they would not display. I added a few more just to rule out there being a problem with the modules in question. I then searched the Drupal forums and found this post. I followed the above mentioned suggestions (moving the modules to sites/all/modules and setting th permissions to 755). I'm still not having any luck.

Does any one have any idea what the issue may be?

gengel’s picture

gengel commented

I'm having the same problem. I've tried putting modules in /modules, /sites/all/modules and /sites/default/modules, and they won't show up in the modules listing. Also tried resetting the cache, different modules - the works

klowe’s picture

klowe commented

had the same problem. run you cron and it will work.

ctopkelly’s picture

ctopkelly commented

I have followed the above and it is still not working.

Not sure what to do

Krazna’s picture

Krazna commented

I have tested this on three different drupal installations with this module http://drupal.org/project/pngfix

The accessrights were originally different from other modules in my /modules.

- Changing accessrights did not help
- Running cron did not help
- Reinstallation did not help

cornucopiacafe’s picture

cornucopiacafe commented

I am having the same problem with trying to get downloaded modules to show up.

I am using XP/sp1. I installed Drupal 6-6 per intructions. I have the latest Xampp installed with the latest Apache, MySql, Filezilla and Mercury.
I have installed the downloaded modules in C:\xampp\htdocs\drupal-6.6\sites\all\modules. The downloaded modules which I cannot see in admin > site building > modules are the following:
cssedit 6.x-1.x-dev
e-card 6.x-1
footermap 6.x-1.2
i18n-6.x-1
language icons 6.x-1.0
simplenews 6.x-1.0-beta5
translation overview 6.x-1.0
views 6.x-2.1
views slideshow 6.x-1.0-beta
wp comments 6.x-1.0

I am using a Zen theme I customized with the Starter Kit. I tried switching over to Garland, but... still no joy. I have run cron, restarted, cleared the cache, even offered up a glass of wine sacrifice to the BOfH. (Sadly, since it is just me here, and I'm a chef not a programmer, I had to drink it.)

I have read ALL the relevant posts regarding this issue, which SEEMS to be fairly common, however... beyond the suggestions of suggesting the modules are placed in sites\all\modules (already there) or suggesting write permissions need to be granted (this isn't Unix) I cannot find anything that suggests how to fix this.

Help please? How am I screwing up?

vm’s picture

vm commented

ensure the folders you created at sites/all have the correct permissions.

MrAdventure’s picture

MrAdventure commented

I had the same problem, non-standard themes weren't showing up either. Permissions all matched my other sites, 755. Finally figured out that I had dropped the standard drupal theme directory into /sites/all/themes. After I deleted it and uploaded custom themes, modules started working as well.

Mr.W.A.C.’s picture

Mr.W.A.C. commented

***EDIT- "I didn't realize that this was in the Drupal 5.x I am actually only running 6.x so if this doesn't apply to you then you can kindly skip it. Hope it helps someone though..."

Funny I had this very same issue. Tried all the suggestions including changing file permissions on ftp.

Still to no avail, until at least the moment I re-read it all including the README.txt that is in the directory at /sites/all/

It reads and I quote quite simply;
"// $Id: README.txt,v 1.3 2006/12/23 15:35:51 dries Exp $

This directory should be used to place downloaded and custom modules
and themes which are common to all sites. This will allow you to
more easily update Drupal core files. These modules and themes should
be placed in subdirectories called modules and themes as follows:

sites/all/modules
sites/all/themes

MY Mistake was simply the Lower/Uppercase distinction in the /Modules and /Themes directory that are required to be completely lowercase. /sites/all/modules and /sites/all/themes

Funny I didn't remember having this problem on other installations. Good to go now! Hope it helps folks.

Be specific right down to capitalization...

dieDuiwel’s picture

dieDuiwel commented

I also had problems with modules not showing up, even after all of the above. Themes in tld/sites/all/themes worked fine but modules in tld/sites/all/modules would not show up. Placing the modules in tld/modules worked. This was with a Drupal 6.x installed via Fantastico via a host's Cpanel. Doing a fresh, manual install of Drupal did not have this problem and all works fine now. It is not the first time Fantastico's drupal install has messed me around, previously mixing table field colation types there by also rendering some modules unusable until all colations were matched up.
If you're using Fantastico to do the install and having problems, I suggest testing a manual Drupal install.

WorldFallz’s picture

WorldFallz commented

This was with a Drupal 6.x installed via Fantastico via a host's Cpanel. Doing a fresh, manual install of Drupal did not have this problem and all works fine now.

Yet another post on why drupal should never be installed with an installer.

vm’s picture

vm commented

a 3rd party installer. Using drupals native installer is best :)

I knew what you meant but felt a need to clarify for the newcomers who tend to learn this lesson far too late.

For the those who tend to use 3rd party installers:
3rd party installers like fantastico or some other provided by hosts are great for testing scripts and allowing you to quickly install. However once a decision is made on which script you want to use there are far fewer headaches when you install the script on its own. Beyond that you know by doing so that you are using the same exact system as the bulk of the people you are asking questions of. using a 3rd party installer adds a nuance that most won't be exposed to.

WorldFallz’s picture

WorldFallz commented

Thanks VM! Now the I see it, what I wrote makes no sense, lol. (edit: now with more english)

EDIT: ooohh... signatures are back. Can't wait for the link spam to start rolling in.

vm’s picture

vm commented

: ) to both.

handinherpocket’s picture

handinherpocket commented

It was the capitals that tripped me up too. I was ready to tear my hair out, until I changed all the folders starting with capitals to small letters. Such a simple thing, but boy, can it cause headaches!

gx502’s picture

gx502 commented

I am a beginner, and i was setting up a test environment, on a Windows PC using WAMP server.

I am getting the same thing, contributed themes and modules do not show up under administration-> site building levels of the drupal site.

I am on a PC, but using cygwin I did a chmod -R 755 to the sites/all/modules and sites/all/themes directories.

Also i checked that the directory names for contributed themes and modules is in lowercase.

Any ideas?

Could this be related to the version of PHP, I am running PHP 5.3 and Drupal 6.16? (Please, excuse me if its a dumb question.)

beatmaster-2’s picture

beatmaster-2 commented

Recently started learning Drupal development (again). The drupal handbook states, in reference to the .info file for a module: "... This file is required for the system to recognize the presence of a module..." After creating a .info file, my module would not show up on the module list page (Administer->Site Building->Modules). After searching the net for a few hours, and finally arriving at this post; and after trying all the suggestions here (755 permissions, re-installation, the works), I decided to create an empty .module file. One refresh later, I was smiling - it worked!

By the way this is a note for Drupal 6.x - am not sure if it applies to Drupal 5.x as well. I am using Drupal 6.14. I have only posted it here because this is what turned up when I search for "module not showing up.."

FredAt’s picture

FredAt commented

There are probably lots of reasons why a module does not show up. Here is one I ran into recently - I accidentally put the .module file in two folders inside sites/all/modules.

drbowen’s picture

drbowen commented

I am having a similar problem on Centos 5.4 and Drupal 6.15. I have untarred and unzipped cck, image, admin_menu, globalredirect, imagefield and placed these into:

/sites/all/modules/

# chown apache:apache all -R
# chmod 755 all -R

I still can't get the modules to show up in the Drupal Administer -> Site Building -> Modules.

There are references to both ".info" for Drupal 5.x and ".module" for 6.x

What is ".module" and what do I do with it?

Any other ideas on why my new modules won't show up in the Administer -> Site Building -> Modules section?

Sam Bowen

vm’s picture

vm commented

modules for drupal 5.x will not work in drupal 6.x. If you uploaded 5.x modules they need to be removed.

the .module file is the main part of the module. you do nothing with it. You leave it inside it's respective folder as with all other files that are shipped with a module. for example; admin_menu folder includes all the files required to run admin_menu. One uploads the enture folder to sites/all/modules.

If the above isn't helpful please redefine your question.

drbowen’s picture

drbowen commented

This is a brand new install of Drupal 6.15. All the new modules were created for 6.x.

I have placed the new modules in the recommended location. I have changed the permissions and ownership as recommended above.

The new modules are not available to enable in the Drupal site. This is the same behavior that prompted this thread.

I need for the modules to show on the list to enable them. I could use some insight on why the new modules are not showing up. I am not sure how I can phrase this more clearly.

Sam Bowen

vm’s picture

vm commented

the clarification asked for was due to this statement "There are references to both ".info" for Drupal 5.x and ".module" for 6.x"

others in this thread state, running cron aided. Have you tried that?

Did you as others in this thread have, install with a host installer? I'd presume that to be the case since you are already using a version that is 1 release behind in security fixes. If so, I'd use drupal's native installer and test.

drbowen’s picture

drbowen commented

Drupal 6.15 was installed using the Drupal installer (before 6.16 was released).

Yes, I have also run cron.

Sam Bowen

vm’s picture

vm commented

then I'm out of ideas if all your folder level permissions are correct. I can't reproduce the issue.

drbowen’s picture

drbowen commented

Putting the modules into the main modules directory causes them to show up immediately in the modules section.

We use virtual hosting with Apache vhosts. Could this be a path issue?

Sam Bowen

techgirlgeek’s picture

techgirlgeek commented

Check your phpinfo() page, a link can be found on the reports, Status report, and make sure safe_mode is not set to On for either Local or Global. If it is set to on for Global, check the system php.ini file and make sure safe_mode is not set to On. If your Local safe_mode is set to On, check the vhosts *.conf file.

Karyn (TechGirlGeek)
karyn@techgirlgeek.com
http://techgirlgeek.com

timlangens’s picture

timlangens commented

I had the same problem. Changing the permissions didn't work, I thought.

When changing permissions, see that permissions are changed on all files in the folder. the files in the folder need execution rights!

lindad’s picture

lindad commented

G'day

I just finished wrestling this problem myself. It seems that it can be caused by many different issues.

I was seeing my modules just fine, moved the site to another directory path. The next few modules I added, did not show up. I checked all the permissions in the threads, the modules etc. Then re-ran my status reports. My file system directory was missing. Works fine now.

Hope this helps someone who has already tried the other ideas...;-)

Joi’s picture

Joi commented

I solved this problem by disabling safe_mode.

barbietunnie’s picture

barbietunnie commented

Turning PHP's safe mode off worked for me. All other options didn't work for me, so if you're still not seeing the newly installed modules, check to see if PHP is running in safe mode on your server. Turn it off if it is

Samshel’s picture

Samshel commented

I've tried everything that has been said here but the problem persists. In my case it is only the flowplayer module with this issue, every other module works just fine. Hope someone find another way to fix this.

jippie1948’s picture

jippie1948 commented

but the peoblem persisted.

Eventually I copied the module folder that wouldn't work in the 'sites/all/modules' folder, into the folder 'sites/myspecalsite/modules' and surprise, surprise it worked and showed up in the module list...
Strange...

Samshel’s picture

Samshel commented

Forgot to post a follow up after I finally fixed this. In my case the flowplayer module that comes within swftools was conflicting with the actual standalone flowplayer module, this happened because both modules had exactly the same name, and so Drupal found swftool's flowplayer.module first and didn't list the one I was using.

mkmaroon’s picture

mkmaroon commented

Hey.

I also struggled with this. Tried all the fixes posted above (thanks for those!) - permissions, php safe mode (was off). No luck. I finally solved the problem, it turned out to be related to SELinux. I had to change the SELinux security context of the module directory (command is 'chcon', without quotes). So, if you have SELinux enabled, you might want to check this. Hope this helps!

faustus23’s picture

faustus23 commented

After some hours of try and error I found out, that I copied the files in the wrong folder (on Open Suse Linux).

It worked for me when I copied the modules into

www/htdocs/drupal-6.22/sites/all/modules
(which was a protected folder, so I had to change the permissions)

and NOT into

www/htdocs/sites/all/modules
(which seems to be the one I should copy the files in according to the documentation)

Good Luck!

vm’s picture

vm commented

www/htdocs/sites/all/modules

The above, from the docs, assumes your drupal install is in the root and not in a subdirectory /drupal-6.22/

if a subdirectory is used, the you are correct, /subdirectory/sites/all/modules

lencrockett’s picture

lencrockett commented

Had this issue recently, turns out it was due to the classic "__MACOSX" folders containing dupes of the modules. Be carefully using zip on a Mac.

dreffed’s picture

dreffed commented

I managed to fix this by checking permission as outlined above but the missing step for CENTOS and eny SE Linux is the SE Linux Contect setting, I copied the setting from the modules that showed to the folders and file of the ones that didn't, now they work.

IHTH

David

sridharpandu’s picture

sridharpandu commented

This is how you change the chcon of your theme file

$ls -Z ~/themes
You should see an output similar to this

drwxr-xr-x  root root user_u:object_r:httpd_sys_content_t bluemarine
drwxr-xr-x  root root user_u:object_r:httpd_sys_content_t chameleon
drwxr-xr-x  root root user_u:object_r:httpd_sys_content_t engines
drwxr-xr-x  root root user_u:object_r:httpd_sys_content_t garland
drwxr-xr-x  root root user_u:object_r:httpd_sys_content_t pushbutton
-rw-r--r--  root root user_u:object_r:httpd_sys_content_t README.txt
$ls -Z ~/sites/all/themes
drwxrwxrwx  root root root:object_r:user_home_t        theme237

One look at the directory listing and the difference is obvious.

Now
$chcon -vR --type=httpd_sys_content_t sites/all/themes

Check

$ls -Z ~/sites/all/themes

context of sites/all/themes retained as root:object_r:httpd_sys_content_t
context of sites/all/themes/theme237 changed to root:object_r:httpd_sys_content_t
context of sites/all/themes/theme237/screenshot.png changed to root:object_r:httpd_sys_content_t

.
.
.

Acer Aspire 5745
[i5 430M, 3GB, 320GB]
Ubuntu 12.04 (Precise Pangolin)
Drupal 6.15, 7.x
DigitalOcean, Go Daddy, Rackspace,

sridharpandu’s picture

sridharpandu commented

Sometimes if the user and role is not assigned in the security context you might get an error message

chcon: can't apply partial context

You should then apply the security context in two steps

chcon -h system_u:object_r:httpd_sys_content_t sites/all/themes
chcon -R -h root:object_r:httpd_sys_content_t sites/all/themes

Acer Aspire 5745
[i5 430M, 3GB, 320GB]
Ubuntu 12.04 (Precise Pangolin)
Drupal 6.15, 7.x
DigitalOcean, Go Daddy, Rackspace,

samcis’s picture

samcis commented

I suggest you download some more modules to see if they are showing the same negative response or not, or download some modules that are ment to create backup. So you can take backup from those modules

The other way could be to just contact the hosting company to take backups.

Or see this http://drupal.org/project/backup_migrate