Closed (fixed)
Project:
Flag
Version:
6.x-2.0-beta3
Component:
Flag core
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
12 Nov 2010 at 23:53 UTC
Updated:
3 Jan 2014 at 02:41 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
mgriego commentedWe've been using this on our production site since the issue was created, and it's been working very well. Features exports only change when there are real changes.
Comment #2
mooffie commentedWe certainly need to fix this.
But isn't this only half of the truth?
Now the flag name will appear in two places, and the programmer will have to update both.
Comment #3
mooffie commentedCan't we just sort the flags in flag_features_export_render() ?
(I admit that having default flags be keyed by the flag name, as you suggest, is a more elegant solution, but your implementation has the flaw I mentioned.)
Comment #4
mooffie commentedBTW, do other modules do this too? I'm asking out of curiosity only, I don't mind adding this.
Comment #5
mooffie commentedIt seems we have two options:
(1) We can sort the flags in flag_features_export_render(). It's a one-line solution.
or
(2) We can change our export format to have the flag names be the keys of the array. The names won't repeat in the array values. I'm attaching a patch to show this (I haven't actually tested it). If this technique ($name => $info) is prevalent in the Drupal world, we should certainly use it.
Comment #6
mooffie commentedScrap it. This won't work. Features' sanitization will override it anyway.
I've looked into how Features sanitizes arrays: _features_sanitize().
- We don't need to sort the $flag->types array because it already gets sorted.
- As for sorting the flags themselves: Features simply does sort() and although PHP has rules for comparing arrays, inconsistencies may still result when moving flags from system to another. So we have no choice but to use the flag names for the keys.
I'll commit a patch similar to #5, after I test it.
Comment #7
mooffie commentedCommitted.
http://drupal.org/cvs?commit=478434
http://drupal.org/cvs?commit=478438
The patch is bigger than expected because I renamed some variables to make the code a bit clearer.
Comment #8
mgriego commentedThanks!