Jeremy Epstein wrote:
So, I propose that this be removed and alslo that a hook be created to allow modules to act when a node type is deleted.
-1 to this feature being removed, but +1 to creating a hook to allow modules to respond to changes to a node type. I have created an issue for this task:
This is a battle I didn't want to fight while getting configurable content types in core, but it needs to be fought now. Lets look at places where the machine readable node type is used: - Database - PHP code - URLs - HTML (id and class attributes) Here is what I think should happen in each case Database: databases like numeric keys. I think it would be good to replace the machine-readable type there with numbers. PHP code: since there is no exposed UI here (always use the [human readable] type name), I think the same numbers might work. This is a bit harder with hard-coded node types, since they have a hard-coded name that is used. Perhaps the hard-coded name can be recalled and used for hook invocation where applicable. URLs: Currently, we have numeric ids scattered in many URLs across Drupal. I'd like to see this change in the future, but we don't have a good example of a design pattern that works and we don't have a system for setting up redirects for changed URLs. I'd like to see a machine readable name work. HTML: There were numerous complaints about flexinode using numeric ids, they are clearly unacceptable here since themeing should not require knowledge of how the database is set up. They should be machine readable. Two more questions- should machine readable names be changed and should they be configurable by users? Machine readable names should definitely be changed. That does affect URLs and CSS depending upon HTML. In an ideal world, HTTP redirects would be set up for changed URLs, but as mentioned earlier, that doesn't exist at the moment. For CSS, a warning or message should inform users of what changes are needed. I've summarized how to make code and the database not care about machine readable names changing and how to gracefully handle them changing in URLs and HTML. I think it is safe to assume that people want the machine readable name to directly correspond to the [human readable] content type name. A bit about the situation now. Here is the help text for the machine readable name: # 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. It is recommended that this name consists only of lowercase # letters, numbers, and underscores. Dashes are not allowed. Underscores # will be converted into dashes when constructing the URL of the create # content page. The name must be unique to this content type. That is a lot to think about, especially when there is a second name that is human readable and directly corresponds to this name. We could auto-generate this name based on the current [human readable] name and simply remove the whole field. If we sum the combined time of people may spend wasting time trying to figure this out and compare that to the remaining developer gain, I think the users should win. I think this is enough to show that machine readable names used in URLs and HTML should be auto-generated based on the content type name. -- Neil Drumm http://delocalizedham.com/