Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Matrix field not importing correctly, ignoring feed configuration for fields #674

Closed
phillipdaviesdeveloper opened this issue Feb 19, 2020 · 8 comments
Assignees
Labels

Comments

@phillipdaviesdeveloper
Copy link

Description

Apologies as I may be misinterpreting the documentation but for CSV and XML format feeds (following the provided documentation for XML feeds, configuring the CSV feeds as you would for any other entity) matrix fields are created without the correct data or default data being set.

On importing entity with matrix field configuration is ignored resulting in a "blank" item being added.

Thanks for any help in advance :)

Steps to reproduce

  1. Create a feed that creates or updates a entity that has a matrix field configured with a boolean and an asset field
  2. Run the feed, any default or provided data is ignored

Additional info

Example configuration:
image

Output in log:
{"new1":{"type":"treatmentImageItem","enabled":true,"collapsed":"1","fields":{"isPrimaryImage":false}}}

As you can see, the imageSource field is not included in the payload and the isPrimaryImage field is set to the incorrect value.

Sample XML node:

<entry>
	<url>*url to match on*</url>
	<MatrixContent>
		<MatrixBlock>
			<image>
				*full path to image asset*
			</image>
		</MatrixBlock>
	</MatrixContent>
</entry>

  • Plugin version: 4.2.0.1
  • Craft version: Craft Pro 3.4.5
@jamesmacwhite
Copy link
Contributor

jamesmacwhite commented Mar 1, 2020

I'm having the same problem I think. Similar feed (RSS/XML) provides full asset URL as a node within a matrix compatiable structure, when running the feed the asset field is blank.

From debugging so far, I have found Feed Me is being told to return here, because fieldInfo doesn't return the urlOrPath key:

https://github.com/craftcms/feed-me/blob/develop/src/elements/Asset.php#L118-L123

It never makes it past this part, so a download of the file is never attempted.

Those keys that Feed Me is looking for only appear when the element type is set to "Asset", it looks in both our cases we are using the asset field when the element type is "Entries".

@pierrestoffe
Copy link

I have the exact same problem. A text field within the Matrix block is processed correctly but the Asset field inside that same block is ignored.

@pierrestoffe
Copy link

pierrestoffe commented Mar 3, 2020

After further debugging:

The issue is only present when a field of the Matrix has been mapped with a Default Value and the Feed element is set to "Use default value". All the fields (inside the Matrix block) that follow this field with a default value will be ignored.

My temporary solution was to add the default value directly in the CSV/RSS/JSON feed and map the Matrix field that used "Use default value" to that element of the feed.

And In my opinion this is the condition that causes the issue:

if ($feedPath == $node || $node === 'usedefault') {

@toufali
Copy link

toufali commented Apr 22, 2020

I'm having what I believe is the same issue -- matrix fields won't populate from defaults set in Feed Me.

As above, I also confirm the "Use default value" option is correctly selected in addition to filling out the default value in Feed Me. (I noticed a closed ticket where this was the issue, and I'm confirming it doesn't apply here.)

Note that the issue for me is present regardless of the mapping mentioned in the previous post.

@danbrellis
Copy link

Not sure if this is the same issue, but I ran into an issue with importing that was caused by using a default field:

I had a matrix field with two block types: BT1 and BT2. In BT1 I had 2 fields: heading and headingLevel. When I set up my feed import, I mapped the heading field to an xml node and set headingLevel to use a default value. I had all the fields in BT2 mapped to respective xml nodes (table field). When I imported, blocks were created for all my block nodes, but all of them were set to type of BT1 (any fields in BT2 were not imported).

XML:

<entries>
    <entry>
        <MatrixBlock>
            <HeadingText>Using Your Project</HeadingText>
        </MatrixBlock>
        <MatrixBlock>
            <table>
                <row>
                    <url>http://google.com/</url>
                    <newTab>true</newTab>
                </row>
            </table>
        </MatrixBlock>
    </entry>
</entries>

Log output:

{"new1":{"type":"BT1","enabled":true,"collapsed":false,"fields":{"headingLevel":null,"heading":"Using Your Project"}},"new2":{"type":"BT1","enabled":true,"collapsed":false,"fields":{"headingLevel":null}}, ...

As you can see "new2" should have been of type BT2, but instead is BT1 and is looking for fields related to BT1.

When I added a node for headingLevel in the XML and mapped it (instead of using default) as suggested by @pierrestoffe, the feed ran perfectly.

If this is a different, albeit related, issue, I'm happy to open a new ticket.

@Friksel
Copy link

Friksel commented Jun 9, 2020

I probably had the same issue as some of you describe here.

There's definitely something wrong with the 'use default value' as it's not working at all in matrix blocks and disturbs everything else. Causing fields to be filled with the wrong data and even adding the wrong blocktypes. I have the 'use default value' set in the dropdown.

I did lots of tests back and forth and these are my findings.

My findings:

  • When using 'use default value' on a lightswitch it doesn't matter at which value the lightswitch is set, it always disturbes the following matrix blocks after the block the switch is in. I had a light switch on an 'iframeblock' and only should have a 'richContent' block after the block the light switch was on, but suddenly with 'use default value' turned on on this lightswitch I got 2 iframeblocks instead.
  • The same behaviour happens when using 'Use default value' on a dropdown
  • When using 'use default behaviour' on a number field FeedMe doesn't even import data here as the number field of that matrixblock is not getting the value from the default field, but from a different imported fieldvalue.

These findings are seen with lots of tests on imports where no previous entry data existed (erased right before import). The strategy was both on 'Create new elements' and 'Update existing elements', so the same as in the online examples for matrix blocks. And the imported data is also in the exact same format as the online examples. And also works fine when no 'use default value' is used inside any of the blocks.

It took me two days to figure out what's going on and why the imports were not working as expected. And I had to check all my data and tried many things to make it work just to find out it's an issue in the 'use default value' part of the importer. That wasn't fun. Hopefully it could get fixed so we don't have to have doubts on our import data and can use default values!!
That said, love this plugin for the rest. If we know this issue it really helps importing stuff!

Thanks in advance!

Plugin version: 4.2.3
Craft version: 3.4.22.1

@i-just
Copy link
Contributor

i-just commented Apr 6, 2023

Importing images via full URL to Matrix blocks - I’m no longer able to replicate this, but I have verified that it works in the latest v4 and v5 versions of the plugin.

Importing images to Matrix blocks via “Use default value” - there’s definitely something wrong there. I’m looking into it.

Also, there’s a new feature, which you might find helpful: “Set empty values”. It will be imported as expected if it’s “on”, the mapped value is empty and the default is specified.

Finally, more of a side note, importing matrix blocks - in v5 (for Craft 4), you can match your data to matrix block type by handle; see #1226 for more info.

@angrybrad
Copy link
Member

Fixed in #1282 for the next v4 and v5 releases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants