🇦🇺Australia @almunnings

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.

Back at you to take a look.
This should add the remaining fields and switch out between uuid and id on the entityId field.

Caveat may be that accessing the entity->uuid() will load that entity - which could be addressed in 💬 How to return a simple object on dynamic_entity_reference values Active

Ok, if unrelated to this issue, please open a new issue if you can reproduce your cache issue.

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

Released in 1.1.0

So is dev working for you? I’ll push a release if so.

Compose nukes all GraphQL caches on save. That could be what you’re seeing.

I’m happy to merge.

2048 is the max for a url. It’s easy enough to revert one day if it proves to be cataclysmic.

I'm just going to push this into dev, have a play around. if cool, we can let this one be done.

Can this be back ported to 4.x? - GraphQL Compose is on the AlterableComposableSchema and I'd prefer to jump into line without dropping support for 4.x immediately.

📌 Merge AlterableComposableSchema into ComposableSchema Active Means changes required.

Let me know if this PR fixes your issue.

https://git.drupalcode.org/project/graphql_compose_preview/-/merge_reque...

Cheers.

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

Yeah elements really should work. I’ll look into reproducing your error today at lunch.

If I can replicate, I can eliminate 🔫😎

Yeah it might not be immediately clear, but tags is already plural, so if we want to load multiple tags… we end up with some kind of naming convention hell

Tags tagss tagsies?
News newss newsies?
Media medion medias

It gets weird fast
Items seemed to work universally in English.

To sum it up quickly, we singularise (optionally) something and then pluralise it for the edge loaders, so you can have a nodePage and nodePages query.

The singular form of news is news. The plural of news is news. If your item is named tags and we pluralise it, it’s already plural.

So we end up with a conflict. That’s where items comes in.

It works in some instances with things like tags. The singular item becomes tag and the plural tags. The system works.

There’s a hook to alter the naming also. I forget off the top of my head.

Basically tricky as help to make everything work for every and make sense. lol.

Its mostly just a design pattern that was core at the start and now we roll with it.

Oh, bummer.
I'm fine with items.

It's a pretty universal word throughout programming.

Just set the fallback to "items" you think?

Moving forward, dates for created/updated should be in UTC.
DateTimes are unaltered coming from Drupal date fields.

API change:
Timestamps should now return in UTC.
Date fields should return "as is" in UTC.
Date range fields should return "as is" in UTC.

Conversion to local or client time should be a frontend/system concern.

Added tests to DateTest.

I'm gonna split out the weird dynamic prop overwrites between the types. Too weird.

This should give some sanity to ✨ Support Smart Date Active to proceed.

Nah you’re right. I just have negative reinforcement to always assume I make the wrong decision with these. lol.

I've mutilated your nice 3 liner (sorry!), but the class needed a good cleanup :D
With this change, set to raw + scalar, and it'll attempt to convert from json.

Let me know if this suits

almunnings → created an issue.

https://salsa.digital/insights/enhancing-navigation-drupal-breadcrumbs

Is a great resource for further breadcrumb info.

Interface is merged.

Also breadcrumbs are a pain in the ass.

Gotcha! Ok I’ll review this at lunchtime today.

Works for me. Is it ?? Or ?: here?

Merged to next release

Side note: I still feel like it a bandaid on the symptom, and it's still going to be getting that deprecated in getCacheId, all we're doing is separating the caches by adding in the getCacheId again.

I'm unsure, quick check and maybe this was missed, and it fixes the issue?

$cid = $this->getCacheId('schema');
for web/modules/contrib/graphql/src/Plugin/GraphQL/Schema/AlterableComposableSchema.php

Good enough for me!

RE the other error you noticed, thats related to 🐛 GraphQL query stops working - seems cache issue Needs work I'm pretty sure.
I'll merge this one in now.

Cheers

Looks like the changes in 🐛 Cache collision when multiple servers are using the same schema plugin Active are breaking.

web/modules/contrib/graphql/src/Plugin/GraphQL/Schema/SdlSchemaPluginBase.php

Method: getCacheId

$this->getConfiguration()['server_id'] is not always set. It's weirdly only sometimes set?

It looks like its set in the server and not the schema?

Full ID returned: full:graphql_compose:my_server
- /admin/config/graphql/servers/manage/core_graphql/explorer
- /admin/config/graphql/servers/manage/core_graphql/voyager

Partial ID returned: full:graphql_compose
- /admin/config/graphql/servers/manage/core_graphql/validate

Somethings not right or I'm missing something here.
Is it an order or operation or missing data?

Aighty cool.
So I guess, as you are the resident French speaker.

if I changed
Éléments
to
Elements

In this scenario, would it be acceptable?

Ok cool, that helps me narrow it down.
I'll put $2 on it being this line:

https://git.drupalcode.org/project/graphql_compose/-/blob/2.4.x/src/Lang...

Could you try change that locally to 'items' instead of $this->t('items')
If that works, we might either leave it as t and strip back the higher ascii.

Thanks for your help!

Yeah strange,
How are you getting the É character into your schema...!

The GraphQL error is a symptom.
I saw it just now when switching between graphql 4 and 5-dev.

Are you using 5-dev by chance? Somehow using graphql webonyx 15?
If so, does switching to 📌 Add GraphQL 5.x support Active and clearing your cache have any positive effect?

If not...
HMM!

Are you injecting your own data from somewhere else?
The only way I was able to reproduce was to put the É character in a fieldname.

Do you have any idea where that field is coming from?

Under Filter Criteria:

• Click "Settings" next to "Your filter"
• Change "Selection type" to "Dropdown" (This should stop your error)
• Click Apply

Under Filter Criteria:

• Click "Your filter"
• Enable "Reduce duplicates"
• Enable "Allow multiple selections"

So now, when querying, you can use an array.
But you need to use the actual IDs. Not the labels.

To get the label IDs, in your query can use the filters field to list out all your filters. So probably on initial load of your view, you can get that list of filters, or put it in state somewhere else? Or just hard code it, up to your app? I'd probably opt to run a query for filters.

{
  testViewGraphql1 {
    filters {
      id
      options
    }
  }
}

Example result

{
  "data": {
    "testViewGraphql1": {
      "filters": [
        {
          "id": "field_tags_target_id",
          "options": {
            "1": "AA",
            "2": "BB"
          }
        }
      ]
    }
  }
}

Then use those IDs to query:
Example query:

{
  testViewGraphql1(filter:{
    field_tags_target_id: ["1", "2"]
  }) {
    results {
      __typename
    }
  }
}

Example result

{
  "data": {
    "testViewGraphql1": {
      "results": [
        {
          "__typename": "NodePage"
        },
        {
          "__typename": "NodePage"
        },
        {
          "__typename": "NodePage"
        }
      ]
    }
  }
}

lol any reason you closed?

Can you attach an export or screenshot of your view please. Need to recreate the view to test.

If breadcrumbs are empty, thats perhaps not the responsibility of this module?

I'd argue that this is better done in another module or a custom module to deal with no breadcrumbs, or it could be mitigated in the implementation?

Hmm, nah not passing tests.
I'll try take a look at this next

Delayed pending 🐛 Issue with the date-only field Needs work

I've flipped this, to not use the field definition, and use the incoming date object as preferred.

Care to test and see if it works as expected now?

I also dunno about adding 12 hours, whats drupal do?

Might just need to change

$value = $item->value to $value = $item->date if its available, and not modify the data

almunnings → created an issue.

✅ Very easy upgrade for GraphQL Compose, I was just missing a fields on an ObjectType.

/subscribing

almunnings → created an issue.

Fixed pending release

Noice

Hiya

Custom Scala should just return the content as is
Which would return the json from the field?

Or does it not do that?
Or are you needing it as a php array earlier for any specific reason?

Mm, menus go via GraphQL in a pretty standard way, they don't go vie the GQLC field producers.

'menu_links' loads via

    $registry->addFieldResolver('Menu', 'items',
      $builder->produce('menu_links')
        ->map('menu', $builder->fromParent())
      );

Which in the GraphQL producer is:

web/modules/contrib/graphql/src/Plugin/GraphQL/DataProducer/Menu/MenuLinks.php

That loads up the menu tree:

    $tree = $this->menuLinkTree->load($menu->id(), new MenuTreeParameters());

    $manipulators = [
      ['callable' => 'menu.default_tree_manipulators:checkAccess'],
      ['callable' => 'menu.default_tree_manipulators:generateIndexAndSort'],
    ];
// ... yadda yadda yadda

So I don't currently have a way to altering the field results, the menu fields in the schema tap direct into props via the graphql module.

What data were you looking to change?
Might signal how tricky what you're trying to do is

I suppose instead of

if (!empty($result = $this->resolveFieldItem($item, $context))) {

Could you use is_null ?

Have you got a test that can recreate your problem?
I tried with this:

./web/modules/contrib/graphql_compose/tests/src/Functional/Core/EntityNodeTest.php

./vendor/bin/phpunit -c /app/web/core/ --stop-on-failure web/modules/contrib/graphql_compose/tests/src/Functional/Core/EntityNodeTest.php

  /**
   * Test unpublished node.
   */
  public function testUnpublished() {
    $this->node->setUnpublished();
    $this->node->save();

    $query = <<<GQL
      query {
        node(id: "{$this->node->uuid()}") {
          ... on NodeInterface {
            id
            status
            title
          }
        }
      }
    GQL;

    $content = $this->executeQuery($query);
    dump($content);
  }

And got back

1) Drupal\Tests\graphql_compose\Functional\Core\EntityNodeTest::testUnpublished
PHPUnit\Framework\Exception: array:1 [
  "data" => array:1 [
    "node" => array:3 [
      "id" => "d22b45e4-0e13-4c57-aecd-e894030c1915"
      "status" => false
      "title" => "Test"
    ]
  ]
]

Is your problem happening as a part of a larger query?

Is the namespace of this command incorrect?

With drush 12
drush status --debug

Results in

 [debug] Could not instantiate Drupal\clamav\Drush\Commands\ClamavCommand: Too few arguments to function Drupal\Clamav\Drush\Commands\ClamavCommand::__construct(), 0 passed in /app/vendor/drush/drush/src/Runtime/ServiceManager.php on line 333 and exactly 3 expected [0.88 sec, 53.82 MB]

Suggest changing:

\Drupal\clamav\Drush\Commands\ClamavCommand
to
\Drupal\clamav\Commands\ClamavCommand

Modules that also implement changes to the AttachmentsResponse can result in the error:

Drupal\new_relic_rpm\Render\HtmlResponseAttachmentsProcessorDecorator::__construct(): Argument #1 ($decorated) must be of type Drupal\Core\Render\HtmlResponseAttachmentsProcessor, Drupal\webprofiler\Render\HtmlResponseAttachmentsProcessor given, called in /app/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 261

Steps to reproduce

Install the webprofiler → module.

Proposed resolution

/src/Render/HtmlResponseAttachmentsProcessorDecorator.php

Change: private readonly HtmlResponseAttachmentsProcessor $decorated,
To: private readonly AttachmentsResponseProcessorInterface $decorated,

Apologies, this is a result of another active issue, there was a patch applied. Closing.

almunnings → created an issue.

Ahoyhoy
This should already be a part of the GraphQL Compose Comment module.