🇧🇪Belgium @StryKaizer

Thx!

Is this still relevant in Facets 3.x?
I think this got fixed in 📌 Always show active facet items Active

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

Do we really need to change all code?
Looks like changing the function to
public function getCount(): ?string {
should suffice.

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

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

Please use search before creating new issues.
https://www.drupal.org/project/facets/issues/3502922 📌 Fix PHPCS issues reported on CI/gitlab Active

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

strykaizer → created an issue.

RestIntegrationTest seems to randomly fail (sometimes green, most times not).

For now, disabled this test so all our pipelines are still working. We need to look into this

In Facets 3 we removed all ajax support for facets as blocks, see 🐛 Facets breaks all AJAX views that uses pagers even without facets Active

You can use Facets Exposed Filters if you need AJAX support, which uses GET requests.

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

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

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

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

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

strykaizer → created an issue.

Facets exposed filters now supports attachments and error is fixed

This is fixed for facets exposed filters in 🐛 Error when adding new display to view Active

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

This is a patch against core views, not facets.

Not sure if we can fix the issue in facets itself, or if a core patch is required?

Every filter in views is by default a
item.
We need to use this type to pass our data to views. in
items can not contain markup, so we can not pass this to views.

Better exposed filters turn
items in other types (links, radios, ...)
So adding markup can only happen in Better Exposed Filters depending on which Better Exposed Filter widget type you are using.

tldr: this can only be added in Better Exposed Filter widgets, not in Facets exposed filters.

I looked into views_pretty_paths, but lack the time rewriting this to a global solution
So I changed mind about #13 , lets just support this feature in facets_pretty_paths.

I like how this patch only works when ajax is disabled, which is great, as ajax enabled views should use the GET params instead.

Thanks for contributing all!

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

strykaizer → created an issue.

MR created, needs review

mcdruid → credited strykaizer → .

Facets pretty paths will stay available for users using Facets 3 with Facet entities (Facets as a block), and Facets 2 users.

However, the recommended way in Facets 3 is now to use "Facets Exposed Filters".
People using "Facets Exposed Filters" will not need this module anymore in the future.

I updated the project summary to clarify. Thx!

Great work,

However, in Facets 3, we are now avoiding to do custom, not facet-related, features anymore.
This is another example of something we should offload to a more global solution, which works for every views exposed filter (not only facets, and not only search-api-based views).

That is why my preferred solution is fixing this in "Views Pretty Paths module" (similar to how we also moved the functionality from "Facets summary" to "Views Exposed Filters Summary", which benefits everyone).

I understand that "Views Pretty Paths module" does not (yet) support the coders plugin system. We should probably contribute that part too in that module.

But for people who need this functionality now: feel free to use the patch above.
The "facets summary" module will probably not change much anymore, as we are focusing on global solutions. So the patch should be working for a long time without too much re-rolls ;-)

@finex: see https://www.drupal.org/docs/develop/using-composer/using-the-drupal-leni... →
which allows you to install modules which are not yet updated and apply patches to them.

But a release would be nice indeed ;)

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

Adding this behaviour as a setting would be really nice!

MR pushed

Documentation on how to use these configactions in recipes:

config:
  actions:
    core.entity_view_display.node.*.full:

      # Basic example on how to restrict blocks.
      entityViewModeRestrictionAppendRestrictedBlocks:
        blocks:
          'Inline blocks':
            - 'inline_block:text'

      # Basic example on how to allow blocks.
      entityViewModeRestrictionAppendAllowedBlocks:
        blocks:
          'Inline blocks':
            - 'inline_block:image'

      # Example on how to allow by region.
      entityViewModeRestrictionByRegionAppendAllowedBlocks:
        - layouts:
            - one_column
            - two_column
          regions:
            - footer
            - header
          blocks:
            'Inline blocks':
              - 'inline_block:text'

      # Example on how to restrict by region.
      entityViewModeRestrictionByRegionAppendRestrictedBlocks:
        - layouts:
            - three_column
          regions:
            - footer
            - header
          blocks:
            'Inline blocks':
              - 'inline_block:text'

strykaizer → created an issue.

It should defenitly be possible.
Instead of looping over existing facets, is should loop over existing exposed filters of a selected view.

Atm a bit busy, but I dont mind contributing in the future

strykaizer → created an issue.

strykaizer → created an issue.

Fix attached for D11

Facets + Blocks is not supported in Facets 3, and no patches for it will be accepted in Facets 3.
Blocks are still supported, but without ajax.

In Facets 3, use "Facets exposed filters" which has 100% ajax support, or stay on Facets 2 if you want blocks + ajax support.

"Facets exposed filters" focusses on the actual Facets parts (the filter itself), while offloading url-generation, widget generation, form placement etc. to views. One of the many advantages for this is 100% ajax support.

Facets 2 on the other hand had a lot of AJAX related issues, since the Facets module was handling all things mentioned above in its own way.

Attached is correct patch.
Remember to apply 3076448 patch from comment 59 first, else this will not apply.

Fixed patch

Thx!

Duplicate from 3459371

I'm not using this module myself.
Let me know if this module has any advantages which entity_ref_filtering_link does not have, so I can help out supporting them.
I will probably contribute them to entity_ref_filtering_link though, as I want people to use modules focusing on the entire views ecosystem, not facets specific.

Facets used to do too much (widget handling, url handling, summary handling, ajax handling, ....)
Since 3.x exposed filters, this all moved to views, which has a lot of advantages.
Everything works for every filter, not just facets filters.
Ajax works, Site builder ux improved, ...

This module might become obsolete by that reasoning. (As facets_summary and some others did too).

Facets are now not a special usecase anymore, and are just a views exposed filter as any other views exposed filter.

This has the advantage that every solution works for all exposed filters, not only facets (e.g. views_filters_summary, better_exposed_filters, url handling thus ajax working, ...)

Since Entity Reference Facet Link uses the old system, that wont work anymore indeed.
There might be solutions which already fix this for all exposed filters, which should also work for facets (see entity_ref_filtering_link)
If not, let me know what is missing, so I might be able to help creating it.

I'm not a fan of supporting facet-specific modules anymore which shouldn't be facet-specific.
If we can write them more agnostic, it benefits all usecases.

Pushed branch fixes this issue by not altering (nor wrapping) urls with data-embed-url.
This allows to use core "Convert URLs into links" filter triggering after this filter without issues.

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

You can reproduce this by enabling a module which needs the canonical url, e.g. responsive_preview

What a difficult decision — this is truly an impressive lineup!

- Joris Vercammen (borisson_)
- Montaña Franco (mon_franco)

We discussed this issue at Drupal Dev Days (Me/WannesDR/Lendude).

One thing Lendude mentioned is: there are people explicitly using "views exposed forms as block" to ensure their forms are not getting refreshed by AJAX.
To keep this backwards compatible, we suggested introducing a setting to toggle the behavior.
For existing views, the default behavior should stay as is.
For new views, the default behavior can be "update the form with AJAX".

I'd suggest pushing 🐛 Ajax exposed filters not working for multiple instances of the same Views block placed on one page Needs work first, which only focuses on replacing the ID and using a data attribute as selector for the AJAX command.

Once that issue lands, we can focus on actually replacing the "views exposed form as a block", keeping the backwards compatibility setting in mind.

3163299-views-multiple-ajax-exposed-filters-11.x is a rework of 3163299-views-multiple-ajax-exposed-filters-10.3 which fixes the test and codestyle.

This patch does not include (optional) replacing of the exposed form for e.g. Facets 3.
I'd suggest to keep this patch focussed on replacing the form ID + using a data attribute as selector for AJAX (instead of an ID)
and fix "optionally replace exposed filters in block form" in a follow up.

Good! It looks like this feature only needs tests now.

We discussed this issue at dev days with Lendude & Wannesdr.

For ajax updates of exposed forms, which is required for e.g. Facets 3 users, we need ajax enabled exposed forms exposed in a block to update the form(s) too.
However, some users' usecase is that they explicitly use "expose form in block" to prevent the form from updating, which is the current behaviour.
That's why we suggest introducing an extra setting, only visible when "expose form in block" is set to "yes", which allows users to choose how the block form should behave (update or do not update on form submit). For existing views, we keep the old behaviour as default value.

@laura.j.johnson@gmail.com

I tried reproducing the media browser issue in vanilla core + layout builder, but I could not reproduce this.
It might be a Gin LB specific issue, which I did not test. If so, gin_lb seems to be the appropriate place to fix this issue.

underscores issue addressed.
Still needs tests

Hi,

Can you confirm that you are using "facets exposed filters", and that your facets are placed in the Views UI, as exposed filters?
It looks like you are still using the old "facets as block" method, which is not supported for this usecase.

You can find more info on how to use the new Facets 3 workflow overhere: https://project.pages.drupalcode.org/facets/exposed_filters/

+1 for this.

I'd also suggest adding extra info to the form-item "Adhoc email addresses" that these emails gets validated against existing users, if the checkbox from this feature is not checked. This is not clear and for non-tech users this might be difficult to find out :-)

Update hook + config schema added.

Feature pushed in branch. Needs review
For now, works for radios/checkboxes widget and links widget.

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