Closed (fixed)
Project:
Tamper
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
12 May 2022 at 20:48 UTC
Updated:
23 Oct 2025 at 11:19 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
mmaranao commentedI ran into this issue as well and basically, what's being returned is a string instead of an actual boolean if you set the no match to either true or false. Although, it's being saved and converted into a boolean value, the schema for the no_match_value type is a string.
I wrote the attached patch to fix this issue and it works for what I need. Hope it does for you too.
Comment #3
interlated commentedI ran into this and ended up with
As the converter.
Based on web/modules/contrib/feeds/src/Feeds/Target/Boolean.php returning an integer.
Comment #4
thomasmurphy commentedI found a similar behaviour with core 11.1.6, feeds 3.0.0, tamper 2.0.0-beta4. Importing a csv value to a boolean, with the convert to boolean tamper, and the no match set to "null" doesn't behave that way. It's defaults to false instead.
I verified this by creating a test node with the "N/A" value set via the checkbox/radio buttons, and a test view renders the boolean value as blank. The only two outcomes with the tamper "convert to boolean" plug-in is default to true or false. For context I set a test csv value to "NULL" to verify that this wasn't a problem related to an empty string.
Comment #5
megachrizIf you can write a test that demonstrates the bug, that would be great! The test should be added to \Drupal\Tests\tamper\Unit\Plugin\Tamper\ConvertBooleanTest.
Since there is a patch, I set the issue status to "Needs work". "active" indicates that there's only a report and no existing code.
Comment #7
megachrizAfter this issue was posted, some changes were made to the boolean plugin in #3322750: Some plugins do not implement submitConfigurationForm() correctly - Add UI tests.
I found one case where the plugin did not work as expected: when the "If no match" was set to "True". In this case the value was returned as is instead of a
TRUEvalue. That's because PHP evaluates the following condition to true when$this->getSetting(self::SETTING_NO_MATCH)isTRUE:And this resulted into the original value being returned instead of
TRUE.Changing this to
fixes that issue.
I have reworked the tests to find this bug. I believe the issue reported originally in this issue got fixed by the changes in #3322750: Some plugins do not implement submitConfigurationForm() correctly - Add UI tests.
@thomasmurphy
I could not reproduce your issue. When I set the "If no match" to "Null" and I import something that does not match the "Truth" or "False" setting, I see in the Feeds log that the item's field really equals
null:So I assume the value gets modified later in the process. Either by a FeedsTarget plugin or by the field that the data gets written to.
Comment #8
megachrizI tested this again manually and added some comments to the tests. I scheduled this to merge.