Impossible to use a Page view or Block view with exposed filters without Ajax:

So exposed filters do not work without AJAX when using a view as the replacement for a taxonomy term page.
The problem with blocks relates to this:
#690748: Views exposed filters don't work in block display

The problem with pages is that the ACTION property of the exposed filter form will point back to the page view, so if a user submits the exposed filter form, they get sent to the page view.

Content Pane views:

ctools has a cool "Content Pane" view display type that allows a work around for this.

You can set a property in the views UI to let a content pane "Inherit path from panel display"

If [set to] yes, all links generated by Views, such as more links, summary links, and exposed input links will go to the panels display path, not the view, if the display has a path.

This property allows the Content Pane display to use an "override_url" property that gets set by panels when a content pane view is embedded into a pane.

I think this property would be a great way to fix links and filter POSTs on taxonomy displays that are embedding views.

Patch coming soon.

CommentFileSizeAuthor
#26 taxonomy-display-views-url-1783968-26.patch631 bytesfearlsgroove
#21 1783968-21-override_path.patch635 bytesfearlsgroove
#8 taxonomy_display-set_override_url_property_on_view-1783968-8.patch618 byteslotyrin
#6 taxonomy_display-set_override_url_property_on_view-1783968-5.patch630 byteslotyrin
#5 taxonomy_display-set_override_url_property_on_view-1783968-5.patch1.31 KBtmsimont
#1 taxonomy_display-set_override_url_property_on_view-1783968-1.patch1.28 KBtmsimont

Comments

tmsimont’s picture

tmsimont commented
Status: Active » Needs review
StatusFileSize
new taxonomy_display-set_override_url_property_on_view-1783968-1.patch1.28 KB

patch attached

codycraven’s picture

codycraven commented

Excellent, thanks tmsimont, I'll review when I get the chance.

lotyrin’s picture

lotyrin commented
Status: Needs review » Needs work

I can reproduce the problem, but applying the patch doesn't seem to solve it.

Also the patch introduces trailing whitespace.

codycraven’s picture

codycraven commented

lotyrin, did you attempt to change the View's display to content pane (and the taxonomy term's display to match)?

tmsimont’s picture

tmsimont commented
StatusFileSize
new taxonomy_display-set_override_url_property_on_view-1783968-5.patch1.31 KB

attached is a patch that addresses the whitespace issue (i think?)

also -- as codycraven points out, you'll need to adjust the view to use a display type of "content pane"

I know that requires ctools, it may also require panels...

lotyrin’s picture

lotyrin commented
Status: Needs work » Needs review
StatusFileSize
new taxonomy_display-set_override_url_property_on_view-1783968-5.patch630 bytes

Oh, I see. Reading the issue and patch more carefully I see that it's strangely Panels-dependent.

This patch should work with or without Panels.

lotyrin’s picture

lotyrin commented

tmismont, could you see if my patch works in your use case (Panels and whatnot).

lotyrin’s picture

lotyrin commented
StatusFileSize
new taxonomy_display-set_override_url_property_on_view-1783968-8.patch618 bytes

Actually, since we're using $view->override_path, not override_url, we can make that even simpler.

view::get_url
view::get_path

I'm also now certain that this will have the same effect as tmsimont's patch, except that it doesn't check for Panels (and the result isn't dependent on Panels, so it should not check).

tmsimont’s picture

tmsimont commented

Well there are actually negative consequences of using override_url via those two functions.

I can't remember off the top of my head what those were, but this was the route I'd initially pursued before I ran into issues. I can re-test that approach and post back my problem within the next day or so, I'm currently caught up with a different project but will circle back to this by the end of the week.

codycraven’s picture

codycraven commented

The patch in #8 looks good to me, but I'd like tmsimont's opinion and testing if possible before committing.

codycraven’s picture

codycraven commented

As a note, this is the only issue preventing the 7.1 release.

tmsimont’s picture

tmsimont commented

ok my bad i will get on this tomorro

tmsimont’s picture

tmsimont commented

hmm i'm not sure if it's related only to this patch or any other changes made in the 7.x-1.x branch but for some reason now when I view the manage display tab I get this error:

Warning: htmlspecialchars() expects parameter 1 to be string, array given in check_plain() (line 1572 of [...]/includes/bootstrap.inc).

I also get a WSOD when I submit the taxonomy display form.

tmsimont’s picture

tmsimont commented

ah I see the "ignore" plugin is now part of the core module -- i was using the same plugin namespace in a supplementary module (resulting in conflict with commit of #1798196: breadcrumb handling makes it impossible to alter breadcrumbs for terms without parents)

more testing...

tmsimont’s picture

tmsimont commented

ah now i remember the problem with using non-panels here.

If you choose a block display, then your exposed filters disappear unless you have ajax enabled, due to the uses_exposed() function implementation in views_plugin_display_block.inc:


  /**
   * Block views use exposed widgets only if AJAX is set.
   */
  function uses_exposed() {
    if ($this->use_ajax()) {
      return parent::uses_exposed();
    }

    return FALSE;
  }

So even if you have the override property set, the lack of "use_ajax" in the block display hides your filters... I'll see how it works if you use a master display.

tmsimont’s picture

tmsimont commented

ok #8 seems to work fine with the master display and panels display, it just doesn't really work with block displays -- but that's not really a big deal since my original patch doesn't fix that problem either. The issue with the disappearing exposed filters on block displays is an issue with views, not this module (i referenced this issue in my original post: #690748: Views exposed filters don't work in block display)

I think #8 works!

codycraven’s picture

codycraven commented
Status: Needs review » Fixed

Committed and pushed to 7.x-1.x.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

donquixote’s picture

donquixote commented
Issue summary: View changes
Status: Closed (fixed) » Needs work

This seems wrong and causes problems with facet search.

The correct path would be

      // Ensure links stay on taxonomy term page.
      $view->override_path = 'taxonomy/term/' . $term->tid;

instead of

      // Ensure links stay on taxonomy term page.
      $view->override_path = 'taxonomy/term/%';
fearlsgroove’s picture

fearlsgroove commented

Also bit by this issue when using facets. Whatever mechanism views is using to replace arguments in that URL seems to be views or panels specific.

Why not just use current_path()?

fearlsgroove’s picture

fearlsgroove commented
Status: Needs work » Needs review
StatusFileSize
new 1783968-21-override_path.patch635 bytes
hefox’s picture

hefox commented
Status: Needs review » Reviewed & tested by the community

Patch is being used on a project with multiple testers/developers and has not presented any problems yet and has fixed the issue.

codycraven’s picture

codycraven commented
Status: Reviewed & tested by the community » Fixed

Applied and committed #21.

  • Commit 0fb0d03 on 7.x-1.x authored by fearlsgroove: 
    Issue #1783968 by fearlsgroove: Fix content listing using Views with...
  • Commit bf8d618 on 7.x-1.x by codycraven:
    Updating CHANGELOG with #1783968 fix.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

fearlsgroove’s picture

fearlsgroove commented
Status: Closed (fixed) » Needs review
StatusFileSize
new taxonomy-display-views-url-1783968-26.patch631 bytes

So it turns out this does fix facets, but it breaks exposed forms. Views will attempt to add the arguments to the end of an override_path value, so when you search instead of /taxonomy/term/123?search=foo, you'll get /taxonomy/term/123/123?search=foo. This actually still works in some cases, but is clearly wrong and will definitely break in others (for instance if there are multiple contextual filters for which a default is provided).

If we use override_url instead, views just uses the url we provide and all works as expected.

vlad.dancer’s picture

vlad.dancer
Primary language Ukrainian
Location Kyiv
commented
Status: Needs review » Reviewed & tested by the community

@fearlsgroove, thanks for the patch. +1 RTBC from me, but I've tested it only for views without facets.

Scott Robertson’s picture

Scott Robertson commented

I can confirm that this patch fixed the issues I was having with facets from the facet API using the wrong URL.

alexp999’s picture

alexp999 commented

#26 working well for me.

vbard’s picture

vbard commented

#26 also worked for me, thank you guys!