Hi,
I exported the following strongarm-variable with included linebreaks via Feature-GUI:
<?php
$strongarm = new stdClass;
$strongarm->disabled = FALSE; /* Edit this to true to make a default strongarm disabled initially */
$strongarm->api_version = 1;
$strongarm->name = 'uc_address_format_840';
$strongarm->value = '!company
!first_name !last_name
!street1
!street2
!city, !zone_code !postal_code
!country_name_if';
?>
After enabling this feature on a new drupal project for the first time, I see status "overwritten" for the feature. The diff at admin/build/features/[myfeature]/diff shows me a "invisible" difference between the "default" and the "overrides" of this variable.
I guess this has something to do with the included linebreaks, since normal string-variables cause not this problem. There propably happens something during import...
The imported variable itself seems to cause no problems. Devel variable editor shows the following outprint after feature import.
<?php
!company
!first_name !last_name
!street1
!street2
!city, !zone_code !postal_code
!country_name_if
?>
But tracking of any changes is quite difficult, if there is always status "overwritten" for this feature.
Comments
Comment #1
TS79 commentedI analysed the problem a bit and it seems like the problem is caused by the line breaks "\n", "\r" and "\r\n", which get lost or modified during feature file creation.
The solution might be the introduction of a mulitline string export format in strongarm/feature.
Dependent on the existence of such a line break in a string, the choice of the correct export format can be done.
The following multiline format might be possible:
...with definitions for linebreaks: 0:=none, 1:='\n', 2:='\r', 3:='\r\n'; (see: http://en.wikipedia.org/wiki/Newline#Unicode for more about line breaks)
In this way at import time the correct multiline variable can be recontructed. Further more you have no problems in tracking variable changes - there will be no "overwritten" message for the feature anymore.
The only disadvantage is a lag of readibility in feature-files or when feature-diff is done for the variables. But since there should be no extensive use of multiline variables, this might be a subordinate problem.
Comment #2
damienmckennaIs the problem instead because of the indenting? Please provide a copy of the raw serialized string so we can review it. Thanks.
Comment #3
TS79 commentedYes I think the indenting causes the problem. The original string definiton of Ubercart module you find in lines 46-51 at page http://drupalcode.org/viewvc/drupal/contributions/modules/ubercart/uc_st...
Here the linebreaks are visible. Please init this string to a variable and try to export and import it with features.
Comment #4
damienmckennaFYI I'm also seeing this in data output from UUID_Features.
Comment #5
damienmckennaCould this be considered a core bug in CTools' export system?
Comment #6
damienmckennaI've reported a bug in CTools as I believe it to be where the bug lies: #920660: Line breaks in exported output cause objects to be considered as overridden
Comment #7
TS79 commentedproblem derefered with latest versions of ctools/stronarm/features. I was looking to an old named export file, which unfortunately survived during latest feature recreation.