Extension talk:Semantic MediaWiki

The best way for getting support for Semantic MediaWiki is to post to its user mailing list. Comments made below are not very well monitored by the developers. There are various options for making yourself heard:

• If you have a usage question, please post them to the SMW support mailing lists (archives).
• If you found a bug or want to propose a new feature, please file it at GitHub. Bugs and requests are regularly considered by core developers and have a great impact on the future development of SMW.
• If you want to contribute to the development, please contact the development community at the SMW developers' mailing list (archives).

When asking for help or describing bugs, do not forget to provide necessary details about your configuration, version details for all relevant components, information about other extensions that are used, and, if possible, a URL where the problem can be seen. See the help page on reporting bugs for detailed information.

The below talk page is most useful for comments regarding the wiki page, but of course you may do as you like (it's a wiki, after all).

Faceted search

To bad faceted search don't supports the same range of property names as Semantic search. Guess its still in alpha state. O well, figure it might be out of alpha in version 5. MvGulik (talk) 22:49, 22 December 2024 (UTC)

SMW Blocked: 2021..2026

As expected I'm still (name)blocked at the SMW site (technocratic garbage) and SemanticMediaWiki at github.

Well, not that I expected anything else from mister professional (and general representative of the SMW team I guess).

Makes one wonder about the fact that some really silly and longstanding SMW bugs are still there might have something to do with the general SMW core group attitude. They will of course never agree to that, but that is the nature of the beast and its followers.
(one now sitting is some white house. Preaching peace and transparency while practicing the complete opposites).

Proud non blind-follower of any group, individual or other garbage. (although I love to hate SMW of course)

MvGulik (talk) 13:14, 1 January 2026 (UTC)

Blocked self-call (#set,template)

Great. No easy single-page testing or debugging of/with "#set:...|template=...".

... And that while with #ask one can re-call the same page more than one's. Go figure! ...

<includeonly>

:p1) "{{{1|<not-set/used>}}}"

</includeonly><noinclude>

{{:{{FULLPAGENAME}}|I'm the general default that will work fine for the first-level self-call.}}

{{#set:SomeProperty=SomeValue|template=:{{FULLPAGENAME}}}}<!-- SMW: I decided that's a bad default and will not allow that. => "Template loop detected: Sandbox" -->

</noinclude>

Might as well add that the (Preview only) warning related to using multiple "|+sep=..."'s in a single #set block:

"Warning: Sandbox is calling Sandbox^{(wrong name!)} with more than one value for the "+sep" parameter. Only the last value provided will be used."

Can be completely ignored, as the last past is not true. (+first one is kinda misleading too in this case.)

(Not sure who is to blame here though. MW or SMW. SMW ofc being my favorite in this case.)

There is one workaround to silents that warning. Only use "|+sep". Con: All inputs will need to use commas(the default) as delimiters ofc.

MvGulik (talk) 17:57, 29 January 2026 (UTC)

userparam (#ask template-call)

As far as the SMW doc(?) pages are concerned it seem the "userparam" #ask parameter is 'the' way to pass on additional data to a #ask called template. In practice this is actually not true, as one can do the same (and more) while not even making use of the "userparam" option at all. Makes one kinda wonder why the "userparam" option actually exists. MvGulik (talk) 13:51, 14 March 2026 (UTC)

Actually, I make rather frequent use of it. There's data the template may require and it's better to pass that info once rather than let each instance try to fetch that in some other way, which is not necessarily possible at all. Rand(1,2022) (talk) 15:15, 14 March 2026 (UTC)

Not quite sure we’re talking about the exact same thing, although it seems that way.

One thing that seems a limiting factor here seems to be related to:

Manual:Template_limits#Post-expand_include_size: "But if you included the same template multiple times with {{foo|arg}}, then the secondary templates are counted each time, even if the argument is the same."

Some merged-code test case worked fine (Post-expand include size: 265,394 / 2,097,152 bytes). While the final version, where the #ask part is now in a called template, hit the 'Post-expand include size' with ease. (have not yet figured out whats actually going on here.)

MvGulik (talk) 18:52, 14 March 2026 (UTC)

Not following you. What does this have to do with userparam? Rand(1,2022) (talk) 19:22, 14 March 2026 (UTC)

Aha, sorry. I misread your "Actually, I make rather frequent use of it." as using the seemingly workaround I talked about. While you actually meant that you are using userparam frequently.

I find that using userparam can be a bit cumbersome especially when you need to use multiple variables (used it for example for drawing some graphical flow-tree (image) which used some recursion.) MvGulik (talk) 08:21, 15 March 2026 (UTC)

That's true. You would need to bundle data your data using arrays and what not (the ArrayFunctions extension can be helpful here), which is what I do but remains a bit of a hassle. I once wrote something similar that allowed for multiple user parameters as long as you prefixed the parameter name with 'userparam' and the rest of the name is up to the site admin. Something like that might help. Rand(1,2022) (talk) 08:25, 16 March 2026 (UTC)