Hi, nice module, i've been testing in D5, and when i go to my view i have both, the views exposed filter form, and the block with the form.

And if i have accessed to my view using an argument it erase it.

Example
you go to 'myviews/arg'
the press submit in the block and you get
'myviews?filter0=x'
without the arg

Sorry for my english

Comments

douggreen’s picture

Is your exposed filter in one of the standard regions (content, left, right, header, or footer)? This could cause the problem, if your exposed filter is in another block region. views_filterblock works this way for simplicity and performance reasons.

I could add an "update regions" button on the settings page to solve this.

A "quick fix" is to edit the following code segment and add your region

Line 155: foreach (array('content', 'left', 'right', 'header', 'footer') as $region) {

As for the argument problem, I thought I had fixed that. Are you sure that you have the 5.x-1.0 version? It should say "views_filterblock.module,v 1.4.2.3" near the top.

A "quick fix" for this is to enable "Clean URLs" on the admin/settings/clean-urls page.

diegogers’s picture

The block is in the right column in the garland theme.

And the module i have says
// $Id: views_filterblock.module,v 1.4.2.3 2007/01/04 16:55:31 douggreen Exp $

Also i had to add to the views_filterblock_menu function this: return $items; . Because it didn't work, i'm no proggramer, just copied from another module.

And i had to modify the callback arguments in the same function.

Hope it helps.

douggreen’s picture

For a non-programmer, that was a great catch on the return $items. Thanks!

I did some additional testing and found the problem related to not hiding the block.

I fixed both of these in the 5.x-dev release. Please test the 5.x-dev release. I'll make a 5.x-1.1 release once you can confirm that this fixes your problems.

diegogers’s picture

Very nice, now it hides the form.

And for the argument erasing in the url I tryed in the function views_filterblock changing

$form['#action'] = url($view->url);
//to
 $form['#action'] = '';

And it worked (as I need/want/expect)

Thanks for this nice module

douggreen’s picture

Based on your feedback that it's mostly working, I created a new 5.x-1.1 release.

It seems that you're still having problems with the arguments. You shouldn't have to change the #action. It might help other users having similiar problems if you could work through two more things:

  • Are you using clean-url's?
  • Could you export your view (on the views admin page) and paste the results here (between the tags <code> and </code>)?

Thanks! and your welcome!

diegogers’s picture

I'm using clean urls.

  $view = new stdClass();
  $view->name = 'actividades';
  $view->description = 'Actividades';
  $view->access = array (
);
  $view->view_args_php = '	if(arg(1) == \'todas\') {
		$view->page_title = "Actividades";
	}
	else {
		$temp = taxonomy_get_term(arg(2));
		switch( arg(2) ) {
			case \'1\': case \'2\': case \'49\':
				$view->page_title = $temp->name . "s"; break;
			case \'3\':
				$view->page_title = $temp->name . "es"; break;
		}
	}
	if(is_numeric(arg(1) ) ) {
		$temp = taxonomy_get_term(arg(1));
		$view->page_title .= " de " . $temp->name;
	}';
  $view->page = TRUE;
  $view->page_title = '';
  $view->page_header = '';
  $view->page_header_format = '1';
  $view->page_footer = '';
  $view->page_footer_format = '1';
  $view->page_empty = '';
  $view->page_empty_format = '1';
  $view->page_type = 'teaser';
  $view->url = 'taxonomy/term';
  $view->use_pager = TRUE;
  $view->nodes_per_page = '10';
  $view->sort = array (
    array (
      'tablename' => 'node',
      'field' => 'sticky',
      'sortorder' => 'DESC',
      'options' => '',
    ),
    array (
      'tablename' => 'node',
      'field' => 'created',
      'sortorder' => 'DESC',
      'options' => 'normal',
    ),
  );
  $view->argument = array (
    array (
      'type' => 'taxid',
      'argdefault' => '2',
      'title' => '',
      'options' => '0',
      'wildcard' => 'todas',
      'wildcard_substitution' => '',
    ),
    array (
      'type' => 'taxid',
      'argdefault' => '2',
      'title' => '',
      'options' => '0',
      'wildcard' => '',
      'wildcard_substitution' => '',
    ),
    array (
      'type' => 'node_feed',
      'argdefault' => '2',
      'title' => '',
      'options' => '',
      'wildcard' => '',
      'wildcard_substitution' => '',
    ),
  );
  $view->field = array (
  );
  $view->filter = array (
    array (
      'tablename' => 'node',
      'field' => 'status',
      'operator' => '=',
      'options' => '',
      'value' => '1',
    ),
    array (
      'tablename' => 'node',
      'field' => 'type',
      'operator' => 'OR',
      'options' => '',
      'value' => array (
  0 => 'actividad',
),
    ),
    array (
      'tablename' => 'term_node_2',
      'field' => 'tid',
      'operator' => 'AND',
      'options' => '',
      'value' => array (
),
    ),
  );
  $view->exposed_filter = array (
    array (
      'tablename' => 'term_node_2',
      'field' => 'tid',
      'label' => '',
      'optional' => '1',
      'is_default' => '0',
      'operator' => '1',
      'single' => '1',
    ),
  );
  $view->requires = array(node, term_node_2);
  $views[$view->name] = $view;
douggreen’s picture

Status: Active » Fixed

The original reported problem of not hiding the block is confirmed fixed. I can't reproduce the argument problem.

douggreen’s picture

Status: Fixed » Closed (fixed)
juanfe’s picture

Title: It doesn't hide the real views filter form. » View with filter arguments and appended $arg
Component: User interface » Code
Priority: Normal » Minor
Status: Closed (fixed) » Postponed (maintainer needs more info)

Hi there,

I saw a similar issue (filterblock v 1.4.2.11) with argument handling that was addressed by changing

  $form['#action'] = url($view->url);

to

  $form['#action'] = '';

in views_filterblock().

My setup:

  • Two views, "devices_english" with path "devices", and "devices_english_filtered" with path "devices/$arg". $arg is a default filter on the second view that searches a CCK field 'dev_manufacturer' for a match and displays those that are corresponding
  • devices_english_filtered displays a filterblock that allows for further filtering on "country"

The default behavior of filters without filterblock (on garland theme) is as follows:

  • user visits /devices/moto
  • only Moto devices are shown
  • user filters for country Brasil
  • path is /devices/moto?filter0=Brasil

On filterblock, the behavior is as follows:

  • user visits /devices/moto
  • only Moto devices are shown
  • user filters for country Brasil
  • path is /devices/%24arg?filter0=Brasil

what is happening is that $view->url is passed as ("devices/$arg") to views_filterblock -- in fact, it's passed that way to views.module in views_filters(). The interesting thing is that if I comment out form['#action'] in filterblock altogether, i get the same behavior (%24arg in the URL). Seems like there's something downstream in views that is "fixing" the URL that isn't happening in filterblock.

Odd. But minor in the grand scheme of things.

andyschm’s picture

I have the same problem and the above one-liner fixed it for me...

inforeto’s picture

Also try $view->url in the argument handling code:

$view->url = "taxonomy/term/".arg(2);

karlmoritz’s picture

Assigned: Unassigned » karlmoritz
Status: Postponed (maintainer needs more info) » Needs review

Had a similar problem. The one line fix above in #4 and #9 doesn't completely solve the issue, as it will prevent the form from functioning correctly if one is not inside the correct view already. E.g. when using an exposed filter block on the main page, that should direct to a specific view, this won't happen anymore.

The following function should solve the issue:

function views_filterblock($view) {

  $action = (substr_compare($_GET[q].'_'.$view->url, $view->url, 0, strlen($view->url)) == 0) ? $_GET[q] : $view->url;
  
  $form = views_filters($view);
  $form['#action'] = url($action);
  $form['#views_filterblock'] = true;
  return $form;
}

$_Get[q].'_'.$view->url is necessary to ensure that the main string is longer than the substring in substr_compare and the '_' will prevent it from matching should $_GET[q] be null.

If I get some feedback on this code / improvements, I will submit it as a patch.

kmh

douggreen’s picture

Status: Needs review » Needs work

You are correct about why #4 and #9 don't completely work.

However, even though you told me what it does, this line is very confusing... I think that an equivalent line is:

  $action = substr($_GET['q'] .'_'. $view->url, 0, strlen($view->url) == $view->url)? $_GET[q] : $view->url;

And I don't see how that will ever be true

If you do submit a patch, please remember to quote 'q'. You're also not using proper string concatenation rules, but since that standard has changed in 7.x, it's not important.

karlmoritz’s picture

I think there is at least a closing bracket missing after strlen($view->url) in your code:

 $action = substr($_GET['q'] .'_'. $view->url, 0, strlen($view->url) == $view->url)? $_GET[q] : $view->url;

This one should work, though:

 $action = (substr($_GET['q'] .'_'. $view->url, 0, strlen($view->url)) == $view->url) ? $_GET[q] : $view->url;

In fact, using substr rather substr_compare, we can get rid of the hack with the underscore etc, so finally we should be able to use:

 $action = (substr($_GET['q'], 0, strlen($view->url)) == $view->url) ? $_GET[q] : $view->url;

The conditional should then be true iff $_GET['q'] begins with the $view->url, followed by null or more characters.

douggreen’s picture

Please roll a patch file (see http://drupal.org/patch/create)

SocialNicheGuru’s picture

YOU GUYS ARE MY HEROES!!!!

I upgraded after reworking my previous views to use arguments in the url (way slick I might add).

Everything looked fine and then I used the exposed filters and all of the sudden my exposed filters using filter block no longer work.

THANK YOU THANK YOU THANK YOU.... I wasted a day on the forums and online trying to figure out why views was doing it, then figured out it was views filter block...

Chris

douggreen’s picture

@activelyOUT, was there a problem with VFB that this issue helped you fix. If so, can you point it out to me again, so that I can fix VFB so that someone else doesn't "waste a day."

SocialNicheGuru’s picture

This helped with arguments from the url being part of the exposed filter action:

// activelyOUT
// Views filter block erases arguments
// change function
// http://drupal.org/node/112552#comment-796805
// Change action line
// http://drupal.org/node/112552#comment-823797

asak’s picture

Will this thread help me with using views_filerblock together with Panels ?

I'd like to set up a panel page with 2 columns - one with the filter block , the other with the resulting table.

Seems that when setting the panel page everytime I try to filter the table i'm redirected back to the normal page view of the view. which is logical, but not what i'm looking for.

Possible? ;)

inforeto’s picture

Sounds right. Try it. It sets the path to be used by the filter.
The argument overrides the normal page of the view used.

SocialNicheGuru’s picture

I have the same problem as in #19.

When I place VFB on the panles page and filter, it takes me to the original view.

How should I configure the panel that VFB sits in so that it refers to the right page. Should I be using context?

I am a little confused.

Chris

UPDATE: this should probably be in its own thread.
I am now having problems with exposed filters in panels. When I click on submit, I am taken to the original view and I am not kept in the panel.

asak’s picture

It seemed to me that in comment #18 you have successded in this... but I understand you didn't

I don't understand what all the patching does if not fix this issue...

Confuzed as well! ;)

inforeto’s picture

I see the patches alter the form action directly but still wonder if it can work just by passing the right $view->url instead of its default value.
The $view->url can be changed wherever $view is present and that value is then used on the block's action automatically.
That can be done straight in the views ui using the php code block of the argument handling code, so no functions need to be edited.
Like $view->url = arg(0); or $view->url = $_GET['q']; (tested on one test site, but not with panels)

asak’s picture

I kind'a understand...
This is a little too technical for me..
I don't have much experience with using arguments in views and allmost none with panels (and even less with PHP).

I'll give it a try anyway! ;)

inforeto’s picture

In general, you just have to put $view->url = "path/to/the/panel/page"; in the box.
Should be easier than patching or theming a function as suggested above.
Getting the right url is what may vary. But try it out because i have not tested with panels, only viewsfield.

asak’s picture

Ok i get stuck very early... I just don't understand:

Links to my TryThis view, after clicking on an exposed filter, look like this:

.../drupal/trythis?filter0=0&filter1=6

And it works correctly, filtering a " Taxonomy: Term for My Vocab " and displays results.

The thing is, I also added an argument of " Taxonomy: Term ID " to this view, so that I'll be able to access the same results as the link above in the following link:

../drupal/trythis/6 - This page displays NO RESULTS.

If I change a term in the exposed filter block, after providing an argument allready, I'm redirected to the wrong page:

../drupal/trythis/6?filter0=0&filter1=2

BUT if I select the same term as I used for an argument, the following link DOES work correctly:

../drupal/trythis/6?filter0=0&filter1=6

This is too technical for me...

The end result I desire: Using a Panel page with 2 panels, one should display the Filter Block for the view in the other panel. Once a filter has been selected, the page should direct to the SAME PANEL PAGE (not to the view page defined in the view settings) and display the results.

I'm sure this is mostly a matter of arguments being passed around - something which I have no experince with.

I can see many issues about this kind of feature, desired by many folks. It isn't clear (to me) what module is responsible for making this an issue.

If anyone has any insight, or better yet - a solution - that would be amazing.

Thanks! ;)

(P.S. - The most relevent threads i've found on the subject until now are:
http://drupal.org/node/277919
http://drupal.org/node/213069
http://drupal.org/node/267358)

SocialNicheGuru’s picture

I tried to get an exposed view in panels to work by taking your suggestions.

I took your suggestion (#23) in function views_filterblock($view) and set

$action = $_GET['q'];
$form['#action'] = url($action);

it works once.

Then when I hit the submit button again, it just hangs.

inforeto’s picture

Setting $view->url is supposed to be the desired method to change the form action for any modules that interact with views.
Besides, other code including views can change the form action afterwards.

SocialNicheGuru’s picture

$views->url does change the views' filters in a panel appropriately if you do not use views filter block.

but the problem lies with views filter block. it is not picking up the right url.

SocialNicheGuru’s picture

I have this current issue in D6 and would like some help.

I am willing to pay a bounty ($25) if exposed block filters in Drupal 6 can get fixed. Anyone else want to chip in?

One use case:
create a view
have the exposed form block
Create a panel with the path node/%/someview
% is the group context

Create a view which lists the owners of nodes and locations myview/%group/%author/%zip
Create a panel view pane
%group is context
%author is panel argument
%zip is taken from url

place the exposed form block into a pane on this panel
place the exposed view into a pane of this same panel
filter the view and click submit
have it come back to the same panel override page and not the original view

Thanks,
Chris

douggreen’s picture

Status: Needs work » Closed (won't fix)

I'm doing some ticket triage and closing all open 5.x or moving them to the latest appropriate version. The latest comment on this is 2.5 years old and this module is deprecated by newer views/panels features.