Renaming content type screws up views filter by node type

This is not a bug.

The machine name of a content type is the unique identifier for that content type. If you change it, you're telling Drupal that it's now a different content type. Functions that identified it by that name no longer know where to find it. There is no way for Views to tell that you renamed it; as far as it can tell, you deleted the original and created a new content type.

Don't change the machine name of a content type once it's created. This is the reason future versions of Views no longer allow you to change the view name.

There is something really important points here:

There is no way for Views to tell that you renamed it; as far as it can tell, you deleted the original and created a new content type.

You respond to this as if there's some magic way for it to tell because we are magically willing it to be prescient and interpret an administrator's intent upon changes in the database. This is a very fine fantasy, but I have yet to write actual prescient code. I'm sure that when I am about to do so, it will let me know.

Not to mention, it's not Views' problem to fix perceived problems in the rest of Drupal's UI. It's not just Views that are going to break if you change your content type names, and its' not Views' responsibility to fix it. It's especially not going to ever happen in the Drupal 5 version of Views, which is not getting much in the way of new features.

The fact that Views has gone 3 years and this is the first time anyone has complained about it indicates to me that you are making a mountain out of a molehill.

Just to throw my two-cents in, I have to agree with xamount on this one. As developers, I think we often forget we are also users. As a head of development, I've had to gently remind my technical infrastructure peers of that on a number of occasions when they have decided to make changes to systems without consulting my team ("You guys are only developers... it's not like you're users," they say as they bring down the development database server rendering 100 employees unable to do their work for a day or two).

One principle of good software design is to never leave a system in an inconsistent state through something our software does. Another principle is user-friendliness, even for developers. After all, how many of us are using colour-coded intelligent editors as opposed to vi or better yet ed, or notepad? And, this area of Drupal is not a "Developer-only!" area, as it's all configuration. In other words, it seems to me that it's really is meant for non-developers.

So, for this particular item, from a functional standpoint, it would be great to be able rename a content type, and even fields, and have Drupal ask the question, "Are you creating a new content type / field, or are you merely renaming?". If the former, then do that, if the latter, do that.

Seems to me that the appropriate modules (such as node.module and cck for custom content types i.e. those very handy CCK fields) could provide an API (hey, don't node and cck already do that?) so that other modules (like views) could implement the hook_node_api and hook_field (there's another one in node.module too), being informed of what happened, and that something was renamed from x to y. Then those module could do their own housekeeping.

Just a thought... :-)

However, I strongly agree that locking either a developer or an administrator into an initial decision unnecessarily (such as the name of a variable in the case of a program... how often do we wind up changing those as we code? ...or the name of a content type or a field) is not a good thing to do.

shawn

As developers you should know that there is an appropriate venue to discuss the solution to this problem. This is the Views issue queue. This is about Views. Ultimately, the problem you're discussing is not a Views problem.

I wouldn't mark this critical. The UI for administering a content type is allready a bit better since it hides the machine name textfield by default. I'll let anyone else come up with some text.

It should be enough to add under the field "type" where the description:

The machine-readable name of this content type. This text will be used for constructing the URL of the create content page for this content type. This name must contain only lowercase letters, numbers, and underscores. Underscores will be converted into hyphens when constructing the URL of the create content page. This name must be unique. WARNING!! Changing the machine readable name after content has been created with this content type is not recommended.

what is bolded has been added by me. I don't think we can use "views" in this area, as core does not ship with views. A simple warning may be enough.

good catch, I've corrected my previous comment. A patch should be created so that it can be reviewed. This is a good one for someone who wants to learn.

Comment http://drupal.org/node/346053#comment-1158072 mistakenly assigned this to Drupal 7.x-dev.
Setting it to 5.10 as initially announced.

it was moved to 7.x so that core developers could work it in and backport it to previous versions. A fix specifically for 5.10 won't happen.

Excuse my ignorance, but why doesn't Views implement http://api.drupal.org/api/function/hook_node_type/6 ? That's what it's there for: to act on changes to the node type, including machine-readable name.

I just had this issue, namely tried renaming content type, and on first check I noticed the views were empty (I checked the node type filter but I have not set any restriction on node type thus I am not sure why)
;)
So I quickly reverted it for the old name and now views pages work again, I believe I will have to update the views manually.

The contemplate modified node pages were broken as well, so it looks like I will have to update the node type name manually in the contemplate table on my next attempt :)

I think I also found some duplicates
http://drupal.org/node/345754
http://drupal.org/node/258706

Again, what exactly is the fix that's being asked for here? Core offers a hook for modules (such as Views and Contemplate) to react when a node's machine name is changed: hook_node_type. The fact that Views can't or won't use the hook for performance reasons or whatever seems like a Views issue, not a core issue. And according to Earl, from a Views perspective this issue is won't fix.

Did I miss something?

You suggest we should be posting these requests to each module separately?

Also, as I understand merlin said he wont fix it before you referred to the http://api.drupal.org/api/function/hook_node_type/6 which seems the proper way to handle this, so he might change his mind :P

You suggest we should be posting these requests to each module separately?

Well, unless someone can explain what we're to fix in core for all of these modules (the only proposed solution I see is someone suggested expanding the description on machine language, which should take someone 5 minutes to make a patch for), then... yes. :)

Good idea, I think the message could be more proactive saying, you may need to change the content type manually in the database tables, so this is only recommended for those familiar with mysql.

For example, I succeeded changing my content type name by going into the contemplate table and rewriting the old content type name which was left intact after the change.

Also, some php block snippets use the content type name as well, so you have to change it there too...

So it is possible to change it, you may just need to do some manual work :)

What if we forwent the screaming at users and simply disabled the ability to change the machine name if content exists of that type, with an explanation as to why that was so?

But if you make a typo on a content type name, aren't you more likely to fix it right when you create it, as opposed to after you have 20 nodes of that type?

I for one really appreciate being able to change the name of a node. Not being able to rename CCK fields has been a huge pain in the butt. Let's not break nodes too.

Looking at http://api.drupal.org/api/function/node_node_type/6 I'm fairly certain that this is a views issue. specifically the part that goes:

function node_node_type($op, $info) {
  if ($op != 'delete' && !empty($info->old_type) && $info->old_type != $info->type) {
    $update_count = node_type_update_nodes($info->old_type, $info->type);
//...

function node_type_update_nodes($old_type, $type) {
  db_query("UPDATE {node} SET type = '%s' WHERE type = '%s'", $type, $old_type);
  return db_affected_rows();
}

So clearly there's enough information for views to update the filter list.

Note that there has been considerations about allowing CCK field name changes until there are actually data in the field. Noone actually took the time to actually implement it, but it's very similar to the suggestions above...

Since views that are in code are immutable, I am simply uninterested in doing a half-ass job of this. I think changing machine IDs mid-stream is bad and should not be done.

I need to look at the guts of this, but it seems to me that there should be some database key for this? I mean, are we really keying off the machine readable name to determine the id of a content type? I can't change nid's, tid's or other id's through the interface.

Ignore me if I'm way off base here. But I think that would bounce this back to a drupal core discussion?

This isn't jsut a views issue, it has cropped up in the access control system, and node-reference as well.

Webchick is right that hook_node_type offers a method for module developers to react to updates to node types. However, it doesn't appear to be happening.

Right now we are asking module developers to proactively implement a hook to detect changes to a node_type if they want to interact with the node system. If we add a content type id to the the node_type table couldn't those changes be pushed to the interacting module as opposed to expecting them to implement a function to detect them?

I'm just asking here, I haven't dug that far yet, any thoughts?

Tresler, How about a more specific example of why this is a core issue. I'm not understanding the problem "asking module developers to proactively implement a hook to detect changes to". We do exactly that in any number of ways. Care that a node is being deleted? Want to control access to a node? You do that by proactively implementing a hook to detect changes.

I really think this is a view issue. As has been noted above CCK and core both manage this. I can totally understand Earl's reasoning for not fixing this, it was spelled out pretty clearly above.

I won't reopen this till I get a chance to write some code, but imo it is a core problem because it is a poor data structure.

I'm not proposing that hooking in pro-actively is wrong. I am saying that by adding a key, you eliminate the need to hook at all, in this case. You don't get nodes by calling the Node title, and you don't get terms by calling the term name. You get them by an ID. If a content type has an ID, there is a whole section of code that doesn't need to be run on every module that wants to keep its functionality associated with one specific content type.

In this case the default behaviour should be to keep functionality associated with a content type, regardless of machine name. The same as it is for nodes and terms, and vocabularies, and watchdog entries, etc.

Anyway, maybe I'll find out why there isn't one when I get some time to address it, we shall see.

Even if IDs were in use I don't think VIews would use them because they're less portable across sites, making the import/export more difficult.

Ok... what is the difference in portability between exporting a content type ID and exporting a taxonomy filter vid? The letter is how filters are exported, as I understand it.

No matter, I'll let it drop since it doesn't seem to be a major issue, and lacks support. One less item on my todo list. :)

-Sam

The difference is that with taxonomy I don't have a choice. If taxonomy had names I would use those instead of the IDs.