You could hook alter the element. For example:
function HOOK_field_widget_single_element_entity_browser_entity_reference_form_alter(array &$element, FormStateInterface $form_state, array $context): void {
$element['#type'] = 'container';
}
Thanks for getting back to me, I was responding with my current situation. I am unable to disable the option given to publishers, now that it is released. My suggestions are just suggestions. This issue shouldn't be about my use case, apologies if that is how it appears. I am interested in fixing the issue, not creating more 🥲
Yes, disabling the ability for users to customise the theme would relieve the cache from being invalidated when users change their password.
But, as it is a feature, I would like to help fix the issue for the 30,000 sites with the cache nuke button :D Ideally, if the code is not in use, and it is an issue, it is removed.
In my circumstance, it's not acceptable to run a cache clear site-wide under any conditions. The deleteAll is an administrative action, and a risk for a bad actor.
A quick skim of the codebase, would lead me to believe this is to work around for theme suggestions.
Do you know what side-effects (in particular) this deleteAll is looking to fix? I could then help test/qa.
If not, perhaps making the deleteAll an administrative option (not available to the user form) that can disabled eg:
"[x] Allow users to change toolbar"
"[x] Clear render cache after user changes toolbar"
At minimum that would allow me to avoid cache destruction 100%
Just attaching a dirty 4.1.x patch to remove the cache clear, mostly to address my own immediate needs.
Saving the form, updates the user's toolbars as expected, which is what the comment suggests would be the issue: (Clear render cache to ensure the correct templates are loaded for our toolbar options.)
I'm currently using PhpRedis as a cache backend, if that's important.
I couldn't see any immediate side-effects of removal.
Perhaps someone knows more
GraphQL 5.x is supported with Compose 3.x
I don't have any plans for commerce support at the moment, as I don't use it. Happy to leave this ticket open for anyone willing to do that body of works.
You could create your own entity plugins for each of commerce's entity types, we support most of the "connecting tissue" with entity references.
Recommend it is a sub-module.
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.