🇫🇷France @mably

mably → created an issue.

mably → created an issue.

mably → created an issue.

@cindytwilliams could you give a try to this issue's MR?

For some reason, domain_source_form_node_form_alter is now executed before domain_access_form_node_form_alter, which causes the issue.

Ok, thanks, will have a look at it.

Was it working fine in beta4 ?

"file_validate and related functions are deprecated and replaced with file.validator service and Constraint plugins"

https://www.drupal.org/node/3363700 →

Couldn't it be fixed by this other issue's MR ? 🐛 SVG validation error Active

FYI it's also possible to use grouped filters to define custom labels.

It would be really helpful to have a reproducible scenario on a fresh Drupal installation that works with beta3 but fails with beta4.

Would be great to be able to fix that server side using a dedicated views_filters_summay_der submodule.

It doesn't look like the standard Drupal autocomplete behavior.

I have something like "My content title (my_content_id)" on my side.

Thanks @gugalamaciek!

Not sure we want to add this code to the main module.

But we could create a new views_filters_summary_custom_labels dedicated submodule for that.

mably → created an issue.

It looks like the new LoggerFactory constructor parameter added in this issue creates a circular dependency problem with some other modules: 🐛 Circular reference detected Active .

Fixed by ✨ Provide Commerce product support via a new submodule Fixed .

@cgalibar please use the plugin alias hook of the commerce submodule.

Seems related to this issue 🐛 Vimeo hash parameter on private video url RTBC .

Thanks for the review @prashant.c, let's merge this!

Hi @prashant.c, could you give a try to this issue's MR please?

And switch it to RTBC if it solves your problem.

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

I would rather say: "Won't fix" for now.

If there is a real motivation behind such a change, and if we can get a good UX/UI design for it, why not

Looks like the exposed form is accessible like this:

$exposed_form = $this->view->display_handler->getOption('exposed_form');

May be we could inject the generated HTML directly in the exposed form instead of the area.

Sounds definitely like an interesting feature to have.

We just need to find the best way to do that.

Not sure we want to do that.

Seems like a radical change from current behavior.

mably → created an issue.

3 related issues have been merged.

Let's mark this as fixed.

mably → created an issue.

Ok, thanks, let's merge it!

I guess you are using this module:

https://www.drupal.org/project/views_core_entity_reference →

Let's see what we can do about it.

We’re always open to feedback and ideas on how to improve the TocJS module.

Feel free to share!

@leipomalla feel free to send me link by DM once it's available, I'll have a look at it.

Is there a public site available somewhere so I can check was the problem is exactly?

This is a basic feature of the module, used on hundreds of sites, so pretty surprising that it doesn't work.

@sokru I finally created an extra MR in this current issue.

Could you have a look at it and tell me if it fixes your problem?

As you can see on this page, no h3 are being picked up by TocJS.

So there is most probably a problem with your configuration.

TocJs can be configured at both the node type level and the block level.

Could it be that you’re looking at the wrong configuration?

@sokru should be easily fixable. Could you create an issue for it please?

Thanks for the fix!

Just started a fresh Drupal 10.5.3 instance with Domain 2.0.0-beta3.

I’m not seeing the redirect behavior you’re describing.

As far as I know, that isn’t a standard feature of the Domain Source module.

Could you try to reproduce your problem on a fresh Drupal 10 instance please?

Otherwise, I won’t be able to help you much.

Domain Unique Path Alias is also a third party module.

Some domain-related custom code may be?

Are you using any third-party domain module?

Merged.

Let's wait a few days before releasing 3.3.0-beta1.

@gugalamaciek what module are you using for your entity reference filters?

@murz we should be ready for merge, could you have a final look?

I have to admit, Claude gave me some clues ;)

Let's merge this!

Boolean label and 2D option values have been merged.

Only the entity reference filter remaining.

Current implementation is more a "Remove all" than a "Reset", am I right?

Looks like we simply needed to replace :

$this->view->preview

By:

$this->view->live_preview

@murz can you confirm that it also fixes the problem on your side?

Created a dedicated method in case we need to add other checks.

Thanks a lot @murz for all this investigation work.

Checking the route sounds like a nice solution, let's see what we can do with that.

mably → created an issue.

Thanks @murz, sounds like an interesting improvement.

Will make a few tweaks and merge it.

You are simply using the wrong configuration setting for that.

Here is the right one:

mably → created an issue.

Ok, on my side I have been working on a separate issue for the boolean part: ✨ Use exposed label for boolean filters when labels are disabled Active .

mably → created an issue.

mably → created an issue.

mably → created an issue.

mably → created an issue.