me again.

We had some issues because of caching mechanisms on node. uid was correctly written to database, but as soon as node was saved via interface it became anonymous again. This seems to be because of caching mechanisms.

Hard workaround would be my patch attached, which works, but I am not sure, whether flushing all caches really is the best variant. I'd like to only clear page cache (like in _admin_menu_flush_cache() case 'cache'). Perhaps we should just duplicate this piece of code (I know, c&p is root of all evil...).

I'd love to hear some feedback on this issue.

Comments

smussbach’s picture

With my patch above all caches are flushed any time a user logs in, which is clearly not desirable. Fixed it with this patch

organicwire’s picture

I cannot reproduce this issue. Can you provide more information about

  • your cache settings
  • general configuration that might be relevant (forms in panels?)
  • steps to reproduce the issue

Generally, if avoidable, clearing caches seems a bad idea to me. On big sites we'd have serious performance issues. Another approach would be to tell the caching system that the specific node or a specific form did change.

smussbach’s picture

I absolutely agree that flushing caches is generally a bad idea. It would be much better to flush only nodewise. I did not find any possibility to do this. Today I found following which might be usable (needs entity API).

// Clear the static loading cache.
    entity_get_controller('node')->resetCache(array($node->nid));

I can reproduce it on every node insert, I try to figure my settings out.
* Cache: entity cache module enabled, otherwise no cache configured
* I use a general add form similar to /node/add/[type], nothing via panels
* Reproduce: Add node anonymously, login, node is transferred (uid correctly set in db). As admin go to Menu -> Content. Username is correctly displayed. Edit node. Authoring information is Anonymous. Tab devel $object->uid = 0. On save, node uid is set back to 0 in db

I am very interested, whether you can reproduce it. If not, my bugfix (or better "hotfix"?) with clearing the cache is only because of some side effects.

organicwire’s picture

Alright, I can reproduce the bug.

  • entitycache installed
  • Anonymous user (Browser 1): create node
  • admin user (Browser 2): list content, open new node, edit node. Author is both times Anonymous
  • Anonymous user: login, authorship is transferred
  • Admin user: view node and edit node: both times author is "Anonymous"

I don't have this behaviour if I disable entitycache. I assume that the problem is how we assign the new authorship. Instead of using the node module, we directly write into the database. So neither cache or entity modules know about the node change.

function _delayed_ownership_assign_nodes($user_hash) {
  ...
      $num_updated = db_update('node')
      ->fields(array('uid' => $user->uid))
      ->condition('nid', $node->nid)
      ->execute();
  ...
}

Fix: Use node_save() instead of db_update. What do you think?

smussbach’s picture

yes, this really sounds reasonable! Way better to use node_save().

organicwire’s picture

Title: Flush caches on node ownership assignment » Entitycache not updated after node ownership change
Status: Needs review » Fixed

Hi Sami, eventually this bug is fixed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

typo