7.36 (Issue #1441950) May Cause Node Types to be disabled

No, it's a real bug of Drupal core since 7.36 breaks existing sites which worked perfectly before. I encountered this problem also (again, with node bundles which were created by Features which are evil anyway).

This issue is also happening on my site on my local environment. I updated from Drupal 7.34 to Drupal 7.36 and half of my content types disappeared. They are not listed under Content and when I go to a view that uses one of them, it gives me an error.

I updated Drupal and ran update.php but the update page did not have any database updates so I don't know what is happening. It has to be on the code side. I resorted the code base back but that did not make the missing content types appear. My local site is messed up now.

I will NOT move this to our QA or production environment for all of our Drupal installations until it is fixed. This issue is huge. Not a very happy Drupal camper right now.

This needs some kind of advisory to go out warning people not to install 7.36.

Yes, for me, they were the result of long ago using Features to define several content types. Eventually, we stopped using that Feature and someone (probably me) deleted the feature module. Suddenly 7.36 discovered that fact and disabled those content types with no indication that it was doing so. I too updated the node_type table to fix it for me.

Same issue for me. I altered the database node_type custom=1 modified=1 locked=0 disabled=0 to restore the node type.

Is there a way to do this automatically in the next Drupal release via hook_update? Or it's possible to create a more serious problem by doing so?

Just as a confirmation, I had an issue also that the custom modules did not show up in the content type list any longer after upgrading from 7.35 to 7.36. I added locked => 0 and custom => 1 to the modulename_install() script

function modulename_install()  {
  $modulename = array(
    'type' => 'modulename', 
    ... 
    'locked' => 0, 
    'custom' => 1, 
    ...
  ); 

and that seemed to fix the problem.

I had to change the module name to "node" as well.

Is this a bug or expected behavior? From reading #1055460: Disabling a feature does not disown content type it seems like this is how many people expected Features to behave, and the change was proposed to core by a Features maintainer. I think it also made things consistent with how other node-type-providing modules (such as Blog and Forum) already behaved when they are disabled.

That said, this is a behavior change (and definitely one that would be confusing if the original module that provided the node type is long long gone) so I'll add something about this issue to the 7.36 release notes.

I added this to the release notes (https://www.drupal.org/drupal-7.36-release-notes):

https://www.drupal.org/node/2464161/revisions/view/8315047/8328269

Following up on the last paragraph there, I'm curious if anyone has seen this change in behavior crop up with a content type defined by a regular module (not a feature)? As I mentioned there I think it's theoretically possible to have a behavior change in some of those cases too, but I'm guessing it's not common.

So there seem to be a few ways to potentially fix this if it happens on a site and you don't want the content type disabled:

1. Reenable the module that defined the content type (that's the one I mentioned in the release notes for now).
2. Run a custom database query (being worked out in the comments above).
3. Just manually re-create the content type via the administrative interface, by hand. As long as you give it the same machine name that the old one had, I think everything will go back to working fine.

Not sure if there are any others.

I also found (reading the above issue) that Features has some dead code to deal with this situation (it was committed years ago but stopped working along the way) so I wrote a quick patch to make it work again: #1055460-128: Disabling a feature does not disown content type (However I don't think that does anything to help with a module that was already disabled and is now gone from the site.)

Thanks for the explanations, David.

I'm not sure your potential fix #3 would work. The content type is not gone, just disabled. So the row is still there in the node_type table. I would expect a duplicate key if one tries to recreate it. And then, there are all the fields that modules are expecting on those content types.

In my case the only choice was the DB update. While it is not the first time, I just don't expect Drupal to force me into manual database updates.

So the proper way is hook_update() in the next version of Drupal core, right?

@NancyDru and @David_Rothstein, I tested David's third bullet in #16 above:

3. Just manually re-create the content type via the administrative interface, by hand. As long as you give it the same machine name that the old one had, I think everything will go back to working fine.

And it loooks like this fix does indeed work. All fields remain, all field settings, comment settings, comment dispay—I even had a handful of conditional fields module settings and all of those were preserved.

However, because it overwrites the existing row in the database, any settings on the Edit tab at admin/structure/types/manage/[machine-name] will need to be reset. This includes Description and all settings in the vertical tabs (Submission form settings, Publishing options, etc.).

I tested on an affected site, which had Features-provided content types where the features were looong gone. Everything seems to be working just as it did prior to 7.36.

I also tested and confirmed the direct database method, setting the following on the node_type table rows for the affected content types:

custom[1], modified[1], locked[0], disabled[0]

Use your favorite SQL interface to set the above values, such as the command line, PHP, drush, or a browser-based tool like Chive or PHPMyAdmin.

I also have this issue. I have used paid theme Dawn, which add some content types. After update to 7.36. all of them are disabled. If I looked at database node_type table all of them have module = dawn_tools, but that module is not included at all to my paid package. There is no Features module either.

This is indeed a rather large issue for anyone using Features-exported content types.

The fixes described in #2 and #12 get everything kosher again. Edit your hook_install() definitions to include:

'locked' => 0,
'custom' => 1,

In the associative array you feed to node_type_set_defaults(). Then you're back on track.

Here's an update that you can stick into a custom module:

/**
 * Rescue content types that might disappear with 7.36.
 */
function tta_custom_update_7005() {
  // Spin through the node_type table.
  // This is only good where we don't have deleted node type modules or features.
  $ret = '';
  $result = db_query("SELECT type, name, module FROM {node_type} WHERE module <> 'node'");

  foreach ($result as $row) {
    if (!module_exists($row->module)) {
      $x = db_update('node_type')
        ->fields(array(
          'module' => 'node',   // Give it back to the Node module.
          'custom' => 1,
          'modified' => 1,
          'locked' => 0,
          'disabled' => 0,
          ))
        ->condition('type', $row->type)
        ->execute();
      $ret .= '<p>' . check_plain("$row->name content type rescued from the missing '$row->module' module.") . '</p>';
    }
  }

  return $ret;
}

Most sites I've seen or worked on will be affected by this change.

The workaround in comment #24 will get us out of trouble.

Thanks NancyDru

I had the same issue. Ours was caused by a Feature that was turned off at some point (years ago).

@lunk_rat, thanks for confirming the workaround that involves recreating content types by hand. (That's what I thought I saw too - you'd have to redo the content type settings but not redo any field settings.)

So this issue is up to 35 followers - still an edge case but one that's definitely affecting a number of sites. (https://www.drupal.org/project/usage/drupal says 50,000 sites are running 7.36 so far, but it's probably quite a bit more by now since the stats are from last week and the release was midway through the stat-collecting period.)

I think for a core fix here, we'd want the least intrusive update possible - basically an update function that reenables things that were disabled (but doesn't change anything else about them)? This would require rolling back the original committed patch also. Which sounds OK to me; it was a bug fix but not a particularly important one, and in the end it turns out it could have used some more review.

Also, thanks to people who have been working on custom update functions for this! #24 looks reasonable to me too though I haven't tested it myself.

My fix is not one to be used in core. I put it into a local custom module so that it would move through the deployment process with core and undo the damage.

Have noticed the same issue when upgrading development branch to 7.36.
There are feature created content types.
Running a database update on these content type as mentioned in #21 restored the content types.

I am unable to edit basic pages after an update. What to do?
Was able to fix using the drush sql-cli and correcting the
node_type table settings for the 'page' type. Very weird that
it would set disabled=1 on an update even though there was
no DB update in the core update...thanks to everyone for the
pointers on where to look for a quick fix.

I came across this issue recently and was really in a bind, #24 did the fix.

Of course, as always, back up your Database before proceeding to be able to revert any changes you make.

We did some counts on what the fix did and this seems like a very solid way to fix the issue.

Thanks a ton NancyDru

Updating to 7.36 from 7.34 on a bluehost multisite was a disaster for me. I am somewhat of a novice/part-timer, but long liker of Drupal. I have never had such a mess before and am at a loss.
I spent all day yesterday until late into the evening trying to restore things. Got them working and assumed the problem was unrelated to Drupal but more about some wonky server work...I, like a sucker, tried again. I got consistent bad results both times. I do not think I ever used Features and have no idea whether I have set up content types incorrectly or not. They have worked, which is about all I know. (I am happy to have someone more knowledgeable check this for me.)

Updating to 7.36 seems to screw up paths on the server or something. I am not going to try a third time but may consider 7.35. The frustration is that restoring the backups is not really fixing things.

Here's what happens to one site (buntingmed.com) when I update/install all but the sites folder to 7.36 from 7.34:

Multiple notices and warnings about php and .inc files, admin interface there but site not loading correctly. Then I restore from backup back to 7.34. These persist but on refresh the reports page, they gradually go away. I refresh cache and more warnings go away (same warnings as yesterday when I tried this). Just in case something happened with the sites folder (despite me not overwriting it), I restored that to this morning's back up. Still a couple notices related to undefined indices or properties of my theme linger.

Now this has been even worse for another hosted site, built just recently.
It totally disappears when I update to 7.36. There is nothing, it had reverted to a blank screen with a host favicon...no log in/admin pages. No apparent drupal installation at all. Around the time it came back late last night, it had been unassigned (probably customer service, who had mentioned this). When I re-parked it, it started working without any problem. Unassigning and re-parking has not restored this today. It is not working at all. You can see it at www.outcomespositive.org.

I am not sure if it will just come back on it's own, since other warnings/notices seemed to gradually improve or what. I am not used to having no explanation, where things just change on their own. Any ideas? And do I dare try 7.35 if/when I get things fixed up again?

thanks for any advice in advance
cheers

The 7.25 branch of the Features module received a patch for this a few days ago. I first updated the Features module to 7.25 and then updated Drupal to 7.36 and it seems to work fine.

I updated to the latest Features module... than updated from 7.34 to 7.36 all custom content types are gone. Disabling the Features module and enabling it again did not help... Any tips how to solve this?

See #24.

I'm not able to get 24 to work. Do I only have to enable the module or is there something else involved? Also, is this fix only good if features is not used? I believe the node_types that are disabled were not created by features.

If the module that created the node type is disabled, this will rescue the content type. It is an update function, so it goes in some module's .install code, with the name changed appropriately, then you have to run update.php.

I noticed in my DB that the module name isn't set to node for the affected content types but something else. I changed the SQL query WHERE module <> 'byname'. There is still no change for me, and I think this is because I'm implementing the module wrong.

I have fixme.info

name = fixme
description = fixes content types
package = Fix
core = 7.x
files[] = fixme.install

fixme.module

<?php>

and fixme.install (includes this script).

<?php
/**
 * Rescue content types that might disappear with 7.36.
 */
function tta_custom_update_7005() {
  // Spin through the node_type table.
  // This is only good where we don't have deleted node type modules or features.
  $ret = '';
  $result = db_query("SELECT type, name, module FROM {node_type} WHERE module <> 'museum'");

  foreach ($result as $row) {
    if (!module_exists($row->module)) {
      $x = db_update('node_type')
        ->fields(array(
          'module' => 'node',   // Give it back to the Node module.
          'custom' => 1,
          'modified' => 1,
          'locked' => 0,
          'disabled' => 0,
          ))
        ->condition('type', $row->type)
        ->execute();
      $ret .= '<p>' . check_plain("$row->name content type rescued from the missing '$row->module' module.") . '</p>';
    }
  }

  return $ret;
}
?>

Shouldn't this work?

Try function fixme_update_7000

@museumboy I'm guessing there are a couple different issues at play here.

1. If you explicitly want to keep museum as the owner of some content types than I think you'd want to test for both:

$result = db_query("SELECT type, name, module FROM {node_type} WHERE module <> 'node' AND module <> 'museum'");

If you just want to change them all to node, NancyDru's sql from #24 is perfect.

2. It is my understanding that update hooks will only fire if the module was already enabled and the version number increments and the hook_update_N increments. Updates do not run just because you've enabled the module. If you want, you can have your install loop through your updates. This may not be a best practice in all instances, but for this kind of fix it seems ideal:

/**
* Implementation of hook_install().
* Runs all updates on module install.
*/
function my_deploy_module_install() {
  // Loop through all available updates.
  // Source: http://dcycleproject.org/blog/43/run-all-update-hooks-install-hook
  // Attribution: alberto56 https://www.drupal.org/u/alberto56
  for ($i = 7001; $i < 8000; $i++) {
    $candidate = 'my_deploy_module_update_' . $i;
    if (function_exists($candidate)) {
      $candidate();
    }
  }
}

Attached is a small module that combines all of these. Download and enable and it should restore your content types on install.

Adding do the list of users with affected sites - in my case due to long-deleted features modules, I lost access to several vital content types. I was able to re-enable them directly by db edits but am concerned that this may happen again... is there something else I can/should do to prevent a recurrence?

Many, many thanks to Nancy Dru and all others who contributed!!

Interestingly we had similar issue. One of our content types got disabled under Structure->Content Types, but contents created using that content type node forms were still around. We did multiple changes to the code and database at the same time, so didn't have a chance to put a finger on any one thing as a source of the issue. We have dozen content types on this site and the site itself is couple of years old since it was published. The site is content-rich and has a dozen content types but only one got disabled.

By a stroke of genius, I looked in the node_type table and noticed that one content type had "disabled" set to 0 whereas other content types had "disabled" set to 1. Once I set the disabled content type to not disabled in the table manually, things return to normal.

Till today, I don't know what really caused it to turn off the "disabled" column and why for that particular content type, I am happy what I did, fixed it. It took only 10 minutes to fix the issue and I moved on to the next issue.

I hope this helps at least some of you out there.

Let's see if we can get a fix in for this into core (and include it in a bugfix release in the May 6 release window).

This patch reverts #1441950: Node types removed from hook_node_info with base = 'node_content' cannot be deleted and then adds an update function to undo any node types that would have been disabled by it (see #27). It seems to work both for a site updating directly from 7.35 and earlier, as well as for a site updating from 7.36 that ran into this issue.

Please review and test this.

@tebearly:

Updating to 7.36 from 7.34 on a bluehost multisite was a disaster for me. I am somewhat of a novice/part-timer, but long liker of Drupal. I have never had such a mess before and am at a loss.
I spent all day yesterday until late into the evening trying to restore things. Got them working and assumed the problem was unrelated to Drupal but more about some wonky server work
......
Updating to 7.36 seems to screw up paths on the server or something. I am not going to try a third time but may consider 7.35. The frustration is that restoring the backups is not really fixing things.

Sorry you're having trouble, but based on your description it really doesn't sound like it's caused by this issue. Perhaps either a problem with server permissions (e.g. files not readable by the webserver) or the files from Drupal 7.36 not being copied to the server correctly, etc? Make sure you are following the instructions in UPGRADE.txt carefully, and hopefully that will help...

@David, great thanks for pushing this fix in the core. Hope to see it in 7.37.

David, I appreciate this change. Based on #14, I assume this will some day work its way back into core (perhaps 8.x). I wonder if there is some way to alert potential users to this before it happens; maybe in a hook_requirements() implementation somewhere?

/**
 * Implements hook_requirements().
 */
function tta_computed_requirements($phase) {
  $requirements = array();
  switch ($phase) {
    case 'runtime':
      $result = db_query("SELECT type, name, module, custom, disabled FROM {node_type}");
      $disabled = $missing_module = array();
      foreach ($result as $row) {
        if ($row->disabled) {
          $disabled[] = $row->name;
        }
        if ($row->module != 'node' && !module_exists($row->module)) {
          $missing_module[] = ucwords($row->module) . " ($row->name)";
        }
      }
      if ($disabled) {
        $requirements['content_type_check_disabled'] = array(
          'title' => t('Content Type Disabled'),
          'value' => format_plural(count($disabled), 'Disabled content type: @list', 'Disabled content types: @list',
            array('@list' => implode(', ', $disabled))),
          'severity' => REQUIREMENT_WARNING,
          );
      }
      if ($missing_module) {
        $list = array();
        $requirements['content_type_check_module_exists'] = array(
          'title' => t('Content Type Module Missing'),
          'value' => format_plural(count($missing_module),
            'Missing content type module: @list',
            'Missing content type modules: @list',
            array('@list' => implode(', ', $missing_module))),
          'severity' => REQUIREMENT_ERROR,
          );
      }
      
      $result = db_query("SELECT n.type, COUNT(n.type) AS how_many FROM {node} n "
        . "LEFT JOIN {node_type} t ON t.type = n.type "
        . "WHERE t.type IS NULL "
        . "GROUP BY n.type ");
      $unknown = array();
      $count = 0;
      foreach ($result as $row) {
        $count += $row->how_many;
        $unknown[] = $row->type;
      }
      if ($count) {
        $requirements['content_type_check_unknown_type'] = array(
          'title' => t('Content Type Unknown'),
          'value' => format_plural(count($unknown), 
            'Unknown content type found: %list',
            'Unknown content types found: %list',
            array('%list' => implode(', ', $unknown))),
          'severity' => REQUIREMENT_WARNING,
          );
      }

      break;
  }
  return $requirements;
}

Based on #14, I assume this will some day work its way back into core (perhaps 8.x). I wonder if there is some way to alert potential users to this before it happens; maybe in a hook_requirements() implementation somewhere?

Well, I think what we'd do is reopen #1441950: Node types removed from hook_node_info with base = 'node_content' cannot be deleted and put a note on that issue to make sure the problem here gets addressed before committing a fix for that again. I think it would have to be addressed directly somehow (more than just displaying a warning to users).

I think 8.x already stores content types very differently, and there's no upgrade path between Drupal 7 and Drupal 8 so I'm not sure what would happen to content types not associated with a module in a future upgrade/migration from Drupal 7 to Drupal 8.

So I would say there doesn't need to be a hook_requirements() like that in core, but it could definitely be useful in a contrib module somewhere (not sure which one offhand).

Now in the Util module

We also had several content types disappear. The interesting thing is that all the content was still visible, we just couldn't pull it up in the content type lists or use it as a view. Thanks for figuring this out. I am working with my database people to see what we have in our node_type table and will look into implementing the suggested temporary module.

Patch from #46 fixes the issue for me. Indeed, all content types are disabled after updating core.

Note that this is a site without features. (so all content types are just and only in the db). Have not seen it on sites with features (yet).

Applying the patch + running the update enables them again. Cache clear and we'r good to go.

Thanks, Rob C. I am curious how you wound up experiencing this issue on a site that doesn't use Features. Any idea? It seems like it would only happen if all content types were originally defined using hook_node_info() (and using that hook in a somewhat non-standard way, with 'base' => 'node_content'), and then those hook implementations were removed later on... basically if the code imitated what the Features module does without actually using it :)

Also, can anyone else test/review #46, and hopefully get it to RTBC?

We'd need to have it ready to go in the next week in order to do a bugfix release during the May window that includes this fix.

Works for me.

I can also confirm that #46 resolved my issues.

Just a quick note that while #46 will work fine, it will change any content types defined by other modules into custom types which may not always be desirable.

I don't use any myself, but I did notice when reviewing the node_type table that the panels_node module defines a Panel content type. The Quiz module defines several content types. I'm sure there will be other examples.

Turning these into custom content types should work fine, but I expect that these content types will be disconnected from their parent modules from that point on. So if these modules modify their content types in future updates, the content types on the site will not reflect those updates, which could cause the module code to break.

@scott.whittaker, can you clarify what the steps to reproduce would be for that? The patch in #46 doesn't have any code that directly changes a content type to a custom state, so I'm not sure how that would happen.

Modules which define their own content types already are not guaranteed to have changes they make in the hook_node_info() code reflected on all existing sites that use the module (since any site that has edited the content type via the admin interface will already have put it in an overridden state). I don't think this patch changes that behavior one way or the other - at least it's not supposed to.

By the way, thanks everyone for the reviews so far.

@#54 David: i do. The site used to be in features, but the node_type table was never updated accordingly. The 'module' column didn't contain 'node' for all of the disabled types, but the removed feature. So still good to go, with a minor note. I don't see this as a real issue, but good to know.

I saw nodes being disabled, which appear on cursory inspection (after spending many hours locating the problem) seem to be node types provided by the OpenPublish distribution (in particular openpublish_blog_post and openpublish_article, which are Features bundled with the distro), AND some (not all) node types which are also Ubercart products.

@David_Rothstein my mistake, I was looking at the code in #24 rather than your patch, sorry.

By the way I came across this issue on another site which is based on the Commerce Kickstart distribution where the product_display content type disappeared. Turns out the product modules had been disabled a long time ago, but the site was substantially build upon the content type they defined.

Thank you so much! installed the module on my Open Publish site. Content types all back now.
Thanks for the quick easy fix. Life saver.

I was experiencing the same issue due to content types created by features on 5 sites I maintain. The patch in #46 worked for me on all my sites. Thanks!

OK, thanks for the followup clarifications everyone, and the additional testing.

Committed to 7.x!

I had pretty much the same problem on one site as the one 108michele had. I fixed it in the db. The content was intact but the content type had lost its definition.

I'm curious if anyone has seen this change in behavior crop up with a content type defined by a regular module (not a feature)? As I mentioned there I think it's theoretically possible to have a behavior change in some of those cases too, but I'm guessing it's not common.

David, I have had this happen on a site which has never used Features. My own custom module created a content type in its install file similar to this:

  $content_type = node_type_set_defaults(array(
    'type' => 'my_type',
    'name' => 'My type',
    'base' => 'node_content',
    'module' => 'my_module',
  ));
  
  // Add the body field
  node_add_body_field($content_type);
  
  // Save the content type
  node_type_save($content_type);

It didn't use hook_node_info().

This module is still enabled and has never been disabled. Upon updating to 7.36 the content type disappeared, and so did some admin menu shortcuts relating to it, although the content itself still displayed correctly, which means I didn't see any problems when testing the update so sadly it got pushed live.

Changing disabled to 0 in the database did not fix it. Applying your patch did.

I'm guessing if I set custom to 1 in the database then I wouldn't have needed your patch. But as I understand it, custom indicates a content type customised by the UI, and this content type was not.

I realise now that the 'module' column of a content type doesn't mean what I thought it did, so the code I used to create the content type is not correct: this content type was not "defined" by my module since it wasn't in hook_node_info(). I should have set the module to 'node' and custom to 1.

This looks like what happened to me after I upgraded a Drupal Commons-based site (no Features) to 7.36 - the Feed and Feed Item node-types disappeared from the content-type list, although they were still working. Since I knew the names of the content types, I tried recreating them and found that all the appropriate fields and display reappeared automatically.

We'll see what happens with 7.37...

Updating to 7.36 and running updb also disabled content types that were created/exported using the Feature module.

I could re-enable those content types again using the db approach described above.

I did it through phpmyadmin, went into the node_type table and adjusted the affected content types to

custom[1], modified[1], locked[0], disabled[0]

plus change the module name to "node". (This last step was important as without it I couldn't re-enable the content types.)

Then I had to update my database again using drush (you can also do it through the administration interface).

This issue caused a lot of headaches here and I had one or two akward situations with customers, some questioning the reliablity of Drupal (which is rubbish, I know). But still some concerns remain.

The conclusion I drew from this case is to ditch Features for good. I just hope that updating my sites to 7.37 won't cause those content types to disappear again.

Thanks a lot to all those that contributed to this issue. Very much appreciated.

The patch in #46 worked for me. I applied the patch after I made the core updates and ran the database updates.

I applied the patch. Then reran the database updates. Which fixed the problem.

I am also using features, this did not happen other sites that were not using features.

Every time I ran the database updates for 7.36 I would loose content types. The content would be there by the type would be missing.

David, I have had this happen on a site which has never used Features. My own custom module created a content type in its install file similar to this:

  $content_type = node_type_set_defaults(array(
    'type' => 'my_type',
    'name' => 'My type',
    'base' => 'node_content',
    'module' => 'my_module',
  ));
  
  // Add the body field
  node_add_body_field($content_type);
  
  // Save the content type
  node_type_save($content_type);

It didn't use hook_node_info().

Interesting. Yeah, I think for programmatically-created content types like this the standard way of doing it is usually to set 'custom' to 1 (see _book_install_type_create() for an example) since although it wasn't created via the user interface originally, the intention is for it to appear the same way as content types that were and behave like them going forward.

However, I agree it should not have broken. I am glad the patch here fixes that scenario too - thanks for reporting back.

Drupal 7.37 is out, so hopefully anyone who experienced this issue (and hasn't yet tried out the patch) will have it solved by updating their site to Drupal 7.37.

I updated the Drupal 7.36 release notes to reflect this, and also changed the description there a bit to include the scenario @Rob230 reported in #68.

I just realized tonight that a site I manage was affected. Several content types no longer visible in admin areas, and in views that filter on those content types. Features *was* used a couple years ago on this site, but was long since removed.

Anyway, I'm confirming that these content types were restored by installing Drupal 7.37.

Thanks to everyone who worked on this fix!

I think this patch can re-enable content types from features that had been manually disabled previously (on purpose). As there seems to be no way of distinguishing those from accidentally disabled content types it may not be "patchable", but this could still be worth mentioning in the release notes.

If it's a concern one could run a select query before the upgrade hooks and re-disable the relevant content types.