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.
Is anybody working on this? I can give it a try if nobody does.
"Flaggings" are the white elephant in the room. They are the records in {flag_content}.
Why make them fieldable? To implements things like:
- A "reason" text field for a "Spam" flag.
- A "folder" taxonomy field for a "Bookmarks" flag.
This would obsolete ideas like "private flags" and modules like "flag abuse".
Comment | File | Size | Author |
---|---|---|---|
#104 | 871064.104.flagging-entity.patch | 18.34 KB | joachim |
#93 | 871064.93.flagging-entity.patch | 18.23 KB | joachim |
#91 | 111.png | 31.19 KB | Oleksa-1 |
#85 | 871064.85.flagging-entity.patch | 16.49 KB | joachim |
#66 | small_addition_for_anonymous_user-871064-66.patch | 347 bytes | MiSc |
Comments
Comment #1
quicksketchSounds like a good idea to me. I'm not currently working on any 7.x only features (or really on 7.x much at all since the APIs keep changing on me). Help fixing the existing Drupal 7-only bugs would also be appreciated.
Also: great to hear from you mooffie!
Comment #2
mooffie CreditAttribution: mooffie commentedSo I'll start working on this :-)
(I haven't "come back" yet. My memory of Drupal is a bit rusty, but I thought the "fieldable flaggings" thing is too exciting to ignore...)
Comment #3
amitaibu@quicksketch,
I think we talked about on IRC, but can you remind me why are you against flag using field API?
Also, if flag itself was a fieldable entity, you would be able to flag flaggings "for free".
p.s. 3AM here, but baby thought it was play time :/
Comment #4
quicksketchTo clarify things, I'm against Flags *being a field*, I'm not against Flags being an entity, and therefor being fieldable.
Comment #5
amitaibu> I'm against Flags *being a field*
Yeah, I mean that ^^ :) Remind me why are you against?
Comment #6
sirkitree CreditAttribution: sirkitree commentedsubscribing
Comment #7
quicksketchFields are intended to be a piece of information about an object. It doesn't line up with the Flag data model, which is basically establishing relationships between two different object (a user and something else). Fields don't let every individual user store a different value, it's always just setting a property directly on the object.
Additionally we need to store custom information (like flag counts aggregation) in a database table anyway, meaning that the benefit of using fields and their swappable storage backend would be minimal. Also, we can't re-architect all of Flag as a field and continue to adequately support both Drupal 6 and Drupal 7. If (and that's a big if) we ever convert Flag to be a field, it will be in the Drupal 7-only version when support for Drupal 6 comes to an end.
Comment #8
mooffie CreditAttribution: mooffie commented(I had this feature implemented two weeks ago already. But I want the patch to be as clean as possible (that is, bereft of hacks), and that's why I've been submitting trivial patches to fix/enhance various issues in the module itself. I think it won't take much longer.)
Comment #9
mooffie CreditAttribution: mooffie commentedOkey dokey.
I'm publishing my work so far.
On the one hand, it's fully functional.
On the other hand, it's incomplete: I wanted to keep this first patch small (I left @todo comments).
How does it look like?
I've prepared a handbook page demonstrating this new feature. It contains some screenshots. This page should be an easy-reading for non-programmers too.
While reading that page you might get the impression that there's a lot of new functionality, and you'd be correct. However, most of this functionality is implemented by Drupal itself (its Field subsystem), not by the Flag module. There's no code bloat.
The implementation
The implementation of this feature ("fieldable flaggings") is strewn over three components:
Downloading
Reviewing the core patch
The core patch has three logical parts to it:
The focus should be on part #2 (because that's the part that has the potential to change wildly).
Before applying this patch:
Make sure the Flag module works for you. Drupal 7 is a moving target.
You'll be fine if (at the time of this writing) you'll be using Flag's 'dev' and D7's alpha7 or later.
Comment #10
mooffie CreditAttribution: mooffie commentedA few words about the Flag Note module:
I was absent for several months and wasn't quite aware of this module. It was only a few hours ago that I looked at it. The proposed "fieldable flaggings" thing obviously has one feature of Flag Notes but it misses another: the ability to keep a history of the flaggings.
So, how can we implement this "history" feature? I see several options (I'm writing this hastily; research is needed):
Comment #11
amitaibu@mooffie,
1) The docs look really interesting, however I think that if it's possible - show bigger images, otherwise, one has to click to see the image, and loses context
2) WOW! :)
Comment #12
mooffie CreditAttribution: mooffie commented(Amitai, thanks. I too would like bigger thumbnails, but the image host I'm using (imageshack) doesn't let me configure this size.)
Comment #13
amitaibu> but the image host I'm using (imageshack) doesn't let me configure this size.)
You can attach the images to this issue, instead of imgeshack.
Comment #14
aaron CreditAttribution: aaron commentedexciting and subscribe! (coming over from #954918: Flag Media).
Comment #15
fagoStill, you could store the reference on the flagging (regardless whether this is an entity) using a field. That's the way field_collection (http://drupal.org/project/field_collection) works. That way you'd automatically support each fieldable entity + I'd be consistent to configure for users I guess. Also it helps you with altering entity forms a lot ...
anyway, for going the fieldable flagging route, consider building upon the entity CRUD API. :)
Comment #16
quicksketchThat is the plan, if we're adding fields to something then the Field API is an obvious choice... for things that are fields.
Comment #17
mooffie CreditAttribution: mooffie commented#1026092: Flag with user reference? was marked a duplicate of this issue.
Comment #18
Itangalo CreditAttribution: Itangalo commentedsubscribing
Comment #19
snupy CreditAttribution: snupy commentedsubscribing
Comment #20
JohnnyX CreditAttribution: JohnnyX commentedSubscribe
Sounds and looks good. I this feature added to the dev or beta release of flags at the project page?
I would use flags and rules as notification solution but flag is missing the rules integration. Could I use fieldable flaggings to work with rules and trigger notification emails that way?
Comment #21
JJones CreditAttribution: JJones commentedIs this in the D7 beta version? Interested in trying this out.
Comment #22
q0rban CreditAttribution: q0rban commentedsubscribe
Comment #23
Shawn DeArmond CreditAttribution: Shawn DeArmond commentedsubscribe
Comment #24
Shadlington CreditAttribution: Shadlington commentedSub'd
Comment #25
q0rban CreditAttribution: q0rban commentedHere's a (untested) re-roll against the current version of Flag. Instructions still in #9.
Comment #26
q0rban CreditAttribution: q0rban commentedWhoops, missed includes/flag.entity.inc.
Comment #27
mooffie CreditAttribution: mooffie commentedI'm unassigning myself because I won't be working on this.
Comment #28
mooffie CreditAttribution: mooffie commentedSome odds and ends:
(...which I didn't want to discuss previously because I wanted to keep this thread focused.)
Users have been asking if it's possible for them to flag on behalf of another user (see 1, 2). We used to reply "No, it's not possible, because we don't have a GUI for this. (But you can do this via code)." But now at last it's possible to implement this GUI because we have a form for editing the flagging. All that's needed (on the GUI side) is to add an autocomplete field to the form, for picking the flagging user. (See the
flag_flagging_form()
function; the$is_privileged
parameter would tell us if the acting user has permission for this). This is similar to what already happens with nodes: privileged users can choose a node author (again, using an autocomplete field).One feature that's already there is the ability, for privileged users, to edit and delete flaggings. This is possible because flaggings have address and can therefore be accessed (e.g.,
?q=flag/privileged-flagging/4571/edit
).Comment #29
Shadlington CreditAttribution: Shadlington commentedApplied #26 to a clean install and so far so good... Kinda.
There's a few issues:
1. There is no dependency on flag form. There either should be or the interface needs to be changed to not allow you to add fields unless flag form is available, as whilst you can add them there is no way to do anything with them if the module isn't available. I noticed this because I forgot to install flag form along with the patch and was a little confused!
2. Does something odd to the Bartik theme. I had changed the colour set to 'Ice' instead of the default 'Blue Lagoon'. However, clicking on flag with the dialog enabled causes the theme to switch back to Blue Lagoon until the page is refreshed! Really odd...
3. Redundant UI element. 'Custom display settings' doesn't contain anything but is still visible. Meh. I'm clutching at straws with this one, really!
Generally seems pretty good though!
I've not tested it all that thoroughly to be honest (only tried a couple of field types) but it certainly seems to work quite well :D
Comment #30
mooffie CreditAttribution: mooffie commented(It's intentional. But I'll explain later; I have to go...)
Comment #31
Shadlington CreditAttribution: Shadlington commentedOkay, got another, maybe. Not sure if this one is normal or not.
Completely uninstalled flag but the database still had the field definitions of the flag fields as well as the actual entries against flaggings in the field tables.
Not sure if this is a normal thing to do with how D7 does fields but it seems like flag should clean up after itself really. I really don't know though.
EDIT: In fact, I was able to re-enable the modules and the fields I'd added were still there.
Comment #32
rlmumfordSo, did flags end up as entities?
Comment #33
mooffie CreditAttribution: mooffie commented"Flag Form", which only provides an out-of-the-box user interface for editing fields, is a distinct component. I don't feel it'd be right to make it a required module.
Incidentally, fields are usable even without the "Flag Form" module; for example, they can be edited with editablefields (in theory), or set via custom code or Rules. When the form isn't used, the fields are assigned their default values (its a nice feature; it's mentioned in the help text).
But I certainly get your point! That's why when the "Flag Form" module isn't enabled, there's a bold message shown on the fields screen. You may have missed it. I guess it should be more prominent (e.g., shown in the message area and on the flag page).
Right. There are more omissions in this patch. Look for the "@todo" comments. For example, the fields data is kept also in the case where a flag is deleted. There's certainly more work to be done.
This is possibly a (usability) bug in Drupal itself.
(The "display settings" govern how a flagging is printed. Much like how a node is printed. This doesn't seem to make sense right now because nowhere flaggings are printed. But they are printable. This will make more sense with the Views integration -- when one constructs a view of type Flaggings (constructing such views is possible with Flag Vista but not with our own lousy Views support).)
@rlmumford wrote:
Flaggings are entities. Flags aren't. But the next logical step is to make flags too entities. No reason not to.
Note that our lousy Views integration won't allow one to fully utilize this feature; e.g., you won't be able to construct a view showing all flaggings whose flag has its "It's a user badge" field set. But Flag Vista will be able to do this.
(This will be my last message in this thread. We want to encourage somebody to step in.)
Comment #34
rlmumfordOk, that makes sense. A flag is therefore like a flagging type? (I think in the code these are labelled flag-type and flag respectively)
Also, if flaggings are entities doesn't that close this issue?
Comment #35
Shadlington CreditAttribution: Shadlington commentedThank you for the informative response moofie.
That all makes perfect sense.
The only 'real' issue that I found then is the odd behaviour with the changing theme colors... But this could well be a problem with Dialog. I would test it but I can't get any other D7 implementation of Dialog to work! Oh well.
EDIT: Also, flag vista looks awesome! Pity there's no D7 yet and you're leaving :(
Comment #36
mooffie CreditAttribution: mooffie commentedWhatever, I think Flag 2.0 should be released asap and that #871064: Making flaggings fieldable (this issue) and #1035410: Flag any entity should be included in Flag 3.0 only. That's because these two features might make the code in the D7 branch (of Flag 2.0) too different than the code in the D6 branch (of Flag 2.0), something which won't ease the maintenance.
(Flag 3.0 should be for D7 only. Flag 2.0 should not get any new features.)
This shows that new (co)maintainer(s) are badly needed.
Mmmmm... if flags will be fieldable entities, then yes. Since flags could then have attributes ("this is a user badge", "this is a folder") they (the flags) could effectively function as types for the flaggings.
(No: "flag_type" stands for the object that can be flagged (by a particular flag); e.g., "node", "user", "comment".)
Comment #37
quicksketchYep, I totally agree with everything you've said mooffie. Thanks so much for all the work you've done on Flag and keeping the issue queue afloat. I'm hoping to start reviewing and getting out a final version of Flag in the near future. The fact that we don't have a stable 2.x branch despite the fact that we recommend 2.x over 1.x is quite silly.
Comment #38
Cyberwolf CreditAttribution: Cyberwolf commentedSubscribing.
Comment #39
Shadlington CreditAttribution: Shadlington commentedI was wondering if there was any update on this? Or flag D7 development in general?
I'm surprised no-one has come forward to co-maintain yet considering flag's wide usage - I know I would if I had the necessary ability.
Comment #40
rlmumfordI would be happy to co maintain. Just let me finish my degree in a few weeks.
Comment #41
TimelessDomain CreditAttribution: TimelessDomain commentedsubscribing
Comment #42
quicksketchFrom mooffie's suggestions (which I agree with):
Comment #43
q0rban CreditAttribution: q0rban commentedWould it be possible to get the changes to the API (except for the field/entity hooks) into 2.x so that users that do need fieldable flaggings can implement it in their own custom module? I think the API changes are fine for both 6 and 7.
Comment #44
q0rban CreditAttribution: q0rban commentedWell, nevermind. I started to work on a patch for that, and it wasn't so trivial. Switching back to postponed.
Comment #45
Fidelix CreditAttribution: Fidelix commentedSubscribing...
Comment #46
zandros CreditAttribution: zandros commentedsubscribing
Comment #47
zandros CreditAttribution: zandros commentedWhen i apply the patch i get these warnings:
Comment #48
zandros CreditAttribution: zandros commentedAnd when i press manage fields it gets me to the edit flag page where no add field functionality is shown
Comment #49
zandros CreditAttribution: zandros commentedany comments?
Comment #50
schrysan CreditAttribution: schrysan commentedI have the same problem. Is there a solution? Any update on that?
Comment #51
rosell.dk CreditAttribution: rosell.dk commentedsubscribing
Comment #52
sslider999 CreditAttribution: sslider999 commentedsub
Comment #53
rafamd CreditAttribution: rafamd commentedsubscribing, would be great to see a 3.0 with this feature.
Comment #54
ericduran CreditAttribution: ericduran commentedHere's a re-rolled of this patch.
Again as mention before this is not going to make it in till the 3.x branch.
So I'm just posting the latest re-rolled to keep track of it.
Comment #55
q0rban CreditAttribution: q0rban commentedUpdated patch, same as #54 except that $reset is passed as TRUE to flag_get_flags() in flag_entity_info(). Without this, flags that have been exported to code are not loaded properly until a full cache clear, causing simpletests to throw notices.
Comment #56
partyp CreditAttribution: partyp commentedsubscribe
Comment #57
goron CreditAttribution: goron commentedHere's a re-rolled patch which applies cleanly to the latest 2.x dev. Same as the patch in #55, except takes out one section with a change which already exists in the current dev.
Comment #58
wroxbox CreditAttribution: wroxbox commentedI'll try to summary my settings and setup
I have latest flag.module with applied patch #57 and I have https://github.com/mooffie/flag_form and I have flag_abuse to mark comments abusive.
Form:
And I get tokens:
The public site looks like
This all works great! Just what was needed. Now I am for Rules.
I wan't to send email to reporter who reported about the comment. So I created rule and try to fetch the email-address.
It seems to find right entity with right field but the flagging:token is missing for value
I assume it should be available as flagging:field-flag-email?
Comment #59
wroxbox CreditAttribution: wroxbox commentedAccidentally renamed the issue. Sorry!
Comment #60
streche CreditAttribution: streche commentedsubscribe
Comment #61
goron CreditAttribution: goron commentedstreche, please use the Follow button at the top of the issue instead of posting comments to subscribe!
Comment #62
wroxbox CreditAttribution: wroxbox commentedHere is the same as the patch in #57, except adds rules support for tokens explained in #58
Comment #63
zilla CreditAttribution: zilla commentedexcellent ideas - i see that this discussion started nearly a year ago, but is this rolled into any recent dev or test release?
Comment #64
q0rban CreditAttribution: q0rban commentedHere's an updated patch from #62 with a few very small changes:
It should be noted, I haven't tested any of the new work from #62, yet this patch is based off of that one.
@zilla, this work exists only in this issue queue, and in the flag_form module to go along with it, now found at https://github.com/q0rban/flag_form (moofie is no longer maintaining his version of flag_form, referenced above).
Comment #65
q0rban CreditAttribution: q0rban commentedAnother slight tweak to this. We are detecting uid and sid in ->flag, but not setting it to the $flagging object that comes in. This means that in hook_field_attach_presave, et. al., those values are null. Attached patch fixes that.
I can't help but think that Flag module could use some ground up re-architecting as we continue to refine this patch.
Comment #66
MiSc CreditAttribution: MiSc commentedJust needed to add support for anonymous users, that will use timestamp for sid value. Pretty stupid, but that I needed to solve a specific problem.
Comment #67
IWasBornToWin CreditAttribution: IWasBornToWin commentedIs there a single patch we can apply to our current, and only, version of Flag? I'd enjoy these features.
Comment #68
MiSc CreditAttribution: MiSc commented@IWasBornToWin: The patch in comment #65 should do the trick for you with the latest dev of flag 2.x.
Comment #69
yogeshchaugule8 CreditAttribution: yogeshchaugule8 commentedlet me take an opportunity to introduce a module which works same way:
The module provides the Drupal admin to attach a webform to a flag so that when user flag/unflag content on the Drupal site, they can add additional information using the webform.
The module page is http://drupal.org/project/flagcoolnote
Comment #70
MiSc CreditAttribution: MiSc commentedflag_form has moved from GitHub to d.o. and changed the name to flagging_form, and a first beta release is now out: http://drupal.org/project/flagging_form
@yogeshchaugule8, interesting solution, but it not the same way, it seems to be a totally other way, but similar result ;-)
Comment #71
juandelacruzm CreditAttribution: juandelacruzm commentedThe updated version (march 14 2012) of flag 7.x-2.x-dev needs the patch in comment #65?
Comment #72
wroxbox CreditAttribution: wroxbox commented@yogeshchaugule8 Is flagcoolnote working also for comments?
Comment #73
MiSc CreditAttribution: MiSc commented@juandelacruzm: Yes, that patch work for the latest dev of Flag 7.x-2.x.
Comment #74
rupertj CreditAttribution: rupertj commentedThe patch from #65 is working nicely for me (For some reason I had to apply it with patch instead of git apply, but that could be my issue...)
Could we get this commited to a -dev release?
Comment #75
Oleksa-1 CreditAttribution: Oleksa-1 commentedWould like to see patch #65 commited as well
Comment #76
quicksketchFlag module has been sadly neglected for a while now on my part. For this to move forward we'll need to get 2.0 out first. #1543826: Applicants Wanted: Flag Maintainership
Comment #77
yogeshchaugule8 CreditAttribution: yogeshchaugule8 commented@wroxbox: Yes, the module will work with comments as well as users.
Comment #78
Scryver CreditAttribution: Scryver commentedI'm running into problems with rules and automated (un)flagging. If I want to unset a flag using rules a ajax error pops up with the following message:
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /climbcheck/flag/flagging/boulder_project/984/delete/ajax
StatusText: error
ResponseText: RulesEvaluationException: Argument <em class="placeholder">flagging</em> is missing. in RulesPlugin->setUpState() (line 648 of E:\xampp\htdocs\climbcheck\sites\all\modules\rules\includes\rules.core.inc).
Maybe because it doesn't use the EntityAPI functions?
Edit: With the normal flag actions it works.
Comment #79
MiSc CreditAttribution: MiSc commented@Scryver, are sure this is related to making flag fieldable?
Comment #80
Scryver CreditAttribution: Scryver commentedWell that was the beginning of my problem after I added fields to flags, so I guess. Should try to undo the fields and backup to the flag module. But I really need this later on...
I've also tried to set some field values automatically with rules without a form popup or anything. But the fields won't save. That's why I said that with the EntityAPI functions you would include a lot of rules and token actions at a low cost. Being able to save the Entity with a rule is something I can't get to work at the moment.
Comment #81
funature CreditAttribution: funature commentedi use the patch of #65 and it works fine. my question is, will that be a problem if one day this feature is added to the flag module? can i update the module then as usual without losing the data?
Comment #82
Itangalo CreditAttribution: Itangalo commented@euroba: I'm not a Flag maintainer, but I would say the answer to your question is "no". Since the patch isn't comitted yet, it can still change (and it might not even be accepted).
Comment #83
joachim CreditAttribution: joachim commentedI've been wondering whether this could go into 2.x or have to wait for a 3.x branch.
In theory, you can entitize any database table by just declaring hook_entity_info() on it and a few associated callbacks.
However, the latest patch for this looks like it changes quite a lot. Given this module tries to keep its 6.x-2.x and 7.x-2.x branches reasonably in sync, that suggests to me this should form the first new feature in a 3.x branch.
I plan on looking at it soon, but after #1035410: Flag any entity.
Comment #84
joachim CreditAttribution: joachim commentedThis patch is going to need a big reroll.
Also, I reckon we can maybe get field form elements into it in the flagging confirm form.
Comment #85
joachim CreditAttribution: joachim commentedJust tried applying this patch. The good news: it applies!
The bad news: it creates a circular dependency!
Our hook_entity_info() goes to look at which flag types we have in order to know about flagging bundles. But since we've added #1035410: Flag any entity, we have a flag_entity class which calls entity_get_info() in its constructor...
Looks like lazy-loading the entity info into that class when we need it fixes the problem -- at least, commenting it out makes my site load again! :D
Here's a reroll of the last patch to keep it fresh; I've also moved functions from entity.inc to the main .module file, as think it's best to use entity.inc for just classes so it can be autoloaded.
Comment #86
joachim CreditAttribution: joachim commentedFiled a patch for taking care of the circularity here: #1689704: investigate performance of storing entity info in flag object vs fetching it.
Comment #87
Oleksa-1 CreditAttribution: Oleksa-1 commentedTested patch from #85 and faced with circularity. Patch from #1689704 solved this issue. Created and removed text fields without any problem, tested with views and it works fine.
I have only one doubts about flag_form submodule maybe it is better to put its basic functionality to flag module code. It is more logical than to have it separately.
Comment #88
joachim CreditAttribution: joachim commentedThanks for testing!
Do you mean this one: http://drupal.org/project/flag_form
I can only see a 6.x branch for that.
Comment #89
joachim CreditAttribution: joachim commentedCan't say I'm thrilled about this method getting yet another parameter. I can see why it's necessary, but it's very gradually making it into a monster.
I'm looking at making the confirmation form have the fields so they can be set on flagging, but for that to make sense the main flag() function needs the $flagging param too, and therefore we need #1689530: flag() should support $skip_permission_check to not have a WTF in our function definitions.
Comment #90
goron CreditAttribution: goron commentedThe flag_form module that was used with this patch before is now flagging_form: http://drupal.org/project/flagging_form
Comment #91
Oleksa-1 CreditAttribution: Oleksa-1 commentedOn this page /admin/structure/flags/manage/bookmarks/fields this module is mentioned and without it enabled not possible to get form. To get forms working I downloaded flag_form module from mooffie post http://drupal.org/node/871064#comment-3496040
Comment #92
joachim CreditAttribution: joachim commentedThanks for the details! I'll look at it today.
Changing the version for this.
Comment #93
joachim CreditAttribution: joachim commentedNew patch.
I've made it so that the Flag core confirmation form has the flag fields. Of course, once you've saved the fields there's no way to edit them again :D
You can see them though if you set up a view.
I've had a look at http://drupal.org/project/flagging_form. It works great with this patch. Not sure whether to suggest it move into this module -- it sort of makes sense, as it's what makes fieldable flags truly useful, though I'd really rather not have more code to maintain!!!
Comment #95
joachim CreditAttribution: joachim commented*sigh* That'll be because the 7-3 branch was a few commits back from 7-2.
Comment #96
joachim CreditAttribution: joachim commented#93: 871064.93.flagging-entity.patch queued for re-testing.
Comment #98
Oleksa-1 CreditAttribution: Oleksa-1 commented1)I have error message after enable flaf module: Deprecated function: Call-time pass-by-reference has been deprecated in drupal_load() (line 1128 of C:\xampp\htdocs\ndb1\includes\bootstrap.inc).
2) on page /admin/structure/flags/manage/bookmarks/fields should be link to http://drupal.org/project/flagging_form instead of
"Note: You don't have the Flag Form module enabled. You'll have to enable it to have the "Form" link-type."
3)"Of course, once you've saved the fields there's no way to edit them again" Why? Imho it should be possible edit/delete these fields (handlers in views) see http://drupal.org/project/flag_note (d6) I used that module and it was very handy to have such functionality.
Comment #99
joachim CreditAttribution: joachim commentedTesting bot is on the fritz. The patch passes all tests perfectly for me!
Comment #100
joachim CreditAttribution: joachim commented> Deprecated function: Call-time pass-by-reference has been deprecated in drupal_load() (line 1128 of C:\xampp\htdocs\ndb1\includes\bootstrap.inc).
Weird. Any chance you could do a backtrace and find out what's causing that?
> page /admin/structure/flags/manage/bookmarks/fields should be link to http://drupal.org/project/flagging_form instead
Yup, will do.
> "Of course, once you've saved the fields there's no way to edit them again"
What I mean is that it's not possible with just the core Flag module. Obviously flagging_form lets you edit the flagging after you've flagged content.
Thanks for reviewing the patch!
Comment #101
Oleksa-1 CreditAttribution: Oleksa-1 commentedOk, will try to backtrace, but with patch from #85 , I do not have such error
Comment #102
Oleksa-1 CreditAttribution: Oleksa-1 commentedSeems fix for Deprecated function: Call-time pass-by-reference has been deprecated in drupal_load() (line 1128 of C:\xampp\htdocs\ndb1\includes\bootstrap.inc) is to change:
for
and some api function should be corrected
852
function flag_user_login(&$edit, &$account) {
>function flag_user_login(&$edit, $account) {
1123
field_attach_form('flagging', $flagging, &$form, &$form_state);
>field_attach_form('flagging', $flagging, &$form, &$form_state, $langcode = NULL);
1130
function flag_confirm_submit(&$form, &$form_state) {
>function flag_confirm_submit($form, &$form_state) {
488
function flag_field_attach_form($entity_type, $entity, &$form, &$form_state, $langcode) {
>function flag_field_attach_form($entity_type, $entity, &$form, &$form_state, $langcode = NULL) {
Comment #103
joachim CreditAttribution: joachim commentedAha. That'll be my fault for copying function definitions from api.drupal.org...
Thanks for figuring it out! :)
Comment #104
joachim CreditAttribution: joachim commentedHere's a new patch with those fixes.
It's only the calls to functions that mustn't have the &; function declarations need them for &$form and &$form state.
Comment #105
Oleksa-1 CreditAttribution: Oleksa-1 commentedThanks, looking forward 7.x-3.x-dev!
Comment #106
socketwench CreditAttribution: socketwench commentedTests clean for me too.
Comment #107
joachim CreditAttribution: joachim commentedHere goes!
The 7.x-3.x branch has now diverged! :D
Thanks to everyone who's worked on the patch and helped with reviewing and testing it.
Issue #871064 by mooffie, q0rban, ericduran, goron, wroxbox, joachim: Added flaggings as a fieldable entity.
Comment #108
Oleksa-1 CreditAttribution: Oleksa-1 commentedGreat news, Joachim! Flag now very powerful module and it can be used e.g. for e-commerce to make orders or has some fuctionality like webforms, really cool)
I care maybe on main project page should be description about difference between 2.x and 3.x ?
Comment #109
joachim CreditAttribution: joachim commented3.x is not production ready yet! I'll add details to the project page when there's a fixed release.
Comment #110
Oleksa-1 CreditAttribution: Oleksa-1 commentedyep, makes sense )
Comment #111
forestmars CreditAttribution: forestmars commentedDisregard #65: flag-871064-fieldable-65.patch queued for re-testing.
Looking forward however to seeing the patched version of 7-3x-dev, and notes as to where it's not production ready.
Didn't see anywhere in this thread why the patch is being committed to 3.x, not 2.0, would be interested in knowing that.
Edit: Given that the 3.x branch is D7 only, it makes sense to keep it separate from the 2.0 branch, which has to support D7 & D6 (as Joachim points out in the comment rafamd links to.) Although I thought the same approach was suggested for Flag Any Entity, the patch for which I think went straight to 2.0 and is now in beta8.
Comment #112
rafamd CreditAttribution: rafamd commented@forestmars, think the latest 3.x dev should be the patched version you are looking for. Notes as to where it's not production ready? given that 3.x branch was created just a few days ago and hasn't even reached alpha, guess the notes aren't on the project page just because it's very new (suppose we'll have an official update on the project page sometime soon, maybe after 2.0 which is the next planned release after current beta8).
See comment #83 on this thread to answer your last question.
cheers !
Comment #113
joachim CreditAttribution: joachim commentedThe status of the 3.x branch is that currently it's undergoing some huge changes and should thus be considered unstable. The plan for those is outlined here: #1703470: [meta] The Great Flag Cataclysm. In particular, right now I could use help with testing #1681540: replace 'content' with 'entity', eg $content_type with $entity_type.
After the big changes land, I'll make a 3.0-alpha.
Comment #114
forestmars CreditAttribution: forestmars commented(comment made in error)
Comment #115
Oleksa-1 CreditAttribution: Oleksa-1 commented@forestmars This issue is fixed please open new one if needed
Comment #116
zilla CreditAttribution: zilla commentedwow, this has become an EPIC thread! given the immense interest in making flags fieldable, would it make any sense to consider the feature first as a module on its own, a plugin to flags, such that users could test out and see how it suits the use case without creating a big core change to flags - or is that sort of a waste of time if the long term goal is to simply enhance the core flags module?
Comment #117
joachim CreditAttribution: joachim commentedThis issue is marked as fixed: the core change is already in!
And anyway, the changes run too deep for that to be possible, I think.
Comment #118
forestmars CreditAttribution: forestmars commentedZilla- Joachim could speak to your suggestion with a greater depth of authority here (in fact he just did) however given how few issues I've seen (at least so far) with this integration, I'd say the decision to merge this in was well warranted. Also, I'd suggest that making objects fieldable is a core concept. (Field all the things!)