I didn't see this issue anywhere else so sorry if this is a duplicate or by design.

When I go to export a page variant that's been disabled via the UI
$handler->disabled = FALSE; /* Edit this to true to make a default page disabled initially */
is nonetheless always set.

While manually editing the export is possible as the comment suggests by far my most common use case is exporting with Features. I could manually update the features too, but ultimately a "drush features-update" would re-export the variant with "disabled = FALSE".

#8 ctools-export_fix-1956528-7.x.patch973 bytespdcarto
PASSED: [[SimpleTest]]: [MySQL] 121 pass(es). View
#6 ctools-export_fix-1956528-5-7.x.patch1.07 KBsgurlt
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch ctools-export_fix-1956528-5-7.x.patch. Unable to apply patch. See the log in the details link for more information. View
Members fund testing for the Drupal project. Drupal Association Learn more


lukio’s picture

I have the same problem. Any idea?


rafaqz’s picture

I'm also having the same issue.

rafaqz’s picture

Project: Panels » Chaos tool suite (ctools)
Version: 7.x-3.x-dev » 7.x-1.3
Component: API » Exportables

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";
jessepinho’s picture

Issue summary: View changes

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.

texas-bronius’s picture

Version: 7.x-1.3 » 7.x-1.6

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). :(

sgurlt’s picture

Version: 7.x-1.6 » 7.x-1.x-dev
Status: Active » Needs review
1.07 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch ctools-export_fix-1956528-5-7.x.patch. Unable to apply patch. See the log in the details link for more information. View

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

Status: Needs review » Needs work

The last submitted patch, 6: ctools-export_fix-1956528-5-7.x.patch, failed testing.

pdcarto’s picture

973 bytes
PASSED: [[SimpleTest]]: [MySQL] 121 pass(es). View

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.

pdcarto’s picture

Status: Needs work » Needs review
MustangGB’s picture

Status: Needs review » Reviewed & tested by the community

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

MustangGB’s picture

DamienMcKenna’s picture

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

rivimey’s picture

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

Seems to be good to go.

japerry’s picture

Status: Reviewed & tested by the community » Fixed


  • japerry committed a67957f on 7.x-1.x authored by pdcarto
    Issue #1956528 by pdcarto, sgurlt, lukio, jessepinho, texas-bronius:...

Status: Fixed » Closed (fixed)

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