I have a CCK content type called Profile, which the Bio module uses for user profiles. A user registered recently, whose profile was all messed up with required fields missing. Interestingly, in views that pulled down profile lists, the data came through normally. The content_type_profile table contained all expected data.
I traced the problem to the cache_content table - the serialized data for this particular record was filled in up to about half-way, at which point the fields just contained empty values. All of the fields from that point on were missing data, required fields included. It's almost as if half-way through filling in that data property, it just gave up and threw nulls into the rest of the fields.
I assume this cache_content record was created at the time of the profile node creation. Haven't seen this problem ever before, but then again it's a new site and this is one of the first users. Not a great track record :( Fixing it is easy (truncate cache_content), but I can't have this happening regularly.
No PHP errors were recorded and no errors in the watchdog. The only potential clue is the fact that a Cron run was completed 4 seconds after the creation of the profile node. Could this have messed things up? Has anyone ever seen anything like this?
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | cck_fix_cache_content_2.patch | 766 bytes | Roman S |
| #1 | cck_fix_cache_content.patch | 399 bytes | Roman S |
Comments
Comment #1
Roman S commentedOK, figured this one out. Looks like my initial suspicions were correct - Cron was indeed to blame (along with the Search module).
What happens is on inserts the node record is created and then a row is created in content_type_profile. Each field in that new row, however, is filled in gradually, one SQL statement at a time. If Cron happens to run midway through that process and the Search module is enabled, it picks up the new node for processing, which ends up populating cache_content with incomplete data.
To test, set a breakpoint in the debugger in content_field() in the 'insert' case on the line that starts with db_query('UPDATE {... run it a few times (to populate those few fields with data) and then run cron.php in a separate window with Search module enabled. You'll notice half the fields missing for the new content.
I'm attaching a patch that basically clears any existing cache_content records for the new node. This mirrors what is currently being done for node updates. Unfortunately this still does not help with the fact that the Search module indexes the incomplete data. Not sure what the most "Drupal" way of fixing this is - I'm going to add a hook to my local project for node inserts and updates to UPDATE node SET changed = time(), or something like that. If this works for the CCK maintainers, it should probably also be added to content_insert and content_update.
Comment #2
Roman S commentedBTW, I created the patch off of 1.9, but it should be compatible with 1.10, since content.module did not change. The D6 version needs to get patched as well.
Comment #3
Roman S commentedMight as well include the full patch - fixes incomplete data in cache_content and in the search index. The content_insert and content_update functions are now identical, except for the $op, which probably should be refactored.
Comment #4
karens commentedThe D5 version is no longer being supported. Sorry.