So I am messing around trying to get a dynamic facebook like button placed where the title and caption go for each image in the views generated gallery. So when you go to the next image in the gallery the facebook like button is updated to a new URL where the image is being populated from in the view.

I am using the facebook like module, along with the views php module to create a field with php code in it then rewriting the output of the title filed to the php code. I can get it to render the path and other information generated in the scrip below, but it wont render a like button?

Working in a test environment here: http://www.rankinstudio.com/TESTS/landscape

Script I am using in the PHP filed to output to the title field. You can see it will output the url, but wont show the facebook button?

module_load_include('module', 'fblikebutton', 'fblikebutton');

$p = drupal_get_path_alias("node/".$row->nid);

$options = array('absolute' => TRUE);
$url = url($p, $options);

$addr = variable_get('fblikebutton_block_url', $url);
$confg = array(
  'layout' => variable_get('fblikebutton_bl_layout', "button_count"),
  'action' => variable_get('fblikebutton_bl_action', "like"),
  'color_scheme' => variable_get('fblikebutton_bl_color_scheme', "light"),
  'show_faces' => variable_get('fblikebutton_bl_show_faces', "false"),
  'font' => variable_get('fblikebutton_bl_font', "verdana"),
  'height' => variable_get('fblikebutton_bl_height', "15"),
   'widthf' => variable_get('fblikebutton_bl_width', "100"),
);
print _fblikebutton_field($addr, $confg);

I know the php script works because I'm using it elsewhere.
This is a hack, just curious if there is something simple I'm overlooking that would make it work?

Thanks!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rjacobs’s picture

Issue tags: -facebook like button in gallery view

Humm, hard to say. So you are trying to "inject" a like button for each image within the gallery title field? I suppose there could be some sanitation issue as image data gets processed and passed-to the Juicebox javascript, but in the case of views the raw field output is largely preserved as-is by the module. One exception to this however if if the markup you want to process has block-levels tags in it (<div>, <p>, etc.) as these are filtered out by default for compatibility with the Juicebox javascript. You could turn this filter off for testing though in /admin/config/media/juicebox (uncheck the "Filter all title and caption output for compatibility with Juicebox javascript" option). You would probably only want to do that for testing though as leaving the option off could have consequences for other gallery contexts.

rankinstudio’s picture

Exactly what I am trying to do. I did try to disable that setting with no luck. It will accept php as it is printing the php variables into the title field but it wont render the like button for some reason.

rankinstudio’s picture

The guys at juicebox don't think it is the javascript stripping the field. I have tested getting a like button into views fields a few different ways that all work fine. To test this, I am going to make a juicebox gallery that doesn't have anything to do with drupal and see if I can get a fb like button to render in the title. If so, I guess its something buried in the module causing it to not render. I'll report back with what I find.

Cheers,

rjacobs’s picture

That sounds like a good idea. I'd also suggest running a test that removes Juicebox (the module and the library) if you have not already. This could be as simple as leaving your view fields as-is but switching your view formatter to something other than "Juicebox Gallery" (e.g., "Unformulated List"), and then ensuring that your rewritten field is included in the display. This would help rule-out any sanitation or alterations happening internal to Drupal or views.

rankinstudio’s picture

Okay. I have set up a juicebox gallery without the drupal module locally and the button rendered without problem in the title filed when I added the basic facebook iframe code to get a like button. It also renders if I do what you said and make the view formatter a grid instead of a juicebox gallery. I can also get it to render in other areas of the view, like the footer. I think this points to the module. Somewhere the php is stripping the html from the title field before sending it to the xml file.

rjacobs’s picture

Ok, it sounds like you've done a pretty good job isolating things. I'm still suspect of the block-level tag filter. You said that you turned that off without success, but I'm wondering if perhaps you were still getting a cached copy of the "bad" output during your test with that filter disabled. If an iframe is involved that'll definitely get stripped when the filter is active.

Do you have an example of the raw like-button markup that is produced, and that needs to be preserved within the title field markup from views? I'm not familiar with the module whose API you are using to generate that, and I wonder if there are some complex structures in there, or even some embedded js. The example link that you gave above does not seem to demonstrate a rewritten title value... though I do see a single like button in the view footer.

rankinstudio’s picture

To simplify things I've gotten away from using that module to import the like button. I created a title template for views:

views-view-field--title.tpl.php

Which contains this code:

print '<iframe src="http://www.facebook.com/plugins/like.php?href=http%3A%2F%2Fwww.rankinstudio.com&amp;width=100&amp;layout=button_count&amp;action=like&amp;show_faces=false&amp;share=false&amp;height=21&amp;appId=476385825737350" scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:100px; height:21px;" allowTransparency="true"></iframe>';
print "title!"

It is working as it is doing what it is supposed to and overwriting all titles in any views all across the test site:
http://www.rankinstudio.com/TESTS

It shows up in all of the other views but the juicebox formatted view here: http://www.rankinstudio.com/TESTS/landscape

It will print the print "title!" but not any of the html.

I disabled the block filter a while ago and cleared all caches...

Thanks for the help Ryan!

rjacobs’s picture

Do you still have the global "Filter all title and caption output for compatibility with Juicebox javascript" option disabled? If not that will almost defiantly strip the <iframe> part. The only tags that filter lets through are:

<a><abbr><acronym><b><basefont><bdi><bdo><big><br><cite><code><data><del><dfn><em><font><i><img><ins><kbd><label><mark><q><rp><rt><ruby><s><samp><small><span><strike><strong><sub><sup><time><tt><u><var><wbr>

Check out the bottom of JuiceboxGallery::filterMarkup() for the specifics (bottom of the file).

Depending on your caching setup you may need to clear your caches after disabling that option before running a new test. Just want to confirm that 100% first.

rankinstudio’s picture

Yes, I am positive I disabled it and cleared all caches.

In the JuiceboxGallery.inc file. If I delete these lines it works:

if ($filter) {
$title = $this->filterMarkup($title);
$caption = $this->filterMarkup($caption);
}

I also tried to hard code its value to false in the juicebox.admin.inc file.

Maybe the filter setting isnt being sent over right?

Thanks again!

rankinstudio’s picture

Right on. I went with the first approach now that the button is showing. Works like a charm! Little bit of formatting and I'm there.

On Live Site:
http://www.rankinstudio.com/landscape

rjacobs’s picture

Maybe the filter setting isnt being sent over right?

Hummm, your observations seem to indicate that this might be the case. I'll need to run my own tests, but it's quite possible that you've spotted a bug. I don't think we have any automated test coverage for that specific configuration option so it could be that some other updates led to this small regression. I don't think that option is used very often so it's possible this issue has been around going unnoticed for a while.

The reason for that filter is explained in #2049777: Captions and titles should not contain block-level tags (they should be stripped). Disabling it does not do harm per se, but having it disabled while placing block-level tags in your titles and captions (which you are doing) will lead to syntactically incorrect markup (block-level tags nested inside of <p> tags that are added by the Juicebox javascript library). To be honest I'm not too sure what problems this could lead to (if any) as most browsers will probably still render things fine, but it's just worth noting that it's technically against the HTML spec.

rjacobs’s picture

Here's something interesting. Even though I've not seen the <iframe> tag on any reference list of inline tags (safe for nesting anywhere), this article says:

Syntactically an iframe element may occur inside a paragraph

So maybe we should be letting <iframe> through even when that filter is active.

rankinstudio’s picture

I noticed with the pre packaged gallery that they did place html into the [CDATA[html code]] tags in the xml file. I am really a novice at most of this and know just enough to get by.

Thanks again for the help :) Hopefully it doesn't cause me any problems.

Cheers!

rjacobs’s picture

Title: Facebook Like Button In Gallery View » Global block-level tag filter cannot be disabled any may also be too aggressive
Component: Views Integration » Code
Category: Support request » Bug report

Yeah, the CDATA wrapper thing is just there to ensure that any form of html can be passed within the Juicebox XML, and is somewhat separate from this inline vs block-level tag distinction.

Anyway, it looks like that global configuration option is indeed not working. Disabling it does not actually disable the filter, so that much is a bug. It should be an easy fix but I'll just need to find some time to verify everything enough to make a commit that addresses that.

The other issue is whether-or-not we should allow <iframe> tags through even when that filter is enabled. I'm still not sure if that's syntactically correct or not, but will see what I can find out. What will result is:

<p><iframe /></p>

...with the <p> part being added by the javascript library (and beyond our control).

rankinstudio’s picture

Awesome. Looking forward to the new commit.

rjacobs’s picture

Status: Active » Needs review
FileSize
3.03 KB

The attached patch should address the broken filter config option. I've also expanded the allowed tags in the filter to include everything in the html5 "phrasing content" list, which includes <iframe> and a few others that were not in there before (but probably should be).

Before committing anything I'd like to add some test coverage for this though.

rjacobs’s picture

Here's the patch expanded with some test coverage... for the testbots.

  • rjacobs committed bfd77b8 on 7.x-2.x
    Issue #2406817 by rjacobs, rankinstudio: Ensure markup filter is less...
rjacobs’s picture

Version: 7.x-2.x-dev » 8.x-2.x-dev
Status: Needs review » Active

Looks good. Committed to D7. Even though the markup filter toggle is working fine in 8.x-2.x, there are still a couple elements from this that should be ported there, namely the change to the filter's allowed tags and the test coverage.

rankinstudio’s picture

The patch is committed in the latest DEV version?

Cheers,

rjacobs’s picture

@rankinstudio, yep, the change was committed to 7.x-2.x-dev, and will also be in the next release of course (not sure when that will be though). The related changes to 8.x-2.x are still pending though.

rankinstudio’s picture

Thanks!

  • rjacobs committed 70dc2a5 on 8.x-2.x
    Issue #2406817 by rjacobs: Ensure markup filter is less aggressive.
    
rjacobs’s picture

Title: Global block-level tag filter cannot be disabled any may also be too aggressive » Global block-level tag filter cannot be disabled and may also be too aggressive
Version: 8.x-2.x-dev » 7.x-2.x-dev
Status: Active » Fixed

Ok, the few bits that needed to be captured in D8 have been ported.

Status: Fixed » Closed (fixed)

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