This is a simple patch that came out of the need to use a solr view in a Panel. After some digging, I realized the base_path isn't being set right because it only looks for paths set by "Page display" views.

This patch changes the following line:

$this->_base_path = isset($view->display[$view->current_display]->display_options['path']) ? $view->display[$view->current_display]->display_options['path'] : ''; 

to this:

$this->_base_path = isset($view->display[$view->current_display]->display_options['path']) ? $view->display[$view->current_display]->display_options['path'] : $_GET['q']; 

Comments

damienmckenna’s picture

StatusFileSize
new1021 bytes

Here's an actual patch file.

Scott Reynolds’s picture

Status: Needs review » Needs work

this is a problem the View is a block. Causes strange problems no?

Scott Reynolds’s picture

lets check the display and see if it uses hook menu

'uses hook menu' is the key. @see views_menu_alter().

smoothify’s picture

I ran into this problem too trying to use this module in a panel.

I fixed it by changing the same line from

$this->_base_path = isset($view->display[$view->current_display]->display_options['path']) ? $view->display[$view->current_display]->display_options['path'] : ''; 

to

$this->_base_path = $view->get_path();

This works with the panel as long as you set the path override in the pane settings. It also still works with the regular page view.

Is there reason i'm missing why this can't be used?

smoothify’s picture

StatusFileSize
new656 bytes

here is a patch for #4

Scott Reynolds’s picture

Title: PATCH: Base URL not set if not a "Page" display, defaults to $_GET['q'] instead of nothing » Use $view->get_path instead of grabing the path from the display
Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

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