Updated to 2.0. Get this error when viewing a node containing address field for CCK:

* warning: asort() expects parameter 1 to be array, null given in /mysitepath/sites/all/modules/cck_address/cck_address.module on line 1179.
* warning: Invalid argument supplied for foreach() in /mysitepath/sites/all/modules/cck_address/cck_address.module on line 1180.

Dunno what to do from here.. Ran update.php but it didn't make a difference.

W

Comments

rconstantine’s picture

Title: Database warnings when updating to 2.0 » UPGRADE TO 2.0 INSTRUCTIONS!!! READ THIS!!!
Category: bug » support

Sorry about that. I could have sworn I added instructions some where about this. This is a known upgrade issue and all you have to do is go to each address field's settings page and re-save them. Be careful to check the settings before you do as the new defaults may not be what you want.

That's it!

The easiest way to find all of your address fields is to go to /admin/content/types/fields, then look for cck_address in the field type column.

VValdo’s picture

Fixed! Thanks! I looked at the README but didn't see it.

W

rconstantine’s picture

Assigned: Unassigned » rconstantine

I'll update the README and the project page when I get a chance.

madflute’s picture

I followed the instruction, and ran update.php a few times but I think my data is now broken. I type the data then hit Save, I get following error and data is g, g, gone. Any help would be appreciated. I am on Drupal 5.5.
====
user warning: Unknown column 'field_address_other' in 'field list' query: UPDATE content_type_venue SET field_address_street1 = '84 Alford Rd', field_address_street2 = 'Simon\'s Rock', field_address_apt = NULL, field_address_city = 'Great Barrington', field_address_state = 'MA', field_address_zip = '01230', field_address_country = 'US', field_address_other = NULL WHERE vid = 849 AND nid = 640 in /home/achonbur/public_html/music/includes/database.mysql.inc on line 172.
user warning: Unknown column 'field_address_other' in 'field list' query: SELECT field_address_street1 AS street1, field_address_street2 AS street2, field_address_apt AS apt, field_address_city AS city, field_address_state AS state, field_address_zip AS zip, field_address_country AS country, field_address_other AS other FROM content_type_venue WHERE vid = 849 LIMIT 0, 1 in /home/achonbur/public_html/music/includes/database.mysql.inc on line 172.

rconstantine’s picture

What your error indicates is that you didn't update the database. Any time you update a module, you need to go to the module admin page and click on the update.php link, then expand the fieldset to see if any schemas have new entries. If so, run the updater. Then follow the instructions I gave for updating individual field instances in content types.

madflute’s picture

As I stated, I did as you just wrote, running update.php then go to Content Type to field => config => re-save. Not sure what I am missing.

rconstantine’s picture

Oops. I guess I read too quickly and missed the fact that you ran update.php

Uh, what did you mean by this:

I type the data then hit Save

Can you verify that your database table includes the columns that your error message says are missing?

madflute’s picture

I can't access to the database right now but I have a clue, hoping this could help.

The existing data are still there so I assume tables are still there. What happened as follow:

MA zip starts with zero but this module drops the first zero, i.e. 02472 is displayed/saved as 2472. When I updated it, I wanted to see if this problem has been solved. I went to the edit mode, added the zero, and hit Save. The error occurred and the address has been wiped out. At this point, this node no longer takes any address string and produces the error which was copied above.

I am pretty ignorant about this stuff. When I go to phpMyAdmin, what should I look for?

rconstantine’s picture

For the content type that you got the error message from, you should have a cck field table in your database somewhere. The name will depend on the name of either the node type, or the field type, which in turn depends on whether you are using this defined field on more than one node type or not. Anyway, you want to make sure that a column called field_address_other exists since that is what the error says is missing.

As for the zip code, I suppose you weren't able to find out if the beginning zero works now since it immediately threw the error, correct? Well, some time ago, I switched the database column from an integer into a string since Canada and other countries use letters in postal codes. So a leading zero should work.

I am a bit frustrated today with some issue posters but will refrain taking it out on you. I'll just say that it seems too many people are stuffing their mouths with steak, even though they don't have teeth, and then are expecting module developers to chew for them. PHP is not hard. MySQL is not hard. Server setup and management is not hard. All of these things can be learnt in one's spare time over the course of just a couple of months with good results. Nobody expects another person to be an expert, but it would be nice if users understood the error messages that they post and can do some of the investigation into the issue themselves - especially if that user is a professional in this field - not that you are. Well, maybe I did take it out on you. Just ignore me and don't get your feelings hurt.

madflute’s picture

I totally understand your frustration. I had been the same place. The way you put it wasn't offensive at all, and I apologize I didn't take a closer look at the error message. You are right, I should had done it.

So, as you said, the table is missing. One thing I don't understand, tho, I don't have field_address_other enabled in the address CCK config. I have both APT field and Other field disengaged.

I just engaged Other field and ran update.php but the table was not created. Do I need to do it manually?

Thanks for your time.

rconstantine’s picture

The columns in the table should be there no matter what your settings, so yes, you'll have to add them by hand. It will be tricky, and dependent on your content types, as to what the SQL will be to add that column to any tables that need it.

Basically, the 'enable/disable' settings for the individual fields is for storage and validation only. If any fields are turned off, it simply allows the column for that row to be blank. The column should still exist. So what it sounds like is that you have some unique DB problem that may or may not be caused by this module. It's hard to say at this point I think. So the course of action I suggest you take is this:
1) get to know how CCK content type and field tables are created. This will allow you to make sure you have everything you should have.
2) examine any tables related to the particular content type/field that gave you problems.
3) examine the install file & examine the code in the module file (I think the hook_field_settings function) to see what columns you should have in each instance of this field
4) correct the tables by making any changes or additions needed

And thanks for understanding my frustration.

madflute’s picture

Thanks. It seems I have to study hard to solve this problem.

I just took a look at the backup database dated before v2 of this module, and "Other" field isn't there. I was hoping if I could see how it is supposed to be.

rconstantine’s picture

I'm pretty sure the 'other' field has been there since the first release of this module. Are you able to install the module on another setup and compare? That might work best. Very strange things going on with your setup.

madflute’s picture

I got it working. Phew.
I first created a pristine Drupal 5.5 install, and added only CCK and Address module to see who it appears in database. I found many discrepancies, like field types differences and value differences.

I corrected them as well as manually adding Other field, and I got it totally working. Thank you so much for your help!

rconstantine’s picture

One last question for you:

What was the first version of cck_address you had installed on the problem system and which versions did you upgrade to? I had only a little support from the CCK crew in trying to figure out the correct way to update CCK-managed tables and columns. Supposedly, they will manage them totally at one point and I won't have to mess with the updates. But for now, there may be errors that I wasn't aware of. Telling me the above info will help me determine whether update_1 or update_2 in the install file needs attention.

rconstantine’s picture

Title: UPGRADE TO 2.0 INSTRUCTIONS!!! READ THIS!!! » Misc upgrade issues

Changing the name and starting a new thread with the old name since upgrading users don't necessarily need to read this whole thread.

madflute’s picture

Title: Misc upgrade issues » UPGRADE TO 2.0 INSTRUCTIONS!!! READ THIS!!!

Yeah, sorry about that. I started to use Drupal last July, and installed Address CCK module around August-September if I remember correctly. I updated every time new version comes. I don't remember the version number but hoping this info would help.

rconstantine’s picture

Title: UPGRADE TO 2.0 INSTRUCTIONS!!! READ THIS!!! » Problem upgrading to 2.0

Uh, why did you change the title back? Thanks for the info. I suppose that isn't too different from most people though, so I'm not sure why your case was different. I don't suppose you could have gotten an error message one time during an upgrade and missed it?

Anyway, I'm changing the title back, particularly because people do not need to "READ THIS!!!"

madflute’s picture

I didn't change the title back. I am not even touching the issue setting box! Was that from my browser cache???? I even didn't know non admin can change the title. That' not good.

I had never seen any error before v2 update. The only problem I have had was the leading zero on zip. That was from the day one but I never saw any error message.

rconstantine’s picture

Are you still having the leading zero problem? Can you verify that the zip column in your DB is varchar and not int? So far as I understand it, leading zeros are fine with varchars and as I mentioned before, I changed it for one of the updates.

madflute’s picture

Yes, I manually changed it from int to varchar, and it took the leading zero now. But update didn't modify the database. I had to manually change it.

rconstantine’s picture

That's good to know. New users shouldn't have a problem, but I'm sure there may be some older-version users out there. Bummer. Sorry for the trouble. So are you resolved so that we can close this support issue?

madflute’s picture

Yes. Although I would be more comfortable if you do it :-)

rconstantine’s picture

Status: Active » Closed (fixed)