Last modified: 2008-10-02 14:55:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13841 - recursive parsing extensions interfere with SMW
recursive parsing extensions interfere with SMW
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Normal major (vote)
: ---
Assigned To: Markus Krötzsch
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-25 07:29 UTC by DaSch
Modified: 2008-10-02 14:55 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description DaSch 2008-04-25 07:29:03 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.
Comment 1 Brion Vibber 2008-04-25 17:58:38 UTC
Please provide a specific example.
Comment 2 Jelte (WebBoy) 2008-08-11 19:02:47 UTC
Probably strongly related to bug 11224.
Comment 3 Steve Sanbeg 2008-08-11 19:50:34 UTC
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.

Comment 4 Siebrand Mazeland 2008-08-18 16:30:55 UTC
This issue should probably have its summary changed, as this refers to an issue with Cite, instead of SMW.
Comment 5 Steve Sanbeg 2008-08-20 05:03:05 UTC
(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.
Comment 6 Markus Krötzsch 2008-09-04 11:17:13 UTC
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.)
Comment 7 Markus Krötzsch 2008-10-02 14:55:52 UTC
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).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links