UESPWiki talk:MetaTemplate

MediaWiki VersionEdit

For the record, at this point the the MetaTemplate upgrade is written specifically for MediaWiki version 1.10 (the current version running on UESP). It might work with MW1.11, but it is completely unable to work with MediaWiki version 1.12 or higher right now.

Eventually, I'll make MetaTemplate compatible with MW1.14 and MW1.15, but the MW variables with which it interacts were completely revamped in MW1.12 and are now buried behind several layers of classes. It's going to take a couple of days of hard-core code dissection to figure out where the data is hidden, how the different node leaves and branches interact, what functions are supposed to be used to modify the data, etc. In the last round of code updates I took one initial, necessary step: I isolated the parts of my code that are going to need revamping, so now most of the MW version-dependent code is in one class that can simply be replaced with a new version, minimizing the amount of disruption/bug introduction.

Overall, however, I'm primarily focused on testing/improving MetaTemplate under MW1.10 for now -- so the good news is that when Daveh does install it, it will be in much better shape than the first version that I posted to UESP. I've been gradually increasing the complexity of my test templates: besides simple templates that test all the individual features, I now have preliminary versions of templates like NPC Summary and Book Summary. In the process, a lot of wrinkles have been ironed out! --Nephele^Talk 14:05, 7 April 2009 (EDT)

Okay. I promise to try to find out more about the behind-the-scenes stuff so I don't have to bother you with so many questions...

You've already seen my first stab at a new Ingredients Summary template, and I've done Non-Relevant NPC too, which with your NPC Summary (I hadn't wanted to LOOK at that one until I was more familiar with the new stuff!), should mean Morrowind (+TR, BM, TR3) NPC lists become easier to produce - quite possibly using #splitargs.

I'll try to find unusual ways of playing with the current additions to see if I can break anything. Please believe I'm only doing so for the good of the site! I'm still insanely excited at the prospect of these new additions, and can't wait until the rest of the extensions are available. At some point I'll post some of my own code, so you can have the pleasure of spotting things I've missed :) –Rpeh^{•T•C•E•} 14:37, 7 April 2009 (EDT)

Depending upon how behind-the-scenes you want to dig... you (Rpeh; sorry everyone else) should also be able to view the PHP code for the extensions where I'm posting it on content1 (/home/nephele/edits/). If you can do anything useful with the code, feel free to root around, copy it, or whatever. Also if you come up with any unusual template snippets or other ideas that might break/challenge the extension, post them and I can copy them over to my wiki for testing. Better to find and fix any problems now than later. --Nephele^Talk 15:40, 7 April 2009 (EDT)

/me brushes off his dusty *IX knowledge, such as it is

I need to find the time to grab the MediaWiki code and work through some of it before I can make much progress. Beyond that, my pedantic, optimisation-hungry self spots things like $this->_stack[$stackuse] being used more than once in one method and wonders how PHP does its compilation and whether creating a separate variable may be slightly more efficient.

I did say it was pedantic...

I doubt if a sub-n00b PHP coder will be much help to an experienced programmer like yourself, but OTOH I know it can be a help to have somebody else cast an eye over any code. I'll see what I can do.

Is your wiki public? If so, what's the address? Email it should you want to keep it hidden. –Rpeh^{•T•C•E•} 16:17, 7 April 2009 (EDT)

Feel free to pass along optimization suggestions, but followup is unlikely to be a top priority -- especially in the chunk of code that will be obsolete with the next MW version ;)

My test wiki unfortunately is local access only, with a lot of layers preventing access, including the general constraint that it's my test web site for everything I'm working on. And that's the only non-work web server I have running. So unfortunately there aren't many options in that direction. --Nephele^Talk 16:45, 7 April 2009 (EDT)

Update: the MetaTemplate code (version 0.4) will now work with the latest MediaWiki version. It wasn't easy, and it revealed a few problems with the new MediaWiki parser functions -- in other words, it requires a few changes to core Mediawiki files. However, the bottom line is that it's now ready for whenever UESP upgrades. The changes are all implemented with internal version checks, so it can be installed now under MW1.10 and will simply recognize once Mediawiki has been upgraded. --Nephele^Talk 13:04, 19 April 2009 (EDT)

#listsaved Implementation QuestionsEdit

The latest addition to the extension, #listsaved, is pretty powerful. A single call to #listsaved can basically generate an entire article; furthermore, the types of articles that it generates are ones that historically have been problematic in terms of the amount of processing necessary to create the articles. Since several aspects of the extension are intended to address problems with these processing-intensive pages, the #listsaved articles should be less trouble than they used to be. Nevertheless, the processing time necessary for #listsaved calls is a concern, leading me to wonder whether additional limits should be coded into the #listsaved function.

The options I'm considering include:

• Should only one condition be permitted for a #listsaved call? An exception would be namespace conditions, e.g., |namespace=Oblivion, because that's a "cheap" condition processing-wise. Therefore, |placetype=Ayleid Ruin|namespace=Oblivion would be allowed, but |placetype=Ayleid Ruin|region=Gold Coast would not be allowed. Currently, the number of conditions is basically unlimited. However, efficiency-wise it's probably far better to only have one condition at a time (and revamp variables so that only one condition needs to be checked). Should this be imposed as a requirement instead of just a suggestion?
• Should there be a limit on the templates that can be called by #listsaved? The intention is for #listsaved to be used with relatively straightforward templates (such as Template:Quest Link or Template:Book Normal). I don't think it would make sense to use #listsaved to call complex templates such as Template:NPC Summary -- or really any template that contains a #save call. However, trying to use such a template within #listsaved, accidentally or otherwise, would probably result in an article that couldn't even be saved because it would take too long to process. So should #listsaved quickly scan the requested template and simply reject certain requests? For example, reject any template that contains a #save call, or any template that is longer than 2000 bytes (for reference, Place Link is just over 1000 bytes, NPC Summary is nearly 9000 bytes). The check wouldn't really ensure anything (it wouldn't catch if the template then calls a complex template, for example), but it would make mistakes less likely.
• Should #listsaved be prevented from being used on templates? The limitation would only prevent #listsaved from functioning if it appears within articles in the Template: namespace; #listsaved could still be used in more general transclusions (for example, so that Oblivion:Ayleid Ruins can still be transcluded into Oblivion:Places). The concern is that inserting a complex #listsaved call into a widely-used template such as NPC Summary would result in a huge server load as all of the NPC pages are automatically regenerated -- although templates such as NPC Summary are protected from anonymous edits specifically to prevent mass propagation of such unwanted additions. Also, implementing such a limitation on #listsaved would probably prevent some legitimate uses of the function. So am I just being overly paranoid here or are some measures necessary?
• Should #listsaved print error messages when it gives up? Right now, it just stops and returns an empty string when there's a problem, and basically you need to then guess why it didn't work. Obviously that's not a good plan longterm, especially if there are additional reasons why #listsaved would give up. So probably the real question isn't whether to add error messages, but how to do it. My first thought is to emulate the Cite extension, that prints out bold red text whenever it refuses to process a tag. Does that approach work well?

These options don't really need to be decided right now -- it may be better to wait until we can see just how long it takes to generate real pages using #listsaved. It's also likely that other coding tweaks (e.g., improving the SQL query efficiency) will have an impact. But I wanted to get the thoughts posted while they're running around in my head. Of course, feedback or other suggestions are welcome. --Nephele^Talk 22:58, 15 April 2009 (EDT)

I think the second restriction makes immediate sense - stop it working on anything that contains a #save. It's difficult to see where anyone would want to make such a call unless they were deliberately trying to hurt the server. More likely such a call would indicate a mistake or a misapprehension so it should probably be blocked at the lowest level possible.

For the other restrictions, I'd say let's wait and see. I can think of several places where this new extension is going to be really, really useful (books, ingredients, places and people spring immediately to mind) and it would be irritating if the process of switching over was interrupted by, say, size restrictions. Having said that, it may be worth coding in support for a max size but setting it large enough not to exclude anything for now. That way, it could be lowered once the initial work had been done. Incidentally, would the maximum be available to change in, say, the System Messages page?

If you can make it print error messages, that would be helpful. It can be tricky to work out what's happening and any help would be great.

Looking forward to using this one! –Rpeh^{•T•C•E•} 04:24, 16 April 2009 (EDT)

Request...Edit

Сan get a copy of this extension for my project?Ruesp 00:07, 12 May 2010 (UTC)

The creator of the extension has left UESP, so it's unlikely that she'll give you a copy. She may still be monitoring the page, though, so you never know. You might also try sending her a message on the forums - she's logged in there at least once since leaving the wiki. Good luck! ‒ Robin Hood↝Talk 15:26, 12 May 2010 (UTC)

I repeat my request. Ruesp 02:13, 11 September 2010 (UTC)

I'm also significantly interested in this extension as well. Who is the creator of this extension? I'd like to try to contact them to ask if I may use it. Thanks in advance.  Valadez   Talk  Contributions  12:01, 29 April 2013 (GMT)

The creator is Nephele. If she gives me the go-ahead, I'd be happy to release it, but until she indicates one way or another if she wants it public, there's nothing we can do. If I recall, she said a while back that it was written with UESP's configuration in mind, so it may well need work before it would be useful on another wiki. – Robin Hood  ^(talk) 18:36, 29 April 2013 (GMT)

Thank you very much. I'll send her a message and see how things go.  Valadez   Talk  Contributions  00:43, 30 April 2013 (GMT)

MediaWiki (the base software used) is free software under the GPL which is a viral, copyleft license, so any derivative code needs to be available on the same terms. This means that both MetaTemplate and UespCustomCode ought to be available. --Gez (talk) 20:21, 14 June 2013 (GMT)

This isn't "derivative code", though, it's whole new code which uses the MediaWiki API. Derivative code would be code that started out as MediaWiki's code, then modified it. There's a good summary of these points on Wikipedia. Obviously, my thinking is what's covered in the "linking is irrelevant" section, but we can actually ignore that debate entirely. The important point is in the very first sentence of that section: "The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them." This would constitute private use. – Robin Hood  ^(talk) 20:49, 14 June 2013 (GMT)

<cleanspace> issueEdit

Currently categories inside cleanspace tags will honor DEFAULTSORT only, if it appears before the cleanspace tag. Else it is ignored. --Alfwyn (talk) 23:53, 15 January 2013 (GMT)

Looks like it is not directly related (disabling did not cure the issue), but SiteCustomCode_body.php makes an attempt to override getDefaultSort via the ParserGetDefaultSort taking care of the common cases "A", "An" and "The". The hook doesn't get called in 1.19 anymore, but this would make the vast majority of manual DEFAULTSORTs unnecessary. --Alfwyn (talk) 16:16, 16 January 2013 (GMT)

Per your edit summary, I had indeed noticed it, though I didn't understand enough to be completely certain of what was going on. I do notice, however, that Manual:Hooks now lists a GetDefaultSortkey hook that became available as of 1.18. Perhaps a small tweak would get that code working again and, as you say, make the manual DEFAULTSORTs unnecessary? – Robin Hood  ^(talk) 20:08, 16 January 2013 (GMT)

A much belated follow-up to this: it looks like the new method in 1.19 and above bypassed this issue and DEFAULTSORT is now honoured anywhere on the page, regardless of cleanspace tags. – Robin Hood  ^(talk) 06:16, 10 November 2018 (UTC)

catpagetemplateEdit

Any chance of getting {{{labelname}}} (returning the page's {{LABELNAME}} as an alternative to {{{pagename}}}? Alternatively, MetaTemplate could get a {{LABELNAME0}} magic word; that would work too. --Gez (talk) 12:55, 21 June 2013 (GMT)

I would be wonderfully excited if we could labelname to work. I believe that might solve several problems in the TR3 and TR4 namespaces, where the pages are all technically subpages of the Tamriel Rebuilt and Stirk pages. That way, we can use the actual name of the page in their templates, rather than have to write out Tamriel Rebuilt/ each time! Jeancey (talk) 18:14, 21 June 2013 (GMT)

Would {{#label:{{{pagename}}}}} or some variation of it work? – Robin Hood  ^(talk) 15:44, 22 June 2013 (GMT)

Nope. Doesn't work. See this for an example of what I'd like to get. Granted, if it's acceptable as-is, I'm fine with using that sort of hack on other category pages; but I worry about the "wiki processing requirements" issue. Alternatively the option of storing the pretty name without encumbering namespace could be used, and then the best way to do it would probably be through the templates that are used on most pages, and then with a robot to edit the categories. --Gez (talk) 20:43, 22 June 2013 (GMT)

Conditional expressions handling no longer needed?Edit

Since the switch to the new preprocessor (see the 1.12 release notes), Mediawiki no longer evaluates all branches of #if or #switch expressions. Thus, all MetaTemplate parser functions should now work as expected when used with regular conditional expressions, obviating the need for special handling.

What might foul up the works is when conditions depend on values that are set by parser functions; since the preprocessor doesn't know Metatemplate is doing that, it would evaluate these values wrong. If that is the case, the evaluation of these conditions needs to be deferred until the "extension rendering" pass, which means we still need that feature. To do: test this. --◄mendel► (talk) 04:12, 13 February 2014 (GMT)

Tested: the parser is smart enough to evaluate conditions correctly that depend on variables set by #define or #local. --◄mendel► (talk) 04:35, 13 February 2014 (GMT)

Yeah, MetaTemplate's initial design goes way back. There's version-checking code in there that's looking for 1.10 and below, as I recall. It could definitely use some updating, and I'd love to give it a total overhaul at some point, but I have so many other projects on the go (not to mention that my knowledge of PHP and MediaWiki's internals is...let's go with "somewhat lacking"), that I suspect an overhaul of any kind isn't gonna be till 2015. Good to know that the conditionals aren't necessary anymore. They're still convenient at times, but there's something to be said for using the standard methods as well. – Robin Hood  ^(talk) 05:20, 13 February 2014 (GMT)