By cxanders on

i have searched this forum for days but found i seem to be the only person with this issue. it is a deal-breaker and i can't seem to interest anyone in answering either so i assume my situation unique.

when i install 6.x on my server - MySQL 5.x, PHP 5.x, Apache - then attempt to change configuration of modules, either enable or disable i experience ...

on install any module configuration changes are ineffective, THEN logout and login again to "administrator" sometimes adding modules to the sites/all/modules/ folder - when i try to enable modules, none of the module configuration changes are saved - nothing, nada - no confirmation lines, no saved changes to module enable/disable! Other configuration, content, blocks, etc. are saved but not modules! i can't add or uninstall modules via the control panel - i can only uninstall by physically removing the files.

any suggestions? what exactly provides data to the module configuration page? which tables are involved? what could be causing this major headache?

-Chris Anderson

⋅ Categories: Drupal 6.x

Comments

VM’s picture

VM commented

exactly what version of PHP 5.x?

What folder level permissions are set on the folders sites, all, and modules?
your sure the folder you created /modules/ is lower case?

cxanders’s picture

cxanders commented

all lowercase - folder permissions is 777, recursive. thanks for trying to help...

PHP 5.2.5

VM’s picture

VM commented

puts me out of ideas. No idea what could cause it beyond those things.

cxanders’s picture

cxanders commented

i appreciate the attempt. i have been trying to solve this problem for about five weeks now, on and off.

i don't have this issue when i install drupal 5.22 but, as this will soon be left in the wind, i want to move on. it doesn't occur with drupal 6.9 - i seem to recall something else (the sidebar login did not work, just sits there, no error just resets - had to use main /user/ login page) occurs with 6.9 but i can get the modules to enable.

next i tried 6.13 and 6.16 and they both fail when attempting to enable modules (they also have the sidebar login issue). maybe something really wierd is going on with my machine - i use nexcess.net for a shared server, MySQL 5.0.51a and PHP 5.2.5 as i said before.

i have a windows box here at the house i am going to try tomorrow - but in any case that doesn't solve my problem when trying to work drupal for clients.

VM’s picture

VM commented

I'd update WAMP to the latest version of PHP 5.2.x and test I'm using the last version before PHP 5.3 which I think is 5.2.11

cxanders’s picture

cxanders commented

the nexcess.net server hosting my sites is not windows ... just my home computer.

VM’s picture

VM commented

erp mixed up your issue with someone elses who is using WAMP. Thats what I get for working on multiple threads at the same time. Sorry.

cxanders’s picture

cxanders commented

i just tried a 6.9 install and no luck enabling modules - this has become a definite deal-breaker, no drupal installs for me since i can't even get an install that works on my own server!

Anonymous’s picture

Anonymous (not verified) commented

Why would you not recommend running a VM with a linux box if you have to run it on a Windows machine as a last ditch effort??

cxanders’s picture

cxanders commented

the problem was found in the install of 6.9 and above - a user "0" without field data was created and caused the erratic behavior i have been dealing with. i removed the blank user from the table and all works as advertised. i suppose someone might want to know where it is added in the install routine but i have given enough to this for the time being...

Ron, for the record now that i know how to fix the bug - i don't need to abandon Drupal if the client likes it!

VM’s picture

VM commented

If i understand correct. You removed uid 0 ?

if so, uid 0 is the anonymous user id. was there an extra uid 0? or are we not talking about uid at all?

cxanders’s picture

cxanders commented

i added the blank user (uid 0) back in and the installation still performs properly. now i suspect the user table was to blame and by making mods to table data corrected the flaw. perhaps repair table would have worked also...

cxanders’s picture

cxanders commented

this morning i accessed my installation of 6.16 which miraculously began working correctly last night after first removing then inserting a user with uid 0, i attempted to log in using the sidebar panel and - poof - it began again, no log in just refresh without error message indicating correct user/pass combo. i tested incorrect user/pass and an error is generated.

to log in i must go to q=user, log in is successful. however, i cannot change block positions nor can i enable/disable modules. once, again, i tried all the fixes i had come across lately with no success.

with all its potential, i appears drupal is not an application i am able to help clients with. ron's work-around using a VM, windows installation is silly when other frameworks exist that function correctly from the beginning.

with so many apparent successful installation, i can only assume my servers present some absolutely unique situation and just move on.

it's been challenging and i wish all you guru's good luck!

VM’s picture

VM commented

I'd sort out the environment issue as it must be something in the environment itself.

you are using the unclean url to login, is clean urls enabled? administer -> clean urls
is the .htaccess file located in your root ?

cxanders’s picture

cxanders commented

just going to outline structure to see if something amiss...

domain contains multiple sub-domains, each located physically in folders on root. main htaccess directs sub-domains to individual using Redirect command - folders as well, works fine. i did not use any url mods for drupal because i didn't want to add too many parameters to debug with module/blocks problem being so specific.

last thing i am trying - previously i un-zipped file to a local folder the compressed the resultant file/folder structure to another .zip file. uploaded directly to the sub-domain folder then un-zipped. perhaps that step altered some files in the process. i am now uploading the original drupal tar.gz, un-compressing the moving the files to the proper folder...

believe it or not - it works! i will work on it today then check again tomorrow to see if this is the actual fix...

cxanders’s picture

cxanders commented

by removing the clean urls - disabling, i mean - i am able to affect mods to blocks and modules, when i enable it, they are not editable. more later as i investigate further...