🇧🇪Belgium @tim-diels

Hi mohamad, thanks for the quick response. Can you also add it as a (download) release (2.0.x) so we can tag the issues to the version? If you don't know what I'm talking about, just let me know. You can also ping me on slack at tim-diels

Hi mohamad, thanks for the quick response. Can you also add it as a (download) release (2.0.x) so we can tag the issues to the version? If you don't know what I'm talking about, just let me know. You can also ping me on slack at tim-diels

As mentioned in #3522879: Support Elasticsearch Connector 8.x → this will result in a breaking change and should be done in a major release.
Why is this is breaking change? We should rename the current method to msearch to match the elastic documentation and the new method should use the current search method (but changed ofcourse).

In my enthusiasm I also added the default search method. This is actually a breaking search for people extending the controller.
Therefor we should extract the method. I created a new issue for this #3523543: Add search method → .

Also the support for Elasticsearch Connector 8.0.x should be done in a major release. So can you please create a new branch for this so we can set the MR to the new branch?

tim-diels → created an issue.

Added a display widget, could use some improvement maybe as this is what I currently needed.

tim-diels → created an issue.

Added it to a MR for easier follow up. Still need to be tested.

tim-diels → made their first commit to this issue’s fork.

I'm sorry for answering so late, but can you provide a complete example on what you try to achieve so it is testable?

Ok code did not change a lot, can you point out what is still needed?

Hi Wouter, thanks for the report and the patch. Could you see if 🐛 When there's a path that is a subpath of trans_path, the getOutboundPath function messes up paths from other places Active fixes the issue? If not, you can use it as base to create a test that fails and then a fix?

Thanks a lot for this great work! Looks wonderful and tested and works as expected. Did some minor changes. Feel free to question these changes and explain why you would need them. I don't see the value of them at this moment.

Hi @steinmb, thanks for the MR, but its still in draft, so not sure if its finished? The code will change a lot with the other issue. So I'm thinking of getting back to this after the other issue has been tested and merged and see what needs to be done here? What you think?

Hi @steinmb, sorry for not being to active on this module. I've been trying to follow up on most of the modules I maintain, but most of them I did not build but got maintainer to get thing forward. I understand the frustration or irritation when things keep hanging. I'll review this module in the next days and see if I can get everything tested.

I added support for Elasticsearch Connector.

tim-diels → created an issue.

tim-diels → created an issue.

tim-diels → created an issue.

tim-diels → created an issue.

tim-diels → made their first commit to this issue’s fork.

tim-diels → created an issue.

@dhaval_panara please do not use mr diff links in your workflow. This is very dangerous! Please read https://github.com/cweagans/composer-patches/issues/347

tim-diels → changed the visibility of the branch 3366187-gin-theme-compatibility to hidden.

Found an issue when using elasticsearch to index nodes. So will need to add an extra check.

As there is no dev release, I targeted the 8.1.1 version and used the 8.x branch as thats where the latest code is added.

tim-diels → created an issue. See original summary → .

Also with the pipelines running now, there is more work to do.

I rebased both MRs but for the 2.x I rebased on the 2.3.x so that MR needs to be changed to 2.3.x instead of 2.2.x. I4m not able to do this, anyone else have this option?

Hiding the patches files as the current approach is to use MRs. There are 2 MRs that seem to solve the issue and patch from #41 looks the same as MR157.

I've tested MR156 and that provided the tokens I was looking for.

But it seems no pipelines are running? I'll rebase and see if that triggers the pipeline.

This is a big blocker for normal composer workflow. We're using this for a month now and looks like its working as expected and does not create any issues.

tim-diels → created an issue. See original summary → .

Trying to reproduce the issue in the first place, but not able to do so. Is anyone else able to reproduce this?

Added both patches in 1 MR. The MR is the latest patch from #3
Will test what msypes describes

tim-diels → made their first commit to this issue’s fork.

Pinged both maintainers on slack to see if they can have a look.

You should use context in your custom code to tell Drupal the string needs to be translated in a given context. See https://www.drupal.org/docs/7/api/localization-api/string-context →
This has nothing to do with this module I think.

Thanks for the work @sourabhsisodia_!
But as you see there is still some fine tuning needed. Would you mind picking this up again? If not, someone else can pick this up after 48 hours.

Seems to be committed in the 3.0.x branch https://git.drupalcode.org/project/field_validation/-/commit/276f386f568...

So can be closed?

I tried looking where to get the :raw token, but thats not available except for the date field or the webform module that provided their own integration.

I tracked it down to having the entity label set from the group title/label with special characters return a html encoded string. We do not need an extra plugin to get the raw value but maybe we can do htmlspecialchars_decode on the entity label set from a token?

So in the classNewEntity in the method execute we can replace the following:

if (isset($entity_keys['label']) && isset($config['label'])) {
  $values[$entity_keys['label']] = trim((string) $this->tokenService->replace($config['label'], [], ['clear' => TRUE]));
}

with

if (isset($entity_keys['label']) && isset($config['label'])) {
  $values[$entity_keys['label']] = htmlspecialchars_decode(trim((string) $this->tokenService->replace($config['label'], [], ['clear' => TRUE])));
}

This issues seems to be outdated as the Gitlab CI is now running instead of Drupal CI?

Yes the cache clearing process needs to be looked at as I have similar issues.

tim-diels → created an issue.

Created MR for 3.x based on the work done above.

@mlncn I like the suggestion you make, but it will take more time and is more complex to get this done. Maybe split that to a new feature request?

Test is failing probably because the cache is not getting cleared properly to hide the link.

But to me this also seems to be incomplete and it should however take care for individual entity types. Now its a global setting but only hiding on the admin/content page. So either have a global setting to hide it everywhere (not a fan of this) or have the setting per entity type.
So I guess this code will need some refactoring to have this as an option for every entity type.

tim-diels → changed the visibility of the branch 3.x to hidden.

tim-diels → made their first commit to this issue’s fork.

Ok then we can set this to needs review. Thanks.

Needs to be done for 2.x also.

tim-diels → created an issue.

Tested both on D10 and D11 and works.

There is however a problem that also exists in D10 already that the checkbox is not styled correctly but that has nothing to do with this MR.

Tests are failing :(

I'll update the code to fix the comments

tim-diels → made their first commit to this issue’s fork.

Can be tested once 📌 Add GitLab CI configuration Active is merged so pipelines are activated, but already provided the fixes.

Can be tested once 📌 Add GitLab CI configuration Active is merged so pipelines are activated, but already provided the fixes.

Created 2 subtasks. One for CSpell and one for PHPCS. PHPStan will solve itself when the Drupal 11 compatibility is merged.

tim-diels → created an issue.

tim-diels → created an issue.

tim-diels → created an issue.

Removed the backwards compatibility stuff as thats not needed when adding a version constraint.

Tested this both on 10.x and 11.x and words as expected.

Can we please get this committed?

tim-diels → made their first commit to this issue’s fork.

tim-diels → made their first commit to this issue’s fork.

tim-diels → created an issue.