[FR] GraphQL : Fetch More Data Related to an Entry

[michtio]

Description

It would be nice if we could Fetch more Data into our GraphQL queries:

With CraftQL it was possible not only to get the sectionHandle, but to get all information that a section holds.

Also, when returning site information currently we can only fetch siteId, it would be nice if we could get more information out of this as well, as the site handle and the site name for example. That only makes sense if we already fetch the siteId.

[andris-sevcenko]

So, an update is due. This feature is still on the table and we realize that it would help a lot when working with the GraphQL API.

It wouldn't make sense to expose just one facet of the site's structure to Craft, so it would be a pretty involved work to expose sites, category and tag groups, sections, entry types, fields, layouts, and more, so it becomes a little bit of an undertaking.

We want to do this right and there currently are things that are a bit more important to get in line for 3.5, so it won't be making the cut for 3.5.

Having said that, it's possible to pull off with a plugin, though, as Craft exposes quite a few GraphQL related events.

[ParallelUniv3rse]

+1 on this. It's nice to see this is planned and worked on, I'm trying to just get the entry's type name in full without it being camelcased like the typeHandle and that seems to be unavailable too.

[michtio]

@andris-sevcenko are there updates on this?

[bzin]

Is there any plan to ship something for Sites in Craft 4?

Usage example will be to generate a Language Switcher, it would be nice to have get this info using GraphQL.

[brandonkelly]

No plans yet, sorry.

[giorgiopogliani]

Any plan yet?

[dioncodes]

The issue was marked as "completed" but I can't find the documentation anywhere... What does the graphql query look like to retrieve all available sites?

[soerenmeier]

I think for that usecase the localized property on an entry is better, because you get the correct url, and no page if it does not exist for that site.

[soerenmeier]

We use the sites information for the frontend router so we know to which site the current request belongs, and can query the right content.

[rtrudel]

I am glad that the scenario of the language switcher was brought up, because it is something similar that I would like to accomplish. However, I would like to bring up another use-case where inside a Vue component, we would want to have a global search engine on the main site, but allow for filtering on one or more sites (and display info or redirect to the proper site from the search results). I understand what @brandonkelly is saying, but I think it is still within the realm of realism to expect to be able to query Craft about the sites it comprises, in the same way we can query globals or certain settings. It doesn't need to return a bunch of relations, just a simple and filterable array of the available sites (or even a dead-stupid flat array could do the trick in most of cases).

Let's also imagine that we want to have a small intranet where each site is a tenant in a mini-SaaS. It would be redundant to go and sync the list of sites in a matrix, table, KV or any repeater type of field in some kind of globalSet or something, and this every time a site is created/modified/deleted just to have something to query from GraphQL...

Some might say that Craft CMS is not intended to create SaaS systems or intranets. I would respond that since it is technically possible to do so, then why not use the full potential of GraphQL to allow a headless site or JS components to access the entire CMS, and not just the "elements" part of it?

We can query and even mutate elements and assets, so why can't we retrieve the list of sites with minimal metadata such as the name, group, language, and baseUrl? I don't think this is a security issue, unless I'm not seeing the full picture in this matter. And anyway, we could decide to make the sites available or not in the schema.

[michtio]

I think for that usecase the localized property on an entry is better, because you get the correct url, and no page if it does not exist for that site.

It do not like this option, as it would require fetching all entries and doing some operations on them. Also based on certain propagation settings, it is not always true that every "language" contains content, so which entry should we pick to list the languages then? I understand what you meant, but it doesn't feel like a sustainable or scalable option for all projects :)

[soerenmeier]

Maybe I miss understood you, yeah if you have like a fullscreen language selection (like apple), all languages should be displayed. I meant more like in the navigation bar small, and there I feel like if the content is not available in that language, the language should not be displayed.
Either way for the moment you could use a plugin https://github.com/Dunkel-Design/craft-graphql-sites