🇦🇺Australia @almunnings

almunnings → created an issue.

Howdy
Per ✨ new schema for softwareApplication Closed: won't fix , Comment #7, I've split out a contrib module at https://www.drupal.org/project/schema_software_application →

Looks like we'll have some overlap, please feel free to take a look

Added as contrib, per #7
https://www.drupal.org/project/schema_software_application →

Feel free to take ownership some day, if desired.

almunnings → created an issue.

almunnings → created an issue.

Howdy!
This MR is no longer applicable to 2.x-dev, and might need a tweak for Drupal 11 support.

Should we branch for 2.2.x support, or just continue in the same MR?
I'm happy to help out, just don't want to step on toes! :D

When you say it takes 5-6 seconds on a cold cache, is that all of drupal or only graphql compose? Like, if you clear your cache, and go to the homepage, is it 5-6 seconds?

Also how complex is your query? Compose isn't really doing anything special with cache. Load more, slow more.

It's almost guaranteed there could be performance bottlenecks. I just dont have the insight to your app to know what that is! Help is always appreciated.

The GraphQL module has built-in support for persisted queries via plugins. I haven't used it, but maybe thats an angle?

I did some digging around this with version 3.x of compose.
I'm still not certain I found it.

I was booting up the plugin instances on getBaseDefinition, which can sometimes come in partially cached of bypassed if the cache in graphql was "full", which would happen if cache went a bit fucky, from incorrect server_id in the graphql validator path, or possibly from some internal GC.

- Thats the hunch anyway. so I wrote away from it.

https://git.drupalcode.org/project/graphql_compose/-/commit/ca0139f615ee...

I guess we can re-visit this once v3 goes into alpha

Sorry, timezones, was asleep! 2 quick :D
Yes thats working as expected now

almunnings → created an issue.

Was seeing some issues with the Gin admin theme. Worked on in Claro.

When the entity references render as a table, gin wraps the table in 2 div elements. Removing those divs, it all worked again.
Unsure if this is immediately related, but combining this patch plus:

/**
 * Implements hook_theme_suggestions_HOOK_alter().
 */
function MYMODULE_theme_suggestions_table_alter(array &$suggestions, array $variables): void {
  if (!empty($variables['attributes']['data-entity-browser-entities-list'])) {
    $suggestions[] = 'table__simple';
  }
}

Has restored functionality in the Gin admin theme.

There is a failing PR up if you wish to continue yourself.

Hi there,
I tried to get this to return a result on my end, and it always came back null.

Am I missing something?
getEntity isn't on the MenuLinkInterface
Are you trying to get `MenuLinkContent` entity view_mode?
Does this require 3rd party modules?

I'm not aware of that being populated by default in how we access the data.

I'm also shifting my thinking to the opinion that frontend logic to choose what to display to a user, should happen on the imlenmentation, not the data. We have no rendering context in the menu, so it's unknown what view mode it would even display?

Maybe I got this wrong.

Closing, no further information was provided.

Closing, no further information was provided.

Opting to update documentation on this one.

Pending 3.x.

Merged in 3.x

I’ll probably move it into the core module, as it doesn’t introduce new entities or graphql module plugins, and is just a field type/resolver.

Will get this into 3.x with tests

almunnings → created an issue.

almunnings → created an issue.

Merged into 3.x-dev

almunnings → created an issue.

almunnings → created an issue.

Merging into dev to test with patch against latest works

almunnings → created an issue. See original summary → .

Merging into 3.0

Merging into 3.0

Attaching patch file for point-in-time.

almunnings → created an issue.

#46 works as expected.

Duplicate

https://www.drupal.org/project/graphql_compose/issues/3515405 📌 Add GraphQL 5.x support Active

This will need to move to a 3.x.x release

Nah thats good enough for now, happy for this to re-open if someone finds a way.

Per your testing requirements

query MyQuery {
  node(id: "f099a6cd-f63b-4f9b-ba26-238cf2271fdc") {
    ... on NodePage {
      tags {
        __typename
        ... on TermTags {
          id
          name
          langcode {
            id
          }
        }
      }
    }
  }
}

Response

{
  "data": {
    "node": {
      "tags": [
        {
          "__typename": "TermTags",
          "id": "1",
          "name": "AAAA",
          "langcode": {
            "id": "en"
          }
        },
        {
          "__typename": "TermTags",
          "id": "2",
          "name": "BBBB",
          "langcode": {
            "id": "en"
          }
        },
        {
          "__typename": "TermTags",
          "id": "3",
          "name": "CCCC",
          "langcode": {
            "id": "bn"
          }
        }
      ]
    }
  }
}

Bigger commit here.
Might need to lean on our buddies Wunder and jmolivas to test.

Anywhere we were loading translations i've shifted it off to a trait that has a hook.

If you have custom logic beyond whatever I'm doing here, probably the hook is a good way about it?

Citing need for new issue for your issue @marcus.w.
Not that I don't believe you, I just need a way to reproduce it.

It's a similar error, but could be indicative of any breakdown in the creation of the schema.

Please try the MR over at 🐛 GraphQL query stops working - seems cache issue Needs work , and please open a new ticket if you are able to find a set of events that can trigger your issue.

Dang it. Didn’t see that pid field sneak in. That’ll need to be changed to an entity reference id too.

Moving this one fwd a bit.

Added schema field type entity_reference_target_id in ✨ Support Comments Active , which this could utilise.

almunnings → made their first commit to this issue’s fork.

I'm unable to reproduce this error.

query MyQuery {
  node(id: "777f15be-c72f-4578-a9cb-c297559c9e89") {
    ... on NodePage {
      paras {
        __typename
        ... on ParagraphLinks {
          links {
            title
            url
          }
        }
      }
    }
  }
}

{
  "data": {
    "node": {
      "paras": [
        {
          "__typename": "ParagraphText"
        },
        {
          "__typename": "ParagraphLinks",
          "links": [
            {
              "title": "Para text",
              "url": "https://www.para.com"
            },
            {
              "title": "sdadsasd",
              "url": "https://www.pasra.com"
            }
          ]
        }
      ]
    }
  }
}

Are you able to re-check and revise on how to reproduce?

Yep cool
As its identical at this stage, might as well just extend TelephoneItem

almunnings → made their first commit to this issue’s fork.

Attaching static patch of diff.

almunnings → created an issue.