// Implementation of hook_flag_default_flags()

yourmodule_flag_default_flags() {
$flags = array();

$flags['bookmarks'] = array (
'content_type' => 'node',
'title' => 'Bookmarks',
'global' => '0', // 0 for false else 1
'types' =>
array (
0 => 'article',
1 => 'blog',
),
'flag_short' => 'Bookmark this',
'flag_long' => 'Add this post to your bookmarks',
'flag_message' => 'This post has been added to your bookmarks',
'unflag_short' => 'Unbookmark this',
'unflag_long' => 'Remove this post from your bookmarks',
'unflag_message' => 'This post has been removed from your bookmarks',
'unflag_denied_text' => '',
'link_type' => 'toggle',
'roles' =>
array (
'flag' =>
array (
0 => 2,
),
'unflag' =>
array (
0 => 2,
),
),
'show_on_page' => 1,
'show_on_teaser' => 1,
'show_on_form' => 1,
'access_author' => '',
'i18n' => 0,
'api_version' => 2,
);
return $flags;
}

Files: 
CommentFileSizeAuthor
#16 flag-document_hook_flag_default_flags-16.patch1.19 KBberliner
PASSED: [[SimpleTest]]: [MySQL] 266 pass(es).
[ View ]
#14 flag-document_hook_flag_default_flags-14.patch1.17 KBberliner
PASSED: [[SimpleTest]]: [MySQL] 266 pass(es).
[ View ]
#11 flag-document_hook_flag_default_flags-11.patch1.24 KBberliner
PASSED: [[SimpleTest]]: [MySQL] 266 pass(es).
[ View ]
#7 flag-document_hook_flag_default_flags-7.patch1.19 KBberliner
PASSED: [[SimpleTest]]: [MySQL] 266 pass(es).
[ View ]
#5 flag-document_hook_flag_default_flags-5.patch1.18 KBberliner
PASSED: [[SimpleTest]]: [MySQL] 266 pass(es).
[ View ]

Comments

Status:Needs review» Postponed (maintainer needs more info)

I'm not sure what action is needed or expected from a maintainer here.

Title:How to create custom module based flags in drupal 7Document hook_flag_default_flags()
Version:7.x-2.0-beta6» 7.x-3.x-dev
Status:Postponed (maintainer needs more info)» Active

I believe appropriate action would be to document hook_flag_default_flags() in flag.api.php.

It's there already -- do you mean put some sample code in it? That would be great. Does anyone care to make a patch?

Status:Active» Needs review
StatusFileSize
new1.18 KB
PASSED: [[SimpleTest]]: [MySQL] 266 pass(es).
[ View ]

Patch is against 7.x-3.x-dev and adds the code from the issue summary.

Status:Needs review» Needs work

Thanks for the patch. Just a few things I'm not sure of:

+++ b/flag.api.php
@@ -57,7 +57,39 @@ function hook_flag_type_info_alter(&$definitions) {
+    'global' => '0', // 0 for false else 1

Is that really the case? Wouldn't a TRUE or FALSE work here?

+++ b/flag.api.php
@@ -57,7 +57,39 @@ function hook_flag_type_info_alter(&$definitions) {
+    'roles' => array (
+      'flag' => array (
+        0 => 2,
+      ),
+      'unflag' => array (
+        0 => 2,
+      ),
+    ),

I'm pretty sure Flag 3.x flags shouldn't have the roles array.

Status:Needs work» Needs review
StatusFileSize
new1.19 KB
PASSED: [[SimpleTest]]: [MySQL] 266 pass(es).
[ View ]

I really don't know the internals of the module that well, so I only copied the code from the issue summary.
You are right concerning the roles, but not the global setting. I have just exported a flag into code and took that as a base to fill the missing info. The global is in there, the roles aren't.
Patch attached.

The global setting is there, but my point was: would it be ok to put TRUE / FALSE in instead? Using boolean constants makes the code more readable IMO.

I agree on readability, but I'm not the maintainer of the module ;-)
I would have to test if booleans are accepted too. I guess so if there is no type testing going on during processing of a default flag definition. Usually php will do typecasting anyway. But I didn't test this.

+++ b/flag.api.php
@@ -57,7 +57,37 @@ function hook_flag_type_info_alter(&$definitions) {
+    'content_type' => 'node',

Should be 'entity_type'.

+++ b/flag.api.php
@@ -57,7 +57,37 @@ function hook_flag_type_info_alter(&$definitions) {
+    'show_in_links' => array (
+      'full' => 1,
+      'token' => 0,
+    ),
+    'show_as_field' => 0,
+    'show_on_form' => 0,
+    'access_author' => '',
+    'show_contextual_link' => 1,
+    'show_on_profile' => 0,

I think these may be obsolete too!

Try creating a flag and exporting it to see the properties that are in 3.x.

Also, TRUE works for the global property, but FALSE totally crashes it!! :( New issue for that: #2059959: 'global' property can't be defined as FALSE in hook_flag_default_flags().

StatusFileSize
new1.24 KB
PASSED: [[SimpleTest]]: [MySQL] 266 pass(es).
[ View ]

Aggred for the entity_type. All the rest is the result of an export. This is also true for the properties that you thought were obsolete.
Updated the patch to include errors and module attributes too.

> Updated the patch to include errors and module attributes too.

Those two should definitely be out!
'errors' is only to do with the flag UI, and shouldn't get getting exported. 'module' is set automatically, and probably should be excluded too. I'll file an issue for those too...

I've committed #2059959: 'global' property can't be defined as FALSE in hook_flag_default_flags(), so you can use TRUE / FALSE for the 'global' property.

StatusFileSize
new1.17 KB
PASSED: [[SimpleTest]]: [MySQL] 266 pass(es).
[ View ]

Concerning #12: module and errors get exported though. Do you file an issue?
I've updated the patch.

Wouldn't it be ever better for readability to define the other options also as booleans, e.g. show_as_field, show_on_profile?

And is it ok, that the export creates code that isn't in sync with the definitions in the api? I wonder because my usual approach for this kind of thing is to create an item, in this case a flag, using the UI, modify it until I'm happy and then have it exported and put into code.

> Wouldn't it be ever better for readability to define the other options also as booleans, e.g. show_as_field, show_on_profile?

Those are fine to use booleans. There's no fix needed here, they are just serialized rather than in database columns.

> create an item, in this case a flag, using the UI, modify it until I'm happy and then have it exported and put into code.

That's absolutely fine. Though I would recommend using Features instead!

In this case though, the purpose of the documentation is presumably people who, rather than use the export UIor Features, are going to write this by hand -- perhaps they want to programmatically set some of the properties, or create a suite of flags. If you're using the export UI or Features, then you don't have much need to read this documentation. Hence booleans are nicer :)

StatusFileSize
new1.19 KB
PASSED: [[SimpleTest]]: [MySQL] 266 pass(es).
[ View ]

Ok, I have updated the patch with booleans instead of integers for the other properties.

Status:Fixed» Reviewed & tested by the community

Works as designed. The patch works. I have deleted the bookmarks and imported it after the new patch was applied and everything worked as expected. No errors. @berliner: thanks for patch. Good to go in the dev version.

Status:Needs review» Fixed

Committed. Thanks!

git commit -m "Issue #1448530 by berliner, sunnyuff: Fixed missing sample code in hook_flag_default_flags()." --author="berliner "

(@Shabana Blackborder BTW, 'works as designed' means something quite specific and usually that we shouldn't commit a patch! -- see https://drupal.org/node/156119)

Will keep that in mind before using the term again! :-)

Status:Reviewed & tested by the community» Closed (fixed)

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