Function _content_type_info() returns a $info array containing obsolete data after making changes to node types. To verify print out $info, then rename a content type and print out $info again. They will be identical. The reason for this is that _content_type_info() returns the $info array from cache even if $reset parameter is set.

To solve the problem, change 

if ($cached = cache_get('content_type_info', content_cache_tablename())) {
  $info = $cached->data;
}

to

if (!$reset && $cached = cache_get('content_type_info', content_cache_tablename())) {
  $info = $cached->data;
}

P.S. I dont have cvs access, so I cant create a proper patch atm. Sorry.

Comments

profix898’s picture

profix898 commented

Update: The above description is incomplete. The suggested change fixes the issue with _content_type_info(), but for some reason (didnt have time for detailed debugging) changes to a content type are still not available from content_types() immediately. I guess the cache is not cleared correctly or the order of execution on hook_node_type is wrong.

yched’s picture

yched commented
Status: Active » Fixed

Right. Modified node types still do not make it because we call node_get_types(), that feeds us its own statically cached data.
I changed _content_type_info() to now always ask for a fresh node_get_types().

Committed (post RC5, I'd rather have this live in -dev for a while).

yched’s picture

yched commented

Fixed in 6.x-2.x-dev (not in RC5)
Took me http://drupal.org/node/294726 to understand why my fix wouldn't work.

This only takes care of 'referenceable nodes defined by content type'. If referenceable nodes are defined by a View which includes a filter on node type, you're on your own (or that would be a feature request for Views).

yched’s picture

yched commented

er, wrong thread, sorry.

karens’s picture

karens commented
Status: Fixed » Active

I've run into another problem with static values that is related to this -- _content_widget_types() and _content_field_types() both get their values from _content_info() and both hold static values that don't get refreshed. When we run content_clear_type_cache() it refreshes _content_info(), but doesn't refresh _content_widget_types() or _content_field_types(), so they still retain invalid static values.

Among other things, It can create problems in a multi-user environment when one user has incorrect static values after another user has changed the underlying info.

I considered adding a $refresh parameter to both _content_widget_types() and _content_field_types() and force them to clear during content_clear_type_cache(), but that won't refresh the static value a different user may be seeing.

I'm wondering why we have the static values in those two functions, isn't the static in the underlying _content_info() function enough?

karens’s picture

karens commented

Oops, I misspoke, the statics are not in _content_widget_types() and _content_field_types(), but in content_field_type_options() and content_widget_type_options(), so they come into play when editing fields.

yched’s picture

yched commented

Right, those statics were added in by dopry a couple weeks ago in http://drupal.org/cvs?commit=130585.

AFAICT, they're mainly here to save repeating the array manipulations that content_field_type_options() and content_widget_type_options() do on top of _content_type_info() data.

Among other things, It can create problems in a multi-user environment when one user has incorrect static values after another user has changed the underlying info.
I'm not sure I see the exact problematic case here. If a user changes the underlying info while another user's request is executing, chances are this request is screwed anyway, even without those two statics.
I mean, _content_type_info() will be wrong just the same, since it is also statically cached, so content_widget_type_options() will rebuld on stale info too.

I don't think removing those statics in content_*_type_options() is a real performance hit, though, so I'm fine with removing them if they cause issues.

yched’s picture

yched commented

Karen, is this something we should fix before a release ?

Andrew Schulman’s picture

Andrew Schulman commented

Where I see this problem-- I think it is the same problem-- is that after I change the description of a content type, the old description is still shown at node/add. Thanks, Andrew.

yched’s picture

yched commented

andrex593 - not related IMO. Content type descriptions are handled and stored by core, not by CCK.