Closed (fixed)
Project:
Flag
Version:
6.x-2.x-dev
Component:
Flag core
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
5 Aug 2010 at 22:29 UTC
Updated:
3 Jan 2014 at 01:42 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
drewish commentedActually this needs more work. flag_features_export_options() is also calling flag_get_flags() which skips disabled, default flags. I'm just using the union of the two arrays for this now.
Comment #2
hefox commentedPatch didn't apply cleanly, but looks like the trouble lines were already fixed so removed them
This solves an issue where, when features computes whether it needs to act, fatal errored during export render, so +1!
Haven't tested the condition that this patch was originally created for though.
Comment #3
hefox commented--relative :O
Comment #4
mooffie commentedTagging.
BTW, you can get a disabled flag with "flag_load($name, TRUE)". This function currently serves as a "menu loader" only, but I wish we'd switch to use it instead of flag_get_flag() because it's more consistent with the rest of Drupal's API (node_load(), user_load(), etc.)
Comment #5
mooffie commentedOne reason flags may be disabled is because their API version isn't compatible with the current API:
(Snippet from flag.module.)
Exporting such flags may produce useless output. Shouldn't we exclude such flags from the exportables list?
Comment #6
mooffie commentedHere's the patch with some minor modifications.
Overview:
(1) The 'disabled' attribute, in the context of Features, should be treated as any other attribute of the flag: be ignored. So we replace every flag_get_flag($name) call with flag_load($name, TRUE).
(2) But if a flag is disabled because it is incompatible, we print an error message and skip its export. (Why print a message? We don't have to but it's a helpful message: if one upgrades his Flag module he'll understand why his old default flags are ignored.)
(3) When we display the list of flags, we show absolutely all of them. This way, a "Recreate" of the module doesn't forget flags that are now disabled (or incompatible).
Comment #7
mooffie commentedCommitted.
http://drupal.org/cvs?commit=471078
http://drupal.org/cvs?commit=471080
(It might seem as if I'm pushing flag_load() through the back door, but there's no other (easy) way to get at a disabled flag; and flag_load() actually follows Drupal's naming conventions. (For uniformity's sake we might want to replace all flag_get_flag() calls with flag_load().))