Skip to content

Fix setting custom fields in variant collection#3931

Closed
boboldehampsink wants to merge 1 commit intocraftcms:5.xfrom
boboldehampsink:fix-setting-custom-fields-in-variant-collection
Closed

Fix setting custom fields in variant collection#3931
boboldehampsink wants to merge 1 commit intocraftcms:5.xfrom
boboldehampsink:fix-setting-custom-fields-in-variant-collection

Conversation

@boboldehampsink
Copy link
Copy Markdown
Contributor

Description

Now also sets custom field values in variant collection, not only attributes

Related issues

Fixes #3927

@nfourtythree
Copy link
Copy Markdown
Contributor

Hi @boboldehampsink

Thank you for bringing this to our attention and taking the time to create a PR we really appreciate it.

I am going to close this PR in favour of the fix in PR #3946

Thanks!

@nfourtythree
Copy link
Copy Markdown
Contributor

The fix in PR #3946 has now been released in Commerce 5.3.6.

Thanks!

@boboldehampsink
Copy link
Copy Markdown
Contributor Author

This release has other issues for me. Now this is broken:

        $variant = [
            'relatedTo' => [
                'targetElement' => [EntryQuery::find()],
                'field' => 'products',
            ],
            'orderBy' => 'isDefault DESC',
        ];

        return Product::find()
            ->hasVariant($variant)
           ->with([
                ['variants', [
                    ...$variant,
                    'limit' => 1,
                ]],
            ])->all();

Could this have anything to do with this fix? 5.3.5 works fine.

@nfourtythree
Copy link
Copy Markdown
Contributor

Hi @boboldehampsink

I have just added a test to the suite which eager loads the variants: 1df2cad

At the moment it looks like this is behaving as expected.

I understand your example was probably partial pseudo-code/simplified, so could you explain what you were trying to do with the query so I can make sure to test it thoroughly. As for one example you have EntryQuery::find() which is a method that doesn't exist (assuming you meant Entry::find()?)

Thanks!

@boboldehampsink
Copy link
Copy Markdown
Contributor Author

Oh yeah I meant that, it is indeed pseudo-code. The problem is in the "hasVariant" method, when I remove it I get results. With that in place, no results. And this works fine in 5.3.5.

@nfourtythree
Copy link
Copy Markdown
Contributor

Is it just flipping between the Commerce versions and keeping the same CMS version that shows the difference? Or is the CMS version changing as well?

Are you able to xdebug or use the debug toolbar to extract the raw query to see what the difference is?

Between 5.3.5 and 5.3.6 we didn't make any changes specifically to querying so in theory there shouldn't be a difference. But I am keen to get to the bottom of the issue you are seeing

@boboldehampsink
Copy link
Copy Markdown
Contributor Author

Only changing Commerce versions. I will look into it some more.

@boboldehampsink

This comment was marked as outdated.

@nfourtythree
Copy link
Copy Markdown
Contributor

And, to follow along with this, you have a craft\commerce\fields\Products custom field on your variant field layout?

Would it be possible to send your tests directory to [email protected]? That might be the easiest way for us to trace through what could be happening here.

@boboldehampsink
Copy link
Copy Markdown
Contributor Author

I sent you a mail 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[5.x]: Variants in product fixtures don't have their custom fields saved.

2 participants