I used the php fillter to embed a view in the FBML reference action.

$view_name = 'MyViewName'; //name of view
$limit = 3; // number of returns
$view_args = array();
$view = views_get_view($view_name);
print views_build_view('embed', $view, $view_args, FALSE, $limit);

It outputs fine, but the links reference the users root domain (myschool.facebook.com/myappname) not (apps.facebook.com/myappname).

What do i need to do to get this working? Why didn't the insert views filter work?

Thanks

Comments

frankcarey’s picture

frankcarey commented

same issue here, i investigated some of the other apps' links, and notices "some" of them had myschool.facebook.com as well, but their links work. Only thing i could think of is that it only works once you "publish" an app?

Looking a little closer;
All the facebook developed apps are myschool links, but "US politics" is a myschool link is too, and i don't think that it is facebook made is it?

I have half a dozen others that are 3rd party and they all say apps.fcarebook.com. Hope this helps
Cheers

Dave Cohen’s picture

Dave Cohen commented

This has to do with Drupal's filter cache. Drupal is geared toward showing content on just one site, so when it builds say, 'example.com/node/123', it caches node content with a key like 'node/123', and that cached content might include a link to example.com/node/999. Later, when it serves up apps.facebook.com/example/node/123, it wants to use the same cache, and therefore the same link to example.com/node/999.

To get around this, Drupal for Facebook installs another filter_cache table in the database. So while serving canvas pages, the filters get cached to fb_filter_cache instead of filter_cache. This is one of the hacky parts of Drupal for Facebook. But, it works OK if your dealing with only two domains, example.com and apps.facebook.com. To support any number of domains, i.e. school1.facebook.com ... schoolN.facebook.com, will require a change to Drupal's filter cache mechanism. This requires a core patch, but its really a good idea in my opinion. Basically, instead of using a simple key of 'node/123' for the cache, a key that incorporates the domain name, and possibly the base_path, should be used.

I'm not certain how difficult all this will be. I suspect not very difficult to code, but fairly challenging to get the patch committed to core.

deadman’s picture

deadman commented

Has any progress been made on this issue or is a core patch going to be the only way to go?

Dave Cohen’s picture

Dave Cohen commented

Reading this over, I think my initial theory about filter cache stuff is not the actual cause of the problem. Can someone point me to an actual profile page which has this problem occuring?

deadman’s picture

deadman commented

Just sent you a message on facebook

giorgio79’s picture

giorgio79 commented
Status: Active » Closed (won't fix)

Cleaning queue.
Reopen if still exists in 6x or 7x