Page MenuHomePhabricator

Parsoid renders "invisible" SemanticWiki links
Open, MediumPublic


[[SMW::off]] and [[SMW::on]] are rendered as normal links. But if SemanticMediawiki is installed, this tag should not be rendered (at least it's mot by the PHP render), they are internal magic variables.

Event Timeline

Kelson raised the priority of this task from to Needs Triage.
Kelson updated the task description. (Show Details)
Kelson added a project: Parsoid.
Kelson changed Security from none to None.
Kelson added a subscriber: Kelson.

I don't know what Parsoid does or how it relates to MW hooks but for SMW on the PHP side it is expected that the InternalParseBeforeLinks hook is being executed before the output in order to apply an internal parse of raw text (which may include the [[SMW::off]] and [[SMW::on]] annotation as well). We know that the functionality is working as expected by running several MediaWiki integration tests against MW 1.19 - MW 1.25.

Configurable link syntax (added in 2007 in T10578) is not currently planned to be supported by Parsoid. Certainly the InternalParserBeforeLinks hook exposes details of the legacy parser which are not compatible with Parsoid (see also There are two basic alternatives:

  1. Add a new narrow hook which doesn't allow arbitrary changes like InternalParserBeforeLinks but focuses specifically on allowing extensions to modify the behavior of [[....]] syntax. Basically the extension would get a first chance to render a double-square-brackets link before the MediaWiki parser does.
  2. Replace use of [[...]] syntax with equivalent syntax using a parser function: {{#....}}.

Currently there are no plans to implement #1, and we understand that the SMW community is transitioning to #2. It's possible they could use some help with linting, etc.

(I'm pretty sure this is a duplicate bug w/ one filed long long ago on Parsoid w/r/t InternalParserBeforeLinks, but I can't find it in phab right now. So we'll pretend this is The Task.)

@cscott Do you have any links handy related to the SMW community's switch to parser function syntax for semantic annotations? I help manage a wiki that makes heavy use of SMW, and if that's the future direction of the extension(s), we'd like to know ASAP so we can start working on transitioning ourselves.

@Dinoguy1000 Currently there is no alternative for the in-text annotation syntax [[...]].

A current alternative for properties-in-a-template would be to use the set parser function with the template parameter: {{#set:Has Some Property=Value|template=SingleValue}}. This lets you set and display a property in a single call (as opposed to a set+show/ask), although it is more verbose.

Check the documentation about set+template here:

And the GitHub issue regarding this (and some concerns):