[SOLVED] - after update edit-field doesnt display
michael_kirk - December 13, 2007 - 23:31
| Project: | Fullname field for CCK |
| Version: | 5.x-1.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | rconstantine |
| Status: | closed |
Jump to:
Description
After updating the fullname module to 1.2, I attempt to create a node which previously had the fullname_field.
The label is still there, but the fields are not.
However, upon editing the field in the nodes content type, (ie. http:///admin/content/types//fields/field_full_name, I added the prefix field, saved it and the problem seemed to have fixed itself.
My guess is that any change to the fields properties would have fixed it.
Perhaps the update script is not quite complete in that it doesnt seem to completely propogate its changes.
#1
So, you're saying that you ran the update script via update.php? Do you have means of looking at your database structure? On my test installation, I had three or four different fields using fullnames and all of them successfully were updated in the DB just fine. So check and make sure that your DB tables which include your fullname fields were all updated. If not, are you using a prefix on your tables? I think this is the module where I screwed that bit up a bit and although a patch is available in the issue queue, I haven't had the time to make a new release with the fix in it.
#2
#3
Same (or similar) issue here as well.
I upgraded from 5.x-1.1 to 5.x-1.4 now my edit form displays a blank table under the Full Name label.
I ran update.php immediately after uploading, this was installed at the same time as two or 3 other module updates, so I don't remember exactly if this module actually made any database changes.
All of my existing field values are still in the database.
#4
Do you guys not have phpmyadmin so you can look at your DBs? You need to at this point so we can establish whether the update was successful or not. You also need to verify that you went into each cck_fullname field definition in your content types and resaved them. If you aren't doing this and telling me so, I can't help.
#5
Resaving seems to have fixed the problem, haven't had to do this for a CCK field update before, is this documented somewhere?
#6
Hmm, I thought I included it in the README, but I don't see it. Bummer. I'll add a note to the project page on the first line in bold.
Sorry about that!
But to answer an implied question: any time a CCK module adds settings, or database columns, you will probably need to resave the field in your content type. Otherwise, all of the new code won't know what to do due to missing info, as in this case. However, it seems most CCK modules change very little. Especially when it comes to modifying the data they track. In other words, I just added 7 fields to this module (5 for preferred name and suffix and prefix to the legal name) that weren't in it before. Most module developers seem to avoid this because the code in the install file is not straight forward. It's particularly messy when you change attributes of existing columns for CCK field types. I have suggested hooks be added to CCK to make these things easier.
Anyway, I'm updating the project page and would appreciate if you edit your last post and put the
<strong></strong>(strong) tags around the whole thing. That way it sticks out for future visitors.#7
Ohhh.... I see. I would still call this a bug, with update status installed (soon to be part of core) there is no need to visit a modules individual page before downloading and installing an update. Maybe point this out in the install.txt or in an upgrade.txt as well?
edit: Looks like our posts crossed each others paths, readme.txt works as well. Good to know about CCK, I'm sure that will save some hair pulling in the future.
#8
It is semi-fixed with the addition to the project page and I will update the README soon. Once all other issues (if any more surface) are taken care of, I'll do one more final release of this. I've learned my lesson of tagging too soon. I'm not making that mistake with og_forum. There's a dev for testing that.
As for the update status module, since it isn't core for 5.x, that makes this not an outstanding bug, but a feature request sort of. Know what I mean? It is currently a contrib module and so it is reasonable for me to expect users to currently come to the project page or module download area of Drupal for a fresh download. Getting one contrib module to work with another when they don't is not a bug. Otherwise we could label just about every module as buggy for not supporting the token module, or og, or views, or whatever.
#9
I agree about contrib modules not needing to necessarily support one another, its hard enough to worry about everything else without worrying about some random module, I was just trying to point out why I missed the message.
This may be using the .install file for something other than what is intended, but would it be possible to use it to set a message reminding people to re-submit their cck field, when actually updating the database isn't possible because of how cck works?
#10
I think that's a good idea an not outside of what the install file is for. I just never thought about it before. I do believe I'm already producing a success message when the DB is updated, so I can just add a note there.
#11
Automatically closed -- issue fixed for two weeks with no activity.