• Bug 48469 has been marked as a duplicate of this bug. ***

I thought I would check another site and form and I can confirm this is happening there too. This seems to be a generic issue, but the number of links grows with the number of form elements.

http://wikiapiary.com/w/index.php?title=WikiApiary&action=formedit

has 162 instances of that link tag.

Could you try [1] and see if it solves the issue.

[1] https://gerrit.wikimedia.org/r/#/c/63273/

I do wonder if this only happens where SF is involved, because on pages such as smw.org or translatewiki I can't find those pages.

I could not get this behavior to display in any case other than editing with a form. If I edit the wikitext without the form, this doesn't happen. I'll try to the patch.

I did

git pull https://gerrit.wikimedia.org/r/mediawiki/extensions/SemanticMediaWiki refs/changes/73/63273/1

and indeed the thousands of link tags are no longer present. Thanks MWJames!

Well, above change was not in respond to this reported behaviour rather placing the link generation at the right place.

I don't hope SF is using some static function that stores state related information about objects (objects should read from the actual ParserOutput). The only function that calls ParserTextProcessor is the InternalParseBeforeLinks hook.

I'd like to have an input from SF an that behaviour because it only seems to occur when SF is involved.

The original bug I opened was bug 48469 on Semantic Forms but Yaron didn't think it was an issue with that. I also suspected it might have been Semantic Forms Inputs, but tests proved that wrong. And when I saw this is on WikiApiary too it was clear this is something with SMW and/or SF. I don't know the internals well enough, but looking at SF_FormPrinter.php is probably where any potential issue would be.

Jamie, it would help if you could try isolate which function is calling "ParserTextProcessor" or "InternalParseBeforeLinks" one after another.

In general, InternalParseBeforeLinks is called before an article is displayed or previewed and because ParserTextProcessorTest and HooksTest (includes the InternalParseBeforeLinks test) only show expected behaviour, it means some function is "ridding" the InternalParseBeforeLinks bus more often during a session.

[1] has been merged May 15 and while I still think it is an issue in connection with SF or SFI, the original issue of "too many RDF links" is no longer prevalent and therefore this bug is rendered fixed.

[1] https://gerrit.wikimedia.org/r/#/c/63273/