Yves, Karen or Jonathan,
using D6.x (which prints all PHP E_ALL notices), some unwanted warnings are displayed:
* When importing a node type (content_copy module), there is a warning about a non existing array index. Its fixed by changing /cck/modules/content_copy/content_copy.module on line 433:
if (isset($GLOBALS['content_copy']['status']) && $GLOBALS['content_copy']['status'] == 'export' && in_array($form_id, $alter_forms)) {
* When importing an existing node again, there is a warning about a non existing variable. Its fixed by changing /cck/modules/content_copy/content_copy.module on line 410 (in fact, its a real bug):
'%field_label' => $field['label'], '%field_name' => $field_name, '%type' => $type_name)));
* When importing a node that has groups (fieldsets), there is a warning about a non existing array index. I thought that was just another small warning but i found out another bug: the $form_values['type_name'] was supposed to have the node type, but it has not. The node type is never sent to fieldgroup_update_fields() function.
Sorry for not providing the patch file.
regards,
massa
Comments
Comment #1
karens commentedI can see the first two problems, but I can't find any way that the last one is a problem. $form_value['type_name'] should only be empty if you chose the option to 'create' a new type, and if you do that, $type_name gets populated with the type name of the imported type.
Can you come up with steps to reproduce a situation where no type name gets to fieldgroup_update_fields()?
Comment #2
brmassa commentedKaren,
hi! thanks for this fast response.
This last problem is twofold:
1* It is a PHP E_ALL "bug", coz the code is trying to pass a a non-existing array value to a function. It can be solved by:
2* The value is not getting passed at all. Even when im importing a node again (over the old one). I can see this because the Devel's
dpm($form_value['type_name'])is always empty and because the "content_group_fields" DB table has several entries with an empty "type_name" column. Steps to reproduce it: import a node once. Then, import it again, over the old one and print the $form_value['type_name'] variable. It will be empty.regards,
massa
Comment #3
karens commentedI still don't get it. What option are you selecting when you import the field, create a new type or selecting an existing type? If the second, you will have a type name in the form values. If the first, there should be a type name in your import code. If there is no type name in your import, how did you create it without one? I'm not able to do that unless I deliberately clobber the export code before I try to import it.
Once you create a bad value and export and re-import it, I am sure it will be goofed up, but I can't see any way to every get to that point.
Comment #4
karens commentedAnd why don't you paste a copy of the code you are trying to import.
Comment #5
brmassa commentedKaren,
i tested it again with the same errors. I basically exported a node type and tried to import it back (selecting the type name on the select box in order to "overwrite" it). If i
dpm($form_value['type_name'])shows that the type name was empty.But since you ask, here is a simple code. Try to import it as a new type than import it over.
REMEMBER TO SEE THE
$form_value['type_name']BEHAVIOR or to delete the"^ E_NOTICE" from common.inc:)regards,
massa
Comment #6
karens commentedOK, I found it. The clue was that it should not have let you try to add those fields to a content type where they already existed. The type name was missing because it was supposed to be going down a path to error out, but a bracket was in the wrong place and it was trying to add them in. Should be fixed now.
Thanks!
Comment #7
brmassa commentedKaren
welcome.
massa
Comment #8
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.