For reference, this problem is somewhat related to: http://drupal.org/node/345754 which relates to lost permissions after changing a node-type's machine name. This issue include that one plus some more oddities.

Basically, changing a node-type's machine name is not a good idea. You should either keep the original machine name or delete the entire node type and start over.

Here is what happens: I had a first content type called "ct1" with a couple of fields defined. I created a node and added a comment as well. Next, I renamed "ct1" (and its machine name) to "ct1renamed". I did not alter the fields. The permissions I had assigned to ct1 did not transfer with the name change. i.e. no permissions are checked after the rename. This appears to be the 345754 issue. The database field "permission" in table "role_permission" still references ct1 (i.e. create ct1 content, etc), but on the screen admin/people/permissions they are rendered as "ct1 renamed". Perhaps this aspect "works as designed", idk.

First set of problems:

  1. The permission settings were misplaced by the rename. (see below, they come back)
  2. The table "role_permission", field "permission" does not reflect the name change (works as designed?)

Flushing caches did not correct anything.

Running cron did not correct anything.

I then re-used the machine name ct1 by creating a new (second) content type called "ct1". The new ct1 saved without any error message. At this point I had the old "ct1 renamed" and the new ct1.

Second set of problems:

  1. The new ct1 is not listed on screen admin/structure/types
  2. The new ct1 is not listed on screen node/add
  3. The new ct1 is not listed on screen admin/people/permissions
  4. The table "role_permission", field "permission" still shows ct1 references while admin/people/permissions references ct1 renamed
  5. Both node_type's (ct1 and ct1 renamed) share the same orig_name (ct1)

Next, I deleted content type "ct1 renamed" which correctly deleted the content that I have created in the beginning. Then, I navigated back to the screen admin/people/permissions. The permissions returned to the ct1 references and the "lost" permissions were restored. I don't know where those permissions were hiding...

Summary:
I also don't know the history behind orig_name but after I renamed ct1 to ct1 renamed, the orig_name remained at ct1. Hence the meaning of orig_name. There must be a hook somewhere that recognizes the rename for displaying the permission text, but that hook does not track the permission settings even though they exist somewhere. When I added the new ct1, there became 2 node types having the same orig_name ct1.

Obviously, the instant fix is not to change machine names.

-Bob

Comments

julien’s picture

julien CreditAttribution: julien commented

Did reproduce the issue for the non-showing content type after readding the old content type ct1. It seems in the db that the two content type rows have for orig_type value "ct1".
It seems that the orig_type value in the table is not updated to make it show up, after renaming the field. Just update the db, change the orig_type value from "ct1" to "ct1_renamed" and it will show up.
It is because of line 722 of node.module. it compare "ct1" to "ct1_renamed" and unset the first ct1 content type.

      if ($type_db != $type_object->orig_type) {
        unset($_node_types->types[$type_object->orig_type]);
        unset($_node_types->names[$type_object->orig_type]);
      }

Not sure where to fix this, if it has to be fix there on display or on node_type_save($info), it seems that the value of $info don't provide any info to check if it's a content type that is being renamed. the is_new value is always set to 1 even on adding a new content type or renaming it.

DanZ’s picture

DanZ CreditAttribution: DanZ commented
Version: 7.15 » 8.x-dev
Priority: Minor » Normal

Proposal: Display the 'orig_type' value on admin/structure/types/manage/% and include an explanation that no new types can use that machine name.

I'll bump this up to "normal" because, even though this bug only bites once in a while, it bites really hard, and it's really difficult to troubleshoot.

I had an Ubercart product type called "book". I changed the machine name before installing the Book module. The "Book page" content type (machine name: "book") did not show up at all, even though it was in the database. This rendered the module useless. To fix the problem, I used a database editor to change the 'orig_type' field of the renamed book type in the {node_type} table.

It was only because I was familiar with the database structure and was lucky enough to find this issue post that I was able to troubleshoot and solve the problem. There was no error message or any other hint as to the problem. This would be an insurmountable problem for some Web admins, with no workaround, and no hint from the Web UI that the orig_type even exists.

"I already changed the machine name. Why isn't this working?"

Some sort of warning or explanation on admin/structure/types/manage/% if you change the machine name would help a lot. It would have saved me several hours of frustrating troubleshooting, and would save other admins from needing to rebuild a site from scratch.

davidwbarratt’s picture

davidwbarratt CreditAttribution: davidwbarratt commented

If you have no nodes associated with the original type, is it a bad idea to change the name of it in the database?

Thanks!

swentel’s picture

swentel CreditAttribution: swentel commented

There's a big chance renaming will be removed, see #2172843: Remove ability to update entity bundle machine names

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost commented

I'm sure that no way to take all relations into account. so better left as is or drop away.

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost as a volunteer commented
Related issues: +#2172843: Remove ability to update entity bundle machine names
DarrellDuane’s picture

DarrellDuane CreditAttribution: DarrellDuane commented

Can someone explain why we have the orig_name field in node_types? Isn't there a way to entirely rename all uses of the original name to the new name ? I know for some modules we'd need to expose a hook to ensure the renaming happens.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dpi’s picture

dpi
Location Perth, Australia
CreditAttribution: dpi as a volunteer commented
Status: Active » Closed (outdated)

Node type machine names are now immutable #2172843: Remove ability to update entity bundle machine names