node types should not be changeable, operations need hooks
While I really appreciate the hard work that went into moving user-defined node types into core, I think there is a problem that needs to be addressed: the ability of users to change the machine-readable name of the node type. First- a question. What is the use case for this? If I don't like the name of a node type (e.g. 'story'), I can just create an alternative. Trying to account for the possibility that the name of the type has changed (to me) makes the code look rather more convoluted than necessary and seems to introduce the potential for more bugs. Allowing users to change the node type will potentially create problems- for example with organic groups, where the names of "group" types are saved in a variable and there is no hook to let the module know they have been changed. Also, the current code fails to update user permissions (which are construced from the node type), if the name of the type is changed. 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. issue posting: http://drupal.org/node/77990
On 8/24/06, Peter Wolanin <pwolanin@gmail.com> wrote:
First- a question. What is the use case for this? If I don't like the name of a node type (e.g. 'story'), I can just create an alternative. Trying to account for the possibility that the name of the type has changed (to me) makes the code look rather more convoluted than necessary and seems to introduce the potential for more bugs.
I was the one that pushed for (and developed) the ability to change the machine-readable name of a node type, and I feel very strongly that this feature should remain in core, and that it is a feature worth maintaining, despite it making the node type system somewhat more vulnerable to bugs. There are a number of important use cases for this feature. What happens when a user decides that they don't like the machine-readable name that they picked a few months ago, and that they want to change it? What happens when that user's site already has hundreds of nodes of that type? If the user is forced to delete the old node type and to create a new one, then all the old nodes become corrupted (and there's no way to avoid this, since the system would have no way of knowing that they need to be updated to the new type). Not to mention the fact that from a usability point of view, it is absolutely unacceptable to have to delete and then re-create a node type, simply in order to update the value of one field. You've pointed out the possibility that users may want to update the names of their node types at some point. It therefore follows that we should make this as easy for them as possible, which is what the current system does.
Allowing users to change the node type will potentially create problems- for example with organic groups, where the names of "group" types are saved in a variable and there is no hook to let the module know they have been changed.
For module-defined node types, (a) the default behaviour is to NOT allow the machine-readable name to be changed, and (b) if this behaviour is modified, and the machine-readable name is modifiable, the original name is always still available, because it's stored in the 'orig_type' field of the 'node_type' table. The 'orig_type' thing also applies to user-defined node types. So modules that need a constant, permanent key to reference, can rely on 'orig_type' instead of 'type'. That's what it's there for.
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: http://drupal.org/node/80257 I have also filed a bug for the 'permission names do not change when node type name changes' issue: http://drupal.org/node/80253
issue posting: http://drupal.org/node/77990
And I have responded to that issue. Cheers, Jaza.
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/
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.
I'd prefer to see customizable 'machine readable node types' go the way of the dodo.
I agree. The only minor masking that isn't completely evident is in the URL, for example node/add/machine-content-type. If we are simulating the machine name change, we'll need to get into aliasing that. Most everywhere else, we should be able to present the user with a human readable content type. Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Darrel O'Pry wrote:
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.
On 8/24/06, Neil Drumm <drumm@delocalizedham.com> wrote:
We could auto-generate [the machine-readable] 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.
This is what the pre-CCK patch <http://drupal.org/node/62340> originally did. IIRC, Dries insisted that everything relating to "auto-generation of machine readable names" be removed from the patch. I am happy to see auto-generated machine-readable names make a return, but you'll have to convince Dries of its merits. Cheers, Jaza.
On 8/24/06, Neil Drumm <drumm@delocalizedham.com> wrote:
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.
Hard-coded node types is the main reason why we didn't introduce numeric node type IDs into the pre-CCK patch. A numeric node type ID is of little value, when you still have to match database node types with hard-coded node types, based on the original machine-readable name. However, I can see that numeric node type IDs (for which, btw, I would suggest 'ntid' as a DB field name) would indeed make life much easier, in terms of foreign key references to node types in the database (e.g. the 'type' field in the 'node', 'vocabulary_node_types', and other tables). We should definitely investigate bringing them in, despite the fact that we'll still have to keep 'orig_type', and use that for linking back to hard-coded module-defined types. On 8/24/06, Darrel O'Pry <dopry@thing.net> wrote:
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?
Darrel is right, using non-permanent fields as database keys is suicide. It's only a matter of time before that causes problems. So yeah, let's keep allowing users to change the machine-readable type name, let's keep using 'orig_type' so that DB node types can reference their hard-coded equivalents, and let's introduce non-changeable numeric IDs for node types, to be used as reliable primary keys. I have created an issue for this task: http://drupal.org/node/80375 Cheers, Jaza.
Jeremy Epstein wrote:
On 8/24/06, Neil Drumm <drumm@delocalizedham.com> wrote:
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.
Hard-coded node types is the main reason why we didn't introduce numeric node type IDs into the pre-CCK patch. A numeric node type ID is of little value, when you still have to match database node types with hard-coded node types, based on the original machine-readable name.
However, I can see that numeric node type IDs (for which, btw, I would suggest 'ntid' as a DB field name) would indeed make life much easier, in terms of foreign key references to node types in the database (e.g. the 'type' field in the 'node', 'vocabulary_node_types', and other tables). We should definitely investigate bringing them in, despite the fact that we'll still have to keep 'orig_type', and use that for linking back to hard-coded module-defined types.
On 8/24/06, Darrel O'Pry <dopry@thing.net> wrote:
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?
Darrel is right, using non-permanent fields as database keys is suicide. It's only a matter of time before that causes problems. So yeah, let's keep allowing users to change the machine-readable type name, let's keep using 'orig_type' so that DB node types can reference their hard-coded equivalents, and let's introduce non-changeable numeric IDs for node types, to be used as reliable primary keys.
Sounds great. +1 -- Neil Drumm http://delocalizedham.com/
On Thu, 2006-08-24 at 14:39 +1000, Jeremy Epstein wrote:
On 8/24/06, Neil Drumm <drumm@delocalizedham.com> wrote:
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.
Hard-coded node types is the main reason why we didn't introduce numeric node type IDs into the pre-CCK patch. A numeric node type ID is of little value, when you still have to match database node types with hard-coded node types, based on the original machine-readable name.
However, I can see that numeric node type IDs (for which, btw, I would suggest 'ntid' as a DB field name) would indeed make life much easier, in terms of foreign key references to node types in the database (e.g. the 'type' field in the 'node', 'vocabulary_node_types', and other tables). We should definitely investigate bringing them in, despite the fact that we'll still have to keep 'orig_type', and use that for linking back to hard-coded module-defined types.
On 8/24/06, Darrel O'Pry <dopry@thing.net> wrote:
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?
Darrel is right, using non-permanent fields as database keys is suicide. It's only a matter of time before that causes problems. So yeah, let's keep allowing users to change the machine-readable type name, let's keep using 'orig_type' so that DB node types can reference their hard-coded equivalents, and let's introduce non-changeable numeric IDs for node types, to be used as reliable primary keys.
so thats what orig type is for... I was wondering about that... I may need to update the cck patch @ http://drupal.org/node/80335 ...
On 23 Aug 2006, at 19:18, Neil Drumm wrote:
Database: databases like numeric keys. I think it would be good to replace the machine-readable type there with numbers.
I think we should use numeric IDs in combination with path aliases to provide clean URLs. It's consistent with the rest of Drupal, makes for a fast/lightweight/cruft-free solution, avoids all kind of problems and is future safe (makes referential integrity easier/faster). I think it a bad idea to auto-generate URLs at different layers of the Drupal application. The path aliasing system attempts to unify/ centralize that task. If we want to auto-suggest names, that should be in relationship with the URL aliasing system. -- Dries Buytaert :: http://www.buytaert.net/
participants (6)
-
Darrel O'Pry -
Dries Buytaert -
Jeremy Epstein -
Neil Drumm -
Peter Wolanin -
Rob Barreca