[development] node types should not be changeable, operations need hooks

[Neil Drumm]

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/