Actually, I decided to create a standalone module on
https://www.drupal.org/project/graphql_compose_file_upload →
.
Because the file upload can work without the graphql_compose_mutations module.
Since we have published the module on https://www.drupal.org/project/graphql_compose_mutations → this issue will be closed.
@jmolivas Yes. Please add me as a maintainer on the new module. I will push the code there (I have some updates also that are not on current MR)
After that I was planning to publish all the graphql_compose_* modules this year.
At first glance, this looks like something Drupal.org could benefit from.
After reading the comments more carefully, I am concerned that this proposal risks doing more harm than good to the contribution ecosystem. If contributions in this category do not result in contribution credits, it is unclear what the incentive would be for maintainers or code owners to participate. In that case, why would they not simply host their non-generic or experimental modules on GitHub, Bitbucket, or even on Drupal’s own GitLab instance?
"Contrib first" is not just a development workflow. It is a core philosophy of the Drupal project. Introducing a module category that weakens or bypasses this philosophy risks fragmenting the ecosystem. Contributors who already follow "contrib first" gain little, while those who do not are unlikely to change their behavior. Beyond Builders and Makers, there is also a large group of (developer) "Consumers", and these users are rarely motivated to publish or maintain code on Drupal.org under such conditions.
For these reasons, I am not convinced this proposal provides a clear net benefit. Drupal.org already has significant challenges and opportunities ahead, especially around AI-related tooling and infrastructure. Adding a new module category without strong incentives or clear value risks expanding the surface area of the contrib system without strengthening it.
theodorosploumis → changed the visibility of the branch 3458995_mutations to hidden.
I was looking for the same feature. In the meanwhile we can use an mcp like this at least to get commits, projects, merge_requests, pipelines etc:
"drupalcode": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-gitlab"
],
"env": {
"GITLAB_PERSONAL_ACCESS_TOKEN": "XXXXXXXXXXX",
"GITLAB_API_URL": "https://git.drupalcode.org/api/v4"
}
},
Example JSON response: https://git.drupalcode.org/api/v4/projects/project%2Fdrupal/
More documentation on: https://git.drupalcode.org/help/api/rest/_index.md
theodorosploumis → made their first commit to this issue’s fork.
I would like to opt-in these modules:
https://www.drupal.org/project/human_decimal →
https://www.drupal.org/project/ief_table_view →
https://www.drupal.org/project/redirect404_home →
https://www.drupal.org/project/transparse →
https://www.drupal.org/project/webform_mailerlite →
https://www.drupal.org/project/migrate_sourceid →
https://www.drupal.org/project/migrate_file_field_bundle →
https://www.drupal.org/project/scrollbar →
https://www.drupal.org/project/documentation_export →
We understand we cannot revert this change and there may be some unexpected issues as early adopters.
theodorosploumis → changed the visibility of the branch 3547465-fix-several-php to hidden.
theodorosploumis → created an issue.
theodorosploumis → made their first commit to this issue’s fork.
Added example for Drupal CMS using https://git.drupalcode.org/project/drupal_cms/-/blob/2.x/recipes/drupal_... for content.
In order to apply the MR patch (which I think is a temporary solution) you need also to reset the field value for the non-source Nodes. You can do this on a hook like this.
function MODULE_field_widget_single_element_viewsreference_select_form_alter(array &$element, FormStateInterface $form_state, array $context): void {
$values = $form_state->getValues();
$langcode = $form_state->getStorage()["langcode"];
$default_langcode = $form_state->getStorage()["entity_default_langcode"];
if (empty($values) && $langcode !== $default_langcode) {
$element = [];
}
}
theodorosploumis → created an issue.
Update bold formatting on the "Alternative approaches" section.
- Add the Alternative approaches section for more advanced developers.
- Remove broken link to https://wimleers.com
theodorosploumis → created an issue.
theodorosploumis → created an issue.
theodorosploumis → created an issue.
Can we merge this PR please and create a new release that supports 11.x?
Thanks!
Sorry, it was an error from my local patches. Closing this.
theodorosploumis → created an issue.
theodorosploumis → created an issue.
Since I have most of the modules mentioned on #6 ready I have a question.
Should I create a single merge request for all of them together or open an issue for each one? I think the second is better, right?
theodorosploumis → created an issue.
Here is the Diataxis technical documentation model: https://diataxis.fr
It's not 100% ready but I will create a MR on this issue with what I have for Mutations up to now.
It misses testing and several meta files probably.
I have no issues with the PR number 97. Thanks!
I was working with the patch from 95.
I found an issue with this feature which may be related to the main module.
When I enable the new module graphql_compose_linkattributes it seems that I cannot override later the Link class with another custom module. Only when I disable the the module graphql_compose_linkattributes I can override it.
How to reproduce this? Enable the graphql_compose_linkattributes module from this patch and then create another module that has similar functionality to this. When you enable it the new fields are not attached to the LinkType (although the new GraphQL type is available on Docs).
We may need to investigate here, also, if methods hook_graphql_compose_graphql_type_alter() and hook_graphql_compose_field_type_alter() allows for multiple and correct inheritance.
theodorosploumis → made their first commit to this issue’s fork.
That's correct, thanks.
theodorosploumis → made their first commit to this issue’s fork.
There is no such built-in feature on graphql_compose currently.
You can achieve this in different ways.
1) Create a GraphQL compose views and get there the Nodes filtered bty taxonomy term tid. See https://drupal-graphql-compose.github.io/documentation/#/features/views
2) Add a custom Field on the Node Union query (programmatically) to get the Nodes of a taxonomy. See https://drupal-graphql-compose.github.io/documentation/#/extending/custo...
3) Use module
https://www.drupal.org/project/viewfield →
to create a Views field on the taxonomy and then get the Nodes there. See https://drupal-graphql-compose.github.io/documentation/#/contrib/viewfield.
Notice that this module extends the graphql module. The code you describe refers to the graphql module and not this one.
theodorosploumis → made their first commit to this issue’s fork.
Here are the modules we are working on. The most interesting are the debug, file_upload, mutations, logout, register, reset_password. The other ones are are self explained. They simply entity related with some minor customizations and extensions on fields.
- graphql_compose_activities
- graphql_compose_debug
- graphql_compose_files
- graphql_compose_file_upload
- graphql_compose_flaggings
- graphql_compose_logout
- graphql_compose_messages
- graphql_compose_mutations
- graphql_compose_posts
- graphql_compose_private_messages
- graphql_compose_profiles
- graphql_compose_register
- graphql_compose_reset_password
I do have a ready mutations module (with exactly that name) but I need some time to create the PR.
In fact, I do have many other submodules I created based on the graphql_compose module but need some work to make them at least ready for review.
theodorosploumis → created an issue.
TheodorosPloumis → created an issue.
TheodorosPloumis → created an issue.
TheodorosPloumis → created an issue.
We also have a similar issue on a SOLR 7.x server with about 100k Search API Items.
Looking for solutions too.
One option that seems to work better is to use the "Solr Suggester" (but this requires SOLR).
TheodorosPloumis → created an issue.
We are using the
https://www.drupal.org/project/file_entity →
module to get nested Files indexed on search_api.
This is used for files inside Drupal of course.
TheodorosPloumis → created an issue.
@hydra This is what I did. Just wanted a static patch because the one from the PR may not apply at some time.