body persists after body field removed from the content type

I confirmed that this defect does in fact occur.

My patch checks the has_body field in a content type before it sets $node->body.

Your patch adds a few garbage characters before the "<?", and to conform with code style your if-condition has to be either on a single line or encased in braces (the latter is preferred, I believe).

Forgot to add: Using a database query is redundant here. Use node_get_types().

Made the changes requested by Arancaytar. Ready for testing.

This works.

Just two remaining issues: Indentation has to consist of two spaces per level, no tabs. Also, core patches should be made relatively from the main directory - in this case you were diffing from inside modules/node/.

Hopefully third time is a charm. :)

Looks good now! This is a simple patch, so one review is probably enough. :)

Is a node teaser still present in this case (if the saved node has a node teaser)? Looks like the has_body field has no effect on previously saved nodes at all(?)

I've updated the patch to disable the teaser as well. However, if I pull up an aggregation of nodes, it now displays "N/A" rather than a teaser. Is this the desired behavior? (I would think so.)

n/a is generated by check_format, as far as I recall.

Just make sure the behavior of a newly created body-less node and that of a node whose body is removed by your patch are identical.

(I'm too tired to test any more tonight and about to get some sleep, sorry.)

Anyone out there who can test this patch?

Your patch generates notices, and sending NULL to check_markup will generate an n/a string that is not normal behavior - ie. that does not happen when creating a new page after disabling the body field, pre-patch. Here is a patch that sets the properties to empty strings, which is what the newly created node has. That avoids isset-notices as well as n/a in the page.

Yeah, that is probably the better approach. I didn't notice the warnings. Good catch.

Works as expected! +1

I'd include a note in the comment on why is a body in fact there, while the node should not have one (ie. data left from previous entry). It might also make sense to drop the body/teaser field data if the body field is removed from a content type, but that's certainly not for D6.

Deleting the data would be needlessly destructive, in my opinion. But let's leave that for when the patch enters the D7 branch.

Comment changed. The code has been reviewed by several people now, so I'm setting to RTBC.

(Incidentally, would it have made sense to put all of this into node_load instead?)

I'd say it would be much better to have this in node_load(), since the node type has no body field, so the node load should not return a body field to start with.

is it possible to add new body fiesld?

Good Day,

This is the 1st thread I came across with this issue. A 2 questions.

1. I noticed that this thread is a few months old. Has this issue been fixed in the latest release?
2. If not, is the patch the only option?

Thank you,

Mark

This patch makes the old body field no longer display but does not remove the body field from the edit form.

After removing the body from a feed-generated content type I applied the above patch to Drupal 6.18. I have several views with exposed filter "Search: Search Terms" which I would now like to be applied only to Titles. Problem: the user entered keywords are still searched and found in the body of several thousands pre-existing nodes.