Hi,

after renaming a content type (via /admin/content/types/{content-type}, one nodereference field is gone; two others, embedded into a fieldgroup, are still there.

The missing field can't be added via /admin/content/types/{content-type}/add_field because it's not listed there; at /admin/content/types/fields, the field is listed with it's correct association to the content type I renamed. Also, the data I entered into this nodereference field still appears in views. As it seems, the field simply isn't displayed anymore in the editing forms (e.g. /node/add/{content-type}; thus, no new data can be entered.

How do I get this CCK nodereference field back without damaging anything?

Thanks & greetings, -asb

Comments

asb’s picture

asb commented

Those old issues might be related:

* http://drupal.org/node/103583
* http://drupal.org/node/247295

However, I'm not using prefixes in my database tables (other system info: Drupal 5.7, Apache 2.2.3, PHP 5.2.0-8+etch11, MySQL 5.0.32).
Please drop me a note if I can give you any more information.

Thanks & greetings, -asb

Leeteq’s picture

Leeteq commented

Subscribing.

asb’s picture

asb commented
Priority: Normal » Critical

Changing the priority to critical since (a) this appears not to be a user error, (b) it happens by using standard functions provided by Drupal, and CCK, and does not involve some kind of "hacking", and (c) a project of mine is going to crash because of this issues (necessary data for the site can not be entered anymore).

giorgio79’s picture

giorgio79 commented

This may be a duplicate:

http://drupal.org/node/346053

asb’s picture

asb commented

Hi giorgio79,

both issues are related, but not duplicates. In both cases the problem is, that the UI allows the user/administrator to do things to Drupal that are harmful (or even worse). Also, common to both issues is a developer's point of view that ignores the needs of non-developers - ranging from administrators to end-users of a preconfigured Drupal installation.

The functionality to rename content types is relevant and necessary; we have done this for years e.g. to localize URLs like "article" or "image". If "new" tools (like CCK and Views) arise, the mechanisms have to adapt, not the users. Not only because software can be changed easier than people, but mostly since software is made to solve problems for humans, not to give developers the heavenly pleasure of having tricked the "stupid" humans. Meaning: If other modules need to be informed about a changed name of a content type, there are to solutions:

* Make the software as stupid as possible and simply prevent/forbid those operations;
* make the software as smart as possible and notify other modules of changes.

That's what APIs and registries are made for. Everything else is bad software design.

Greetings, -asb

karens’s picture

karens commented
Status: Active » Closed (won't fix)

The D5 version is no longer being supported. Sorry.