Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment #1
douggreen CreditAttribution: douggreen commentedIs 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
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.
Comment #2
diegogers CreditAttribution: diegogers commentedThe 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.
Comment #3
douggreen CreditAttribution: douggreen commentedFor 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.
Comment #4
diegogers CreditAttribution: diegogers commentedVery nice, now it hides the form.
And for the argument erasing in the url I tryed in the function views_filterblock changing
And it worked (as I need/want/expect)
Thanks for this nice module
Comment #5
douggreen CreditAttribution: douggreen commentedBased 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:
Thanks! and your welcome!
Comment #6
diegogers CreditAttribution: diegogers commentedI'm using clean urls.
Comment #7
douggreen CreditAttribution: douggreen commentedThe original reported problem of not hiding the block is confirmed fixed. I can't reproduce the argument problem.
Comment #8
douggreen CreditAttribution: douggreen commentedComment #9
juanfe CreditAttribution: juanfe commentedHi there,
I saw a similar issue (filterblock v 1.4.2.11) with argument handling that was addressed by changing
to
in views_filterblock().
My setup:
The default behavior of filters without filterblock (on garland theme) is as follows:
On filterblock, the behavior is as follows:
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.
Comment #10
andyschm CreditAttribution: andyschm commentedI have the same problem and the above one-liner fixed it for me...
Comment #11
inforeto CreditAttribution: inforeto commentedAlso try $view->url in the argument handling code:
$view->url = "taxonomy/term/".arg(2);
Comment #12
karlmoritz CreditAttribution: karlmoritz commentedHad 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:
$_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
Comment #13
douggreen CreditAttribution: douggreen commentedYou 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:
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.
Comment #14
karlmoritz CreditAttribution: karlmoritz commentedI think there is at least a closing bracket missing after strlen($view->url) in your code:
This one should work, though:
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:
The conditional should then be true iff $_GET['q'] begins with the $view->url, followed by null or more characters.
Comment #15
douggreen CreditAttribution: douggreen commentedPlease roll a patch file (see http://drupal.org/patch/create)
Comment #16
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedYOU 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
Comment #17
douggreen CreditAttribution: douggreen commented@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."
Comment #18
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedThis 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
Comment #19
asak CreditAttribution: asak commentedWill 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? ;)
Comment #20
inforeto CreditAttribution: inforeto commentedSounds right. Try it. It sets the path to be used by the filter.
The argument overrides the normal page of the view used.
Comment #21
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedI 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.
Comment #22
asak CreditAttribution: asak commentedIt 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! ;)
Comment #23
inforeto CreditAttribution: inforeto commentedI 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)
Comment #24
asak CreditAttribution: asak commentedI 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! ;)
Comment #25
inforeto CreditAttribution: inforeto commentedIn 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.
Comment #26
asak CreditAttribution: asak commentedOk 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)
Comment #27
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedI 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.
Comment #28
inforeto CreditAttribution: inforeto commentedSetting $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.
Comment #29
SocialNicheGuru CreditAttribution: SocialNicheGuru commented$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.
Comment #30
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedI 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
Comment #31
douggreen CreditAttribution: douggreen commentedI'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.