Closed (fixed)
Project:
Simplenews
Version:
7.x-1.x-dev
Component:
User interface
Priority:
Major
Category:
Bug report
Assigned:
Reporter:
Created:
3 Apr 2012 at 15:46 UTC
Updated:
27 May 2012 at 13:50 UTC
Jump to comment: Most recent file

Comments
Comment #1
clemens.tolboomNext 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
I expected a call to this function in
so promote this now to a bug.
Comment #2
clemens.tolboomAfter 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.
Comment #3
clemens.tolboomOn 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 ...
Comment #4
berdirOk, 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.
Comment #5
berdirComment #7
berdirChanging version.
Comment #8
berdir#4: fix_content_type_upgrade.patch queued for re-testing.
Comment #9
corvus_ch commentedMigrating 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.
Comment #11
corvus_ch commentedRomved code redundancy and added a condition in a test database query.
Comment #12
berdirThanks, commited.