Extension talk:Semantic Title/Flow

Previous page history was archived for backup purposes at Extension talk:Semantic Title/LQT Archive 1 on 2015-07-10.

It's probably really easy, but I cannot get my head around this: Let's say:

1. I am trying to use Page Title/Displaytitle/Semantic Title to use an ID as non-changing URL (HERO001516, HERO001517, HERO001518, …) and the display title comes from a text field (e.g. via input in page forms).
2. Now, the user puts in "Batman" and HERO001516 is created. I want to be able to link in the wiki with [[Batman]] to HERO001516. This doesn't work out of (my) box, Batman is a red link.
3. A redirect would be an option, but then the user changes Batman to "Spiderman" and I would have to also rename the redirect page, which leads the functionality for me ad absurdum.
4. I have learnt I can display the page title in page forms (instead of the ID) via setting $wgPageFormsUseDisplayTitle = true;, wonderful.

But how can I link to pages via their set page title? And do I need Extension:Display Title for this, or is this, what it is doing, would Semantic Title improve the linking functionality or is {DISPLAYTITLE:…}} even enough and I have just missed a point? Happy for any hints.

> I want to be able to link in the wiki with [[Batman]] to HERO001516.

Linking to wiki pages requires the page title (HERO001516), not the display title (Batman). The page title is the non-changing ID used both in URLs and in links. If you linked using the display title, you would have the same problem that you mention in 3 - renaming would require adjusting all of your links. Also, since page titles are unique but display titles may not be unique, it may be impossible to resolve the link using a display title to a particular page.

What Extension:Display Title gives you is that the link text displayed by [[HERO001516]] would be displayed as Batman.

Indeed this is out of scope of this extension. However I see the "issue" or better feature request for creating a separate extension that takes the subject label and creates a redirect from a page called like this to the subject page. I have looked around a bit for an extension that does just this about one and a half years ago but have not found any. It appears that there is still not extension around for this. When it comes to the a changed subject label this hypothetical extension would just create a second redirect.

Thank you both for your explanations! Good to know it doesn't make sense to look further. – I was even thinking I might lead MediaWiki's core function of unique URLs/page titles ad absurdum by trying to give a dynamic value that characteristic… I will have to reconsider the idea of an ID here and make use of redirects. I could have lived with redirecting display titles, though. And in Page Forms, there is a function for "unique in category", which could resolve the question for uniqueness (although it sounds a bit like trouble after manual changes…).

@Kghbln yes, something like that would be interesting. I have often wondered about this particular limitation of the display title approach. When using PageForms, the mapping between display title and page title is handled for you. But, for a user typing in wikitext wanting to link to a page, the need to use the obscure page title is troublesome. I have to admit that I have never liked redirects for some reason, but they may help here. But, I'd rather have a page keep a list of aliases (maybe using the new MCR capability?) that it could be linked from. When a page is rendered, when the link renderer encounters [[x]] it would look for a page with the title x. If none is found, it would look for pages with an alias (a current or previous value of display title) of x. If one is found, the link would be rendered to that page. If more than one is found, a link would be created to a dynamically generated disambiguation page. If none is found, there would be a red link. The caching behavior of this approach would have to be considered.

The advantage of creating a redirect page is that you get an subject showing up in the title key search and that people are probably triggered to edit the redirect target page rather than the redirect if unsure where to place the content best.

However having a page keep a list of its aliases is probably nice to have and MCR looks like it could be supporting a solution here. Your brainstorm sounds good to me. I am not sure if the title key search would work here but this is probably a matter of implementation. One other thing still to consider is what to do with redirects to sections of a subject which is very often done too.

I am running a 1.27 MW and was installing this extension. As I understand it, the extension distributor packs up and sends out a specific commit from the extension's git repo, in this case it looks to me like commit with id ca0248090a5cc557d27516415dc3324635b0dd99 . When I git clone the extension from github, I can see that this commit is indeed the tip of the REL1_27 branch, which is as expected.

But, the contents of the code delivered via the extension distributor does not appear to be equivalent to the contents of the code you see when checking out REL1_27 from the git repo. The extension distributor for example has the newer extension.json scheme.

Am I misunderstanding something here? I'd prefer (for the time being) to git clone my extensions, but I'm not entirely sure now which commit is the one which is expected to work with MW 1.27.3.

Thanks!

For extensions that are marked with the new "Compatibility Policy" set to "master", you should use the master branch. ExtensionDistributor should generally not be used for this type of extension. The head of the master branch should still work with MediaWiki 1.27.

However, almost all of the functionality of SemanticTitle has been replaced by the newer DisplayTitle extension used in conjunction with the DISPLAYTITLE magic word built into MediaWiki core as well as the "Display title of" property provided by Semantic MediaWiki. SemanticTitle is provided for backward compatibility only.

Roger. Thanks Cindy!

You're very welcome!

When editing an article and changing its title property value, then saving, the displayed title does not immediately show up. It only gets updated after another (null-)edit or purging the page.

Is this the expected behavior? Tested with version 3.2 (a05a9ea)

offtopic: what software you use to record such gifs ?

Software like e.g. “giphy capture“

That you for the video. It clarifies the situation. Yes, this is expected behavior when setting the semantic title using a property. SemanticTitle was almost completely rewritten to use the displaytitle page property in version 3.0. The ability to set the semantic title with a semantic property was kept for legacy reasons but will be phased out in the future. The issue has to do with how page properties get saved. I suggest that you switch to using {{DISPLAYTITLE:New Title}} instead.

Sorry, I don't quite understand (your last sentence seems incomplete - what should i use instead?). I thought the whole point of this extension was to set the title via a semantic property, or not?

Sorry, I forgot to use "nowiki" in my answer, so the DISPLAYTITLE bit didn't appear. I have fixed it above. Yes, the original intent of this extension was to use a semantic property, but due to changes in MediaWiki core, SemanticTItle was updated to be consistent with features available in MediaWiki core. In this way, the extension does not duplicate functionality and is as efficient as possible.

If we're going to use DISPLAYTITLE, why we need this extension for ?

DISPLAYTITLE only updates the title displayed at the top of a page. Semantic Title also uses this display title value for the link text for links to a page. It optionally adds a subtitle to the page with the original page title. And it also provides a parser function that returns the display title of a page.

Might be worth thinking about moving this functionality into another extension though as it seems unrelated to the "Semantic" part in the extension name. This would be less confusing. The semantic title extension on top could then be deprecated or fixed.

Yes. My plan for some time has been to create a new extension, DisplayTitle, that has this non-Semantic MediaWiki-dependent functionality. Then, SemanticTitle would retain only the functionality to set the display title from a semantic property. The two extensions would be independent of one another; DisplayTitle could be used alone, but SemanticTitle would typically be more useful when used with DisplayTitle.

General benefit of having semantic property as source for page title is that property itself may come from sources other than page markup.

In such a case, where does the value of the property come from? Is it set in another extension? If so, which one? I would like to understand this use case better.

For example there is Extension:Semantic Extra Special Properties though it is not very obvious that someone would like to use some of these system-like properties as pagename, but possibility of adding semantic properties to pages programmatically exists, so there is a use-case for that.

Do you have a specific need for this functionality - having a semantic property that is set programmatically by an extension used by SemanticTitle as the source of the display title of a page? I do agree that it is a theoretical possibility.

My current (widespread) usecase: As you might know, I generally use scribunto in conjunction with SMW (and Cargo).

So If I understand SemanticTitle and DisplayTitle correctly:

• I store a semantic property (e.g. named "has display title"
• SemanticTitle would then use the contents of this property and set a display title (assumming the namespace is configured correctly)
• Extension:DisplayTitle would then use this set display title in link texts

Now my "problem": My interface to SMW is SSC (SemanticScribunto Extension) which allows for easy and efficient storing of semantic data. Using {{DISPLAYTITLE:xxx}} in my modules would require a comparably "expensive" parser function call via frame. So for me the better way would be, if my module would store semantic data (and therefore the page title), and semantic title would serve as the middleman to DisplayTitle. The alternative could be a lua function in core or DisplayTitle to set the display title of a page inside a module.

Interested to hear your thoughts @Cindy.cicalese?

Interesting. I like the idea of defining a Lua function that directly sets the displaytitle and could be used from within other Lua functions. The PHP supporting that function would need to call CoreParserFunctions::displaytitle() from a context that has access to a parser. No semantic properties would be required, which would be a good thing, since as described earlier in this thread, the mechanics of setting the display title page property from a semantic property is convoluted and does not work perfectly, often requiring a null edit. It seems unnecessarily complicated to introduce a semantic property if the page property can be set directly from a Lua function. I'm not sure when I'd have a chance to work on this, but feel free to submit a patch to DisplayTitle to do this.

Done. :) Needs review and merge.

Awesome! Thank you!! It looks great! Does it satisfy your use case and work as we hoped? I will try to test it on our infrastructure today. I'm assuming that the extension still works OK without Scribunto installed (obviously without the extended functionality), right?

I tested it on 1.27.1 and it does what it is supposed to do. For my use case it means, augmenting the modules for all the entities that need a display title. Until this is finished, I will keep using SemanticTitle. After that, it should be obsolete for me.

Thank you! I also tested, and it works great! I merged the patch and updated the documentation at Extension:DisplayTitle.

Great! Thanks! <3

Then trying to refresh (inital indexing went smooth) the search index for the Extended Search extension I got for following query error with a stack trace:

A database query error has occured.

Query:

INSERT INTO `49275_page_props` (pp_page,pp_propname,pp_value) VALUES ('1577','displaytitle','MyTitle') Funktion: SemanticTitleHooks::setDisplayTitle

Error:

1062 Duplicate entry '1577-displaytitle' for key 'pp_page_propname' (localhost)

Backtrace:

#0 /.../w/includes/db/Database.php(901): DatabaseBase->reportQueryError('Duplicate entry...', 1062, 'INSERT  INTO `4...', 'SemanticTitleHo...', false)
#1 /.../w/includes/db/Database.php(1464): DatabaseBase->query('INSERT  INTO `4...', 'SemanticTitleHo...')
#2 /.../w/extensions/SemanticTitle/SemanticTitleHooks.php(103): DatabaseBase->insert('page_props', Array, 'SemanticTitleHo...')
#3 /.../w/extensions/SemanticTitle/SemanticTitleHooks.php(53): SemanticTitleHooks::setDisplayTitle(Object(Title), 'Weisung zur Mul...')
#4 [internal function]: SemanticTitleHooks::onParserBeforeStrip(Object(Parser), '{{KIWIPageHeade...', Object(StripState))
#5 /.../w/includes/Hooks.php(195): call_user_func_array('SemanticTitleHo...', Array)
#6 /.../w/includes/parser/Parser.php(443): Hooks::run('ParserBeforeStr...', Array)
#7 /.../w/includes/content/WikitextContent.php(331): Parser->parse('{{PageHeade...', Object(Title), Object(ParserOptions), true, true, NULL)
#8 /.../w/includes/content/AbstractContent.php(497): WikitextContent->fillParserOutput(Object(Title), NULL, Object(ParserOptions), true, Object(ParserOutput))
#9 /.../w/extensions/BlueSpiceExtensions/ExtendedSearch/includes/BuildIndex/BuildIndexMainControl.class.php(699): AbstractContent->getParserOutput(Object(Title))
#10 /.../w/extensions/BlueSpiceExtensions/ExtendedSearch/includes/BuildIndex/BuildIndexMwArticles.class.php(126): BuildIndexMainControl->prepareTextForIndex(Object(Title))
#11 /.../w/extensions/BlueSpiceExtensions/ExtendedSearch/includes/BuildIndex/BuildIndexMainControl.class.php(263): BuildIndexMwArticles->indexCrawledDocuments()
#12 /.../w/extensions/BlueSpiceExtensions/ExtendedSearch/includes/BuildIndex/BuildIndexMainControl.class.php(398): BuildIndexMainControl->buildIndexWiki('Indexiere Wiki ...')
#13 /.../w/extensions/BlueSpiceExtensions/ExtendedSearch/maintenance/searchUpdate.php(27): BuildIndexMainControl->buildIndex()
#14 /.../w/maintenance/doMaintenance.php(103): SearchUpdate->execute()
#15 /.../w/extensions/BlueSpiceExtensions/ExtendedSearch/maintenance/searchUpdate.php(38): require_once('/var/www/html/0...')
#16 {main}

Do you think this issue lies within Semantic Title or should this be addressed with the creators of the Extended Search extension?

This is probably due to the way SemanticTitle sets the displaytitle page property. This property is really only supposed to be set by the parser when the DISPLAYTITLE magic word is used on a page. SemanticTitle retains the ability to set the display title from a property, but this is mostly for backward compatibility. I have seen that error before, but it is usually transient. I encourage you to switch to using DISPLAYTITLE if possible. If you use the DISPLAYTITLE magic word, a property holding the display title will automatically be created for you, so it can still be queried.

Thanks a lot for your feedback! Switching to DISPLAYTITLE is actually what I recommended to the users of the respective wiki as a sane way to avoid this issue. Since it is future best practice anyway ... Still I did not want to withhold the info on the error in case other things perhaps relate to it.

Excellent! Thank you!

The tag for version 4.0 is still missing. Will be great to get it. :)

Done!

I wonder, weather it is possible to use this extension to use a property to define alternative pagenames / redirects for the main title.

I would like to have something like a uuid inside each page and be able to link to the page by this uuid.

If I have a page with name "bla" and property "has uuid=SomeUID" it should be reachable with "http://wiki.com/wiki/uuid:SomeUID".

SemanticTitle controls the rendering of the title and links, but not the URL itself.

Thanks. Does anyone know a plugin, which implements alternative URLs ?

I believe you can use some hook ( like that Manual:Hooks/ArticleFromTitle ) to match your UID with real page and redirect user / alter rendering. To fetch page with needed UID you can use https://github.com/vedmaka/SemanticQueryInterface

To put it in other words: you would like to have redirects, or at least they should serve what you would like to do, e.g. information on Jane Doe is saved in the wiki on Page "P25468" with the display (semantic) title "Jane Doe". In this situation if you enter "Jane Doe" in the search field you do not get her suggested (e.g. TitleKey extension) right away since the page has actually a different name. Or if you would like to directly link to her page from outside without knowing the exact page name but just the display title. Both use cases could be solved with a redirect by a page called "Jane Doe" with a redirect to "P25468".

As a matter of fact I tried to achieve this by using Semantic Forms and automatically create a page "Jane Doe" redirecting to page "P25468". Creating such a page is no issue but getting the value into the #REDIRECT[[P25468]] was not possible - at least I did not manage to get it to work.

Yes, this feature (= automatically create redirects) would be dynamite.

Just yesterday I stumbled upon the AutoCreatePage extension and figure I/you should give this one a shot.

@Vedmaka It looks very much like one could probably create an extension based on the Semantic Query Interface extension if the AutoCreatePage extension does not do the job.

Yep, I think so, though I did not put too much optimizations into Semantic Query Interface, so it would be a nice to be aware of performance while developing such redirect extension.

I have a problem with the semantic page title showing, I just can't make it appear. In my template I have tried to add the following:

("Hat Titel" is defined in LocalSettings as title property.)

• {{#set:Hat Titel={{{Titel}}}}} – to silently add the property. No effect.
• {{DISPLAYTITLE:[[Hat Titel::{{{Titel|}}}]]}} – as described on this page. No effect.

If I include [[Hat Titel::{{{Titel|}}}]] somewhere in the table/page code, it's showing up! (But I don't want it anywhere on the page...)

On the property pages it's the normal page title showing up instead of the semantic title.

I'm not sure why the first way isn't working, but that is no longer the recommended way to set the display title. The most common problem with that approach is not setting the property to be of type Text. That would silently fail like you are seeing.

But, you should really use DISPLAYTITLE. The problem is that you should be providing text rather than a property to DISPLAYTITLE:

{{DISPLAYTITLE:{{{Titel|}}}}}

Try to do {{#set:Hat Titel= }} with the trailing blank within the parser function. I cannot remember exactly but there is some other context that requires it to do it like that.

Thanks for your offers! I tried all of them. @Kghbln your version wouldn't work with Semantic Forms, I need to tell what form field the title comes from.

In the end, my last version with the property plus the one with #set worked, but DISPLAYTITLE didn't! What caused my issue was a wrongly set data type (it was not set at all), instead of type text. Tried with type page, too, does really only work with data type "text"! Thanks a lot for that hint.

I have included a little note here, as I found the description above not bold enough, feel free to edit, of course.

Thanks for updating the extension page. I had thought that the property type was documented there, but clearly not boldly enough.

I'm guessing that the reason that using DISPLAYTITLE was not working was that you still had $wgSemanticTitleProperties set in your configuration file. That would override DISPLAYTITLE, so you would still be getting the erroneous behavior if the type of the property is not text. If that's not the case and you detected some other bug, please let me know.

Thanks!

One the wiki Zabien tested the configuration parameter is indeed still set with "Has pagetitle" for the main namespace.

@Cindy.cicalese are you saying that I should use either the $wgSemanticTitleProperties or the DISPLAYTITLE? I read from the docu that the former always has to be in there to work. Then I also don't understand the sentence "Being installed and configured, Semantic Title handles page titles and links with no user intervention." (If I don't need any configurations, maybe "usage" should come before "configuration".) But, as I read it, I have two options: Tell in LocalSettings.php or in the template what property should be used. Should work automatically, then, but doesn't, because: Either way, when filling data with a form, I need to tell in the template, what form field corresponds to the property. Sorry, if I'm being picky here, I try to narrow it down. If I use the version you mentioned, {{DISPLAYTITLE:{{{Titel|}}}}}, how will the property ever get stored? @Kghbln sorry, what wiki do you mean??

@Zabien, sorry for the confusion. Yes, you should either use DISPLAYTITLE or set $wgSemanticTitleProperties to set the page title. Doing both is redundant. The latter will override the former.

Since SMW 2.4.1, a property Display title of is automatically set for any page that uses DISPLAYTITLE to set the page title, allowing the display title to be queried. This behavior is present even without the SemanticTitle extension.

This confusion is in part due to the evolution of the SemanticTitle extension. Initially a property needed to be set in order to set the display title of the page, but the extension was updated to use the built in DISPLAYTITLE functionality in MediaWiki core. The ability to set the display title using a semantic property is a legacy of the original approach, left in for backward compatibility. My plan is to create a new DisplayTitle extension that has all of the non-SMW-dependent functionality of SemanticTitle. This will leave only the ability to set the display title from an SMW property or Cargo field in SemanticTitle. I would expect that most people would use only the DisplayTitle extension.

@Zabien I meant this. @Cindy So basically SMW core took over the functionality of ST since version 2.4.1 and would no longer be useful for a wiki using SMW meaning that a DisplayTitle extension will be something for Cargo or plain MW?

@User:Zabien Oops, I remember that I pulled ST from sandbox some time ago for testing purposes and did not added it back after. So your test yesterday showed only SMW behaviour. I just added version 3.2 again.

@Kghbln, not quite. There are two distinct bits of functionality in SemanticTitle: 1) setting the display title and 2) using the display title in places other than the title of a page (links, etc.). When SemanticTitle was originally written, the support for DISPLAYTITLE in MediaWiki core was not what it is now. Setting the display title from a semantic property duplicates functionality now in core in a less efficient manner and sometimes requires a null edit to update the displayed page title. So, for setting the display title, I now recommend using DISPLAYTITLE rather than indirectly setting it through a semantic property. However, SemanticTitle is still required in order to use the display title as link text for links to a page with a display title. It also provides a parser function to return the display title of a page. This latter functionality is what will move into the new DisplayTitle extension. DisplayTitle will work without Semantic MediaWiki, since it only needs the DISPLAYTITLE functionality in MediaWiki core. The approach taken by SemanticTitle (and in DisplayTitle in the future) for updating the link text only works for text generated by PHP, however. For extensions that use JavaScript to display links to a page, they need to do a bit more work to get the display title for the link text. This is what is now built in to Semantic MediaWiki for JavaScript-based result formats. In addition, a property was added by SMW to reveals the display title for a page. Note that this property is used to query the display title, not (as far as I know) to set the display title.

Thanks a lot Cindy for elaborating on the current situation and functionality as well as providing additional background information! I believe this leaves nothing left to say. I am sure that others will appreciate this as I do.

Does the extension also effect the links in "Special:Recent changes"? Would be nice to be able to display the semantic titles there. Thank you.nanus:awelso e

Yes, it works in Special:Recent changes.

Now SemanticTitle sets only DISPLAYTITLE in SMW?

> Consequently, Semantic Title will now work with display titles set with that magic word.

Without $wgSemanticTitleProperties ?

In version 3.0, if you use DISPLAYTITLE to set the page title, that value will be used as the default link text on links to the page. This was not the case before.

You can continue to use $wgSemanticTitleProperties, but it is no longer necessary if you use DISPLAYTITLE. In fact, the implementation of DISPLAYTITLE is preferable to that of $wgSemanticTitleProperties, since the storing of the value happens at a better point during parsing of the page. I am actually considering phasing out $wgSemanticTitleProperties and the new corresponding Cargo variant in a future SemanticTitle release for those reasons. I welcome feedback on this decision.

Cindy,

I am experiencing an unexpected behaviour for categories.

When I use DISPLAYTITLE: xxx in category:Yyy, the category name is rendered correctly both in the page and when the category is linked, e.g. [[:Category:Yyy]] renders as xxx.

However, when using {{#categorytree:Yyy}} the category tree is rendered using the Page name (also used as URL) instead of the Display Title.

Is it a feature of Semantic Title, Category Tree or there is a particular setting that I need to add to LocalSettings.php to activate the functionality?

Thank you

Category Tree would need to be updated to use the display title rather than the page name.

Cindy,

Please can you expand on the "Category Tree would need to be updated" part, does it mean I need to install a newer version for it to work or does it mean the author of Category Tree needs to modify its extension to use semantic title?

In the latter case, can you provide a summary description of the mechanism used by semantic title e.g. if one needs to replace calls to Title::makeTitle(...) with SemanticTitle::makeTitle() or alike and a pointer to likely functions that need to be updated, as Category Tree does not appear to be maintained, at least in recent time.

Thank you.

Sorry - I meant the latter. It looks like this is now addressed with the patch https://gerrit.wikimedia.org/r/#/c/307332/.

It seems that ST is only working with

$wgMainCacheType = CACHE_NONE;
$wgEnableParserCache = false;

but this is not mentioned on the Extension page. Can someone please confirm if this is really the case or if I have another issue here. I came across this, because Extension:ConfirmEdit requires caching to enable Captchas for the login page...

We use

$wgMainCacheType = CACHE_ACCEL;

with SemanticTitle with no issues.

Caching is kind of an issue I believe. If you create a new page and define the property used for the title, then save, the title shows still the original page name for me. When I save again or just call the url with ?action=purge then it gets updated. This is the same issue as using an inline-query to query properties queried on the same page. To make matters worse, whenever updating the property of the page title you will experience the same behavior. It really just gets updated after saving or purging the page again (or because of an event like used template edit triggering a purge).

See Title property value update takes additional null-edit or page purge to take effect to discuss this further.