This patch prevents user-defined multi-line strings like PHP eval code in argument handlers and views headers / footers from being indented when a view definition is exported

For example, a string like this:

'default_argument_php' => '$my_var = "foo";
if ($my_var == "foo") {
  // do some stuff
}',

Currently gets indented like this upon export:

'default_argument_php' => '$my_var = "foo";
  if ($my_var == "foo") {
    // do some stuff
  }',

A further export would cause additional indentation:

'default_argument_php' => '$my_var = "foo";
    if ($my_var == "foo") {
      // do some stuff
    }',

And so forth.

Indents in user-defined strings alter the whitespace content intended by the author and furthermore each additional export of a multi-line string appears as a substantive change in version control systems when no real modifications were made to the string.

CommentFileSizeAuthor
views_var_export_indentation.patch.txt1.65 KByhahn

Comments

merlinofchaos’s picture

Status: Needs review » Fixed

Committed to 2.x and 3.x

JirkaRybka’s picture

Thanks for fixing this :-)

And just for record - this was really nasty bug, if someone use a more complex filter on the input format for header/footer/empty Views texts. In my case, the "Texy!" pseudo-markup filter translates lines starting with a '-' into HTML item-lists, which are further themed via css. The indentation on export completely destroyed the layout, as the '-' wasn't at the start of line anymore, so after moving my views into site-specific module no translation occurred, and just unprocessed string was shown with no theming.

(Just stating the use case here, so that search engine see this issue if someone run into the same problem later.)

Status: Fixed » Closed (fixed)

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