How to manually pass an argument to a views block through interface

I had a similar question and i delved into ctools_views module, it's realize 'content pane' views page and 'arguments input' . Feature what are you looking for is not ready or deprecated(?).
At this moment, this way is works for me.
https://drupal.stackexchange.com/questions/206433/drupal-8-page-manager-and-panels-contextual-filters-for-views-block
Will be glad to read comments from module maintainers, where is the road map of development? I'm think about help to contribute.

I created a patch for ctools_views submodule that adds the "Contextual Filters" setting in the "Allow settings" block option that allows to pass arguments from Panels.

@marto87, many thanks for your contribution.

Because it is a large patch, It would help reviewers with the patch if you could provide additional context and explanation. I realize you have included comments inline, but perhaps an overview here would be useful to get started with?

It would also be very much appreciated if you could include or modify simpletests for the code.

@rivimey, this patch allows to pass static arguments from Panels to views blocks, setting them in their corresponding block options form. It shows as much text inputs as contextual filters added in the views block, you can set static parameters for each one. Then that parameters are passed as arguments to their corresponding views block when building the page.

This is useful if you want to reuse the same views block in a single page to show different data filtered by an argument, not the url.

Thanks for the patch! I tried testing but wasn't sure how to configure. I didn't see any new options in my views contextual filters or in the views block I had placed in a region with page manager (using both block type variant and panels variant). Even configuring the block via core blocks placement doesn't show the views contextual filters. Please provide steps for testing. I did do a quick look at the code and only noticed very minor nitpicks but I can't say I grok all the code. Thanks.

1. +++ b/modules/ctools_views/src/Plugin/Display/Block.php
   @@ -53,6 +54,9 @@ class Block extends CoreBlock {
   +
   

   Nitpick: Extra space.

2. +++ b/modules/ctools_views/src/Plugin/Display/Block.php
   @@ -53,6 +54,9 @@ class Block extends CoreBlock {
   +
   

   Nitpick: Extra space.

3. +++ b/modules/ctools_views/src/Plugin/Display/Block.php
   @@ -184,6 +188,36 @@ class Block extends CoreBlock {
   +
   

   Nitpick: Extra line.

4. +++ b/modules/ctools_views/src/Plugin/Display/Block.php
   @@ -283,6 +317,27 @@ class Block extends CoreBlock {
   +
   

   Nitpick: Extra line.

5. +++ b/modules/ctools_views/src/Plugin/Display/Block.php
   @@ -362,6 +417,17 @@ class Block extends CoreBlock {
   +      for ($i=0; $i < count($arguments); $i++) {
   

   Nitpick: $i=0 => $i = 0

This is a duplicate of #2287073: Allow views contextual filters to expose the context using argument validation plugins. Please review the patch which is available in this issue.

Just in case someone is using this patch i updated it with additional checks for empty argument values.

This is not duplicate because if someone using ctools_views - block is different and 8.3 still not released

This is not duplicate because if someone using ctools_views - block is different and 8.3 still not released

Woops, it seems I need another revisit on this kind of blockception :D
Thanks for the correction and sorry for the confusion.

Added test for patch in #10. We are using this patch in a project and it is working fine for us.

Thank you for the patch! I have added the test patch in #10. I am not sure if I am configuring this correctly. I have a block view which has contextual filter of Content: Has taxonomy term ID. The settings are:
Filter value is not available -> Show "No results found"
Filter value is available is set to Specify validation is set to Taxonomy term ID
Contextual filters is selected under Block settings, Allow settings and the Block configuration form for the view allows me to enter a term id as a contextual filter.
However, this seems to have no effect.
I am using Ctools 8.x-3.0+2-dev on 8.3.4. I am not using Panels. Is Panels perhaps a requirement?

I tested the patch in #10 and it did not work.

The patch sets the contextual filter values correct, but they get overwritten by views which takes empty values from the environment.

I created a patch working for my case as well as a interdiff to the patch from #10.

Unfortunately, neither #10 nor #14 patch worked for me, the passed value just don't arrive to the views in my case.

See #2886116-2: Passing a value into a views contextual filter from a block field for an example of how to use the functionality added to core in #2287073: Allow views contextual filters to expose the context using argument validation plugins to pass values from a block to a contextual filter. At this time, you can pass a value from a context such as the URL, but you cannot do what this issue aims at: pass a specified value such as a string or integer.

However, the latter is possible through Page Manager. See #2769791-6: How to pass context parameters into blocks added to a panel page for an example of that.

Overall, it doesn't seem worthwhile to continue in the direction this patch is headed, since it will lead to duplicated UI on block configuration forms--one from core, one from ctools. (This is, by the way, what's currently happening with Page Manager--so with ctools there could be three sets of UI elements....)

Still not able to get this working in 8.4.x. Commented on the issue from #17. Still need a clear example of how to do this via Page Manager or something.

Also, just selecting a hard-coded string context is not the user experience we are looking for. In the IPE when adding a View Block, we want the content editor to enter the value of the filter.

In our case, the view normally has a "&type=content-type" query string in the URL. We want to pass this value from the Block config when the editor added the view block to the page. Seems annoying to require a hardcoded string context added to the panel page for each content type...we just want a string field to enter a value (otherwise it doesn't work when adding new content types to the system).

I think we need a plan for a consolidated way to achieve this functionality that we had in D7 and is missing in D8. Passing arguments to a View Block seems like a pretty basic need.

i am passing arguments to blocks using the following method (from views UI)

add a contextual filter.
when the filter is not available

either

provide default value
type:raw value from URL
select path component

or

content ID from URL.

I want a string field to enter a value too. It is worthwhile to continue in the direction this patch is headed because it is trying to provide functionality that none of the other options provide.

We can't teach our customers how to use page manager, but panelizer / layout builder with its little roll up at the bottom is perfect. I just want to let them drop in a view that shows for example a single article teaser with a text box for them to enter the article's ID without overwhelming them with extra options and steps and technicalities.

Creating a block type for this and having them create a new custom block entity for each one is not the same thing either. We have reusable custom blocks too and having them do it that way would clutter up that list with endlessly created custom blocks.

I agree this is a basic need.

#15 seems to be working for my use case. The empty dropdown version of the same field is still present but I expect it will be easy to hide.

Maybe I am not getting something about this whole thing. Even for powerful megadevs... How is having to use page manager and being able to inject a custom context into a dropdown to use on a different admin page supposed to be more useful than this text box? Isn't this more efficient in the system and for working with it?

#15 Works finde for me!
Couldn't we not just bring this in the module and improve further if necessary? ;)

Love this patch however when i add a TID to a view as a contextual filter then i override that in the block config then visit the page patch in #14 fails with this error.

Drupal\Component\Plugin\Exception\ContextException: The tid context is not a valid context. in Drupal\Component\Plugin\ContextAwarePluginBase->getContextDefinition() (line 79 of /app/docroot/core/lib/Drupal/Component/Plugin/ContextAwarePluginBase.php).

rerolled the patch from #10 that did not cause this error. However it still was not overriding the arguments in the rendered view. Added $this->view->build(); after changing the arguments to force the view to rebuild with the new augments fixes all that for me.

Another reroll as https://www.drupal.org/project/ctools/issues/2820783 is effecting this as well. Patch updated to include patch from #2820783 as well as adjustment with new option.

Thanks for all the work here. I closed #2769791: How to pass context parameters into blocks added to a panel page from panels in favor of this approach, since it will benefit from it as well. This is an important feature to have IMO. If we could get this in and then add the ability to pass tokens that would get us really close to the panels + content pane experience of D7 that's so powerful.

Here's an update to #25 that works with token replacement. I don't want to delay #25 if this adds too much, but wanted to share.

+++ b/modules/ctools_views/src/Plugin/Display/Block.php
@@ -423,15 +423,20 @@
+        $token = \Drupal::getContainer()->get('token');

@@ -515,2 +520,33 @@
+    $context_service = \Drupal::getContainer()->get('context.repository');

That should use \Drupal::token() and \Drupal::service('context.repository')

Thanks for the feedback Andy.

Update patch to work with released ctools 8.x-3.1.

Fix issue with applying patch.

The patch on # 32 no longer applies ... it needs to be changed

I rerolled the patch from #32 to be applicable to the latest dev version.

There was an issue with the "Items per page" option at the previous patch. I rerolled it again to fix this issue.

I uploaded the first patch that allows passing arguments from Panels to block views in this issue in comment #4 when there was no way to do this and just like @nedjo said in #17, the functionality is now implemented in core. I think this patch is no longer necessary, we upgraded our site and we no longer use it.

I'm not sure it covers the use case that this patch does. @nedjo's example points to a views config that pulls the contextual filter from the URL and it bypasses page manager (or layout builder for that matter). What this patch allows you to do is place a block on the page and then set the context that you want to pass relative to the placement. This is important because the same view display can be used across multiple pages when the URL parameters are not consistent.

For example, if you have a views block that expects a taxonomy term id contextual filter... You could pass it from a node's field value (via tokens) on a node page or from the page's term context when viewing a taxonomy term page. In the examples, provided this would require 2 view displays with separate contextual filter configs.

In the Page Manger example, I had a hard time implementing this because of the context type validation that happens when loading the UI. If the exact match context type, is not available, you can't pass the value.

IMO, this patch brings us much closer to the things you were able to do with passing context in D7 page manger/panels and it works with any UI for dropping views blocks in a layout.

If I'm not following you or you have ways to make this happen without the patch, definitely let me know!

I am trying to apply this patch, but are not sure how.
I tried

 "drupal/ctools": {
                "Manually pass an argument to a views block through interface": "https://www.drupal.org/files/issues/2019-03-28/ctools_views-pass_arguments_to_viewsblock-2759445-37.patch"
            },

and

 "drupal/ctools_views": {
                "Manually pass an argument to a views block through interface": "https://www.drupal.org/files/issues/2019-03-28/ctools_views-pass_arguments_to_viewsblock-2759445-37.patch"
            },

under "patches" in the composer.json.
Neither worked.

You can apply this patch to the *current* dev version of ctools:

cd docroot/modules/contrib
rm -rf ctools
git clone https://git.drupalcode.org/project/ctools.git
wget  https://www.drupal.org/files/issues/2019-03-28/ctools_views-pass_arguments_to_viewsblock-2759445-37.patch
cd ctools
patch -p1 < ../ctools_views-pass_arguments_to_viewsblock-2759445-37.patch

But I still haven't figured out if it even applies to my use case of needing to pass a term from the currently loaded node page to the embedded views block configured on the same page.

Hey @harry slaughter,

If you're on a taxonomy route (e.g. taxonomy/term/911) you can apply the patch from #2998826: Term route context and then pass `[term:name]` or `[term:tid]` tokens when adding the block to your layout.

If you're on a node page, look at admin > help > token and determine the token to get from the current node to the entity id value that you need. Maybe something like `[node:field_my_term:0:id]` (just guessing there).

@andyg5000 thanks for the reply. Unfortunately I'm dealing with a 'node/123' route. That node will have a term id I'd like to pass to the views block that's on the same node page. I expected that creating a node->taxonomy relationship and then adding a views filter that used that relationship could do the trick, but that doesn't seem to work.

I'm still unclear what the use case is for this current patch.

My primary use case for this patch is being able to have dynamic views blocks (with contextual filters) that can be placed without having to depend on a specific route. The same view can be used on a node, term, or other route as long as the contextual filter is resolvable from a token.

If you don't have this requirement, and you can build your view to use the contextual filters witth context from the node route, then you don't need this patch.

andyg, I'm pretty sure we're talking about the same thing. But what I'm confused on is: "as long as the contextual filter is resolvable from a token".

AFAIK, contextual filters are limited to filtering based on current path/route, Authed user properties, and some more obscure bits. Where do tokens play a part here?

And TYVM for the patch btw. It's adding the term id filter to my block config page, but there are no values populated.

This is a screenshot from layout builder that hopefully clear up the confusion. I can use the same view block on a node or a term page just by changing the token value passed to the view. `[node:field_primary_tag:entity:tid]` in this instance, or `[term:tid]` if in the context of a taxonomy term page. I can also just hardcode the tid if I want on any page. Without this, you'd have to build 2 view displays with their own contextual filter config. One for nodes, one for terms, etc... This site has a ton of views, so re-use is huge :)

Awesome response.

The missing link here for me was that we're currently using panelizer, so the tokens don't come into play.

As I understand it, layout manager is the generally preferred method of content layout, so maybe I can use this as an excuse to move us to layout manager.

Thanks

I tried patch on #37 and it provides the expected UI changes in both Views UI and Blocks UI.
I enabled the ctools_views module.

Now, whenever I try to access pages with the block in them I get:

Uncaught PHP Exception Symfony\Component\Routing\Exception\InvalidParameterException: "Parameter "taxonomy_
term" for route "entity.taxonomy_term.canonical" must match "[^/]++" ("" given) to generate a corresponding URL." at core/lib/Drupal/Core/Routing/UrlGenerator.php line 204

I really can't think how this is connected, but things break when I apply the patch.

Also tried #37 after i applied another important patch making "exposed filters" config avaliable. I did not succeed.
#2657060: Add Configure Filter functionality to block views configuration.
I applied it by hand. No special error but saving the block does not work. Loop forever.

I applied it to the latest dev only. That works. Tried it with an exposed node id context, works.
Also works if you add multiple node ids like 307+256

Previous patch didn't apply against 8.x-3.2 branch, I adjusted it a bit against recent module changes & rerolled.

Patch Failed to Apply

1. The patch is for 8.x-3.2 version, I can't choose it in versions, so I guess 8.x-3.x already has fresh changes on top of it,

   On our project patch applies properly for 8.3.2:

   Gathering patches for root package.
   Gathering patches for dependencies. This might take a minute.
   - Installing drupal/ctools (3.2.0): Loading from cache
   - Applying patches for drupal/ctools
   https://www.drupal.org/files/issues/2020-01-14/ctools_views-pass_argumen... (Expose contextual filter & other settings to block UI)
   https://www.drupal.org/files/issues/2020-01-20/3107484-ajax-calls-miss-o... (Ajax calls do not respect overriden through block UI views changes)

2. Btw, as was tested by me - the patch (current implementation) has issues with ajax facets & views ajax calls (pager, filters etc), they don't respect the overridden changes at all, so Ive created related issue & uploaded a rough patch there to fix it for our layout builder related case (see issue description for more details) : https://www.drupal.org/project/ctools/issues/3107484#comment-13428569

Can anyone tell me the steps I need to get this working with Layout Builder?

I'm using Drupal core 8.8.1 and ctools 8.x-3.2. I've applied the patch from #50. I've enabled ctools, ctools_views and ctools_block modules and cleared caches. When editing a block placed via Layout Builder I do not see the extra field as shown in #46.

@maskedjellybean you have to enable allowed fields on the middle views settings column (select the fields you want to override).

@Pavel Ruban thanks! It works!

A couple questions/thoughts. This is how my form looks now:

1. Is there a way we could ensure that the Override Title field appears after the Display Title field?
2. For my use case this form is going to be accessible to the client/content editor. The default field label is not very intuitive. Just a thought, and I have no idea how difficult this would be, but what if within the middle views settings column, we were able to override the default field label and set a custom one? Additionally, setting a field description would be very helpful. I'm aware I can alter the label and add a description with a hook_form_alter(), but I imagine now that we have Layout Builder there will be many people looking to expose this form to content editors and writing code for every view block could get tedious.

I tried to use the solution of #53, but the allowed options not appear in the view... Only Items x page...

Seems lie the method of the Block class of ctools_views block.php aren't never executed.

Created a new patch for latest version

Needed a re-roll and was bug with the for loop in #58. If we get approval of this technique from a maintainer, we can write tests.

There is a problem in the patch in the following lines:

if (!empty($args)) {
     $this->view->setArguments($args);
     // Force the arguments to take.
     $this->view->build();
   }

Forcing the view to build means that every step after that in the method is not taken into consideration. You can test with disable filters and configure sorts - they are not working, because they are set after the build() method.
If it's necessary to invoke build() to the view in order to apply the arguments, I suggest that this should happen at the bottom of the method, after all view adjustments take place.

Good day,

I have been trying to make this work with the last patch, not sure if it has something to do with drupal version here is my configurarion

Drupal 8.9.1
Ctools 8.x-3.4

Modules enabled Ctools, Ctools Views and Ctools Block. And applied the patch in #60

Unfortunatelly in the middle views settings column the new options doesn't show up, only the "Items per Page" checkbox is shown.

Can you please give me some advise?

Regards,

Julian Mancera

Marking needs work due to the comments from #61. I'm using this in one of my projects but don't have those constraints. However, we don't want to commit it until that is fixed in the patch.

Hi all,

I made a clean drupal install and following the instrucctions and the patch works fine, debugging my preinstalled site to check what module is causing the issue.

Regards,

Julian Mancera

@julianmancera: quoting @sam152 from #3077402-3: Declare an incompatibility with ctools_views:

Yeah, they use the same approach to customising the block settings. Not really sure there is a reasonable way around that beyond declaring the incompatibility.

There are also other modules like views_exposed_filter_blocks that use this approach and are incompatible.

Hi @anruether,

Thank you for pointing me in the right direction, the module that was causing was the views_exposed_filter_blocks. I just submitted an issue to the project with a patch in case is usefull =) .

https://www.drupal.org/project/views_block_filter_block/issues/3163140#c...

Regards

Julian Mancera

I think this is the correct status as per comments in 63 and 61.

I'm using the patch from #60 and it works pretty well, but I just noticed that the argument is ignored after clearing an exposed filter in an ajax-enabled view. In my case, I'm placing the block via Layout Builder.

Steps to Reproduce

1. Create a content view block showing nodes that have two entity ref taxonomy fields (using different taxonomies)
2. Enable Ajax for the view
3. Add a contextual filter for one of the taxonomy ref fields
4. Under Allow Settings, enable contextual filters
5. Add an exposed filter for the other taxonomy ref field
6. Place the block on a page using Layout builder or block admin - add the tid of one of the terms in the taxonomy you referenced in step 3
7. Make sure you have published content that has their tax ref fields populated - make sure some content is tagged with the term that corresponds to the tid in the previous step and that some content is not tagged with that term. Also make sure some content is tagged using the other taxonomy
8. Go to the page with the view on it - it will show just the nodes tagged with the tid from step 6
9. Filter on a term using the exposed filter - it will correctly narrow down the results
10. Clear the exposed filter (in my case they are checkboxes so I uncheck my previous selection)
11. Note that now the results are showing all published nodes - it is ignoring the argument I configured in step 6

Hey Everyone,

Regarding #61: We're up against logic in Drupal\views\Plugin\Block\ViewsBlock::build() that forces the setting of views arguments to the default action (ignore/all) or the value as available from context. To get this patch added cleanly, I think we'd have to work with core to allow the arguments to be set in our preBlockBuild() method. It seems calling $this->view->build(); is the hack that this patch has used to bypass this limitation. I'll post a patch that moves that call to the end of preBuildBlock() shortly, but would like to hear from others on how to deal with the issue above.

Another option might be to replace/decorate the views_block Block Plugin whenever arguments are enabled in our settings.

Core logic : https://git.drupalcode.org/project/drupal/-/blob/9.2.x/core/modules/view...

Here's an update to the patch that makes the suggestions from #61. I'm leaving as needs work until I hear some feedback on #70.

The patch also includes fixes to formatting and a check of $context->hasContextValue() to prevent errors with missing context values.

Just in case someone is using this patch i updated it with additional checks for empty argument values.

What was the point for the check? If someone passes an empty argument through UI it won't be ignored but rather replaced by the next available argument. That will mess the result.

It's great we can pass arguments to views blocks via config (thank you!), but it would be nice if the Admin Label for the argument was used as the input field's label (when provided), rather than the plugin ids which are kind of scary...

I'm uploading a patch that does this.

Possibly my use case is wrong for the work being done here?

- view 1: fields from a bundle (Event), contextual filter set as content id from url, with a bit of playing and enabling/disabling modules i got "context filters" to show up in Allow settings
- for Teaser view mode of Event, i use layout builder and add block from view 1
- view 2: list of teasers of type Event

in LB i now have option to pass in nid as contextual filter. If i set as a static value then my list of teasers returns all the results as the same node/event - which makes sense.

if i set nid in LB as [node:nid] i get nothing.

Is the issue that i have the wrong token or that the teaser in LB doesnt know context of which node that teaser is for (was hoping that's the whole point of this work).

hmm.. debugging the token code for this it doesn't seem like there is context per teaser (item in the views list).. so perhaps not what this work is trying to solve. :(

had hoped LB was a little "smarter" but i have managed to do what i wanted with EVA (use Views to define a Teaser view mode).

@liquidcms I'm currently working on two projects: Views Tokenized and Context Stack. The latter one is currently in a PoC implementation phase, but when it works out the combination of those two modules might solve your described needs (if I understood correctly what you're trying to accomplish). For more logic control what node should be loaded, ECA might be helpful (currently major development ongoing there).

@mxh, my use case is pretty simple (i think). Use layout builder to override teaser view mode and use views in that view mode too add in content based on the NID of that teaser.

Took a look at those modules. ECA doesn't seem an obvious fit but i suppose it helps to write event handler code (??) to add node context for each teaser? Views Tokenized doesn't sound like it would help. Not sure what Context Stack is meant to do.

EVA is doing the task nicely at the moment:
- eva view to assemble all the field values (some require multiple relationships and field formatters)
- twig template to style the fields as required
- Teaser view mode with single EVA field defined in its display

After that, numerous views to list out teasers.

Adding a version of the patch that ensures the title fields are displayed together. The new settings fields were being injected between the title and title override fields which didn't make sense to me.

I am trying to pass content type as a contextual filter from Layout Builder to a Views block.

Not sure how the contextual filter is meant to be added but i set as "Fixed".

- with the patch from #73 i get a Content Type select list when placing my block in LB. The list has options of "None" and "view_mode" - none of these work.

- with the patch from #70 i get a "type" text field that works as expected (I also get the same broken Content Type select list as above).

@banoodle thank you for working on this. To show the labels is a welcome improvement! But: #73 and #79 don't show contextual filters anymore if they don't have an Administrative title set. #71 shows all filters properly.

In the before mentioned patches there is something else that changes. I enabled layout builder on a taxonomy term display. When I now resave a views block with contextual filters, you can see in the diff that the key changes to the label. That doesn't look right to me (I also altered the filters, don't get confused by that):

               arguments:
-                field_h4c_frontpage_value:
-                  type: numeric
-                  value: all
-                id:
-                  type: group_id
-                  value: all
-                tid:
+                'Limit to certain taxonomy term IDs (or enter "all")':
                   type: taxonomy_index_tid
                   value: ''
+                'Only show certain content IDs (multiple IDs: "1,2,3")':
+                  type: node_nid
+                  value: ''
+                'Exclude certain content IDs (multiple IDs: "1,2,3")':
+                  type: node_nid
+                  value: ''

@anruether:

+++ b/modules/ctools_views/src/Plugin/Display/Block.php
@@ -241,6 +249,41 @@ class Block extends CoreBlock 
+          // Get the Admin Label.
+          $admin_label = $plugin->adminLabel();
+
+          // If Admin Label is set, use it.
+          if (!empty($admin_label)) {
+            $argument_name = $admin_label;
+          }

This smells strange.

Patch #79 works well with a minor adjustment. The $argument_value should not be overwritten by the admin label since it is used to identify the plugin. Here is what works for me...use $admin_label for the textfield title and set it to the $argument_name if empty.

if (empty($admin_label)) {
            $admin_label = $argument_name;
          }
...
          $form['override']['arguments'][$argument_name]['value'] = [
            '#type' => 'textfield',
            '#title' => $admin_label,
           ...
          ];

I can confirm the patch #79 with the #84 variation is working as expected. Tested in core D9.3.13

Here is a re-roll of #79 with the adjustments from #84.

Works for me in Drupal 9.3.13 w/ ctools 3.7.

I've applied this patch and I can't see "contextual filters" under allow settings, is there something wrong?

I have a basic view and contextual filter for taxonomy terms.

Thanks Dan

@danharper: for "contextual filters" to appear as an option under the View's "Block Settings": "Allow Settings" section, both the modules ctools and ctools_views (included in the ctools project suite but not automatically enabled) need to be enabled. I've also enabled ctools_block too since it seemed apropos regardless.

Greetings All:
I wanted to take a moment to ask for clarification on what I'm seeing as to where this issue currently stands these days...
the issue is being able to define a Views Block display with a contextual filter, then using the Layout Builder dialog to add that Views Block display while also selecting/entering its contextual filter via the dialog...

First, in trying to keep as close to core functionality, with as simple as an example as possible...
if I do a fresh install of D9.3.16 (with further only installing drush and enabling the core layout_builder and layout_discovery modules), for example:

1. I add a List(text) field_category to the Article content type, with several key|value pairs defined.
2. I then define a View Block with field_category being the contextual filter.
3. I then give Basic Page the ability to use Layout Builder...
4. ...then I Add Block via the Layout to add that View Block display, which brings up the dialog.
5. The dialog does show the contextual filter option, and with a nice dropdown list...
6. ...however the dropdown list is not populated with any valid values, just "-None-", and cannot figure out any way to get them to populate...

Is there something I'm missing to get this field to populate with valid keys? Or is this part of what has been broken from the beginning and that this thread attempts to fix?
Depicted below:

Then, I installed/enabled ctools and its accompanying ctools_views and ctools_block modules, and applied the patch from #86...

1. I go into the Views Block display, and now go into "Block Settings": "Allow Settings" and a "contextual filters" checkbox is now present, and I select it.
2. Then going back to Layout Builder, there now exists a *second* contextual filter entry box for field_category. This time it is a manual entry field, not a dropdown.
3. I am able to enter a key into this new field, and it DOES work to insert the correct version of the view! ...
4. ... which is great, but confusingly there is STILL the dropdown list provided by core present, and with no pre-population of valid "List (text)" field values in either field.

As depicted below:

Might someone please be able to clarify that yes what I'm seeing is indeed the current expected behavior, of core, and when the ctools modules/patch is applied?
Thank you!

The #86 works for me. I tested with Layout Builder.

Drupal 9.4.4
ctools 4.0.1

Steps to reproduce:
- Create a Vocabulary "Type"
- Create some terms under "Type" of vocabulary
- Create a field entity reference on Article Content Type
- Create a new view "Recent Article", and add a "Block" display
- at "Block Settings" section, check the "Contextual Filter checkbox in the "Allow Settings".
- at the "Advanced" section, add a new contextual filter "Content: has taxonomy term NAME"
-- I'm using "drupal/views_taxonomy_term_name_depth" which allows contextual filter by term name.
- The Preview should be returning values already.
- Click "Save"

Layout builder configuration:
- If using "drupal/layout_builder_restrictions", make sure to enable the "List Views" blocks to the content type.

Node page's configuration:
- Go to the Layout tab
- Click to add a new block
- Place the "Recent Article" block
- an input text should be available now, "Content: Has taxonomy term NAME"
- Add an existent Taxonomy term name.
- Click "save" or "update"
- Now, you should be able to see the Article list filtered by taxonomy term.

Currently, patch #86 provides a text field so content editors can add parameters manually.
I've improved it a little bit so now it supports List(text) fields as well.
It replaces the textfield with checkboxes and populates with the field list settings.
Please review the merge request #25 (4.1.x) and #26 (8.3.x).

I took the liberty of creating a new branch for 3.x, because the branch that MR 26 was based on was called 8.x-3.x in the issue fork, which caused some trouble for me locally. I Think I resolved the merge conflicts.

Hi all, I was running the previous version of Ctools using the patch (#86 I believe), which worked perfectly for passing arguments to views and displaying the appropriate content with layout builder.

Since doing that latest Ctools update (8.x-3.13), i'm only presented with a dropdown to select whichever filter, but given no options in the dropdown. Any thoughts on something I've missed? The views should be good as they validate w/ arguments in the preview window.

I'm on the latest version of D9 core.

Thanks!

This is the patch for:

Drupal 9.4.8
ctools 4.0.3

As reported in #97 the patch in #86 no longer applies to 8.x-3.13. I've also confirmed that the last version of 4.x that it will successfully apply to is 4.0.1.

I have not tried the patch in #98 as it reports that the patch failed to apply in the notes.

I'm running Drupal 9.5.1 on PHP 8.1.13

This is a reroll of #86 for 8.x3.13.

Fair warning, I've done it a bit blindly without too many tests.

I've successfully implemented the patch from #100 for 4.0.3 on Drupal 9.5.5 PHP 8.1.13

Great work @hanoii

I can't reproduce this on ctools 4.0.4 anymore

Wrong issue.

Just applied patch #100 on ctools 4.0.4 and Drupal 9.5.11 and seems to be working great with layout builder.

Applied #100 on drupal 10.3.2 and ctools 4.1.0 with great success! Thanks people!

👉🏼 The issue title "How to manually pass an argument to a views block through interface" was confusing to me and took me a while to find and to grasp that this is the robust solution, I was looking for.

Something like "Manually pass contextual args to Views Block from Block Display configuration" may be better!?

Happy with D10.5.1 and Ctools 4.1.0. Thank you #100, just working fine in Layout builder as well as in Block builder. I agree with tomsaw for a better titling. Also, may we promote the status to "reviewed and tested / RTBC".

Added static patch for 4.1.x, improving compatibility with Drupal 11.3.

Added static patch for 4.1.x, addressing a PHP warning when checking for the "string_list_field" argument type.