Posted by clemens.tolboom on April 3, 2012 at 3:46pm
5 followers
| Project: | Simplenews |
| Version: | 7.x-1.x-dev |
| Component: | User interface |
| Category: | bug report |
| Priority: | major |
| Assigned: | corvus_ch |
| Status: | closed (fixed) |
Issue Summary
(Hopefully this helps others.)
We upgraded our site and now node/add/simplenews are displaying voting API values for the newsletter. This is not good.
This felt like a core issue for not setting the widget values correctly when upgrading. A suggestion KarenS made somewhere was to just touch the widget settings. I haven't found that one but these are related.
#952970: Undefined index: required in field_default_form()
#931512: Node body 'description' and 'required' are missed on nodes upgraded from D6 to D7
So just visit your
- admin/structure/types/manage/simplenews/fields
- start editing the taxonomy field type and save it.
Now the taxonomy values have their expected values again.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| simplenews-wrong-taxonomy.png | 20.07 KB | Ignored: Check issue status. | None | None |
Comments
#1
Next step is to get back the Simplenews tab on node/%node/simplenews
This is resolved by visiting admin/structure/types/manage/simplenews
Now check the 'Use as simplenews newsletter' on the 'Publishing options' 'tab'
I think this is an upgrade _bug_ now.
Scanning the 6.x-2.x code it uses simplenews_content_types where 7.x-1.x uses simplenews_content_type_NODETYPE
simplenews.install is not checking for values of both mentioned variables to update D6 settings.
The only occurrence is when _installing_ simplenews
<?php
function _simplenews_install_nodetype() {
// Create a newsletter type if needed.
$type = node_type_get_type('simplenews');
...
if (!field_info_instance('node', 'field_simplenews_term', $type->type)) {
simplenews_add_term_field($type);
}
variable_set('simplenews_content_type_' . $type->type, TRUE);
}
?>
I expected a call to this function in
<?phpfunction simplenews_update_7000() {}
?>
so promote this now to a bug.
#2
After the customer fixed the above we now ran into "Illegal Choice has been detected"
- #999814: An illegal choice has been detected. Please contact the site administrator.
- #989742: Illegal choice 7
- #1356864: SimpleNews error: An illegal choice has been detected. Please contact the site administrator
Suggests a solution by berdir which is a little abracadabra to me :(
Checking the field settings I noticed we have TWO category fields. One from the upgrade and another from ?
My guess now is the upgrade transformed the simplenews category to an 'detached' state for simplenews which created a new field without proper settings.
What do you think?
When checking the 'weird version' it is attached to the wrong category which seemed to be empty.
#3
On irc berdir explained the second taxonomy term field 'field_simplenews_term' was added by checking the content type was a simplenews type. Thus that lead to a duplication of taxonomy fields.
After configuring the added taxonomy field correctly I was able to send a newsletter.
We now should delete the 'old' taxonomy as simplenews relies on the machine readable name being 'field_simplenews_term'.
But I guess old news issues need to get the term set correctly first. ... to be continued ...
#4
Ok, forgot a bit about this.
This patch is a start.
- Converts the variable.
- Adds *our* field to the content type.
Two remaining issues:
- Because it's a new field, the old values are gone :(
- The auto-generated field is still there, that should be removed.
An alternative that would resolve both issues is setting the simplenews_category_field variable, which *does* exist to that of the auto-generated field name. That works if we can guarantee that there is only a single field for the vocabulary, even when using multiple content types as newsletters.
From looking at taxonomy_update_7004(), that might actually work.
Will get back to this later.
#5
#6
The last submitted patch, fix_content_type_upgrade.patch, failed testing.
#7
Changing version.
#8
#4: fix_content_type_upgrade.patch queued for re-testing.
#9
Migrating existing category field instead of creating an new one. Also moved the migration code to simplenews_update_7000 to prevent side effects for installations where this is allready fixed manually.
#10
The last submitted patch, simplenews-1513634-9.patch, failed testing.
#11
Romved code redundancy and added a condition in a test database query.
#12
Thanks, commited.
#13
Automatically closed -- issue fixed for 2 weeks with no activity.