🇪🇸Spain @omarlopesino

omarlopesino → created an issue.

I confirm that Scala returns the context as it is , but the problem is that the returned json by the formatter is a plain text of the json, and not the json decoded.

Then, in the GraphQL view, instead of returning

"myJsonField": {
"foo": "bar"
}

it returns:

"myJsonField": "\<code>{\r\n  \"foo\": \"bar\"\r\n}\</co..>"

This MR allows recognizing this specific case and do the conversion.

The MR fixes the problem. it just fixes the parenthesis so each empty call is separated. Please review, thanks!

omarlopesino → created an issue.

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

All the warnings reported by static analysis have been fixed, which led to some small refactors. It should preserve the old behaviour. Please review, thanks!

I agree that would be a definitive solution. In the meanwhile, a patch generated from this MR can be used to be able to view status report in sites using xray audit but not using paragraphs.

Ups my bad, I didn't check the submodules. This is already supported by the graphql comments submodule, thanks for letting me know.

Would it be good idea supporting the rest of fields of the comment entity type? I mean, the entity_id, entity_type, field_name , and pid.

I've updated the MR updating the Comment GraphQLEntityType plugin with those fields.

The MR solves the problem for me, please consider reviewing and merging, thanks!

omarlopesino → created an issue.

MR created. Please review, thanks!

omarlopesino → created an issue.

Created MR. Please review, thanks!

omarlopesino → created an issue.

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

Created MR. PLease review, thanks!

omarlopesino → created an issue.

I've just added a commit that ensures there is a field that sets which are the allowed query tags, so if a query tag is passed dinamically, it does not add unwanted query tags.

Please review, if it looks good I can add tests.

Agree with #5. Closing this issue in favor of https://www.drupal.org/project/graphql/issues/3491736 🐛 Cache collision when multiple servers are using the same schema plugin Active , which already applies fixes detected at this issue.

Merge request re-rolled. Tests are passing now. Ready to review again.

I've just adapted the tests to the new functionality, ready to review again.

I find this issue pretty useful for my use case. I want to build an API and having generic mutations helps a lot to get all the job done.

Don't mind me adding to the MR some improvements:

- Retrieve uuid in generic entity queries.
- Allow reading graphql compose configuration to use the same field names than in the rest of graphql queries.

I have created a MR with the proposed resolution, please consider reviewing and merging it into the module. Thanks!

omarlopesino → created an issue.

Gitlab CI tests added. No phpcs/phpstan errors found :) just a minor cspell error that is just fixed in the MR.

Please review, thanks!

I've just seen in this commit the compatibility with Drupal 11 is added: https://git.drupalcode.org/issue/group_term-3507121/-/commit/8997937bb25...

Adding a .gitlab-ci.yml file so that it is possible confirm compatibility with Drupal 11 through tests / static analysis.

omarlopesino → created an issue.

About this issue, I am aware of this problem, and we have this important problem if we fix it: If we release a new version changing the module name, the sites using this module would break. It is true that uninstalling the site , updating the module, and reinstalling it would fix it, but having to reconfigure an entire module should be avoided. Any ideas to deal with this problem?

Patch from #2 is empty. Is it possible that you have renamed it but the patch haven't been generated correctly?

I suggest you following these instructions → or use Drupal GItalb repositories → to create a merge request.

I notices too late about this issue :/ and I don't know if my answer will be useful as possibly the root problem is fixed somehow. However, I will reply in case this is needed for future use cases.

The To field is the same field used at the standasrd Webform email handler, as you mention it must be filled with either the manual list of emails or a token.

To add subscribers dynamically, it is needed to code it as it is not possible to dynamically get them out of the box. There are two possible solutions that needs to be evaluated:

1. In a custom module, implement hook_token_info and hook_tokens to provide a token with the list of subscriber emails, separated by comma.
2. If the subscribers are saved through a contributed module that manage newsletter subscriptions, a submodule into webform entity email can be created.

This has been released releases ago, but forgot to move the issue to 'Fixed'.

LGTM. Added to merge train, and it will be released in alpha14

Currently we are using select queries → , which already supports database prefixing, as they are automatically added by Drupal API.

If your wordpress database has a database prefix, it should be declared at database definition at settings.php (or other settings file) .

Example:

$databases['legacy']['default'] = [
  'database' => 'legacy',
  'username' => 'db',
  'password' => 'db',
  'prefix' => 'elem_',
  'host' => $host,
  'port' => $port,
  'driver' => $driver,
];

This example adds the 'prefix' => 'elem_', property to let Drupal nows the database prefix on queries. This should fix the issue. Indeed, I had to do this on my project to make it works with a wordpress site that has database prefixes.

Let me know if that fixes the problem for you.

Marking task as Needs review in the meanwhile.

Released at 1.0.1

I've merged and there were no issues. Released at 1.0.1

Merged and released at 1.1.9. Now the module is fully compatible with Drupal 11.

The tests fails, I guess because Salesforce module was not yet compatible with 11, but now it is compatible.

Thanks for noticing this! This change will prevent false positives / negatives. Merging. It will be released at 1.0.1

Released at 2.0.2

Released at 2.0.2

Released at 2.0.2. Thanks!

After reviewing it looks good to me. For a moment I have thought on what happens with this requesst as it is paged. and I've ensured that is possible to add pager arguments through the query.

It will be released at 2.0.2

Released at 1.0.0-alpha13

Released at 1.1.1

Thanks, I've just commited this into the main branch and it will be released at 2.0.2

It looks good to me, thanks for fix the method so we get the correct WordPress term ids!

PHPunit tests fails after adapting the code to Drupal 11. It is needed reviewing what is happening and fix it.

After reviewing everything is enough okay. Version 2.0.0 has been released and now the module is stable.

Release candidate created. After reviewing a stable version will be created, probably on Monday.

1.2.1 is compatible with 11

Drupal 11 compatibility changes have been merged and released at 1.0.1

The MR build is failing.

This module has been refactored in 2.x version and currently there is no support for the development version.

THe version 2.x will support the latest Drupal version.

Most of the steps are done, the pending points are adding the status report , RC, review and create the stable version :)

Working on it.

omarlopesino → created an issue.

Sure! It is not possible contacting them through Drupal (they do not allow be contacted directly from drupal.org). I've sent a direct message through drupal.org Slack. Hopefully they respond.

I have tested it on my site and I confirm the ajax block form can be properly configured in Drupal 11. Thanks!

omarlopesino → created an issue.

I wonder if this module should use plugins to support the different purger types, so this escalates better.

This issue is really interesting, thanks for the contribution @kevinb623 . Supporting queues may drastically improve the performance when there are too many URLs to purge.

Also many thanks for helping reviewing @dpi, it saved me time.

The most priority changes needed to merge this are:

1. Make form labels translatable
2. Hook install to configure existing sites.
3. Coding standards must pass, Currently, this module is integrated with Gitlab CI to help on this purpose.
4. Ideally, applying every suggestion mentioned in the feedback.

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

Thanks for all your feedback.

I agree that ¡ purging additional URLs than the self URL is out of the main purpose of this module. However, it is a good idea start giving support to it as purging image style URLS is consequent to purging the original file URL. Removing only the original file may leave the files cache inconsistent (older image in not purged image styles, new image in new image styles).

I agree with the solutions proposed at #6. My only doubt is how to separate image style logic from 'purge file' logic. A submodule looks good, but most sites uses image styles. Maybe we can separate the logic by dispatching a hook that lets adding more paths based on the current file. What do you think?

Released at 1.1.2, Please note my comment in #5 in case it might affect sites already using the patch.

The changes looks good for the needed use case (dynamic base URLs).

I've added a change to prevent main base URL to not be removed when URLs are altered: https://git.drupalcode.org/project/purge_file/-/merge_requests/7/diffs?c...

Merging and releasing.

Thanks! Gitlab CI integration has been released at 1.1.1 version.

Drupal 11 compatibility changes have been released at 1.1.1 version.

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

Hi. Many thanks for offering as a co-maintainer!

I've just merged the automated bot Drupal 11 minimal adaptations and it seems to be enough. However, I agree adapting to new Drupal features that are only available in newer versions.

Hope you don't mind me asking you to open an issue and with a merge request with those improvements that uses Drupal 10.3+ new features? After seeing everything is ok, I would add you as a co-maintainer so you are free to release.

I've just created a 2.x branch for this purpose.

omarlopesino → created an issue.

The MR works fine into my site (Drupal 11). I've updated the MR thinking that the MR needs reroll, but i guess it is for the D7 patch, not the MR.

I've noticed that for example, when I create a newsletter issue, and I send it, if I create a translation, I can't send the translation of that content. This implies that if I want to send a newsletter in multiple languages, I need to create every translation before sending it.

Could it be good idea to re-queue the newsletter when a translation is created?

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

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

Released at 1.0.4

After integrating the last issues this problem has been fixed, sorry for not noticing before. Thank you!

Looks good to me. It will be ready at 1.2.0

Looks good to me. It will be ready at 1.2.0

Looks good to me. It will be ready at 1.2.0

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

MR fixing the problem, please review!

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

It breaks in Drupal 11.1 because it does not have the function layout_builder_at_form_entity_form_display_edit_form_alter anymore, which is used by this module.

Please check this patch that adds backwards compatibility among different Drupal versions. if you see it ok, we can add it to the bot merge request.