(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.

#11 simplenews-1513634-11.patch8.81 KBcorvus_ch
PASSED: [[SimpleTest]]: [MySQL] 1,798 pass(es). View
#9 simplenews-1513634-9.patch6.31 KBcorvus_ch
FAILED: [[SimpleTest]]: [MySQL] 1,792 pass(es), 7 fail(s), and 4 exception(s). View
#4 fix_content_type_upgrade.patch2.46 KBBerdir
PASSED: [[SimpleTest]]: [MySQL] 1,705 pass(es). View
#2 Newsletter issue | two Newsletter categories.png16.83 KBclemens.tolboom
#2 Newsletter category | default values.png14.4 KBclemens.tolboom
simplenews-wrong-taxonomy.png20.07 KBclemens.tolboom
Members fund testing for the Drupal project. Drupal Association Learn more


clemens.tolboom’s picture

Category: support » bug

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

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)) {
  variable_set('simplenews_content_type_' . $type->type, TRUE);

I expected a call to this function in

function simplenews_update_7000() {}

so promote this now to a bug.

clemens.tolboom’s picture

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 :(

Make sure that you haven't enabled the Newsletter category field in the manage display forms for the corresponding content type.

Checking the field settings I noticed we have TWO category fields. One from the upgrade and another from ?

Newsletter issue | two Newsletter categories.png

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.

Newsletter category | default values.png

clemens.tolboom’s picture

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 ...

Berdir’s picture

Status: Active » Needs review
2.46 KB
PASSED: [[SimpleTest]]: [MySQL] 1,705 pass(es). View

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.

Berdir’s picture

Priority: Normal » Major

Status: Needs review » Needs work

The last submitted patch, fix_content_type_upgrade.patch, failed testing.

Berdir’s picture

Version: 7.x-1.0-beta2 » 7.x-1.x-dev

Changing version.

Berdir’s picture

Status: Needs work » Needs review

#4: fix_content_type_upgrade.patch queued for re-testing.

corvus_ch’s picture

Assigned: Unassigned » corvus_ch
6.31 KB
FAILED: [[SimpleTest]]: [MySQL] 1,792 pass(es), 7 fail(s), and 4 exception(s). View

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.

Status: Needs review » Needs work

The last submitted patch, simplenews-1513634-9.patch, failed testing.

corvus_ch’s picture

Status: Needs work » Needs review
8.81 KB
PASSED: [[SimpleTest]]: [MySQL] 1,798 pass(es). View

Romved code redundancy and added a condition in a test database query.

Berdir’s picture

Status: Needs review » Fixed

Thanks, commited.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.