You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a followup to #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:
{"errors":[{"message":"Internal server error","extensions":{"category":"internal"},"locations":[{"line":2,"column":3}],"path":["save_manuals_chapter_Entry"]}],"data":{"save_manuals_chapter_Entry":null}}
humandevs
changed the title
Attempting a GraphQL mutation via API defaults to the last site id, not the default siteId, and Craft 3.7.14 throws internal server error if that site is disabled
Attempting a GraphQL mutation via API defaults to the last siteId, not the default siteId, and Craft 3.7.14 throws internal server error if that site is disabled
Oct 11, 2021
Actually, I think this is still just the same bug as #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
changed the title
Attempting a GraphQL mutation via API defaults to the last siteId, not the default siteId, and Craft 3.7.14 throws internal server error if that site is disabled
Attempting a GraphQL mutation via the GraphQL API in Craft 3.7.14 throws internal server error if there is a disabled site
Oct 11, 2021
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 #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
The text was updated successfully, but these errors were encountered: