So I've come across a usecase where I'm trying to make a jump menu from the different flag links. Basically we are using flags to designate a specific location you are in. For instance, just for the sake of simplicity, Dallas, Odessa, Abilene. Based on that flag, several views show up different results (think of a car lot... different cars are available at the different lots in those cities). This is flags on taxonomy terms btw.

So we list the terms, and then we tried to set the "Link" as the url... but then realized that it literally is trying to render a link for that field. I could make a module that adds a link type "URL" and makes the URL the title of the link... but that feels REALLY hacky. Any ideas to help me just retrieve the flag link url?

CommentFileSizeAuthor
#8 flag-allow_views_output_of_url-2012702-8.patch1.83 KBgeneralredneck
#2 flag-allow_views_output_of_url-2012702-2.patch1.5 KBgeneralredneck
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

generalredneck’s picture

generalredneck
him/his
Primary language English
Location Texas, USA 🇺🇸
CreditAttribution: generalredneck commented
Version: 7.x-2.1 » 7.x-3.0-rc1

messed up on selecting the version

generalredneck’s picture

generalredneck
him/his
Primary language English
Location Texas, USA 🇺🇸
CreditAttribution: generalredneck commented
Status: Active » Needs work
FileSize
flag-allow_views_output_of_url-2012702-2.patch1.5 KB

So what I decided to do was to use the rewrite options since they don't techincally apply any way because of the fact that we overload the render function.

So by default I make Render as Link happen, however, if you unselect that, you will get just the URL. Note as of this patch it only works for normal links really... If another module passes on an HTML element... this screws the pooch.

Marking it as Needs Work but feel free to comment.

joachim’s picture

joachim CreditAttribution: joachim commented

I'm not really sure I understand your setup, or what you are trying to achieve.

> Dallas, Odessa, Abilene

These are taxonomy terms?
And users flag the one that they are in?

For starters, that seems like a very peculiar use of Flag module. Presumably you are only in one location at a time, so you're having to do legwork to ensure each user has only one term flagged. A more suitable architecture would be a simple term reference field on the user, which automatically enforces the 1-1 relationship.

> So we list the terms, and then we tried to set the "Link" as the url... but then realized that it literally is trying to render a link for that field

What URL? What field? Can you be more specific in your explanation please.

Is your patch adding new options? If so, it needs to specify defaults for them too.
Is it modifying the options from the parent class? If so, it needs to explain why it's doing that.
Also, a blank line between each option please, for clarity. And indent with spaces, not tabs.

Though it's probably not worth rerolling until I understand whether it's something we'd want to add to the module :)

generalredneck’s picture

generalredneck
him/his
Primary language English
Location Texas, USA 🇺🇸
CreditAttribution: generalredneck commented

First off, You are right, a simple term reference or entity reference would work wonderful here IF all the users were signed in. That's where flags come in. Your architecture allows for users (even anonymous ones) to be able to select items that they want to flag... I have implemented a rule to only allow one flag in this particular taxonomy vocabulary to be selected at any time.

with that said... forgetting the use-case totally... you can't use the flagging capability as a jump menu because the field handler ALWAYS returns a rendered link. Additionally there are several default views options that are available but do nothing because in the ops field handler, the render function is overloaded. These options include but are not limited to everything under "rewrite results".

So the part you are having trouble understanding is we I tried to use the flag link as the path field for my jump menu. What this did was cause the path to be something like %20%20%20
%20%20%20 because of the filtering that happens to a field that is inserted as the path value in a jump menu.

Simular things happen if you use the field as a token in "Rewrite the output of this field" on other fields. You get the literal link causing you to have to be careful what you use it for.

Having the ability to retrieve the url that a field link contains is valuable in these types of situation where you may want to build specially formatted links inside a view.

As for my patch and the options I added, I was merely implementing the options that views provides to you via the "Rewrite" section which is known as "alter" in the code. So yes, an explanation would be, "Implementing Rewrite functionality"...

Particularly, I was implementing "Output this field as a link". Which is what your module does by default. The patch then checks to see if the if that option is has been enabled... if it has, we get a link, otherwise, we get the flat URL.

The only glitch I find in this whole use-case for anonymous users is that javascript must be "enabled" by passing the $_GET['has_js'] parameter and simply predicting where people will use this URL would be hard.

joachim’s picture

joachim CreditAttribution: joachim commented

Ah right, now I get it. Thanks for the explanation :)

The reason the Views flag field outputs a rendered link is that it can't know what the link will actually be.

If the link just goes to the confirmation page, then that would perhaps be okay, but you would be losing the consistent CSS on all flag links.

If you're using JS links for your flags, then you need to have the wrapping classes and their CSS, otherwise the JS won't work.

+++ b/includes/views/flag_handler_field_ops.inc
@@ -57,6 +57,13 @@ class flag_handler_field_ops extends views_handler_field {
+		$form['alter']['make_link']['#default_value'] = 1;

Defaults should be set in option_defaults(), not here -- otherwise, you can never see what the stored value is.

generalredneck’s picture

generalredneck
him/his
Primary language English
Location Texas, USA 🇺🇸
CreditAttribution: generalredneck commented

Can you educate me a bit.. I'm ignorant?

Why exactly is Javascript necessary for a flag to be set for an anonymous user? Is it a security measure or what not? It would seem that you could set a cookie via the $_COOKIE variable on the back end if that's what you are trying to accomplish. And I"m sure I'm missing something here because this module has been through way too much for there not to be a reason.

I understand the reasoning for the JS links... but it seems like you could do something like make a link to a page with a ?destination="" on it to return back to the page you were at and still accomplish everything that happened during the AJAX.

I couldn't get confirm to work via anonymous either... which I thought I read somewhere you put "anonymous must have javascript and cookies enabled."

generalredneck’s picture

generalredneck
him/his
Primary language English
Location Texas, USA 🇺🇸
CreditAttribution: generalredneck commented

oooooooooo

// For all anonymous users, require JavaScript for flagging to prevent spiders
// from flagging things inadvertently.

generalredneck’s picture

generalredneck
him/his
Primary language English
Location Texas, USA 🇺🇸
CreditAttribution: generalredneck commented
Status: Needs work » Needs review
FileSize
flag-allow_views_output_of_url-2012702-8.patch1.83 KB

fixing the default options for now... still needs work though...

joachim’s picture

joachim CreditAttribution: joachim commented
Status: Needs review » Needs work 
+++ b/includes/views/flag_handler_field_ops.inc
@@ -45,6 +45,7 @@ class flag_handler_field_ops extends views_handler_field {
+    $options['alter']['contains']['make_link']['default'] = TRUE;

Are you sure that's the right array structure? What is 'contains'?

Also, can you match the format for the assigned value please?

+++ b/includes/views/flag_handler_field_ops.inc
@@ -55,8 +56,13 @@ class flag_handler_field_ops extends views_handler_field {
+    $form['alter']['path']['#disabled'] = TRUE;
+    $form['alter']['absolute']['#disabled'] = TRUE;
+    $form['alter']['replace_spaces']['#disabled'] = TRUE;
+    $form['alter']['external']['#disabled'] = TRUE;
+    $form['alter']['path_case']['#disabled'] = TRUE;

I don't know offhand what all these do, so they each need an explanation of why they need to be disabled in the handler settings.

+++ b/includes/views/flag_handler_field_ops.inc
@@ -158,6 +164,15 @@ class flag_handler_field_ops extends views_handler_field {
+    if (!$this->options['alter']['make_link']) {
+      $link_type = $flag->get_link_type();
+      $link = module_invoke($link_type['module'], 'flag_link', $flag, $is_flagged ? 'unflag' : 'flag', $entity_id);

This needs a comment to explain what this special handling is about.

+++ b/includes/views/flag_handler_field_ops.inc
@@ -158,6 +164,15 @@ class flag_handler_field_ops extends views_handler_field {
+      //TODO: Make this work for other link types.

Needs work then... :)