🇦🇺Australia @almunnings

Pretty-much ready to commit this, I just want to create a test for the comment in 8eaabeaf, just has me being a bit cautious here.

Merged to 2.3.x develop. Thank you.

Thanks for the heads up.

almunnings → created an issue.

almunnings → created an issue.

Adding some findings to the topic.

I just wanted to select a default layout for a "section" of my site.
I don't really want to set default content. Just select a the specific layout.

Got there with:

/**
 * Implements hook_form_FORM_ID_alter().
 */
function MY_MODULE_form_layout_paragraphs_component_form_alter(array &$form, FormStateInterface &$form_state) {
  if (isset($form['layout_paragraphs'])) {
    array_unshift(
      $form['layout_paragraphs']['#process'],
      [MyModificationClass::class, 'setDefaultLayout']
    );
  }
}

declare(strict_types=1);

namespace Drupal\MY_MODULE\Form;

use Drupal\Core\Form\FormStateInterface;

/**
 * Set the default selected layout for the layout paragraphs component form.
 */
final class MyModificationClass {

  /**
   * Form #process callback.
   */
  public static function setDefaultLayout(array $element, FormStateInterface $form_state, array &$form): array {
    /** @var \Drupal\paragraphs\ParagraphInterface $paragraph */
    $paragraph = $form['#paragraph'];
    if ($paragraph->bundle() === 'section') {
      $behavior_settings = $paragraph->getAllBehaviorSettings()['layout_paragraphs'] ?? [];

      if (empty($behavior_settings['layout'])) {
        $behavior_settings['layout'] = 'one_column_narrow';
        $paragraph->setBehaviorSettings('layout_paragraphs', $behavior_settings);
      }
    }

    return $element;
  }
}

Change out MY_MODULE, section, one_column_narrow to fit your needs - yey, default layout set.

Grab 97 please. 95 I’m not gonna merge. If same issues happy to move fwd on your feedback

On or 95 or 97?
I’m working with 97

Same issue
Confirm fixes

Merged in dev 2.3. Thanks!

Fine to move server to arg, I’ll just make it an optional arg. Default to all servers.

On dev branch, if you wanted to review.

Yeah that filename is just the default filename, incase people used a dir path in the output location.

You could make it myfile.potato
Don't really need this patch.

As sweetchuck says.

Changed it to just use the views prop 'total' => $view->total_rows ?: 0,

Should be the same/same without the nully bits.

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

Create a custom module. Eg:

In a mymodule.module file

use Drupal\media_library\Form\FileUploadForm;

/**
 * Implements hook_media_source_info_alter().
 *
 * - Disable dropzonejs for media library add form.
 */
function MYMODULE_media_source_info_alter(array &$sources) {
  if (!\Drupal::moduleHandler()->moduleExists('dropzonejs')) {
    return;
  }

  if (isset($sources['image'])) {
    $sources['image']['forms']['media_library_add'] = FileUploadForm::class;
  }

  if (isset($sources['video_file'])) {
    $sources['video_file']['forms']['media_library_add'] = FileUploadForm::class;
  }

  if (isset($sources['audio_file'])) {
    $sources['audio_file']['forms']['media_library_add'] = FileUploadForm::class;
  }

  if (isset($sources['file'])) {
    $sources['file']['forms']['media_library_add'] = FileUploadForm::class;
  }
}

And in a mymodule.install file

/**
 * Implements hook_install().
 */
function MYMODULE_install() {
  module_set_weight('mymodule', 50);
}

This should disable it on the normal forms. Weight 50 is just a random number I chose, it just needs to run after dropzonejs module.

Releasing in 2.2.1

Releasing in 2.2.1

Releasing in 2.2.1

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

almunnings → created an issue.

Heyya
I've combined the feedback.

Are you able to test PR 97 please.

Yep can get this done

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

Can see the merit in wanting this specifically for Dynamic Entity Relationships.

They can get a bit out of hand.

I like your field type idea.

It’s new behaviour compared to how everything else works, so we might need to introduce a specific setting for the field type.

Specific settings for fields aren’t currently really supported, so it’s a good chunk of work to do it right.

Perhaps we can introduce a settings object into the schema and attributes of the plugin. This could allow adhoc extra fields to be added to the config ui.

klausi → credited almunnings → .

klausi → credited almunnings → .

klausi → credited almunnings → .

almunnings → created an issue.

Also looks like changes have been made on the 2.2.x branch and not on the issue branch. I'll do some force pushes to move this around.

Ok
Bit of a mess, because the git branches were garbled.

https://git.drupalcode.org/project/graphql_compose/-/merge_requests/93 is my commit.

Let me know how that goes for you, added bonus of some tests on it.

Oh, looks like you edited the 2.2.x branch and not the issue branch, i'll need to fix that up.

Yeah good pickup! To avoid a breaking change, we could filter it as you suggest. I'll pop in another Fork/MR

The current filtering needs to be thrown out and re-done, and tap into the field conditions better.

Replace the lot by building around the graphql producer "entity query"
https://github.com/drupal-graphql/graphql/blob/8.x-4.x/src/Plugin/GraphQ...

And implement cursors on-top of that to manage the offset.

This is a worth while feature request. I've had to point people at Views multiple times. But sometimes, people want cursors.

Breadcrumbs are based off URL path in Drupal by default. I think, lol.
Usually by path alias. It should however work with add-ons.

I've not done anything special here.
The tests in `BreadcrumbTest` should point the way.

Does your drupal node have breadcrumbs if you visit it in the backend?

Happy to bring this into main module rather than a sub module.

oh nice, this was fixed

LGTM!

Hey, cool chat prompt!
I'm a "write as I think" kind of responder, so forgive me if I ramble.

Mutations are a bit of a clean slate right now.
The comments mutation was a start at it, but it was just to compliment the comments module.

I often found myself torn in two states of mind about starting any deeper integration.

Most of my use cases for writing content back to Drupal have been ad-hoc or really specific. The most useful one I can think of, which I haven't got here is webforms.

I've not yet felt the burning desire to go and create nodes and the node content ui in a headless ui.

If we were to address generic entity mutations, it would be pretty generic, and possibly limited by the nested complexity horrors of things like paragraphs.

Theres also the suggestion that you can just write your mutations in graphql without compose, and you can leverage the compose types for returning content.

I've got a sample module on a repo that I gave someone in Slack.

https://github.com/almunnings/drupal-graphql-sample-mutation

My personal opinion is yes to webforms, and yes to basic entity/fields, and "oh lordy" to extended contrib support.

Do we have any good examples of mutations for nested entity structures (like paragraphs) written by anyone else? Something we could leverage as best practice? I feel like I'd just wing it with some data producer mapped monster.

2.1.1 patch at https://git.drupalcode.org/project/graphql_compose/-/merge_requests/89.diff

MR passing tests
Merging to 2.2.x and creating backport patch to get y'all through til tomorrow and I can release not on a laptop in bed :D

Cool,
Reproduced, test altered, patch in MR against 2.2.x

Assuming this goes well, i'll release 2.2

Got it, thanks that’s really helpful

Could either of you attach some config please.

From what I can gather, its something to do with your schema having a field with a hyphen in the field.
EG

type Whatever {
  ti-tle: String
}

GraphQL\Error\SyntaxError: Syntax Error: Invalid number, expected digit but got: "t" in GraphQL\Language\Lexer->readDigits() (line 439 of /app/vendor/webonyx/graphql-php/src/Language/Lexer.php).

Do you have any custom schema or config with a hyphen in the field?

I try to prevent you ever using dashes.
It might be something custom or overridden?

Please attach your graphql compose yml and check for any contrib in graphql that might have a field with `-N` in the name.

👀

Ok, should be done
Hows this data shape look?

query {
  node(id: "ccc6baa9-1545-4332-ac48-daedb146dd6a") {
    ... on NodePage {
      social {
        id
        name
        value
        url
        weight
        description
      }
    }
  }
}

Please test on the 2.2.x and let me know if you're happy with that

Ok great, I'll add some tests tomorrow night and get this in.

Thanks!

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

almunnings → created an issue.

Reroll of #73 for Drupal 10.3

Ok nice, thanks for that

The failing tests are another issue, i'll get them passing now and update the MR once done.

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