Last modified: 2008-10-02 14:55:52 UTC
In many cases the Extension interferes with other Extensions, in most cases the References are not display at the <references/>. That`s happening for example when using SemanticMediawiki.
Please provide a specific example.
Probably strongly related to bug 11224.
Cite displays the references at the end of parsing the page, unless that is a recursive parse called by another extension. Some extensions don't do this correctly, thus triggering various hooks, such as the end of parse hook, at the wrong time. I believe the issue with SMW is that it does non-standard handling in order to attach its magic to the [[link]] syntax, and uses a single hook to handle the links and display the data at the end of the page. Using separate hooks so that the links are parsed and store in one and the metadata displayed from another should fix this.
This issue should probably have its summary changed, as this refers to an issue with Cite, instead of SMW.
(In reply to comment #4) > This issue should probably have its summary changed, as this refers to an issue > with Cite, instead of SMW. > The only examples I've heard of are cite+SMW & poem+SMW, so I'll put the subject to match my understanding of it.
I agree with Steve: SMW should not print data in the hook it uses now. The question is: which hook should it use? The clean way would be to handle the data like MW categories, but is there any way to extend MediaWiki to include additional category-like data (which lives in the parser cache and can also be translated for each user)? (P.S. We are also working towards having no data on pages by default, offering better browsing instead. This may alleviate the issue.)
The development version of SMW 1.4 now uses a different hook for displaying the Factbox. Factbox display now is more stable and reliable. By default, the Factbox now is *below* the categories at the page bottom (since MW 1.14); this is no bug but intentional. It is still above (at the end of the article) in MediaWiki up to 1.13. Moreover, the data stored by SMW is attached to the ParserOutput, thus saving it from any cross-firing parsing activities of other extensions. Recursive parsing extensions should no longer interfere with SMW at all, so I close this bug (even though I am unsure about the initial complaint/problem; re-open if any such problem still occurs with SMW>=1.4b-SVN).
