I've been experimenting with adding a Netvibes widget for my taxonomy/term/X View. The path for the page is 'taxonomy/term/%'. The path for my widget is 'taxonomy/term/%/widget'.

When I view the taxonomy term page the widget url shows as http://example.com/taxonomy/term/%25/widget/uwa

As you can see the percent gets encoded, rather than replaced with the argument used on the View page. I tried a few URL formats as mentioned in the help description. Nothing helped.

Comments

G Gavitt’s picture

I am getting the exact same thing. The % is encoded rather then being replaced by the argument.

G Gavitt’s picture

I have quick and really dirty work around..this will only work if your on the page of the view...

on line 259 of web_widgets_plugin_display_web_widgets.inc
change

$path = url($this->view->display[$this->display->id]->display_options['path'], array('absolute' => TRUE));

to

$path = $base_url . request_uri();

(function from http://api.drupal.org/api/function/request_uri/6 )

and use global $base_url; right below the function around line 256

That will assign the current url..(which is the page of your view with the argument) to the embed code that is generated. However..you will always see the embed code on that page on outside embeds...because I am pretty sure the module is supposed to generate a view with-out its own embed code widget and by changing that line, you will bypass the link to that view.

As a work around for that...
You can append $path = $base_url . request_uri(); with something like $path = $base_url . request_uri() . "/embed" ;
Then you can make a new view using the same path as the original embedded one but add the /embed to the end of the path. Then you can theme that page anyway you want.. even take over the whole page with a page tpl from the path like page-examplefolder-examplefolder-embed.tpl.php and that will also pass the argument.

G Gavitt’s picture

I just started working on a better fix for this..

In the web_widgets_module add

function code_url_for_arg($view_arg) { 

  $view = views_get_current_view();
  $view_arg_load = $view-> args[0];
  $view_arg = str_replace('%25', $view_arg_load, $view_arg); 
    return  $view_arg ;
} 

Then in web_widgets_plugin_display_web_widgets.inc

Replace
$path = url($this->view->display[$this->display->id]->display_options['path'], array('absolute' => TRUE));

With

$pre_arg_path = url($this->view->display[$this->display->id]->display_options['path'], array('absolute' => TRUE));
$path = code_url_for_arg($pre_arg_path);

That will replace the %25 with the value of the view argument. Only works for the first argument so far but I am pretty sure the replace function could be re-written to replace all the %25's with their proper views argument. Also I dont think it plays well with an empty argument yet..it will probably? pass // in replacement of the null value.

aron novak’s picture

Status: Active » Needs review
StatusFileSize
new1.46 KB

Well, thank you guys for making clear what was wrong here. Can you test if the patch below works fine?

G Gavitt’s picture

Works great for me so far. Thank you aron.

alex_b’s picture

Status: Needs review » Needs work

I'm pretty sure there is a views API function to build this URL.

aron novak’s picture

Status: Needs work » Needs review
StatusFileSize
new1.09 KB

Attached a patch that uses views api.

aron novak’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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

jmonster’s picture

Status: Closed (fixed) » Active

I am using the above following code for getting the base path $path = $base_url . request_uri();

This is a very novice question, but after using this code, i end up with the tail of the url eg /taxonomy/term/24 and the mysite.com/ part is cut off

Is there any way to make it show the entire url? i have struggled with this for a while now and always struggle when it come to path related problems, but am sure its very easy. Can anyone show me the light?

clemens.tolboom’s picture

Status: Active » Closed (fixed)

This issue was fixed and the report from #10 is an old support question. Feel free to create a new support request issue.