Closed humandevs closed 3 years ago
Actually, I think this is still just the same bug as https://github.com/craftcms/cms/issues/9842, albeit in 3.7.14. Specifying the siteId in the mutation doesn't change the error, and enabling the disabled site in the example allows the mutation to function properly, mutating the siteId specified in the mutation. Thus, it's just that having a disabled site throws an error when attempting a mutation.
Not sure if I should delete this issue and reopen the previous one, or keep this issue open.
@humandevs
There was a bug fixed in Craft 3.7.16 that addressed disabled sites being included in site selection sometimes.
So, after that version, you'll probably end up updating the entry on a disabled site.
More to the actual problem you had - if you don't specify the siteId
parameter, Craft will default to the current site, not the default site. The current site is mainly determined by the URL.
Either way, I would strongly recommend always to specify a site ID when dealing with multi-site installations.
Description
This is a followup to https://github.com/craftcms/cms/issues/9842. Now, in Craft 3.7.14, if a mutation is made without specifying a siteId, Craft still throws an error if a disabled site exists.
Note, in the below example, siteId 19 exists, but is disabled. The mutation is not specifying the siteId, so I believe it should assume the default siteId (1), but it still throws an error referencing the disabled site 19. Note this doesn't seem to throw an error when testing via GraphiQL - it seems to require making a GraphQL REST API call to the /api endpoint:
Here's the mutation that is causing this issue:
And the response from the server:
And the web.log error:
Steps to reproduce
Additional info