🇦🇺Australia @AlMunnings

Is it a sequence?

https://www.drupal.org/project/config_inspector → might help

Hmmm no, I don't think you've tested that

    1)
    Drupal\Tests\graphql_compose\Functional\Contrib\DoubleTripleFieldTest::testDoubleField
    Drupal\Core\Config\Schema\SchemaIncompleteException: Schema errors for
    triples_field.settings with the following errors:
    triples_field.settings:fields.first missing schema,
    triples_field.settings:fields.second missing schema,
    triples_field.settings:fields.third missing schema

You might benefit by adding some phpunit tests to your module to check it installs ok?

Cheers

Looks like you need to define your schema for triples_field.settings within your modules schema.

Testing reveals an issue with Drupal 11.

\Drupal\Core\Config\Schema\SchemaIncompleteException: No schema for triples_field.settings

This may be an issue for the triple field module.
Feature delayed until upstream module passes D11 tests

https://git.drupalcode.org/project/graphql_compose/-/jobs/1815750

Yeah I struggled with the structure of some of these config entities. I understand it’s a fieldable entity, but you then are creating an entire bundle type for one config set?

Its probably worth your while stepping outside of graphql compose to get your bespoke structure, you could introduce a new query that returns just one config entity without any args pretty easily, and you could return the config entity and let gqlc handle all the fields for you

Maybe it just isn’t fitting the entity queries provided by gqlc per se.

I can help you make a little module if you’d like?

Hokay,
So I guess my comment would be:

3.x is still around, but 4.x is out with a completely new structure,
The integration probably doesn't belong here, and is probably more of a "create your own module and add a 3.x plugin if you need it" situation.

The patches existence should be enough of a "nudge in the direction" for any Drupal 9/10 GraphQL 3.x devs needing integration, but this issue could be closed.

Oh Lordy!

As it happens, I’m contracting back at the agency that needed that patch, this week, on that exact site. Wild.

I’ll check today for you

almunnings → created an issue.

I'm not suuuuper across this module
But from memory, the config pages settings can be exposed as tokens?

You could then use those tokens in the provided "custom info" settings to expose the settings. If that helps?

Quick search, similar thread:
https://www.drupal.org/project/graphql_compose/issues/3361379#comment-15... ✨ Expose Configuration Type Entities for Site-Wide Data Fixed

Alternative option might be views?

Merged into 2.2-dev, no plans to back port at this stage.

Thanks!

2.1.1 released. Thanks!

I guess we need to make a decision.

If lang code is requested, and latest is requested, and there is no latest revision for that language… null ok?

Seems logical

Although we might not even make it here, as the entity load with language could also fail if there was no revision.

I might make a test today and just set this in stone

I’ll take it onboard though. It can be reworked to only request once.

Done pending 2.1.1/2.2.x release. Thanks all.

Added to patch for MR for testing

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

@bstan Did you want to run your eyes over https://git.drupalcode.org/project/graphql_compose/-/merge_requests/80 please

I think it'll cover your use case.

Added in some junk code, but it'll do nicely:

  /**
   * The latest revision identifiers.
   */
  const REVISION_LATEST = [
    'latest',
    'newest',
    'working',
    'working-copy',
  ];

  /**
   * The current revision identifiers.
   */
  const REVISION_CURRENT = [
    'active',
    'current',
    'default',
  ];

So you should be able to do:

node(id: 123, revision: 'working-copy') {} // or latest, newest, working
node(id: 123, revision: 'current') {} // or active, default
node(id: 123, revision: 456) {}
node(id: 123) {}

Have a go, let me know!

almunnings → changed the visibility of the branch 2.2.x to hidden.

almunnings → changed the visibility of the branch 2.2.x to active.

Just a hunch, but I suspect people might get a bit more use out of this with opening up the input to be a String, rather than an Enum.

We could load in by revision ID then.

WORKING_COPY also seems redundant, as it's the same as providing no value.

So I'm kind of leaning into:

- Change input arg to String
- Remove Enum
- Rename "Version" to "EntityRevision"
- Check for "latest" or attempt to load revision by arg value.
- Integrate graphql Buffer `EntityRevisionBuffer` to do the loading

If you're cool with that, I can have a refactor this weekend.

Possibly related / unrelated. Lines are blurry
Had success with the following configuration, as this issue's changes would suggest.

phpunit (next major):
  variables:
    _PHPUNIT_CONCURRENT: 1
    _TARGET_DB_VERSION: $CORE_MYSQL_MAX
    SYMFONY_DEPRECATIONS_HELPER: "disabled"

Noting, I needed to use SYMFONY_DEPRECATIONS_HELPER as disabled with PHPUnit 10. The weak setting was still spilling out hundreds of deprecations from functionality outside my control :)

The tests do pass locally with Drupal 11 and PHPUnit 9, without "disabed"

Config used:
https://git.drupalcode.org/project/graphql_compose/-/blob/0fffe9decbb215...

Job result:
https://git.drupalcode.org/project/graphql_compose/-/jobs/1595359

Apologies for the 2.2.x dev spam, fumbling around in CI to get Drupal 11 support tested.

Please assign me in gitlab for a review once you're happy with it.

Hot dog.
Lets never speak of this again.

Drupal 11 CI passing.
Will create a new issue to remove gitlab-ci patches as contrib updates.

almunnings → created an issue.

Howdy
This looks like a GraphQL project issue.
GraphQL Compose never had 3.x support.

Could you please address your question over to https://github.com/drupal-graphql/graphql/issues

Or try... I dunno, uninstalling GraphQL and re-installing. Or reinstalling 3.x to uninstall it then installing 4.x?

From memory, there isn't an upgrade path between 3.x and 4.x - But I could be mistaken.

It's kinda not in my wheelhouse

almunnings → created an issue.

Thanks for the bug hunt

The behaviour explanation could be:

Edge connections (menus and routes) when using a langcode changes the context of the response using the language_context producer. EG:

# EdgesSchemaExtension
$builder->produce('language_context')->map('language', $builder->fromArgument('langcode')),

Which basically tells Drupal "I expect everything and all subsequent results in this language" - Which avoids prop drilling the langcode, at the expense of modifying the entire query (which sometimes sucks if you're batching queries in alternating languages)

Fundamentally: Without the 'language context', when generating a url, it thinks it's the site default.

Simple fix: Slam the field's language into the url after generation. Bingo!

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

almunnings → created an issue.

Nice, cheers for the find (and the test!).

I'll merge that up now.

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

almunnings → created an issue.

Considering that I am the author of both modules, perhaps it could be taken into consideration:

- the meta package didn't work as desired
- there was no stable release including the sub module
- the sub module no longer exists

And now it’s causing unwanted side effects.

Is it possible to remove the meta package? Or rename it to free up the normal package name?

🙏

almunnings → created an issue.

Tagged and released

Thanks all

Sweet. The update will rerun next release due to a number change, but glad that’s the issue found.

Will push up b5 now.

@CedricL Please pull dev at hash, or apply patch

https://git.drupalcode.org/project/graphql_compose/-/commit/3377d6294360...

Let me know if that is fixed after running drush updatedb or the database updates via the Drupal UI.

Thanks!

almunnings → changed the visibility of the branch 3441242-undefined-array-key to hidden.

Looks like its the schema changes.

schema_configuration: {}

Should be

schema_configuration:
  graphql_compose:
    enabled: true

I'll create an update function to check for graphql compose schemas and update that.

If I put in a sneaky little dump($this->getConfiguration()); in web/modules/contrib/graphql/src/Plugin/GraphQL/Schema/ComposableSchema.php in the method getExtensions

I get the following:

  /**
   * {@inheritdoc}
   */
  protected function getExtensions() {

    dump($this->getConfiguration());

    return array_map(function ($id) {
      return $this->extensionManager->createInstance($id);
    }, array_filter($this->getConfiguration()['extensions']));
  }

 array:2 [▼
  "extensions" => array:16 [▼
    0 => "graphql_compose_entity_schema_extension"
    1 => "graphql_compose_language_schema_extension"
    2 => "graphql_compose_information_schema_extension"
    3 => "graphql_compose_blocks_schema_extension"
    4 => "graphql_compose_comments_schema_extension"
    5 => "graphql_compose_edges_schema_extension"
    6 => "graphql_compose_image_style_schema_extension"
    7 => "graphql_compose_layout_builder_schema_extension"
    8 => "graphql_compose_layout_paragraphs_schema_extension"
    9 => "graphql_compose_layout_schema_extension"
    10 => "graphql_compose_menus_schema_extension"
    11 => "graphql_compose_metatags_schema_extension"
    12 => "graphql_compose_preview"
    13 => "graphql_compose_route_schema_extension"
    14 => "graphql_compose_views_schema_extension"
    15 => "example_extension"
  ]
  "enabled" => true
]

What do you get? (Plugin IDs might vary between dev and beta4)

Ok, it probably boils down to...
$this->getConfiguration()['extensions']

I'll take a look deeper there tonight after everyone goes to bed :)

There was some schema changes upstream in GraphQL which I had to try work with.

Can you try going to the GraphQL schema in the GraphQL admin interface, and just clicking "save" ?

Eg URL: /admin/config/graphql/servers/manage/YOUR-CORE-ID

Not sure thats it, `getDefinitions` should always return an array. I feel we have a bigger issue with merging non graphql_compose schemas into the final result.

Your array function

'fields' => fn() => $subFields,

Needs to have array keys. The key is the field name.

You're returning:

[
  0 => ['type'..., 'description'],
  1 => ['type'..., 'description'],
]

You need to return something like.

[
  $name => ['type'..., 'description'],
]

Try this:

        $types[$field->getTypeSdl()] = new ObjectType([
          'name' => $field->getTypeSdl(),
          'description' => (string) $this->t('A data field is a specialty field provided by the CMS.'),
          'fields' => function () use ($field) {
            $columns = array_keys($field->getFieldDefinition()->getSetting('columns'));
            $subFields = [];
            foreach ($columns as $column) {
              $subFields[$column] = [
                'type' => static::type($field->getSubfieldTypeSdl($column)),
                'description' => (string) $this->t('The @field value of the data field', ['@field' => $column]),
              ];
            }
            return $subFields;
          },
        ]);

This makes it appear in the schema.

You'll then need to do a bit of work in your `DataFieldItem` class to return the correct value.

Released with beta4
Thank you

It’s all built on those plugins loading.
Did you check your namespaces?

As you are the maintainer of the triple field module, there is good opportunity for you to add this integration to your own module.

Is there any reason you don’t want full control?

Can you give dev a go again now please.

Thanks

Yeah k, I see the issue.

CommentableTrait gets all fields, regardless of if te bundle is enabled.

Working on a fix now.

In regards to the node/article comments error, can you provide a reproducible setup that causes this issue?

I believe the error
I just don't know how to recreate it

Did you create or delete any entity types after or before saving the graphql config?
Have you tried clearing caches?

typed_data is a requirement of graphql?

I think that minimum stability is actually on your composer.json not mine?

Can you try manually installing https://www.drupal.org/project/typed_data →

Please and thank you.
Works as expected.

Added to beta3 release. Cheers

Yep thats how it's done! Thanks! Merging

Beta 2 tagged, thanks all

Beta 2 tagged, thanks all