Fatal error: Class 'views_handler_field_node' not found in ... content.views.inc

Also experiencing this issue. Upgraded to newest views [views-6.x-2.0-rc1] and newest Content Construction Kit [cck-6.x-2.0-rc2] and problem started appearing. Went to drupal-6.x-dev to try to fix, but no luck.

Judging from the initial post, this seems to be occurring with 1and1.

Also on my site... completely breaks the entire site....

You can't even get to the update.php after installing this.

Fatal error: Class 'views_handler_field_node' not found in /home/virtual/site29/fst/var/www/html/modules/custom/cck/includes/content.views.inc on line 255

Where's the patch? Does it take some time for it to show up like a commit??

*this is a copy from my previous post*
I have gotten the same error this happens when you enable both views and cck module at the same time. Although when they are activated independently they work fine. A work around was to just move the two files in cck/includes/content.views.inc and content.views_convert.inc to another directory. This allows them to both work together and will temporarily fix the issue. Took me 4 hours to figure that out! Fun Times.

so what would be a fix for this? I really need views and cck working.

edit : i took the above advice and took the 2 files named and moved them to the book folder, seems just fine now *sigh* /wishs for a fix soon

also awsome module

I can't replicate either on my test D6 setup, or on a fresh D6 with CCK-RC2 and Views-RC1 tarballs.
The only case I can replicate this is with CCK's short-lived RC1, that indeed had a such a bug.

I hate to ask, but are you *positive* that the code that runs on your server is the one from http://ftp.drupal.org/files/projects/cck-6.x-2.0-rc2.tar.gz ?

I had this problem and now all I can get out of drupal is "Page not found". Any ideas why this might be occurring? I have tried deleting the views and cck folders and using phpMyAdmin to disable all cck and views modules, but still no change.

Once you get the 'Page not found' error, the only fix is to go back to your backup and start over. That's the core bug I noted above. Then you have to be sure you're using the version of core from #6.

Edit the title, it's too long to see

So not good that I didn't take a backup then. Any way round this?

Add to your /index.php after
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

this code:
menu_rebuild(); // use just once
die(); // use just once

Read once your hompage and remove this lines. This should help you.

Moving those two files (content.views_convert.inc & content.views.inc) seemed to bring my site back online also. Went ahead and moved up to 6.3-dev. Have not tried to put the files back after the upgrade.

Is moving the two files the 'correct patch'? As 'meadtj' said, it was a temporarily fix and no better fixing solution showed up.
I noticed that if I move cck-6.x-2.0-beta back to my module folder instead of cck-6.x-2.0-rc2 drupal would work again. I don't know how it would work. If it would either work fine.

So I'll try moving both files to another directory and see what happens

Hope to have news soon.

Someone posted the same bug under Views, and I found a simple solution for it

http://drupal.org/node/278154

If the change at
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/cck/include...
is undone, it starts working again.

My guess here is that content.views.inc is being loaded before node.views.inc where that class is defined.

The real solution, I think,, would be to set content module's weight to 1 in the system table.

The weird thing is that I'm totally unable to reproduce this. I've tried clean installs on a couple different machines with all different variations of CCK and Views (by themselves and with Date and Calendar too, since they've been mentioned in some places) using the tarballs of both official releases and development snapshots and never ever get this error.

Anyway, if someone getting this error can confirm that changing the system weight works, we can easily make that change.

Change mentioned in post 14 also worked for me.

/me has a sudden flash : betting my shirt that people seeing this put the cck folder in /modules instead of /sites/xxx/modules/
So module_list() returns 'content' before 'node'.

If that's it, I don't think I'm in favor of changing the weight, which can have other consequences. People just aren't supposed to do that.

#18 yched, you're a genius!! I just tested what happens if I move CCK to the main modules folder and now I get this error too, so that's the issue.

I was able to fix it by simply editing the weight of the CCK module in the system table. I changed it to 2 as Views was set to 1, so I just moved it to be after that. Then visiting update.php worked fine, no DB updates from cck or views evidently, and now the site is back up...

I was attempting to update CCK, Views, Link, and Pathauto all at the same time. (weekly module updating) when this problem arose.

So changing the weight DID fix the issue without moving any files from the module.

We could add a hook_requirements to test where the module is located and set a warning if it's in the wrong place. But that warning only shows up on the admin status page, so it's easy to miss.

I know it is not recommended to put contrib modules in the main /modules/ folder, but I think it is *allowed*. But we could say CCK must not be there.

And look at the error messages above -- they all show content.views.inc being in the main modules folder.

Ok, I reported the previous bug (without a patch) so I guess I'm partially responsible for this :P

How about simply doing a

    module_load_include('inc', 'views', 'modules/node.views');

[edit: (at the top of content.views.inc)] ...so that the file containing that views_handler_field_node class is included? The others all seem to be included automatically so they shouldn't be a problem, it's just that one file if I'm correct.

I can confirm that moving the cck folder inside the main modules folder creates the problem and #23 fixes it. Are there any downsides to that fix? Will it break anything in installs or profiles? Which is the better fix? I think #23 is better than changing the weight since changing the weight could have other implications.

Was not aware that you couldn't put contrib modules in the main modules folder. Does it hurt to move those modules by simply moving the specific module to the sites/xxx/modules folder without doing any kind of config/add/remove?

I think changing the weight and moving the module are equivalent; what happens is that sites/all/modules ends up coming after modules, alphabetically, so you get an effective weight of 1. Well, kind of; you're still pretty early in sites/all/modules where with a 1 you'd come after most contrib. So I guess not *equivalent*. But similar.

(Excerpt of post at http://drupal.org/node/277889):
(note: correct folder does not seem to prevent the problem from occuring)

- Installed Drupal -dev (drupal-6.x-dev.tar) to localhost/drupaldev - (could localhost have anything to do with this?)
- Added CCK package (cck-6.x-2.0-rc2.tar) to C:\apache2triad\htdocs\drupaldev\sites\all\Modules
- Enabled only Content module from Drupal module admin
- Get WSOD

merphq: In *this* issue: The problem you're seeing is not the problem being discussed in this issue. =)

#25 It has been 'recommended' since Drupal 5 that you put contrib modules in sites/all/modules and leave the main modules folder to be only core modules.

You can move the files by picking them up and moving them, and then going immediately to admin/build/modules and save that page. Drupal will find the new file locations when you visit that page and save them when you save the page.

One reason I hesitate to alter the weight is that there are hundreds of modules that depend on CCK and any one of them might have altered their own weight to be sure they run after CCK so they can do something that can only work after CCK is loaded. If we alter CCK's weight, those modules will break (and any modules that depend on them will break). It could be a whole house of cards. Or it could be nothing at all to worry about.

merlinofchaos: True I guess. I was just trying to offer what I thought might be useful info in terms of folder locations. I'll shut up now. :-)

Modules themselves all load as a group, so that really isn't normally an issue. It's an issue here mostly due to the OO aspect.

Normally, the weight only controls hook execution order, and most of the hooks CCK uses are probably not so much order dependent. I don't *think* it'd be a problem, but I do understand hesitating.

Another reason not to fix this with a weight change is that as soon for anyone upgrading from a previous version (with the current weight) the only way we can alter the weight is in an update, and this error will prevent them from being able to even get to the update page. I just tested that to be sure and confirmed you cannot get anything but a WSOD at update.php while this is broken.

Thanks for the :

Add to your /index.php after
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

this code:
menu_rebuild(); // use just once
die(); // use just once

Read once your hompage and remove this lines. This should help you.
+++
This has worked to let me get into my home page normally.

#23 works great

The same question will arise for any module that define custom Views handlers. Those handlers necessarily extend some previously defined class, and I think in most cases this parent class will be one that Views defines.
I'm not sure the answer we want is that such modules need to have a weight > 1. And, like Karen, I'm quite reluctant to alter content.module's weight.

I see two other ways :
1) change views_module_include() so that it loads the base [core_module].views.inc files *before* any other.
Should cover 90% cases, but not the case where, say, filefield needs to extend content.module handlers (it seems it won't, but at some point jpetso considered this)
2) [my_contrib_module].views.inc files need to explicitly include the files defining the classes it extends, like jpetso suggested in #23

For now I committed jpetso's suggestion as a hotfix. Will release a RC3

Someone should also add some documentation to Views about this so other module developers avoid this problem :)

Not sure where would be the best place to do that though.

I don't think Earl will be too pleased if lot of other modules start loading up his include files. I think he would rather load it himself at some earlier point in the request.

Moshe, if I understand this right all we're doing is making sure they get loaded in the right order. CCK is not including this file anywhere, it's only included by Views when it's needed. So our additional include will only get triggered when Views is already trying to include this file and it will just make sure that the node class gets loaded before instead of after this one.

I was not aware that modules should not be put in the "main" modules folder, can anyone tell me where i can find something about that in the documentation. I would like to read up on it.

#40 The preferred module location is documented in several places, http://drupal.org/getting-started/5/install-contrib/modules and http://drupal.org/node/22283 are a couple.

KarenS is right; the only real solution is that if you're going to extend some other module's classes then you probably need to ensure that module's .views.inc is included before yours. The use of require_once is safe because if you're already in *.views.inc you know that *.views.inc files are going to be included anyway, *and* require_once is smart and fast so it won't get included again. (do not use include_once if you can avoid it. Please use require_once).

A comment of this nature should probably go in Views documentation in api-handlers.html and/or api-plugins.html (which is incomplete anyhow).

module_load_include() should be fine, then (uses require_once)

Fixed, then.

Note to people finding this issue because they get this error :
- use CCK RC3
- *please* do not put contrib modules or themes in the main /modules and /themes folders, this is extremely bad practice. use sites/all/modules and sites/all/themes, or sites/example.com/modules and sites/example.com/themes, as explained in http://drupal.org/getting-started/5/install-contrib/modules