Disabled page variant is exported as "disabled = FALSE"

I have the same problem. Any idea?

Thanks!

I'm also having the same issue.

This is a ctools issue...

from export.inc: 904-906

 if ($schema['export']['can disable']) {
    $output .= $indent . '$' . $identifier . '->disabled = FALSE; /* Edit this to true to make a default ' . $identifier . ' disabled initially */' . "\n";
  }

Changing it to something like this fixes the export. But it might break something else! who knows. There may be some reason it was hard coded, but that may be from the days before features was the main use of ctools export?

  if ($schema['export']['can disable']) {
    $disabled = ($object->disabled) ? 'TRUE' : 'FALSE';
    $output .= $indent . '$' . $identifier . '->disabled = ' . $disabled . ";\n";
  }

I'm having the same problem. In my case, I have a Page Manager variant for the node view page in a Features module, but I've disabled it by editing the FEATURE_NAME.pages_default.inc file and setting $handler->disabled to TRUE. When I revert the feature using Drush, it attempts to revert page_manager_handlers every time, because it always thinks it's been overridden.

Meanwhile in the Features UI's "Review Overrides" section for this feature module, it says the following: $data['node_view_panel_context']->disabled = FALSE; /* WAS: TRUE */

So, this is the same issue as above; but I just wanted to point out that it affects Features and reverting as well.

Good additional observation, @jessepinho. Specifically it shows like:

Component type: page_manager_pages
    ),
    'participants_se' => array(
<     'disabled' => TRUE,
---
>     'disabled' => FALSE,
      'api_version' => 1,
      'name' => 'participants_se',

in feature-diff. As the original issue reporter notes, this manual change produces the desired effect of disabling the page on revert at deployment, but, indeed, future feature-updates rewrite to disabled => FALSE (and will un-disable at deployment). :(

Based on #3 I created a patch for this on the latest dev version which fixes the issue for me.

Hopefully this patch will pass testing (per https://www.drupal.org/project/ctools/git-instructions).

I made a slight change that sets the value of $disabled as 'FALSE' if $object->disabled == FALSE OR if it is not present. I don't know if $object->disabled can ever not be present, but it seemed safest to assume that it might not be. In that case, I assume that the exported object should not be disabled, since that seems to be the default.

I encountered this bug over in #2752965: Disabled property validation rule immediately overridden, patch works fine.

This wasn't added to 7.x-1.10, bumping it to 7.x-1.11.

Patch in #10 applies cleanly to 7.x-1.x

Seems to be good to go.

Fixed.