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

[Darrel O'Pry]

On Wed, 2006-08-23 at 10:18 -0700, Neil Drumm wrote:
> 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.


Why not use a sanitized human readable name in places like css and html
output?  What we're really talking about is user morphable database
keys, which in my opinion is out right wrong. We don't give end users
access to change nids? or any other ids do we?  

1) When you start considering cck/field.module whatever it will be, uses
node->type extensively as a database key. I'm sure there is quite a bit
of other code that would really like to have that string set in stone.
Modules that generate content types being one of them.

2) When you change that 'machine readable type' aka database key, in a
transactionless database you're asking for lots of trouble!

We need a reliable name to use in code and in the database. You can hide
it from site users with a properly sanitized 'Human Readable' type.

I'd prefer to see customizable 'machine readable node types' go the way
of the dodo.