Upgrade to D6 blocks access to Content types

Hi.

Firstly: How would I do so? As mentioned, the error message says:

This content type has inactive fields. Inactive fields are not included in lists of available fields until their modules are enabled.

That is supposed to say, if I interpret the message correctly, that the field in question is not included in lists of available fields until their modules are enabled. There is nothing I could "remove" or even change/reconfigure regarding the field in question, at least not in the administrative interface at ../admin/content/node-type/{content-type}/fields, and that's what I meant with the title of this issue ("Upgrade to D6 blocks access to Content types"). And most definitely I won't touch the CCK database tables directly, at least not without very precise instructions.

Secondly: To my understanding "removing" a CCK field from a content type deletes the data in this field. It must not be necessary to delete data for being able to upgrade (why would I waste my time writing content in the first place if I won't be able to maintain it through a f* upgrade?)

Thanks & greetings, -asb

GREAT advice. Have you ever seriously used Drupal? On what planet are you living?

> Research before hand ensuring that all modules you relied on were updated to Drupal 6.x would have been a benefit.

GREAT! If everything in Drupal would work this way, I'd still run the (for ages) unsupported 4.1. Most probably I would have been hacked a dozend times (because of unfixed security leaks), and most probably we wouldn't have this conversation (because I for sure would'nt run and recommend Drupal anymore).

Are you aware that lots of maintainers refuse to maintain even their D5 versions anymore, that lots of D5 modules haven been revoked/unpublished/whatever? On one hand I would have to uninstall those modules (unmaintained, security leaks, etc.) and loose content. On the other hand I would never be able to upgrade to D6, since I'd have to wait forever for modules to be ported that will never be ported (yes, I'm waiting since 2007 for a bunch of mission-critical modules to get an active maintainer for D5 and since 2008 for those modules to be ported to D6). That is quite some time when support for D5 breaks away with increasing speed.

> I'd REMOVE the field in the D5 installation before upgrading to D6.

GREAT! If everything in Drupal would work this way, I'd most probably still run the default page and nothing else. I made this error when basing several sites on modules that were not ported to D5 (and lost some content); I made this error again with D5 when I based several sites - as well private as well as commercial ones - on modules that will not be ported to D5 and/or are de facto abandoned; if I would delete all this content, I'd loose approximately 1250.000 nodes and maybe 95% of my user base. I tried to correct this error by using the CONTENT CONSTRUCTION Kit. If this sh*t repeates a 3rd time, we'd have to re-label it to CONTENT DESTRUCTION Kit. Since this abandoned modules tragedy even applies to the default input format on eight of my Drupal sites, I'd simply loose 100% of all content if I'd took your suggestion seriously.

Honestly, are you really suggesting to NEVER upgrade Drupal if modules are abandoned, not maintained or other modules don't offer migration paths? That's Drupal standard, not the exception!

But back to the topic; it simply must not be possible to loose the ability to fix errors by upgrading. If CCK should really be designed this way, it'd be seriously broken.

Greetings, -asb

Again brilliant logic: If there's no maintainer, a module can't have no bugs, and as it can't have no bugs the issue must be set to fixed. Wow!

When I upgraded, this module wasn't yet marked as "abandoned". Search the issue queue and go back a few months. Yes, I'm trying to be patient.

The original question remains: Since this module is abandoned and no D6 version will be available: How do I get access to my content type back? And I'm making an addition: ..."without deleting the content"...?

My approach to "resolve" this issue (with crucial help from attheshow):

mysql> UPDATE `content_node_field_instance` SET `widget_type` = 'optionwidgets_select',
`widget_module` = 'optionwidgets' WHERE `field_name` = 'field_[YOUR-FIELD-HERE]';
TRUNCATE `cache`;

After this, the field is still marked as "inactive" by CCK. So I once again disabled CCK and all related modules, ran update.php, enabled content.module, ran update.php again, enabled option widgets, ran update.php again and so forth.

To get the field active, I did an

mysql> update content_node_field set active = '1' where active = '0';

Checking the result of the operation:

mysql> select active from content_node_field where active = '0';
Empty set (0.00 sec)

This got me an

warning: preg_match() expects parameter 2 to be string, array given in /var/www/aem/includes/bootstrap.inc on line 771.

Additionally:

mysql> select widget_active from content_node_field_instance where field_name in ('field_cck_kategorie');
+---------------+
| widget_active |
+---------------+
|             1 |
+---------------+
1 row in set (0.01 sec)

Thus:

mysql> update content_node_field_instance set widget_active = '1' where widget_active = '0';
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 0

After enabling the rest of the CCK related modules, I got access to my CCK field back, meaning that I could at least delete that f***g CCK field. However, after deleting the field, I'm still getting this warning: preg_match() expects parameter 2 to be string, array given in /var/www/aem/includes/bootstrap.inc on line 771. - but that's just another problem.

Don't try this at home (and definitely not at work!), this most probably is even more destructive than CCK itself.

Greetings, -asb