Jump to:
| Project: | Node Convert |
| Version: | 6.x-1.5 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Issue Summary
First, thanks for this module, it's pretty useful. I think I found a bug where if you're converting nodes that have fields that use filtered text, the ordering in the update gets messed up. At least, this seems to be what is happening. The format is stored in another column in the table, but the 'multiple' flag is not set, so the column gets skipped, and then the wrong values get updated in the database. I've attached a diff of what I think is working for now. I am on a deadline so I do not currently have the time to think about all the cases, but I wanted to report this issue and show the diff in case someone is able to look at it in the meantime. In the diff, I am just tricking it into using the multiple column case, when it finds a column called 'format'.
Ian
| Attachment | Size |
|---|---|
| node_convert_formatted_text.diff | 1.56 KB |
Comments
#1
This bug is still present.
#2
I'm not sure what to say. I tried converting a simple filtered text field, and a re-used filtered text field, and it looks ok to me. Can't reproduce the bug. So more info is needed.
#3
I forgot what caused me to run into this bug. It is one of the following:
1) Converting from plain text to filtered text.
2) Converting from filtered text to plain text.
3) Doing the above when it is a multivalue field.
I think the issue has to do with #1 or #2. But, of course, I'm done with the project now.
It makes sense that this would happen in #2, if the values are stored for an entire node type in a single table, because then the column count would be out of sync when making the transition.
#4
It's happening when you try to convert from a filtered text item to a non-filtered text item on our setup. I've solved it by going into the content type and setting the source item to plain text, but this definitely is occurring.
UPDATE: the reverse also seems to be true, that it's happening when moving a non-filtered text item into a filtered text item.