🇧🇪Belgium @davidiio

I have used your merge request .diff file (https://git.drupalcode.org/project/graphql_compose/-/merge_requests/120....) on Drupal 11.1.5, graphql 8.x-4.11, graphql_compose 2.3.0. It applies and singuliarize option can be on or off without error.

I might not be the best to say it is RTBC, but for me, it is working :)
Thanks!

Yes, I suppose.
In french element is supposed to be "élément" (if displayed to a human reading french) but these strings are not supposed to be displayed so it is ok without accent, I would never name a variable with accents.

YES :)
Changing $this->t('items') to 'items' does eliminate error for us.

Thanks a lot!

Thanks for your answer!

We are using graphQL Version : 8.x-4.11
Following the stacktrace the webonyx error goes back to graphql module

/web/modules/contrib/graphql/src/Plugin/GraphQL/Schema/AlterableComposableSchema.php(173): GraphQL\Language\Parser::parse('extend type Que...', Array)

When logging the $extensions variable it is trying to parse I have found a very long string. It looks like all the content types and terms we exposed with graphql_compose and in this string some words appear in French especialy the word "Element" is translated to "Élément" in different places like

 extend type Query {
      """List of all TermTags on the platform."""
      termTagsÉléments(
        """Returns the elements that come after the specified cursor."""
        after: Cursor

or in this part that looks like a view on which we exposed the number of "element per page"

        """The page number to display."""
        page: Int = 0
        """Éléments par page. Allowed values are: 5, 10, 12, 20, 24, 25, 50."""
        pageSize: Int = 20

I was able to remove the É from the "Éléments par page" by configuring the view but other strings like "termTagsÉléments" remain even when remmoving all accents from "Element" in /admin/config/regional/translate

This is a weird string because only the "Element" word is translated and it is translated event on part of words like in "termTagsÉléments".
We had this same issue on a prod site when activating a module and some translations were updated. Is it possible that core translation introduced some bug?

Happy to see this going forward.

Ihave installed toolbar_menu 3.1 on drupal 11.1.5 and applied this merge request .diff file as a patch and it works as expected!

Thanks for making this happen dydave :)

davidiio → created an issue.

After some disabling and enabling of graphQL and GraphQL Compose and returning to the explorer page between modifications we also notice that unticking the "Enable Singuliarize" checkbox in the "String inflector" tab of graphql_compose settings produces the same bug.
Maybe this issue is a graphql_compose issue and not a graphql issue.

Hello,

We face the same issue here once with an apdated site (we restored backups to make it work again) and now we face it with a new dev website with Drupal 11.1.5 and GraphQL 8.x-4.11 and Graphql_compose 2.3.0.

We noticed this error GraphQL\Error\SyntaxError : Syntax Error: Cannot parse the unexpected character "\uc9". dans GraphQL\Language\Lexer->readToken()

And realized that this bug happend only after translation updates, if we revert our prod site, enable a new module that updates translation we have this bug again.
Are any of you using multilingual sites? Maybe this is a lead to find out what is wrong here?

We are not able to apply this patch using mglaman/composer-drupal-lenient (along with the drupal 11 compatibility patch) on a drupal 11 with Commerce 3
Composer still complains about commerce_mollie requiring commerce 2.

Should this issue (and drupal 11 compatibility) be prioritize higher? Since drupal 11 is here and commerce 2 is not compatible with drupal 11 all new commerce installs will be in commerce 3.

This module not being compatible with D11 and Commerce 3 means all users of commerce_mollie are unable to upgrade their website.

Same probleme here, we are unable to save our view due to this error.
I don't know why there is a default file to load but using File::load() on null is not possible.
Checking for null on lines 317 and 357 of src/plugin/views/display/XlsDataExport.php did make it possible to save the view
But maybe there are some other places to look for this problem. Sorry we don't have time to look more into this issue right now

Hello,

We had the same probleme here on drupal 10.3.6, user_history 1.1.0
When clicking "initialize" batch process won't start because a type is missing somewhere on field storage config creation.
Applying patch from first post does make it work.

Error:

Drupal\Core\Field\FieldException : Attempt to create a field storage changed with no type. dans Drupal\field\Entity\FieldStorageConfig->__construct() (ligne 271 de /web/core/modules/field/src/Entity/FieldStorageConfig.php).

Trace:

#0 /web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(222): Drupal\field\Entity\FieldStorageConfig->__construct()
#1 /web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(232): Drupal\Core\Config\Entity\ConfigEntityStorage->doCreate()
#2 /web/core/lib/Drupal/Core/Entity/EntityBase.php(523): Drupal\Core\Entity\EntityStorageBase->create()
#3 /web/modules/contrib/user_history/user_history.batch.inc(54): Drupal\Core\Entity\EntityBase::create()
#4 /web/core/includes/batch.inc(296): user_history_add_tracked_fields()

On multivalue tablefield a new empty table is added avery time the node is updated making the edit form longer and longer and databse full with empty data if the user don't manually delete the table from the form.

Thanks for your answer Megachriz. It is not blocking for us anyway. I will investigate if I have time.

Hello,

We have the same issue here and this patch from a somehow similar issue didn't fix the porblem:
similar issue: https://www.drupal.org/project/feeds/issues/3189557 🐛 Setting a target for "langcode" field will sometimes throw "this field cannot hold more than 1 values" Needs work

We have a multilingual site we have imported users and then we tried to import articles and set the uid as the feeds_item.guid of the previously imported user and faced the same issue

Authored by (uid): Authored by: this field cannot hold more than 1 values

We have created a simple environnement on simplytest.me and the issue is the same
You can try it here https://master-hfr0tovoioejutcmmgxmlqbhohe8jk8x.tugboatqa.com with login/pass = admin/admin

davidiio → created an issue.

I really don't get it. I also tried it on simplytest.me and it worked on standard drupal 10.3.6 and burndown 1.0.43.
But when trying a new standard drupal 10.3.6 with burndown 1.0.43 on my server I have the error.
I don't know what's going on but thanks for your help!

I have tried desabling and reenabling the module.
When module is enable we can't create any field on any content type, juste tried on Article, when clicking on "create new field" we get the error.
I will investigate more

Hi Jeremy, I continue for Matthieu.

We have tried 1.0.43, 42, 41 and also 1.0.x-dev and always have the issue.

The file burndown.field_type_categories.yml is present in burndown/config/install and also in our drupal /config/sync folder:

Burndown:
  label: 'Burndown Fields'

Cache clear did not help.

Do you see anything wrong here?

We applied patch from #18 and media library edit modal now diaplays save button.
Tried it on Drupal 10.3, gin 3.x-rc11 and media_library_edit 3.0.3

I can't upgrade this website to D10 right now. We're stuck with 9.5.11 and so we can't use BEF 7 version. I could try it on other sites but here I would like it to work on D9.5.11 and BEF 6.0.6. Downgrading to BEF 6.0.5 made it work though.

We have a view of node filtered by a date field (not the created date) we enabled BEF and selected the datepicker widget for this exposed date filter and got the warning I mentioned, there is nothing else I could say about this issue. When I don't use the datepicker filter is working.

davidiio → created an issue.

After changing the OR for a AND operator in my previous commit I was able to use the module without the log
Cannot use view object to get third party settings.

For a basic configuration the module successfully removed duplicates from view.

1. Create a few articles
2. Add a reference field for articles in Basic Page.
3. Create a few basic pages referencing multiple articles.
4. Create a view of Basic pages
5. Add a relationship to article
6. Note that some basic pages titles are duplicated
7. In the title field config in "Views Distinct settings" tick "Filter this field"
8. Note that duplicated title are removed from the view

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

I 've been working on this recently for our projects and improved it a little. The first menu element was displayed as it has children even if it was not the case. Now this is fixed.
I have created an issue fork and a merge request for this to be reviewed.

I have made an issue fork '3296982-refactoring-and-D10-readiness' with a merge request.
But before that I have pushed a poorly named 'dev' branch from local. When I try to delete it I have a message saying "Prevented by server hooks"...

Hi there,

We have successfully upgraded our website to Drupal 10 and use Download by combining this rector patch with the changes mades in this issue refactor an improve the code →
Now all code combined in this patch attached if you want to make a new release for D10

Patch is working for us

This patch is working.
It would be great to make the change in the module code and create a new version

Patch applied and no more errors on drupal 10.1.8
Thanks

Hello again,

Duration seems to be properly updated when using code like this:

$entity->{$start_field}[$delta]->duration = ($entity->{$end_field}[$delta]->end_value - $entity->{$start_field}[$delta]->value) / 60;

But I would really appreciate if someone with mre knowledge about smart_date could check if this is a bug or not and if my approach is correct.

Thanks :)

davidiio → created an issue.

davidiio → created an issue.

I have applied this patch using lenient https://www.drupal.org/docs/develop/using-composer/using-drupals-lenient... →
Patch is applied, I have updated my site to D10 without problem and email_blocker is working.

Please update module so we can use it properly

Thanks for your answer.
I thought avoiding splitting would be the solution but since it is how it is supposed to be done I have looked somewhere else and configuring the fee to be applied only when order amount is greater than 0 solves the problem for us now.

davidiio → created an issue.

OK Thank you very much I will try that!

davidiio → created an issue.

Applying patch #2 made all operations links/bulk operation checkboxes in our views appear "broken/missing handler".
Removing the patch made it work again we can't use it like this but we don't have time to improve the patch now or investigate more on this.

davidiio → created an issue.

davidiio → created an issue.

Thanks Murrrayw for your answer and solutions options.
Much appreciated!

davidiio → created an issue.

davidiio → created an issue.

davidiio → created an issue.

Hi everyone!
We had the same problem using the module selective_better_exposed_filters trying to reduce the number of options of a "taxonomy term with depth" filter.
I made small ugly patch.
Noticing the $filter->definition['field_name'] could not be found and so the $field_id variable could not be set I have set it after using this code:

if($field_id == NULL) {
   $field_id = $filter->options['reference_field'];
}

I guess a better approach would be to check if the filter is indeed a "taxonomy_term_with_dpeth" filter but I really could not find this info when inspecting the $filter variable :(

Patch failed to apply on D10 but I could make it work on D10 by copy/pasting same code at different line numbers in files. Also I could not find this test file in D10.1 :

/core/modules/media/tests/src/Kernel/ResourceFetcherTest.php

Sorry for re-opening this issue but I think an ->accessCheck() is still missing in /src/Form/OrejimeSettingsForm.php, around line 387.
It prevents from opening de module configuration page.