Upgrade to D6 blocks access to Content types
asb - June 24, 2009 - 22:35
| Project: | CCK Taxonomy Fields |
| Version: | 5.x-1.2 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
Hi,
when upgrading to D6, one of my sites had an cck_taxonomy field; this field seems to block access to the content type in question. I'm getting the error message:
This content type has inactive fields. Inactive fields are not included in lists of available fields until their modules are enabled.
Kategorie (field_cck_kategorie) is an inactive cck_taxonomy field that uses a cck_taxonomy_1 widget.Well, since this module is abandoned and no D6 version will be available: How do I get access to my content type back?
Thanks & greetings, -asb
#1
have you tried removing the offending fields from the content type?
#2
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
#3
Research before hand ensuring that all modules you relied on were updated to Drupal 6.x would have been a benefit.
I'd REMOVE the field in the D5 installation before upgrading to D6.
#4
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
#5
LOL - nope I"ve never used drupal :eyeroll:
I've given you multiple options, pick the option that suites you best
two other options: port the module on your own to work with D6 and the latest CCK.module. Hire someoone to port it for you.
I, nor anyone can help when/if/how contrib developers handle maintenance of their modules, or when they decide the modules isn't work their time investment.I only use well supported modules and am very very very, picky about what goes into any drupal installation I am part of. That's part of the risk of becoming dependant on modules that aren't popular or used by a large portion of the community with the skillset up port them when the next version of drupal is released.
to stay on topic and ignore the rest of your rant:
Your original question
my answer:
use your D5 backup
disable AND uninstall the offending module
THEN upgrade, hopefully on a test site as if you are using other modules that have since become unsuported or abandoned you can tend to those as well.
Either way this isn't a bug report it's a support request or a feature request. The module is marked as abandoned therefore there is no maintainer for this module.
Care to step up to the plate and maintain it? If so file a webmasters issue.
#6
marking as fixed as there is no mainatiner for this module.
#7
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"...?
#8
you can keep it active if you like, suit yourself, I hope someone comes along that can try and work around the issues you have with my logic.
you've been given your options.
1) Port it on your own
2) Hire someone to port it
3) wait for someone else to port it (Unlikely since it hasn't been done yet, and the project page states a better alternative)
4) delete the module and use the alternate method stated on the project page. (I don't understand how this will delete content, were talking about whatever field this module creates and deleting that field from the content type so that the upgrade not longer looks for it)
5) continue to keep a D5 site (D5 hasn't been sunset yet)
Seriously, what other options do you think there are? Continuing to bitch at me gets you know where though it does extend my life as I get to laugh at your angst. ; )
hmm, as I type this, continuing to to ponder this issue and reread the project page it also dawns on me that you can head over to the alternative module issue queue and check to see if someone else has needed to move to the alternative module before you, and can help guide you through the process. There may even be an upgrade path ... certainly worth asking. 600 sites were using this module at some point if I am reading usage statistics correctly. I suppose If I have to list these options again, I'll add this as #6, and probably rank it higher on the list of options. Sorry this option is coming a little late, as I said it just dawned on me.
Good luck.
#9
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
#10
I think I know an alternative?
I am upgrading a site from 5 to 6 and basically ran into the same issue. In my case there were two CCK related modules that were not ported. I'm a designer so I couldn't port them myself. And in my case there was an alternative module that was enthusiastically maintained so it just made more sense to switch than pay for a short term patch.
Anyway, I didn't uninstall the fields prior to my running the upgrade. Nor did I realize the GUI would prohibit me from doing so afterward. So after hours of work I was unwilling to start over figuring there must be another, more hand on way to do this.
1.) Enter PHP My Admin
2.) Find the table for my CCK type using the abandoned fields
3.) Select all relating rows.
4.) Drop them
This however didn't stop me from getting the error noted above. So I kept looking and fixed that error with the following:
1.) Enter PHP My Admin
2.) Find the table called "content_node_field"
3.) Select rows relating to your field. There seemed to be one row for every field used on the site.
4.) Drop them
*shrug*
Maybe this was a bad idea. I'll let you know if it breaks something else.
Now to find a quick way to port all that data over. *gulp*
#11
Ya know... to be safe I ended up exporting my data to a CVS file. Created a new content type and node importing in all the data back in.