existing machine names are changed when human readable name is changed (e.g. node type, vocabulary)

Yes, this does sound actually critical. Curses.

There might be two issues here: [EDIT: as per comment #4, only item 1 below is the real issue.]

1) Where the machine name is editable, clicking [Edit] should and does let you edit it. But, simply changing the human friendly name shouldn't implicitly change the machine name. People might have CSS rules targeting machine name derived CSS classes, and simply changing the label of an object shouldn't cause all that CSS to break. Steps to reproduce: edit the "Tags" vocabulary. Rename to "Tag". Machine name changes to "tag". Expected behavior: an already existing machine name should not automatically change when the human friendly name is edited.

2) In some cases, the machine name is the primary key. For example, "type" is the primary key of the {node_types} table. @pwolanin: are you suggesting that because of this, the "article" machine name shouldn't be editable at all? Note, there are places where we don't allow editing machine names. For example, module-defined node types like "forum", and for text formats. So, we can choose to make node type machine names not editable at all, if the fact that they're a primary key requires that.

Tagging.

I tested this patch, and it does solve the issue.

        // We only bind this behavior if we do not yet have a machine name.
        // In other words, when adding a new object, not when editing.
        if ($target.val() == '') {
          // Preview machine name in realtime when the human-readable name changes.
          $source.bind('keyup.machineName change.machineName', function () {

Should the comment about what this code is for ("Preview machine readable name...") go before the other comments, as such?

        // Preview machine name in realtime when the human-readable name changes.
        // We only bind this behavior if we do not yet have a machine name.
        // In other words, when adding a new object, not when editing.
        if ($target.val() == '') {
          $source.bind('keyup.machineName change.machineName', function () {

I encountered another unrelated bug, which this patch did not affect. I'll search the queue in a minute here.

subscribing

It's not the front-end code that's broken. The JS supports changing machine names, but whether that is allowed is controlled by the server-side code/markup.

We don't want to lock the machine name from explicit changes as #10 does, just automatic ones. I'm pretty sure it's a front-facing JS change we want here instead of a backend php one.

See http://drupal.org/node/952048 (which is the unrelated bug that bit me while testing this patch) - as far as I know, machine names are supposed to be changeable.

Right. It's fine to change these machine names, and removing the ability to do so would be a regression.

But we want to make sure that if a pre-existing machine name is already there when the form first loads, it doesn't get modified by the JS when changing the human readable name.

Which is exactly what #6 does. +1 for that solution.

@pwolanin: the reason I suggested the comment move was because
// We only bind this behavior if we do not yet have a machine name.
references a "this" which hasn't been explained yet, and won't become apparent for several more lines. I'd rather explain the behavior we're aiming for, then say why it's inside an if statement.

How about:

// If we do not yet have a machine name, bind the behavior to auto-generate one.
// Prevent an accidental change if the human-readable name is edited.

Alright, understood the problem now. Attached patch is what we need to do. Current logic in the code is a bit wishy-washy with regard to the condition it appends an Edit link, and the fundamentally different condition it enables the live preview + automatic changing of the machine name form value.

Getting much closer. Testing #18, still found one bug:

1) Create content "fruit".
2) Set machine name to "fruit_machine" and save.
3) Return to edit the content type.
3a) The edit page says "Machine name: fruit" <- This is a bug that's been present in every patch so far
4) Type a new name for the content type
4a) Without the patch, the machine name (correctly) does not auto-update.
5) Press save.
5a) Correct machine name, "fruit_machine" is preserved.

In short, the JS does not update the machine name unless explicitly told to do so, which is the desired behavior. However, it incorrectly displays the machine name on the edit page.

The current patch solves the critical aspect of this bug, but leaves another, closely related bug of lesser severity intact. I think fixing this is an easy change - just tell JS to read the machine name out of #edit-type, and only use #edit-name as a fallback.

Waiting for pwolanin's feedback on #18.

Attached patch also fixes the last remaining bug mentioned in #19.

Stray tab, sorry.

Can't reproduce that anymore with the latest patch.

Everything looks good to me, including the docs and a manual test. With pwolanin's +1, I think we're good to go.

Committed to CVS HEAD. Thanks.

I have a content type which has several views and rules applied to it. I also have several nodes of this type already created. Can I go into phpmyadmin and change the machine name everywhere it exists in the database? And avoid breakage?

Thanks