Malfunctioning State dropdown

but once I try to add the address field into my content as a standard user

Do you mean that you let users create content types? Or do you mean it breaks when simply creating content?

Does the specified table actually exist? (admin_drupal.content_field_address_1???) That's a funny name for a table.

One more thing you can do is install the dev module and enable SQL backtracing so that when you get errors, we can figure out which function called what and with what variables. That would be the most helpful and is how I solve such problems on my machine.

Um, devel has its own permissions, so make sure that user has them. It wouldn't be an admin really.

Oh, wait a minute. You said godaddy? There are semi-known issues with godaddy. I'm not sure if it's AJAX related or what. I actually moved hosts from godaddy for the same problem! I can't believe I didn't see that you mentioned them. I should read these messages a little closer. A while ago, I was using my godaddy hosting account (which I use for personal stuff - Gallery mostly) as a testbed for a Drupal project. All I wanted to do was set everything up there and then move it over. Well, when it came time to setup the CCK_Address module (using that crazy other-users-probably-will-never-use-it feature of selecting addresses from known database entries) I could not get the table columns to populate the child drop downs, nor the state to populate either. I think I tried for 5 hours until, for no apparent reason, it worked one time. As I only needed to set that one address up that way once, I didn't think about it and after I moved the project over, users didn't have any problems with the AJAX stuff.

A quick search at google for drupal web hosts will turn up several articles worth reading. Godaddy does not make the cut. In fact, another problem I had with them was "The SQL server has gone away". I'd get that message (50-100 times on one page) after the MySQL server would take a dump. Reloading the page (once or twice or more) would bring it back. Not something you'd want users to have to do. This would really only happen on particularly heavy pages, but still - not a good thing. Drupal is notorious for its heavy database usage. It's not uncommon for a regular page, viewed by an authenticated user (not cached), to use over 200 queries.

So for now, I'm leaning toward host issues. And from my experience, they aren't too willing to help out - at least with shared hosting accounts. I couldn't say how their more expensive offerings are.

By the way, due to the number of queries Drupal makes, it can be processor intensive and has been known to get accounts turned off so as not to short-change the other accounts on the same machine. I think godaddy is offering drupal now in their applications section, but that shouldn't be mistaken for catering to drupal users' needs.

I'm pretty sure the change you're making won't make a difference, but let me know anyway.

I read the first page of that article. I'll read the rest when I get the chance. If it proves to be a better option than Activeselect (the way I use it solves the problems mentioned on that page), then I guess I'll rewrite my module! Thanks for the link.

As for now, I'm still sticking with the idea that SOMETHING related to how godaddy is operating is the problem here, but I don't know what it could be. Have you had any other Activeselect-based modules work? I wonder if the implementation of AJAX in it isn't quite right, or fails in certain conditions.

Using Firebug in Firefox, I was able to see that the correct data was being returned from the AJAX query, but wasn't making it into the drop down fields. The AJAX spinner graphic would keep on spinning for hours (I left and ate lunch once). What was missing was the command to append the document with that data that was returned.

Like I said, no problem on any other setup I've used. So I'm not sure this is a bug - or something that can be debugged. Maybe a support request? What do you think? Do you have any other web space elsewhere you could try out? Or a friend with space you could borrow?

The drop downs will work without AJAX if you disable the activeselect module.

Something else to try. On my godaddy account (still use it for personal, non-drupal stuff), I just tried this and had the same problem as before. Then I enabled the stuff in devel and it worked. See the screen shot.

I neglected to suggest that you try the same settings and let me know if it works.

For me, it looks like all I need are "collect query info" and "display query log" and everything works. That's strange. Have you tried uninstalling devel and seeing if it works then? Did you ever NOT have devel installed when you tried to use this module?

That would suggest to me that a content type itself has become corrupted. You should try to delete that content type and then rebuild it. The CCK module itself is looking for a data field that does not exist. Most of the data field housekeeping is done by the content module. In fact, I can't think of any creation/maintenance/destroying that my module does directly. Is this the same content type that you started with and the one you tried to use drop down states with, or is it a new one? Have you inspected your database to make sure that the table exists?

So I was finally able to figure something out I think. I realized that all of my own installations were screwed up like yours but I had some things in place preventing their detection.

Anyway, I compared the js file of the dev version of activeselect to the release version and there is one significant change which seems to solve the problem. As there are no other detrimental changes to the js file and no changes whatsoever to the module file, I'm advising the use of the dev version. Please see if that fixes things for you as well. Marking this as fixed unless you tell me otherwise.