Item10762: _authorWikiName in TOPICINFO causes problems

Eg. https://wiki.trin.org.au/Main/SpongesGroup

We've got MongoDB disabled atm

-- PaulHarvey - 18 May 2011

so the meta isn't validating on render, and it gets chucked into the topic text content

-- PaulHarvey - 18 May 2011

I ran a sed script over our wiki, and the problem has been cleaned up. Reducing to low (I guess we can probably close it... but I wonder if it will happen again)

-- PaulHarvey - 23 May 2011

They're still cropping up. Garry attached a file to https://wiki.trin.org.au/Acacia.NewickExplorer?raw=debug and there's two TOPICINFO entries now..

MongoDBPlugin was running at the time.

-- PaulHarvey - 27 May 2011

This also occurs whenever we rename a topic. I wonder if it has to do with SemanticLinksPlugin.

-- PaulHarvey - 01 Jun 2011

This is probably just noise, but I was debugging in SemanticLinksPlugin's beforeSaveHandler - and observed that immediately before $topicObject->save(), there was no _authorWikiName key in the TOPICINFO. Confirmed by dumping $topicObj->getEmbeddedStoreForm(), $topicObj->find('TOPICINFO') and $topicObj->{TOPICINFO}.

After the save, that $topicObj still didn't have a _authorWikiName.

You only see the _authorWikiName key when you load that topic with a new meta obj. So it's happening during save.

Finally, this is probably just noise, but I have an unconfirmed hunch that this problem is exhibited only when there's more than one save operation during the request. For example, asking SemanticLinksPlugin to reparse an individual topic works fine, but more than one update and we start seeing the _authorWikiName junk. Same for GlobalReplacePlugin, and renames, and other bulk-update type operations (PermLinkPlugin/deploy, etc.)

Hope these aren't red herrings

-- PaulHarvey - 27 Jun 2011

this should now never happen - in that the serialisation of a Meta object should ignore all elements who's name starts with _

-- SvenDowideit - 28 Jun 2011

I guess we're waiting on me test? Hopefully staging VMs will be running latest code soon, and I can close.

-- PaulHarvey - 16 Jul 2011

Sadly it's still happening, although not as often.

One guaranteed way to reproduce is with JEditablePlugin.

I'll writeatest

-- PaulHarvey - 08 Sep 2011

mmm, paul - any news on that test?

-- SvenDowideit - 01 Mar 2012

It turns out the rename tests show the failure already

-- PaulHarvey - 01 Mar 2012

This is fixed now. Yay

-- PaulHarvey - 16 Mar 2012

Commenting is disabled while not logged in