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.
I have a site where the majority of users never register or log in, but do access content. I was using the flag_content module, which did allow anonymous flagging, and have switched to this module. Is it possible to allow anonymous users to use a flag?
Comment | File | Size | Author |
---|---|---|---|
#91 | flag_anonymous.patch | 38.29 KB | quicksketch |
#88 | flag_anonymous.patch | 24.99 KB | quicksketch |
#87 | flag_anonymous.patch | 20.81 KB | quicksketch |
#71 | flag-271582.patch | 16.76 KB | ultimike |
#67 | flag-271582.patch | 16.71 KB | ultimike |
Comments
Comment #1
Mike Sances CreditAttribution: Mike Sances commentedI was able to achieve this by commenting out lines 636-638, 184-186, and modifying line 448 to
Sorry, I don't know how to make a patch file.
Comment #2
quicksketchBecause of the way flag keeps a status on flagging, allowing flags for anonymous users won't work quite the way you expect. That is, all the anonymous users on the entire site basically count as a single user. A piece of content flagged twice by two users will still only count as one.
In order to figure out anonymous flagging, we'd need to develop this seriously. That is, IP Address recording, use of cookies or session, and "moving" those flags over when the user signs up for the site.
Comment #3
mooffie CreditAttribution: mooffie commentedI think flag_content's flag is 'global'. Perhaps we could make our 'global' flags work for anonymous users too. But we certainly don't want an anonymous to be able to *unflag* a node.
Interestingly, different people see very different things when they see 'support anonymous users'. There's a feature request in views_bookmark's queue with at least four different interpretations on this.
Comment #4
Mike Sances CreditAttribution: Mike Sances commentedApparently Google's crawlers like to flag every node on my site...just a warning to anyone else who wants to try my method.
Comment #5
janusman CreditAttribution: janusman commentedJust my $.02 about how I think "anonymous users should flag":
Case 0: Keeping Robots out!
For nice robots: use rel=nofollow in flag links. For misbehavers: uhmm... don't tell me we would have to CAPTCHA this! =|
Case 1: Flags that are per-user (like bookmarks), and current user is anonymous
Case 2: Flags that are global, and current user is anonymous
Not sure yet =)
Comment #6
moshe weitzman CreditAttribution: moshe weitzman commentedI could usw the exact implementation that Moofie described:
Comment #7
tuti CreditAttribution: tuti commentedI would also like to see anonymous flagging be added
Comment #8
techninja CreditAttribution: techninja commentedI second that request.
And yes, I agree.. Cookies can be a good way to go, if not just attaching to Drupal's already setup php session id. Also, to the maintainers, YES this an annoying aside for all those that do just fine flagging content for logged in users, but for how open and incredibly useful this project is, it's almost not fitting to the theme of the project to not include it.
Comment #9
techninja CreditAttribution: techninja commentedAh well.. turns out Session Favorites floats my current project just fine. Hopefully anyone else looking for this functionality will find this useful.
Maybe next year for the flag module ;)
Comment #10
mooffie CreditAttribution: mooffie commentedComment #11
mitchell CreditAttribution: mitchell commentedhttp://drupal.org/project/lazyreg seems to fit for #5: Case 1
There's a patch for 5.x but 6.x seems delayed.
Comment #12
jiakomo CreditAttribution: jiakomo commentedWhen I first installed this module, I navigated to /user/access, only to find out eventually that "Anonymous users may not flag content".
So yes, anonymous flagging would be great, please, for global and non-global flags.
Comment #13
3lite CreditAttribution: 3lite commentedI'm using this module to let guests flag a node [I like it or I didn't like it] they are all anonymous users... =/
Comment #14
dropchew CreditAttribution: dropchew commented+1 subscribe
Comment #15
mitchell CreditAttribution: mitchell commentedI'm going to try to port lazyreg today; this seems like the ideal solution. If you have time to help, please email me or ping me in irc.
Comment #16
chirale CreditAttribution: chirale commentedCould the Session API module be useful for an alternative approach? The Session Favourites module use it to store a favs list based on cookies and session ID. Session Favourites works for anonymous and authenticated users, but Flag has a more advanced interface, so porting this functionality to this module can be a valid alternative to lazyreg.
Comment #17
chirale CreditAttribution: chirale commentedI attach a patch to the flag directory (6.x-1.0-beta6): it implements the Session ID provided by Session API module to distinguish one anonymous user from another, adding a new row into the database table named 'sid', filled with values provided by session_api_get_sid() (only this Session API function is used). It uses #1 method to allow anonymous users to flag content.
This method is an alternative to Lazy Registration proposed above: it implies some changes to the code apart these (which provides only basic functionalities), and this approach should be tested deeply, especially when a single authenticated user has multiple sessions opened: now a flags are assigned to a uid + sid couple, but if it causes problems on registered user this method could be used solely for anonymous users (uid = 0).
TODO:
Comment #18
chirale CreditAttribution: chirale commentedHere the right patch.
Comment #19
mooffie CreditAttribution: mooffie commented(chirale, I haven't yet checked out your code, but I'm in favor of the idea. I see there's a demand for this feature and, a bonus, your patch seems small.)
Comment #20
chirale CreditAttribution: chirale commentedPrevious patches comes with an error on the first page visit by a user
since the Session ID (sid) is not assigned. This new patch solve this issue, using a fallback value (sid = 0, not assigned on session ID table) if sid is empty.
The query is executed to check whether a content is flagged or not, so an empty result for a new user is valid, but interaction with uid field should be tested deeply (since I use this function primary for anonymous users, any suggestion and improvement on this point is welcome).
Now a single logged-in user on two different browser can have two different flagged content, maybe this patch can be changed to use sid only for anonymous users, and uid for logged-in user. Even in this case, sid / uid interaction should be considered, since someone can ask to preserve the flagged content for an anonymous user that became a new user (after a registration or a log in).
Comment #21
quicksketchLooks to me that queries like this:
Are likely to cause troubles for authenticated users. If a user logs in and flags, then log out, logs back in, then won't they get a different session ID? I haven't looked into Session API to see how such a situation is handled.
Feel free to actually remove the lines of code that are no longer needed rather than commenting them out, we'll still be able to see the changes in the patch file. Is there any way we can make this requirement optional, rather than hard-coded? That is, Flag would continue to work as-is for authenticated users, but when Session API is enabled, you get anonymous voting?
Great looking work so far! I'd be happy to get this into flag.
Comment #22
chirale CreditAttribution: chirale commentedThanks quicksketch. On this patch I've separated authenticated and anonymous users.
Anonymous users: uid = 0, session id (sid) assigned
Authenticated users: uid = current user ID, sid = 0 (not assigned)
On flag_content, table will be:
Where only uid or sid are filled (uid for authenticated, sid for anonymous). In the example there are three users, one authenticated (uid = 1) and two anonymous (session ID 2 and 5).
I've also added Session API as required module to install Flag on the info file.
Pending issues:
Please test on a new patched installation of Flags (uninstall the old one to delete db tables), since database structure changes can probably leads to weird errors on existing Flag data.
Comment #23
mitchell CreditAttribution: mitchell commented@chirale: Thank you for your work on this; this is a very exciting patch, and it seems like you're getting close :-))
When you said you added session_api to flag's dependencies, that gave me the idea to go ask the session_api developers to #360701: Port to 7.x and to create a core feature request: #360705: Add wrapper layer around authenticated and anonymous users so that they can be treated as one and the same. It seems like many modules will be able to learn from your patch here to make their functionality accessible to anonymous users.
Comment #24
quicksketchIf possible I'd *really* like to make Session API optional, not required. Flag should be well written enough that we should be able to do this with only a few
if (module_exists('session_api')) {
calls. It's great news that authenticated users have a session id of 0 anyway, since that makes it so that we can easily enter a default value for authenticated users when Session API is not available.Comment #25
chirale CreditAttribution: chirale commentedAt this time I've included it because there aren't these controls, and running the patch without that module causes a white screen. When these controls will be introduced, Session API can be switched to optional rather than required. If Session API is unavailable, however, #1 should be modified to block anonymous role selection on Flag admin screen, and a message referring to Session API to enable that role should be included there. Otherwise both sid and uid will be 0 for anonymous users.
Comment #26
quicksketchYep great. That was what I was expecting. Since we only need Session API for anonymous users, Flag should continue to operate as it does now for authenticated users, then if you have Session API it will enable use for anonymous.
Comment #27
chirale CreditAttribution: chirale commentedHere's the new patch according to #25 requirements.
Comment #28
quicksketchLooking good. Some more comments:
- Don't use tabs in the code, two spaces is standard for indentation.
- Always use brackets for IF statements, even if it's only one line.
- There's a call to session_api_available(), but if the module isn't enabled that's going to cause a function not found error.
We also might have to do a database update, as right now uid = 0 means that the node is flagged "globally" for all users. At the same time though, perhaps we can simply make uid/sid = 0 mean a global flag, since anonymous users should always have an SID.
Comment #29
chirale CreditAttribution: chirale commented"make uid/sid = 0 mean a global flag" seems to me the right solution, if we don't want to implement an additional "global" flag field.
Comment #30
jwilson3I've worked out anonymous flagging for Drupal 5 based off the patch in comment #27. Its incomplete / broken and you can find out my problems (has to do with views) in my issue: #374278: Allow anonymous users to flag content (D5 backport).
Comment #31
chirale CreditAttribution: chirale commentedThis is the 6th version of the patch (made from 6.x-1.0-beta6). I've cleaned up the code according to #28 (I run code-style.pl, now it only complains that there are "mixed case function or variable names" errors on original code), introduced the flag_get_sid($account) (that call session_api_get_sid() where session_api is available) function and global flag support (sid = 0, uid = 0).
I've made several tests (without Flag actions enabled, please test it) and it works for global flags with and without anonymous flagging enabled, and with authenticated users and anonymous users with standard flag.
jrguitar21: nice to see a D5 version! Take a look to this patch, maybe it can be useful.
Comment #32
quicksketchNice! This looks pretty much ready to go to me! Views support even. Looks great. I've been thinking we need to end this "beta" business and make a stable release. However, I'd like to save this feature for 1.1 (especially considering we need to finish the D5 backport).
Comment #33
jwilson3I looked at the code in #31, and it seems like it would work but correct me if im wrong in that the views display is going to require now an additional query (in the _is_flagged func) to check to see if a flag is flagged for a specified uid / sid pair?
so please correct me if im wrong but, is it like this?:
1) complex views query with lots of left joinage, and passing along the extra fields 'sid' and 'uid' for the ride into the 'handler' method
2) handler method uses those two fields, as well as the content_id (flag id) in the _is_flagged query to detect if its flagged for said user.
... guess I'm just a little confused, and my concerned for performance makes me ask why there has to be two queries to detect if its flagged or not.UPDATE... D5 Backport
It looks like D6 has been functioning this way for a while with the necesity for additional queries in the $flag->is_flagged() stuff, so now I don't feel as bad for adding overhead. I backported that function to D5 and it fixed my problem. Have a look at comment #2 on the backport page i created for an updated and working patch for D5.
Comment #34
mooffie CreditAttribution: mooffie commented(@jrguitar21, the Views integration doesn't call $flag->is_flagged() (or $flag->_is_flagged()). In other words, no extra query is fired for each row.)
Comment #35
szy CreditAttribution: szy commentedCould you please update the patch to work with rc1, and then with stable 1.0? :]
Thank you! :]
Szy.
--
Warsaw, Poland | Fjords of Norway
Comment #36
quicksketchHere's a reroll that works with the latest 6.x version.
This version adds an extra few lines to hook_user() to automatically transfer flaggings from an anonymous user to a logged-in user when the user logs in. Unfortunately this caused a few oddities with Session API, since the users session is changed when they log-in, and by the time hook_user is fired the global $_SESSION variable has already changed. To solve this problem I put a call to flag_set_sid() in hook_init(), so we set the user's Session API sid before the login process begins.
I also added a hook_update() to update existing databases.
This patch does not yet perform any sort of cleanup of old sessions from the flag_content table. I was trying to figure out how Session API usually does this, but its current API doesn't seem to be used by other modules. I've opened an issue over there to make some changes that would make its cleanup suitable for use with Flag. See #380550: Create a More Helpful Cleanup API. If that doesn't get approved, we might need to do our own kind of cleanup in a hook_cron().
Comment #37
quicksketchAh, and the patch.
Comment #38
szy CreditAttribution: szy commentedGreat! :]
Thank you, it's one of my most favourite modules.
Szy.
Comment #39
sunWe want to integrate with http://drupal.org/project/visitor instead. We managed to get some experienced developers, webchick, jhedstrom (Session API), Eaton (Voting API), John VanDyk, and me to join forces on a unique API for handling "visitors" (anonymous and authenticated users) in Drupal. See #324743: Puzzle pieces for the intent and underlying concept.
Comment #40
quicksketchDoh... well I guess it's a good thing we didn't add this to 1.0. Sounds like the maintainer of Session API is on board with merging with Visitor. At the same time it's disappointing that after acknowledging there were already 5 solutions we went ahead and made yet another one under the pretext that "this one will be better than those other ones". :P
I'm moving this to postponed while the dust settles. :(
Comment #41
chirale CreditAttribution: chirale commentedSince the Session API code actually exists, maybe we can make flag_get_sid() adaptable on (existing) Session API and compatible with (oncoming maybe) Visitor? Developing a new module can require some months, so why we have to wait? Personally I like concept like Cache Router and WYSIWYG (the module, not the approach :-D), that let developers free to choose from different methods to do the same thing (caching or choose an editor).
Comment #42
Nilard CreditAttribution: Nilard commentedAny progress?
Comment #43
crizsubscribing
Comment #44
crizsorry, changed status unintended...
Comment #45
Coupon Code Swap CreditAttribution: Coupon Code Swap commentedsubscribing
Comment #46
chilledoutbeardedman CreditAttribution: chilledoutbeardedman commentedFollowing the trail on this was fun...
It looks like this was paused to wait for the completion of the new visitor module (#39 above). Then looking at the visitor module, we see that the last cvs update was about 6 months ago, right about the same time that the visitor module was conceptualized in Puzzle Pieces.
It seems like there is plenty of interest in this feature, based on the number of people commenting on it. Is this still in the works? Does anyone know what the status is or what the current plans are for this update or the visitor module? Is there somewhere else to find more information about all of this aside from Puzzle Pieces, the visitor module page, and this page?
Comment #47
quicksketchYeah after all the hubbub about "Visitor" and the universal handling in core, I think the best approach is what we already have (#37 above). The other proposed approaches would require a full dependency on another contributed modules, versus this approach is "install only if you need it". Development has died down a little bit on Flag since we got a 1.0 out the door and the maintainers are both busy with other projects at the moment. Let's bump this back to needs work, get a reroll and start testing again.
Comment #48
chilledoutbeardedman CreditAttribution: chilledoutbeardedman commentedThat last tag I added should have been "anonymous flagging" (not "anonymous tagging"), but I mistyped and can't find how to edit the tag.
Comment #49
chilledoutbeardedman CreditAttribution: chilledoutbeardedman commentedLooks like our last two comments came in at the same time and my status overwrote yours. Setting back to needs work re #47.
Comment #50
mitchell CreditAttribution: mitchell commentedIn general, if there are other issues that can be tagged anonymous flagging, that could help people keep abreast to our going consensus.
credit to fago for isssues tagged rules 1.0.
Comment #51
mitchell CreditAttribution: mitchell commentedFixing status.
Comment #52
crizgreat, the patch from #37 works fine with flag 6.x-1.0 btw. already using it on a productive site... ;)
Comment #53
mitchell CreditAttribution: mitchell commentedOutput of patch in #37
(aside: new component categories would be cool! this could be 'Provided module integration' instead of 'User interface')
Comment #54
parrottvision CreditAttribution: parrottvision commentedwill be awesome! subscribe
Comment #55
marvix CreditAttribution: marvix commentedBad to force the visitor to flag a node, keep it open, and add option to store what he flagged based on cookies & session.
subscribe!
Comment #56
cashwilliams CreditAttribution: cashwilliams commentedI'm also using the patch from #37 in a production site. Thanks for the good work!
subscribe!!!
Comment #57
ju.ri CreditAttribution: ju.ri commentedthanks for this! works great on my site. two aspects seem kind of unsolved: the cleanup of the session ids and the mass flagging by search engines. can I put a "nofollow" somewhere to at least keep out google?
Comment #58
jrust CreditAttribution: jrust commentedworking great against flag 6.x-1.1. I added this to robots.txt to prevent any false flagging:
Disallow: /flag/
Comment #59
AlxM CreditAttribution: AlxM commentedThis is working great for everything except global flags, when logging out all global flags i have set are unflagged.
Hope someone can help and this does work really well for non-global flags
Thanks
AlxM
Comment #60
mattiasj CreditAttribution: mattiasj commentedGreat feature that can be used for like-functionality on sites.
Comment #61
parrottvision CreditAttribution: parrottvision commentedwith the exception of global flags does anyone think this might make it as contributed into the module?
Comment #62
gulliverrr CreditAttribution: gulliverrr commentedHi Mike @ #1,
could you please explain a bit more as these lines dont correspond to anything relevant in the latest 6.x version. I can only assume the line to be edited to:
'#options' => user_roles(),
is @ 692 in file flag.module.
Your solution is good enough for me as I want global flags for anon users without intelligence. One flag as inappropriate should unpublish the content and inform moderators, so I dont really want to load the solution with SessionAPI etc.
Thanks
Comment #63
gulliverrr CreditAttribution: gulliverrr commentedMike replied in a PM and his line numbers from #1 are refering to the 5.x module and not 6.x.
Thanks for the clarification Mike
Comment #64
ultimikesubscribing
Comment #65
ultimikeI just applied the patch from #37 and the anonymous functionality appears to work great for the flag I have that needs the anonymous visitor support.
I am having an issue with another flag I have on the site that doesn't allow anonymous users to utilize. I think the issue I'm having is related to the patch from #37 because what I'm trying to do works on a different site with an unpatched version of Flag 6.x-1.1. Here are the details:
Flag1:
- global=no
- roles that may use this flag=anonymous users, authenticated users
- What nodes this flag may be used on: story
Flag2:
- global=no
- roles that may use this flag=content admin
- What nodes this flag my be used on: page
The idea for Flag2 is that the site's content admin users can Flag various pages around the site. Then, using Views, I'd like to create a block that lists all the Flag2 flagged pages for all visitors (including anonymous) to view. Relevant details about the view:
- Relationship: Flags: Flag2 by any user (include only flagged content by any user)
At this point, everything works great on the site that has the patched Flag module except for the fact that anonymous users don't see the Flag2 view (block). When I go into the flag/includes/flag_handler_relationships.inc file and comment out the code added by Patch #37:
The Flag2 view works as expected, but it breaks the anonymous user flagging capabilities. Perhaps this bit of code needs some sort of conditional around it?
I further confirmed the issue by creating the exact same Flag2 and View on a site with an unpatched version of Flag 6.x-1.1 and not seeing the issue.
Suggestions?
Thanks,
-mike
Comment #66
quicksketchThanks for the report mike, but this issue should stay as a feature request that "needs work", since it's not a bug Flag until it's been committed. Though it would definitely be good to correct this behavior and include the fix in the patch.
Comment #67
ultimikeNate,
Good point about the "category" - my bad.
Anyway, I believe I've fixed the issue by wrapping the relationship definition in a conditional to make sure the flag is available to anonymous users. If not, the relationship to the Session ID doesn't get included. It seems to have fixed the problem.
There's a chance that a similar fix needs to be made in the "includes/flag_handler_field_ops.inc" file, but I haven't had the time to think of a good test case for it.
I've re-rolled the patch against the latest -dev version of the module and attached it here.
-mike
Comment #68
quicksketchThanks, though rather than checking $user->roles against $flag->roles, we should just be using
$flag->user_access($user)
, since Flag actually has a method just for this purpose. This makes it so that we could potentially have access granted on criteria other than roles.Comment #69
ultimikeHmmmm... I'm not sure I follow you...
The code that I added simply checks to see if the particular Flag is available to anonymous users:
The check isn't dependent on a particular user's role, but on the roles assigned to a particular flag.
I'm not sure how a user_access($user) call will fit in here...
Also - I found a small bug in my previous patch file having to do with flag.install - I'll re-roll and post once we iron out this user_access() issue.
-mike
Comment #70
quicksketchOh, I'm not making much sense, sorry I saw role checking and immediately jumped conclusions without reading the rest of the code. Never mind, that's an excellent approach. :-)
Just to have one last whimper, maybe this would be a shorter way of saying it:
if (array_search(DRUPAL_ANONYMOUS_RID, $flag->roles) !== FALSE) {
Comment #71
ultimikePhew - thought I was missing something big.
Good point about the array_search() call - seems like every time I need to search an array, I implement it a little differently. Regardless, I made the change and the updated patch is attached.
Thanks,
-mike
Comment #72
swentel CreditAttribution: swentel commentedI'm running this patch on a dev site and their is a major problem when page caching is turned on. Only the first user can flag, all other users will see the 'Bad token. You seem to have followed an invalid link.' message, simply because their session is different from the first time the page got cached. Not sure what the best approach is here to fix that.
Comment #73
pvhee CreditAttribution: pvhee commentedSubscribing
Comment #74
dirksonii CreditAttribution: dirksonii commentedsubscribing.
Comment #75
turadg CreditAttribution: turadg commented+1 subscribe
Comment #76
mcpuddin CreditAttribution: mcpuddin commentedWhy not just use the the "Plus 1" Module with the Voting API? It has the following features:
1) AJAX
2) Extensive Views Support
3) Session based voting
4) Session time-throttling to prevent fradulent votes
The only two things that are lacking is:
1) If you wanted to add multiple types of flagging
2) Add actions after every flagging
Comment #77
jhedstromRecent changes to Session API now persist the assigned sid across simple login/logout session changes, which should help out with this patch.
Comment #78
crea CreditAttribution: crea commentedSubscribing. Does this patch need more testing ?
@macpuddin: you can't compare "Plus 1" to flag cause it's whole different module with different use case (even while sometimes it crosses with Flag)
Comment #79
gulliverrr CreditAttribution: gulliverrr commentedIs it planned for these changes to be included in a proper release soon/at all?
Comment #80
quicksketchThis feature is planned for the 2.x version of Flag, though it's unclear how long it will take to implement this feature properly and get out a 2.0 version. There's a serious issue with listing flagged content in Views, as noted in #377396: Number of elements must be positive in /includes/database.inc on line 241 that should be fixed before this is committed.
Comment #81
Lukas von BlarerHi
I am trying to get this patch to work. I am using the stable version version on the drupal project page. I guess because the versions do not match with the diff patch, it isnt working.
Could anyone give me the right version to patch or even the patched version?
Thanks in advance.
Lukas
Comment #82
Lukas von BlarerHi again
Is there nobody to help me out?
Thanks
Lukas
Comment #83
quicksketchLukas, the current patch won't apply to any version of Flag. Even if it did, it's marked "needs work" because it does not work fully and I'd suggest avoiding trying to use it unless you intend to develop it further.
Comment #85
Lukas von BlarerHi quicksketch
So how are you developing if it is not working at all? What bugs are remaining? I could really need this...
Thanks
Lukas
Comment #86
quicksketchNo one is currently developing it, it needs to be manually updated and then developed from there. I've been working on the 2.0 version of Flag recently though so hopefully we'll come back to this soon, since it'd be the main feature and reason for a 2.0 version.
Current problems:
- The patch does not apply any more and needs updating to the 2.x code.
- Anonymous flagging does not work with the page cache enabled (As noted in #72).
- Anonymous flags do not show up properly in views (As noted in #80 and #65).
- Sessions need to be cleaned up on cron and nofollow needs to be added to links to prevent search-engine crawling (As noted in #57)
Comment #87
quicksketchHere's a patch that is nearly ready for commit unless any further problems can be found.
Done, mostly just a few changes for the new $flag->access() method.
Anonymous users are now given a less secure token than authenticated users, since they all need to have the same token when page caching is enabled. We've used a similar mechanism in Fivestar module for anonymous users.
This problem seemed to have stemmed from always requiring a JOIN on the flag_content.sid (Session API ID) column even if it wasn't necessary. This JOIN is now only added if showing a page that is limiting the flagged content to the anonymous user's content exclusively. Additionally I disabled the anonymous user page cache when displaying a list of content flagged by anonymous users so that an anonymous users "My bookmarks" page will work as expected. Views that show flagged content by all users (anonymous and authenticated) are not affected by this change to the page cache.
Session API created hook_session_api_cleanup in the 1.1 version, which is now implemented by Flag to clean up expired IDs.
Between this patch and #335453: Import/Export Support, this completes all the functionality I'd like to include in the 2.0 version of Flag, so the sooner this is reviewed the sooner we can put out a new alpha/beta for the 2.0 version.
Comment #88
quicksketchI wrote the current patch again the 1.1 version of Session API, though the APIs have changed in the 1.2 version which has not yet been released (see #589800: Release 1.2 version). This patch should work with either version of the module by making an adjustment to flag_session_api_cleanup().
This version also implements a change to hook_requirements() which recommends /flag/ be added to the site's robots.txt file to prevent search engines from randomly flagging/unflagging content on the site.
Comment #89
chirale CreditAttribution: chirale commentedSo this patch applied to Flag 6.x-2.x-dev coupled with version Session API 1.1 solves all the bugs listed in #86? Will the next Flag 2.x developement snapshot implement these changes? I like to try the latest version, especially if solves the troubles with cache.
I think that a Flag 2.x + Session API 1.2 (released on October 5th) is the right choice, but 1.2 support should be confirmed to proceed with an extensive testing, because 1.1 support is discontinued. Thanks.
Comment #90
fumbling CreditAttribution: fumbling commentedThanks for putting this together. I applied the patch and enable Sessions API 1.1. I didn't notice any up front errors, and each flag-settings page now does have checkboxes for anonymous users, but when I check those boxes and save the new settings, anonymous users are still not able to flag posts. The flag links simply don't appear for anonymous users. Is there anything special I need to do beyond enabling Session API and checking those boxes?
Comment #91
quicksketchThis version of the patch now works for "global" flags. I can no longer find any problems with this version of the patch. Note that you need to run update.php after applying the patch. If you've already run update.php from a previous version of the patch, then you should re-install flag or start from a previous database. The flag_update_6201() function ended up being used by #489610: Add index to 'count' in flag_count table, so if you run update.php again you'll likely receive database errors.
Unless there are huge bugs in this version, I'll probably commit to the 2.x branch to make testing easier. After this it's clear sailing to a 2.0 beta. :-)
Comment #92
quicksketchAh, also regarding the significant increase in file size... this version adds quite a bit of JavaScript to show the correct flag state for anonymous users when the page cache is enabled. Anonymous user pages are always output the same regardless of the user's flags, then flag.js checks the user's cookies and updates the state to match.
Comment #93
quicksketchWell, let's put it into CVS and see if dev users can dig up any problems. Committed to the 2.x branch! Thanks chirale and ultimike for the persistence and all the rerolls. Since this issue is already nearly pushing nearly 100 comments, please open a new issue for any problems with the anonymous flagging system.
Comment #95
Coupon Code Swap CreditAttribution: Coupon Code Swap commentedUnfortunately, Flags is not usable for anonymous users in the current iteration because spiders / web crawlers are triggering the flags even with the nofollow attribute on the flag links, as posted here:
http://drupal.org/node/639510
Comment #96
newacct CreditAttribution: newacct commentedOr
if (in_array(DRUPAL_ANONYMOUS_RID, $flag->roles)) {
Comment #97
superdorx CreditAttribution: superdorx commentedhttp://drupal.org/project/flag_anon
Comment #98
BenK CreditAttribution: BenK commentedKeeping track of this thread...
Comment #99
thebuckst0p CreditAttribution: thebuckst0p commentedSubscribe.
Comment #100
Sepero CreditAttribution: Sepero commentedThe most relevant posts in this thread appear to be: #37,#71,#80,#93,#95
So the solutions seem to be either
A)
Install Flag module 6.x-2.0-betax (or 6.x-2.x-dev), and Session API
And add this to robots.txt to prevent false search engine flagging: "Disallow: /flag/"
B)
Use the "recommended release" Flag module 6.x-1.x
And follow the directions here http://drupal.org/node/999102
Comment #101
mooffie CreditAttribution: mooffie commented@Sepero:
There's no need for special instructions.
Use Flag 2.x 'dev' (because bugs are fixed almost daily; "beta4" has some bugs when used with page caching). Its UI already gives you all the information you need (If it doesn't, please file a bug report).
(And there's no point in using 1.x: it doesn't support anonymous flagging (unless you use some unofficial patch). The homepage clearly lists the "Flagging for anonymous users" feature under "Version 2.0 Information" only.)
Comment #102
Anonymous (not verified) CreditAttribution: Anonymous commentedthank you Sepero #100
Comment #103
derhasi CreditAttribution: derhasi commentedFix for sql error of #20: #1293448: Error in SQL Syntax regarding SID
Comment #104
CodigoVision CreditAttribution: CodigoVision commentedThanks #100, I think It might be really helpful if someone added the robot.txt tip to the module page after the anonymous user part. Or maybe a link to a page or readme. It seems like that is a pretty important step that will be overlooked by most people. I know I never would have thought of it. Thanks for a great module, I love this new feature too. If anyone wants to see it at work: http://www.itravelcostarica.com click on any listing, I still have to add a link to /favorites & /bookmarks now for anonymous users.
Comment #105
JayShoe CreditAttribution: JayShoe commentedIs there a solution to this? I would like to have anonymous users allowed to flag content.
Comment #106
JayShoe CreditAttribution: JayShoe commentedI found this in the module itself after installing.... Yes it works...
"Users may only unflag content if they have access to flag the content initially. Checking authenticated user will allow access for all logged-in users. Anonymous users may flag content if the Session API module is installed."
Comment #108
jenlamptonIt would be great if we could allow anonymous users to flag without replying on the abandoned Session API module (latest relase, 2012). It currently breaks all caching and doesn't work with varnish. See #1983696: Incompatible with Varnish