Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
the attached patch is a flag Ops field handler for generic entities.
it extends views_handler_field_entity and implements functionality from flag_handler_field_entity_ops and flag_handler_relationship_content.
there are some @todo markers for code duplication which would require refactoring flag_handler_relationship_content.
maybe related to, but not depending on #1035410: Flag any entity and #1315850: Add support for Entity API properties
Comment | File | Size | Author |
---|---|---|---|
#56 | 1362298-independent-query-backend-flag-links-56.patch | 5.31 KB | bisonbleu |
| |||
#27 | 1-create-a-rule-page.png | 17.83 KB | AllanTheDream |
#27 | 2-rule-configuration.png | 38.45 KB | AllanTheDream |
#13 | 1362298_independent_query_backend_flag_links-13.patch | 5.31 KB | mh86 |
#12 | 1362298_independent_query_backend_flag_links.patch | 5.23 KB | mh86 |
Comments
Comment #1
dasjoComment #2
mh86 CreditAttribution: mh86 commentedreally? ;)
Comment #3
dasjosorry :) unstaged changes.
this one should be better
Comment #4
dasjowith all changes
Comment #5
loganfsmyth CreditAttribution: loganfsmyth commentedJust submitted a patch over here so you know. #1362704: Remove hook_views_handlers and fix API version
* You use "$content_type" in options_form, but it doesn't look like it is defined anywhere?
* Seems a bit odd to replace the entire form with the error instead of just replacing the 'flag' element.
* What is the benefit of this currently if it is only attached to nodes? Doesn't it just duplicate the views support that is already there?
Comment #6
dasjohi loganfsmyth,
thanks, i will look into your suggestions.
regarding
the patch allows to use flag in search api views for example.
i'm not an expert, so i would be asking if we can attach it to other entities as well?
Comment #7
jaxxham CreditAttribution: jaxxham commentedHi, I'm getting:
In views. Any ideas?
Thanks.
Comment #8
joachim CreditAttribution: joachim commentedSounds like the patch needs further work.
Comment #9
joachim CreditAttribution: joachim commentedThis hook doesn't exist in D7.
And more generally, I don't really get the point of this patch and this issue.
With #1035410: Flag any entity, I can make a view of any entity type and get a flag link on it with the relationship. Marking as postponed until someone explains to me why we need this.
Comment #10
mh86 CreditAttribution: mh86 commentedThe idea of this patch is to display the flag/unflag link on any kind of view, in particular on Search API views (and the Search API views integration uses the generic Entity API views tables).
Maybe we've missed something, and it's already possible with the existing code. Furthermore this patch just exposes the link for the generic node table (views_entity_node) and misses the other possible entity types. And maybe just adding an Entity API property for flag links is easier / more useful and does the job for views as well.
Comment #11
joachim CreditAttribution: joachim commentedI'm going to mark this as wontfix.
If I've misunderstood what this issue is about and what the patch does, please reopen and explain it :)
Comment #12
mh86 CreditAttribution: mh86 commentedRe-opening this issue with an updated patch for the new branch.
But first of all I'll try to explain it in a better way: Views has the ability of different query backends. By default it comes with the database backend, that of course supports all entity types. The Search API (and maybe others) have their own backend and can't use database specific fields. So at the moment I can't display a flag link field on a Search API listing.
Views already has a solution for that, as it includes generic 'views_entity_' . $entity_type base tables, that can be used by any backend and do not rely on database queries, e.g. this is used for the node edit links.
Now this patch adds a flag handler to the generic tables. Thus is can be used with Search API and even the Database backend, which, unfortunately, duplicates the functionality with the existing flag handler.
The patch might need some further tweaking (code reuse, comments), but let's first clarify how we can get something like this into the flag module.
Comment #13
mh86 CreditAttribution: mh86 commentedUpdated patch that fixes php warnings with empty views results.
Comment #14
joachim CreditAttribution: joachim commentedI appreciate the work you're doing on this, and I apologize for the delay in reviewing.
I need to take some time to properly get my head round this different query backend malarkey -- any links you can post to blog posts / tutorials / other gentle introductions would be much appreciated.
Comment #15
kaizerking CreditAttribution: kaizerking commented@#13 this patch could not be applied
Comment #16
mh86 CreditAttribution: mh86 commentedThe original Views issue for generic entity fields is here: #1172970: provide a unified way to retrieve result entities
I see the current patch only as a starting point on how the code could look like, but I'm not really happy with it yet. It duplicates the flagging handler for the database backend and there is some code duplication. Replacing the existing database flag op handler with this code isn't a good idea either, as it can't join to the flagging table and needs to query each entity (if it's flagged) separately, which will be less performant.
@kaizerking: are you using the latest 3.x dev snapshot?
Comment #17
kaizerking CreditAttribution: kaizerking commentedyes, I have netbeans git cloned
Comment #18
joachim CreditAttribution: joachim commentedSorry, that issue is still Greek to me. Can you give me an example of how this is actually used?
Also, AFAIK netbeans is rubbish at applying patches.
Comment #19
mh86 CreditAttribution: mh86 commentedyep, use Search API with Views and a table listing and try to display the flag link in a column
Comment #20
joachim CreditAttribution: joachim commentedOk, but it's more this bit that I need explaining in words of one syllable or less:
I still have no idea why views has a load of 'views_entity_FOO' tables, or what a query backend is.
Sorry to be dense.
Comment #21
mh86 CreditAttribution: mh86 commentedI'm not a Views expert, but I'll try to explain it:
Views allows to have different types of query backends, but only implements the database backend. Other modules may implement different ones, like the Search API in order to connect to different sources, like Apache Solr.
The way field data values are retrieved is usually different (sql selects in the database backend, entity loads + field values extraction in Search API, etc...). So actually, you would have to re-implement your field handler for each backend type.
Some of the fields are pretty simple, like a node edit link, and can be made reusable across the backends. Instead of directly accessing the node id from the sql result, the full entity is loaded in a generic way and used for constructing the link.
For example, if you look at node.views.inc, you'll find following code:
The first line just tells that the old database specific implementation has been moved to the generic entity table (views_entity_[entity type]) and fields from this table can be used with any backend.
While I see that the current flag link database specific implementation has some advantages, it is still a bit comparable to the node edit link use case.
I have no idea if any of this information helps ;-)
Comment #22
joachim CreditAttribution: joachim commentedYes, that's a huge help thank you!
I actually get it now. (And it seems rather crazy to me, but that's out of the scope of this issue!)
> I see the current patch only as a starting point on how the code could look like, but I'm not really happy with it yet
Does your patch still need more work?
Comment #23
mh86 CreditAttribution: mh86 commentedI was taking a look at the latest patch again: it might need some documentation and variable naming improvements, but the thing that bothers me is the duplication of flag handler for the database backend.
With this patch you would have two possibilities for adding a flag link: first you can use the new "Content: Flag links for entities" handler, and second you can add the flag relation and the according flag link handler. Having both will confuse people, and I don't know yet, how to best solve it (not sure if a better naming of the handlers will be enough)
Comment #24
bennos CreditAttribution: bennos commentedusing flag relation is the typical way in flag module. My vote for this way. It woul be more consistantly
Comment #25
joachim CreditAttribution: joachim commentedIn light of the above two comments I'm going to set this back to CNW. I'm not entirely sure what is still needed here, but it looks like this patch has some more development to go before being stable :)
Comment #26
mvcmh86, thanks very much -- this code works beautifully for me using a view with a search api backend.
it seems like the only problem here is a usability issue in the case of the database backend. is it possible to simply make your code not run for the default database backend?
Comment #27
AllanTheDream CreditAttribution: AllanTheDream commentedHello All,
The patch in comment #13 works fine at adding the flag links as fields in a Search Index view(a view of type search index) - I have applied the patch to the flag module, updated the database, and the flag links field appeared in the list of fields in the view which wasn't the case before applying the patch. The trouble am getting with this is that the patch seems to have changed a number of things in the database and it has messed up some configuration or code in the flag module, let me get you up to speed on what I did and this is before I applied the patch;
The Flag and the Rule seemed to work fine, the user could only flag a single node of this node type at a time.
- default_preset is the flag's machine name
My question is, is this patch messing up the flag code and the database that the flag can't be trimmed anymore, and I can't unflag? Please help me out, and give me some insight into this.
Comment #28
robinvdvleuten CreditAttribution: robinvdvleuten commentedIt works correctly in combination with the Search API and Views. Thanks!
Comment #29
zilla CreditAttribution: zilla commentedis this almost RTBC, or are the issues in #27 above still persistent?
Comment #30
pinkonomy CreditAttribution: pinkonomy commentedI tried the patch on #13 on a search api view . It works fine,the flag is appearing as a field in the View. (The view is of type Solr index).
But this field is of type "Content" ,not "indexed node" . Is this fine or should also be indexed?
thanks
Comment #31
pinkonomy CreditAttribution: pinkonomy commented@robinvdvleuten Which patch did you test?
Comment #32
pinkonomy CreditAttribution: pinkonomy commented#13 doesn't work for me :(
Anyone help on this please?
EDIT:After trying #13 I can see a Flag field in the view ,but its not indexed.Is this correct or should be indexed?
Comment #33
pinkonomy CreditAttribution: pinkonomy commentedAlso,how can I create a view search api with only flagged content?This needs a reference of the flag correct?Does this need another patch?
Comment #34
mas0h CreditAttribution: mas0h commentedAny update on this?
Comment #35
campbdy CreditAttribution: campbdy commentedSubscribing
Would like to be able to add relationship to Search API view to get flags for the current user, i.e. Flags: compare_bookmarks (by current user), as you can in 'normal' views.
Comment #36
joachim CreditAttribution: joachim commentedThere's no need to subscribe to issues like that any more: just use the 'follow' button.
And for general information: this issue is not going to be advanced by the current maintainers, as it involves areas that are out of our expertise (well, mine at least). The only way this will move forward is if people who need this feature work on it and create a patch which is reviewed by other users who need this feature.
Comment #37
marcoka CreditAttribution: marcoka commentedapplied the patch. the question now is where can i add the flag link. i created a view using search api and added indexed fields. if i go "add fields" i can see no flag link i only see the fields indexed by search api.
edit: this will only work if the NODE ID is indexed. Otherwise no link field appears :)
if i select it the i get "missing plugin error"
p.s this is a really useful idea.
Comment #38
khiminrm CreditAttribution: khiminrm commentedpatch from #13 works for me (Flag 7.x-3.5)
Comment #39
dimapanin CreditAttribution: dimapanin commented@mh86 thank you, patch from #13 post works (Flag 7.x-3.5).
Comment #40
pinkonomy CreditAttribution: pinkonomy commentedPatch from #13 works,however when added in a view,it says : Content: Flag link for entities
Is this fine or should this field be indexed like the other fields?
thanks
Comment #41
7thkey CreditAttribution: 7thkey as a volunteer commentedPatch #13 works for me using the latest dev version.
Thanks!!
Comment #42
Nkendall CreditAttribution: Nkendall commentedHey everyone, the update on 10/18/2015 seems to have broken patch number 13. This is way above my head, but the issue seems to be that the code at line 200 in includes/views/flag.views.inc has changed the data alter function. I'm not sure how to modify the new function, but from my novice's eyes that's all I can figure...
Comment #43
criscomSame here, update to Flag 7.x-3.7 breaks my site (WSOD).
PHP Fatal error: require_once(): Failed opening required '/var/www/mysite/sites/all/modules/flag/includes/views/flag_handler_field_entity_ops.inc' (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/mysite/includes/bootstrap.inc on line 3186
Comment #44
ibuildit CreditAttribution: ibuildit commentedConfirming it does not work with 3.7 but works with 3.6
Comment #45
aseabrook CreditAttribution: aseabrook as a volunteer commentedDitto. Can we get an updated patch?
Comment #46
monstrfolk CreditAttribution: monstrfolk commentedThis worked on 3.7 dev for me.
Comment #47
nicxvan CreditAttribution: nicxvan as a volunteer commentedThis allows me to add the flag / unflag link, does anyone have any guidance to how to get a relationship or sort from this? I need to sort the results based on which items a user flagged.
Comment #48
joachim CreditAttribution: joachim commented> Confirming it does not work with 3.7 but works with 3.6
The patch applies on dev at least:
Whether it actually works or not I don't know.
> This worked on 3.7 dev for me.
There's no such thing... 3.7 is a fixed release. Dev is the latest from git.
Comment #49
liland CreditAttribution: liland commentedPatch #13 didnt work now even on Flag v3.5
I can see new field in Views "Flag link for entities", but when i add this to my View i get error - handler is broken or missing.
Node ID is indexed (comment #37)
If someone can help - I will be grateful.
Comment #50
oldspot CreditAttribution: oldspot as a volunteer and at Zoocha commentedJust applied patch #13 to 3.7 and all went well:
Cleared caches and the "Flag link for entities" appeared in my search api view. Thanks.
Comment #51
Goodmood CreditAttribution: Goodmood at AnyforSoft commentedHi @liland.
I had the same problem after applying of the #13 patch.
So I had a new field "Flag link for entities" in my views, but after adding it received "broken handler".
I'm using some contrib profile on website with included organic groups module. After checking my VCS I found, that new handler from patch #13 was placed in wrong directory (og module instead of flag). After replacing file I found that flag field working well for me.
Probably you have the same problem?
Best regards.
Comment #52
ishan.dikshit CreditAttribution: ishan.dikshit commentedAnyone facing any issues with flag 3.9? It doesn't work for me.
Comment #53
criscomThe update 7.x-3.9 only worked with the patch in #13. We haven't edited the views yet but the field has "Flag link for entities". So as of now all good.
Comment #54
joachim CreditAttribution: joachim commentedCould some of the apparently large number of people using this patch actually take the time to reroll it and review it? Contribute back please, as well as benefiting from other people's work!
Comment #55
Marcus 78 CreditAttribution: Marcus 78 commentedWorkaround
Use https://www.drupal.org/project/views_field_view
Use node id as a field in index
Create a view with contextual filter on node id, relations to the flag that you want. Lets call it flagview
Add the flagview inside your search view and use the node id a the contextual filter on the flagview
All modules, no code
Drawbacks, might be a bit slow but it worked for my project
Comment #56
bisonbleu CreditAttribution: bisonbleu commentedNeeded to apply the patch in #13 to a fresh version of flag (7.x-3.9). Re-rolled the patch against 7.x-3.x.
Comment #57
destinationsound CreditAttribution: destinationsound commentedTested #56 on the latest version and it works fine, however, it doesn't address the Filter or Sort Criteria integration. It would be great to have Flag fully integrate with Search API Views including the various criteria options present in a regular view integration.
Any idea how difficult it would be to add Filter and Sort Criteria options to this patch?
Comment #58
hongqing CreditAttribution: hongqing commentedIs there a patch for Drupal 9? Thanks.