Extension talk:Labeled Section Transclusion

From MediaWiki.org

[edit] Problems with Installation

I am trying to install this extension but I do not know what I am doing wrong. I copied all of the files and saved them separately into textpad as whatever name the download site has them as (lst.php, default.settings, etc.). I entered the require_once commands into defaultsettings.php and then it did not work. Is there anything I did not do correctly?

You should make the changes to LocalSettings.php, not DefaultSettings.php; then check Special:Version, to verify that the extension is loaded. If it didn't load, try checking your web server error logs for a reason, or try adding the line "error_reporting( E_ALL );" to LocalSettings.php", which may help show the error. -Steve Sanbeg 16:27, 29 May 2007 (UTC)

[edit] Proposed Enhancements

[edit] awareness of templates

Currently labels must be part of the text source of an article itself. It would be nice if the label could be buried within a template. Partly for esthetical reasons and partly as this would allow to easily transclude the contents of template parameters.
Example: You use a template in your articles for, say, year of birth and year of death of people. You want to transclude the person´s name (i.e. the page name) and the two dates. If transclusion does not understand templates, you will have to put section markers around the parameters when calling the template in each article. If transclusion can handle templates you will be able to hide the labels in the template (writing them only once!).

This is a limitation of the MediaWiki parser, which doesn't allow XML-style tags in templates; I assume this was deliberate. It affects all extensions, it's just more obvious with this one. I'd really like to see this, myself, but it appears that it can't be done. -Steve Sanbeg 16:41, 21 November 2006 (UTC)

Although, I must admit the Parser documentation is somewhat sparse, so it's always possible I'll discover some hook to do this. But at least for now, it's not obvious. -Steve Sanbeg 15:39, 22 November 2006 (UTC)

just to bookmark bugzilla:6312, for the same problem in the cite extension. -Steve Sanbeg 23:23, 5 December 2006 (UTC)

[edit] shortcut for simple transclusions on paragraph level

In not so few cases you may want to transclude exactly the text body (paragraph) which belongs to a section header defined by
=== my headline ===
or so. It would be boring to put transclusion labels around all these paragraphs. There should be a shortcut for such situations. Maybe one could use a "+" symbol or a "#" as a prefix for the section name to refer to the text body of headings. It could be left to the inclusion mechanism to identify the correct level of the heading; the transclusion would have to contain everything up to the next heading on the same level (including embedded subheadings and their bodies).

This was discussed at wikisource:project:Labeled section transclusion but it was dropped. In part, this was because they were more concerned with exactness of which parts are transcluded than a shortcut, especially since the most common use won't be the same as sections. There may be other issues with using visual markup to denote the sections; i.e. someone changing the name of a heading wouldn't know that they also broke a transclusion. It may be possible to have some way to put a mark in the text, that would be transformed to the normal markings when the document is saved, but I'm not sure how to do that, or how well-liked that would be. -Steve Sanbeg 15:51, 22 November 2006 (UTC)

I understand the purists but I really felt tempted to offer a little hack which would allow transclusion of chapters as a a whole. If you have many existing documents which use a common template and therefore have a chapter with identical name you wouldn´t really want to embrace them all with section tags I guess. In my definition a "chapter" is the text after a ==heading== up to the next heading (or up to the end of the document), regardless of the next heading´s level. Very pragmatic, very simple.

My suggestion is to use the heading text with a prefixed "#" to indicate the transclusion of a chapter. This is at least downward-compatible to the current solution. You can find the source on my metawiki homepage meta:User Talk:Algorithmix#Labeled Section Transclusion. You will notice that it was originally triggered by the wish to enhance another extension called meta:DynamicPageList2. In the discussion of that extension you will find more details.

Let me add an example: You have documents about people which contain a short "Summary" statement about each person, maybe including year of birth and year of death. And there are other capters named "Education", "Work" etc. Somewhere in the 'person' document you have a link to another document, say a 'city' where the person lived. My idea is to automatically include a list of people [together with a summary statement about each person] into the city document. Using DPL and LST together this can easily be done and looks really nice. I see this as a logical extension to "inverted links" which carries semantic information beyond the pure name of the referring page.Algorithmix 23:12, 23 November 2006 (UTC)

Hi. It seems to me that the more flexible the feature is, the more useful it becomes. Adding an additional option to transclude "regular" sections (what you refer to as "chapters"), as well as labeled sections, would be great, and indeed was contemplated in the original discussion. Does "downward compatible" also mean that it would be easy to incorporate in the coding? Dovi 21:27, 25 November 2006 (UTC)

Yes, in fact it is already contained in my version of the coding (Just ignore the first part about DPL2). "Downward compatible" means that you could write something like

{{#lst:someArticle|mySection}}

to use the feature as it is, i.e. based on explicit section markers, and something like

{{#lst:someArticle|#Some Headline}}

to include the regular section ("chapter body") of a section carrying the heading "Some Headline". If the parameter starts with a "#" it will be interpreted as a heading name otherwise as a section label. Try the source code of my homepage to test it if you like. Algorithmix 23:44, 25 November 2006 (UTC)

My main concern is that when a lot of people are collobarating, using headings that are intended as visual markup to denote sections could cause a lot of confusion when someone changes a hading, and has no idea that they're breaking transclusions. This could be useful on smaller sites. However, since the wikimedia software doesn't even support redirecting to section headings, I suspect that having this as an integral part of the extension would make it more difficult for us to get this installed on wikimedia projects. We probably want to hold off on making significant, non-obvious changes until this gets installed, unless we know we have enough support for them that it won't impact what we're trying to do.

As far as implementing it, I can see two ways it could be done: either fully integrate it into the wfLst_pat_() function, so we could mix and match section marks & headings, i.e. to transclude from a heading to the end of a section, or vice versa, or implementing another parser function (similar to what I did with the #lstx function, to avoid adding weird syntax to do exclusion) as a sort of extension to the extension. Although the first would be more flexible, it's also more likely to derail what we're trying to do. Since we don't need all of that functionality (for example, it would allow excluding a section marked by a heading, which is consistent, but unlikely to be useful), this may be a better way to go. Then, site that want a stricter approach could install the core functionality, while those that want more convenience could add to it. Probably, putting your functionality in a #lsth function would be the way to go.-Steve Sanbeg 19:32, 27 November 2006 (UTC)

As you have seen I created a second variant of wfLst_pat called wfLst_pat_heading. I did not want to intermix the two ways of describing/tagging relevant portions of a text. To me it would sound quite logical to have a corresponding #lsth function which uses the heading based transclusion approach only. This would easily allow a configuration switch to deactivate the heading based selection mechanism for SysOps who are concerned about the volatility of headings. Personally I still think that headings could be used; after all mediawiki accepts something like [[myArticle#its first heading]] as a valid link. Changing the heading breaks this link. Nobody seems to be very concerned about that today. Maybe that is because you still are guided to the beginning of the article if the heading has changed. My proposal for #lsth is therefore as follows: if no matching heading is found the reaction should depend on an option which is specified together with #lsth; in standard mode (non-obligatory heading) nothing happens, in "obligatory mode" we include the first 100 characters of the article. This is an analogy to putting you to the top of an article if the heading based href link fails. Algorithmix 21:22, 27 November 2006 (UTC)

Yeah, I was concerned about having a seperate pattern function in one of the existing parser functions; adding another parser function would be better. I don't think splitting on characters will work; you could get weird results if you split in the wrong place in formatting. Altough it would be possible to transclude the introduction, it's probably better to just use either an empty string or a link, which has less potential for weirdness, and would probably make the error easier to find & fix. -Steve Sanbeg 22:21, 27 November 2006 (UTC)

A link would be the perfect solution. It could show the desired heading text but it will -- as a heading with that text does not exist -- behave as usual, i.e. it will link to the beginning of the document. And in case mediawiki will some day offer a means to fix this type of "slightly broken link", LabeledSectionTransclusion will benefit from that without further effort. Algorithmix 22:49, 28 November 2006 (UTC)

I've put another extension at http://mediawiki-tools.cvs.sourceforge.net/mediawiki-tools/extensions/LabeledSectionTransclusion/, based on your code. Currently, it works the same as #lst: a missing page shows a red link, a missing section shows an empty string. -Steve Sanbeg 23:00, 28 November 2006 (UTC)

[edit] Intuitive name

Hi. At the Wikisource page, someone suggested using a more intuitive term in the code than "lst". If and when this becomes widely used, not only is the code "lst" likely to make no intuitive sense to the user and be hard to remember, but the "l" (letter) is highly likely to be confused with "1" (numeral).

As it stands, the most basic coding works as follows. Sections are marked off as:

<section begin=chapter1 />this is a chapter<section end=chapter1 />

And they are transcluded by using:

{{#lst:article|chapter1}}

May I suggest a more intuitive term for the transclusion code? It seems to me that the easiest to use remember would be precisely:

{{#section:article|chapter1}}

Or maybe even just:

{{#sec:article|chapter1}}

What do people think? Personally, I think I slightly prefer "section" to "sec" (second choice). But any other suggestion for any other word that can be used more intuitively would be fine as well. It doesn't really matter as long as it is usable. Dovi 14:18, 20 December 2006 (UTC)

P.S. Other supporting options would be used just as already proposed. Section exclusion as:

{{#sectionx:article|chapter1}} or maybe {{#xsection:article|chapter1}}

and "regular" sections with heading as:

{{#sectionh:article|chapter1}} or maybe {{#hsection:article|chapter1}} or {{#sectionhead:article|chapter1}}

Whatever people think looks and works the best. Dovi 14:32, 20 December 2006 (UTC)

Since it hasn't been installed on a project yet, it would be possible to rename it. But a simpler solution may be to create an alias, either globally or per language. Then we could just keep the functions named after the extension, and treat this as a localisation issue. -Steve Sanbeg 16:17, 20 December 2006 (UTC)

Is it important to keep the function named after the extension? Dovi 20:20, 20 December 2006 (UTC)

Probably not, but it would seem simpler on special:version. Naming parser functions seems a bit odd, in that the name that's shown on special:version can't be called directly (it's only called through an alias) and I think can't be the same as a parser tag. Which means it can't be named section, since that would conflict with the tag, but it could be called section. So renaming these may not be worthwhile; the names now are probably reasonable, and we could always add longer names if desired. We can even put off the language availablity issue until someone suggests using non-English names for them. Myabe we just need section, section-x & section-h or similar aliases for people who'd rather they're readable than short.-Steve Sanbeg 18:49, 21 December 2006 (UTC)

What do you think of these for the actual code:

• {{#isection:article|chapter1}} for "include section"
• {{#xsection:article|chapter1}} for "exclude section"
• {{#hsection:article|chapter1}} for "header section"

Simple and to the point. It actually seems to me that aliases in general are less important. In English the code itself should have names that do the job without confusion, and if other languages want to create aliases they can, but the code shouldn't depend upon that.

What worries me is that as actual code, the three letters "lst" are not intuitive enough, and that especially in English they are highly likely to be confused with "1st" (as in "first"). Dovi 06:45, 27 December 2006 (UTC)

I was thinking that it's more consistent to have a common prefix, with something to seperate words, which is why I was thinking of #section (clearly the most important function), #section-x & #section-h. It would be possible to use #section-i (or #i-section) or some other name. I'm not sure if adding a prefix letter with no delimiter would be as clear, but something to think about.

AFAIK, the names in the code don't actually do anything, they're just displayed in special:version. If we do decide that we don't need a function named #section, then we could rename them, though. -Steve Sanbeg 20:37, 31 December 2006 (UTC)

Any of these options sounds good, doesn't really make too much of a difference.Dovi 13:21, 2 January 2007 (UTC)

[edit] Bug with section indices with "empty" headings

There is what I believe to be a small bug when using #lsth to transclude a heading "section" from a page where there is an empty heading "section". Let me explain with an example from an imaginary page Foo:

= Section 1 =
== Section 1.1 ==

Some text.

=== Section 1.1.1 ===

Some more text.

If I transclude Section 1.1 on imaginary page Bar with {{#lsth:Foo|Section 1.1}}, then try to use the [edit] link on Section 1.1.1, I will actually be directed to edit Section 1.1. On Foo, the section numbers in the edit link for the three sections will be 1, 2, and 3. But on Bar, the edit link for Section 1.1.1 will have section=2 instead of section=3.

It looks like this happens because Section 1's "section" contains nothing. If I add a blank line before the Section 1.1 heading, things get back to normal.

Let me say that if this does get fixed, I probably won't upgrade. On the site I'm managing, we're already making fairly heavy use of this extension, and I'm currently leveraging this bug. I'm writing this up here for the benefit of users of this extension, and also in case anyone has feedback of a better way to achieve this.

Another example page Foo2:

<!--Section 1 deliberately left empty -->
= Section 1 =
== Section 1.1 ==

Some text.

=== Section 1.1.1 ===

<includeonly>===Section 1.1.1 (transcluded from Foo2)===</includeonly>
Some more text.

=== Section 1.1.2 ===

<includeonly>===Section 1.1.2 (transcluded from Foo2)===</includeonly>
Even more text.

Now if I transclude Section 1.1.1 on page Bar2, I get the heading "Section 1.1.1 (transcluded from Foo2)", whose [edit] link ends with section=3. Following this link will bring up Section 1.1.1 for editing. Without transcluding the empty "Section 1", the link on the transcluding page would end with section=4 and bring up the undesired Section 1.1.2 when clicked. --Ken Crowell 16:24, 30 January 2007 (UTC)

Thanks for the feedback. I fixed a problem with the regex, which seems to take care of that.

Generally, if you want to be precise about what is transcluded, it's probably better to use the more exact #lst, instead of #lsth, i.e.

= Section 1 =
== Section 1.1 ==

Some text.

<section begin=1.1.1/>
===Section 1.1.1<includeonly> (transcluded from Foo2)</includeonly>===
Some more text.

<section end=1.1.1/><section begin=1.1.2/>
===Section 1.1.2<includeonly> (transcluded from Foo2)</includeonly>===
Even more text.
<section end=1.1.2/>

It's also possible to use #lsth with a mix of wiki & HTML sections. HTML sections don't work very well in transclusion anyway, and so are generally ignored by lsth both for inclusion and when counting offsets (by default, mostly for efficiency). i.e.

<h1>section 1</h1>
==section 1.1==
some text

Should have similar effect; the HTML section currently won't be counted. -Steve Sanbeg 16:46, 31 January 2007 (UTC)

[edit] Test wiki

Hi. Is there is test wiki where one can experiment with this feature in the meantime? Dovi 06:21, 14 June 2007 (UTC)

I don't have access to install it on any public wiki; convincing someone to install it on one of the offical test wikis would probably involde similar effort to having it installed on ws -Steve Sanbeg 20:43, 20 June 2007 (UTC)

[edit] Editing the origin article

Hi Steve...

Actually I'm playing around with your nice extension. In this context I'm faced with a standard problem of transclusion within wiki. When choosing the edit-button, the user isn't able to change the content of the article, because only the "transclusion-syntax" is displayed.

Do you think it would be possible to manipulate the edit-function in a way to refer to the origin article, in the case of transcluded content?

greets... --Demagggus 12:34, 15 October 2007 (UTC)

If I understand what you want, the simplest way is probably to just put headings in the text that's being transcluded. then, each heading will get an edit link which points back to the appropriate section in the original text. -Steve Sanbeg 15:26, 19 October 2007 (UTC)

[edit] Transcluding sections from different articles

Hi,

suppose i have many articles in which i annotated sections with the keyword "linux". in another page i want to display all the sections with "linux" as keyword; or a link to those sections.

i think, as per the current functionality, we need to use the article name as a parameter, like {{#lst:article|chapter1}}. but in my case, i have many articles, and i don't know the names. my requirement is to find where all i have relevent information on "linux".

can it be achieved?

Jack

That would be a pretty significant enhancement, to add a table to track which pages have which section. It may be more useful to put all those pages in a category, and use something like semantic mediawiki or DPL call LST on pages in the category. -Steve Sanbeg 23:06, 8 November 2007 (UTC)

You may want to have a look at Extension:DynamicPageList. It offers search criteria based on regular expressions and contains and embedded version of Labeled Section Transclusion. --217.111.20.10 20:31, 27 November 2007 (UTC)

[edit] Including the Heading in Transcluded Output?

I was wondering if it could be made possible to include the section title along with the body text when including a section with #lsth?

I was kind of surprised when I realized that ONLY the body text and subordinate headings were included. I think there should be an option to include the section heading as well.

-Steve

That was mostly done because if the heading wasn't transcluded, it would be easy to add; i.e. with a template like

=={{{2}}}==
{{#lsth:{{{1}}}|{{{2}}}}}

but if it was added automatically, it couldn't easily be removed. It would be possible to add an option, but using a template is probably easier. -Steve Sanbeg 23:03, 8 November 2007 (UTC)

But then the edit link would be wrong. It would be nice when using lsth to include a useful edit link as well. 72.165.173.27 18:59, 11 August 2009 (UTC)

[edit] Includeonly / noinclude tags are ignored

When transcluding a section containing <noinclude> and/or <includeonly> tags, is their any way to get LST to honor them? I'd think it would be a fairly simple change to the code. --Jonathan Kovaciny 15:53, 10 January 2008 (UTC)

I'd think the parser should be able to handle those itself, although I haven't looked at it in awhile. It could also depend on the versions of mediawiki & LST you're using. -Steve Sanbeg 19:41, 10 January 2008 (UTC)

[edit] LST not working?

I've deployed the extension files and made the required changes to LocalSettings.php on my WM 1.11.x, PHP 5.x wiki. I checked the version page of the wiki, and it shows

MediaWiki: 1.6.10 
PHP: 5.2.5 (apache2handler) 
MySQL: 5.0.45 
Extensions: 
Parser hooks: 
DynamicPageList2 (version 1.6.4), based on DynamicPageList, featuring many improvements, by IlyaHaykinson, Amgine,Unendlich, Cyril Dangerville,Algorithmix 
LabeledSectionTransclusion, adds #lst and #lstx functions and <section> tag, enables marked sections of text to be transcluded, by Steve Sanbeg 
ParserFunctions by Tim Starling 
StringFunctions (version 2.0), Enhances parser with string functions, by Ross McClure & Juraj Simlovic 
Variables, Define page-scoped variables, by Rob Adams 
Extension functions: 
wfSetupVariables, wfStringFunctions, (, setup), wfSetupParserFunctions, wfCalendarExtension, wfRssExtension, (, setup) and wfLabeledSectionTransclusionHeading 
Parser extension tags: 
<dpl>, <section> and <rss> 
Hooks: 
EditFilter: CalendarEditFilter 
LanguageGetMagic: wfVariablesLanguageGetMagic, wfStringFunctionsLanguageGetMagic, ExtDynamicPageList2__languageGetMagic, wfParserFunctionsLanguageGetMagic, LabeledSectionTransclusion::setupMagic and wfLabeledSectionTransclusionHeadingMagic 
ParserClearState: (ExtParserFunctions, clearState) 
visited from 192.168.50.140
Retrieved from "http://192.168.50.136/wiki/index.php/Special:Version"

(The wiki version is incorrect -- installed from 1.11.x, but copied some files from our 1.6.10 wiki over during the upgrade, which appears to have overwritten something.)

Anyway, when I put '<section begin=chapter1 />this is a chapter<section end=chapter1 />' in the 'article' page, and '{{#lst:article|chapter1}}' in the target page, I just get '{{#lst:article|chapter1}}' displayed. Does that sound like a parser, or LST, issue?

Thanks -- com^lnssi^roberts^michael 1/10/08 13:06

Sounds like a parser problem; the parser isn't recognizing that the parser function is installed. Possibly that got messed up when you copied files, and no parser functions work, so you may want to try with a clean installation. -Steve Sanbeg 19:43, 10 January 2008 (UTC)

Thanks for responding. It looks like you're correct. When I get rid of the leading '#' sign, a la ParserFunctions for MW 1.6.10, LST works. What I did was install MW 1.11.03, then copy over all the content from our old 1.6.10 installation, which worked, but MW reports that it's 1.6.10, and PF apparently requires the 1.6.10 syntax, so apparently something I copied over wasn't content. -- MR

[edit] Hide templates?

Is there a way to completely prevent any templates in the source text from being transcluded? --Jonathan Kovaciny 21:56, 31 January 2008 (UTC)

No, this is the same as regular transclusion, it just selects which part to transclude. Removing all templates would require another extension to be written -Steve Sanbeg 14:27, 1 April 2008 (UTC)

[edit] Error message after installation

When I try to install this extension, it is shown in the Special:Version page, but on each page I get the following message now:

Warning: call_user_func_array() [function.call-user-func-array]: Unable to call LabeledSectionTransclusion::setupMagic() in C:\Web\htdocs\mediawiki\includes\Hooks.php on line 114
Warning: array_slice() [function.array-slice]: The first argument should be an array in C:\Web\htdocs\mediawiki\languages\Language.php on line 1105
Warning: array_slice() [function.array-slice]: The first argument should be an array in C:\Web\htdocs\mediawiki\languages\Language.php on line 1105

What is wrong? I am using MediaWiki 1.9.0

I'd guess that when the extension was modified to use the new parser, it somehow broke backwards compatability with old mediawiki versions. You may want to try using either a newer mediawiki or older LST -Steve Sanbeg 14:27, 1 April 2008 (UTC)

[edit] Bugreport: #lsth breaks template expansion/parser functions

wenn I use #lsth to transclude a section, Templates and parser-functions are not evaluated (and are shown as-is, i.e. like </nowiki>Extension talk:Labeled Section Transclusion</nowiki>). If I transclude the same text with #lst, it works. For a demonstration, see here.

We use MediaWiki-1.12.0, LabeledSectionTransclusion is an SVN-checkout, revision 32412. -- Mati 15:30, 25 March 2008 (UTC)

• It isn't a question of #lst or #lsth but you can't transclude the same section twice in the same page (make lsth first and lst second and lsth will work and not lst).--Nbrouard 09:04, 1 April 2008 (UTC)
  • That sounds like there could be a problem with the caching in the new preprocessor. -Steve Sanbeg 14:27, 1 April 2008 (UTC)
• It hase been reported on https://bugzilla.wikimedia.org/show_bug.cgi?id=12906 and the workaround works for me!--Nbrouard 08:04, 8 April 2008 (UTC)

[edit] Suggestion for LST tags to act as anchors

Suggestion: Would it be possible for this extensions to be upgraded with the additional feature that the LST tags (to begin sections) also automatically act as anchors, such that the point within in a page where a section begins can be linked to?

On "anchors" I am referring to the functionality described in M:Help:Link#Manual_anchors. Dovi 14:01, 31 March 2008 (UTC)

Yeah, I guess we could either normalize the section name or add an id argument, and render it is a span or a tag to get that effect -Steve Sanbeg 14:27, 1 April 2008 (UTC)

[edit] Templates

lst does not work when the section tags are transcluded. This was pointed out above in 2006, and you indicated that this was because the parser does not allow XML style tags in templates, and that this was a problem for cite as well. In w:User:Simetrical/Ref_test_2, cite seems to work fine at the moment. I did my own test and while lst still does not work, the text between the ref tags comes through fine when ref tags are transcluded -- the same functionality that we want from lst. Are you sure that it is not possible to make lst work properly with templates? --71.17.30.236 02:32, 1 April 2008 (UTC)

That part of the parser has been completely rewritten, but I haven't had the time to fully understand the new one, to see what all the affects of that are. -Steve Sanbeg 14:27, 1 April 2008 (UTC)

I recently began working on a text that requires exactly this functionality. Embedded within the text are letters (in special fonts) that refer to comments made on the main text by a variety of different persons. My idea was to present the text in two formats: One with these letters as links to comments, the other without them (because they interfere with the flow of reading), and letting the user decide which version he wants to use (with or without letter-links to comments). So I tried putting the letter-links within LST tags, and then using lst-x to produce an automatic version of the text without them. That didn't work, of course, because transcluded section tags don't work, as pointed out above. Dovi 20:39, 1 April 2008 (UTC)

[edit] Transcluding from Other Namespaces

I am trying to transclude an article from the User namespace but having problems. For example, I want to do {{#lst:User:Tester|chapter1}}

But that doesn't work. Is there a way to do this? -ahui 99.249.236.178 17:57, 11 April 2008 (UTC)

Template:Brian7632416 <-(Darn, I can never remember that shortcut.)

Me, too. I wanted to transclude the "Most viewed pages" section from Special:Statistics. Any info on transcluding from "other" namespaces? -Brian7632416 04:08, 16 September 2008 (UTC)

Me, again. I just learned learned about the config setting $wgAllowSpecialInclusion, which, according to Manual:Configuration settings, will "allow special page inclusions such as Special:Allpages}}," but enabling that config doesn't let me transclude all special pages, just {{Special:Newpages}} and {{Special:Allpages}} (so far). I still cannot transclude {{Special:Statistics}}, for example, so I can't get to {{Special:Statistics}}'s section titled "Most viewed pages." Brian7632416 00:10, 20 September 2008 (UTC)

The extension just does the normal transclusion (except defaulting to main namespace instead of template) then pulls out the requested sections. User namespace should work fine; many of the early test cases and examples were done that way. With special pages, it's coded into the page whether they are transcludable or not, although I believe the trend is to make more of them transcludable. -Steve Sanbeg 20:23, 22 September 2008 (UTC)

[edit] Bugreport: lsth.php has wrong function call

lsth.php has, in its current revision (rev. 34149), a bug: line 97 of the code calls method_exists with only one parameter, basically the call uses the wrong syntax. The patch is trivial:

Index: lsth.php
===================================================================
--- lsth.php    (revision 34149)
+++ lsth.php    (working copy)
@@ -94,7 +94,7 @@
     $result = substr($text, $begin_off);
 
 
-  if (method_exists($parser->getPreprocessor))
+  if (method_exists($parser, 'getPreprocessor'))
   {
     $frame = $parser->getPreprocessor()->newFrame();
     $dom = $parser->preprocessToDom( $result );

(This assumes that the check is indeed necessary. It could just be cut out as well, if that doesn't break older versions) -- Mati 09:34, 3 May 2008 (UTC)

[edit] lst bug when used in combination with regular transclusion and footnotes?

Hello, on s:en:On the expression of a number in the form 𝑎𝑥²+𝑏𝑦²+𝑐𝑧²+𝑑𝑢² I use lst to render a footnote spanning two pages. I'm pretty sure it worked before but now the last footnote, at the bottom of the page breaks off abruptly. The relevant pages are s:en:Page:On the expression of a number.djvu/3 and s:en:Page:On the expression of a number.djvu/4. I've tried to fix it by replacing spaces with underscores but it just doesn't seem to work. Is that a bug or is there some kind of trivial error in my markup?--GrafZahl (talk) 15:31, 13 May 2008 (UTC)

Maybe the interaction between noinclude tags and parser functions has changed with the new preprocessor? I haven't had a chance to verify that, but that looks like the most complex part of what you're doing. -Steve Sanbeg 16:13, 14 May 2008 (UTC)

[edit] When <section> is itself transcluded

I have a image with the following in the text part:

<section begin=caption />Blah, blah, blah.<section end=caption />

And elsewhere I am linking to image

[[Image:Foo.jpg|thumb|{{#lst:Image:Foo.jpg|caption}}]]

This works a treat, and allows me to store the default image caption in a single place—namely in the image.

However, sometime I would the caption text to itself be generated by a template. E.g. with Template:caption defined as:

<section begin=caption />{{{text}}} &copy;&nbsp;{{{author}}}<section end=caption/>

…which I would like to invoke in the image text as:

{{caption|text=Blah, blah, blah|author=Joe Blogs}}

When I view the image page directly, this renders the caption correctly. However, when I try to include the caption elsewhere via #lst, it fails—seemingly because it tries to locate the 'caption' section before the {{caption}} transclusion has been processed.

Is there any way around this? (I'm using MW 1.12.0 with PHP 5.2.0 and subversion snapshot r36656 of LST.) —Ras52 00:07, 27 June 2008 (UTC)

I don't think there's an easy way to change the order the parser does things; it will look for the section first, then parse it. So I think the only way around it would be to move the section outside of the template call, i.e. <section begin=caption />{{caption}}<section end=caption/> -Steve Sanbeg 17:12, 27 June 2008 (UTC)

[edit] Transcluding Links Problem

I am running v1.12 of Mediawiki and have run into a problem with LST that occurs in Firefox 3.0 but works as expected in IE7. If I have a document 'B' from which I am transcluding a section 'S' into a document 'A' where the section to be transcluded contains local links to document 'A' i.e., [[#LinkToSomewhereInA]] it looks like the links in document 'A' are active, but when clicked they do nothing.

If I hover over the link I can see on the status line that the correct url is being selected. I need this to work in both IE7 and FF3. Can anybody help? Pmcintosh 15:33, 1 July 2008 (UTC)

[edit] lst and templates

Hello, this isn't working regarding the {{{text|}}} function in templates, meaning I can't specifically transclude the variable created from the given text that is submitted into the template. If that doesn't make sense, I'll try again:

{{SomeTemplate
|Number=100
}}

----
On the template page:

Template:SomeTemplate


Number: <section begin=NumValue />{{{Number|}}}<section end=NumValue />

Number2: {{#expr:{{#lst:{{PAGENAME}}|HealthValue}} / 10}}

Number3: {{#expr:{{#lst:{{PAGENAME}}|HealthValue}} * 40}}

It doesn't accept this function, is there a way to fix this? Right now the only way to get it to work is by replacing {{{Number|}}} with an actual number.75.85.8.65 07:02, 13 October 2008 (UTC)

You know, I really hate it when it logs me out like that... Daedalus969 07:02, 13 October 2008 (UTC)

[edit] A couple of questions

I have read through the documentation and the discussion page, but have not found the answer to three questions. I wonder if someone would help me out. First, is it legal to transclude a labeled section on the same page in which the LST reference occurs? Second, what happens if a LST call is made to a non-existent section on a page (hopefully the null string is returned). Third, early during the discussion it was suggested this extension is intended for deployment on the wikimedia projects. Will this be automatic or should we lobby for its inclusion? Thanks, Dnessett 23:39, 27 June 2009 (UTC)

I have experimented and found answers to the first two questions, so no need to reply to them. However, see next section for a possible bug. Dnessett 16:14, 29 June 2009 (UTC)

To clarify what this extension does a bit, it uses the normal transclusion to get the text, but allows flexibility in what section you want to choose. In affect, it's just a more flexible variation of the includeonly, noinclude & onlyinclude tags; where instead of defining sections by intended behavior, they're defined by name, and the behavior is selected by the transcluding page. So it would only be a bug if the extension does something unexpectedly different than regular transclusion. There is a loop detection in mediawiki to prevent pages from transcluding themselves, which sounds like what you're hitting. -Steve Sanbeg 16:35, 30 June 2009 (UTC)

Thanks. By the way, I think this is a very useful extension. I am fairly new to wikimedia projects, so I wonder what one has to do to make the case of installing it on one of these projects. It appears that the wikimedia servers are pretty heavily loaded and consequently there is great reluctance to install new extensions (correct me if I am wrong). If my reading is correct, does that mean attempting to get new extensions installed on project servers is unlikely to succeed? Dnessett 14:34, 1 July 2009 (UTC)

Thanks. The extension was written for wikisource, and is already active on all of the language projects. It should be reasonably straightforward to add to other small projects if there's community support. For big projects, i.e. the wikipedias, there is a higher standard for the load on the system, although I think any issues there were resolved when it was migrated to the new preprocessor. Tim Starling, who wrote the preprocessor, also migrated this extension, and is one of the people who decided what's active where, so you could check with him. -Steve Sanbeg 15:47, 12 August 2009 (UTC)

[edit] bug?

I was playing around with the features of this extension and wondered if I could build a counter. The documentation suggested otherwise, but I tried anyway. So, I opened a sandbox and entered the following: <section begin=Count />0<section end=Count />{{#lst:|Count}}. On preview this produced '0'. I then entered <section begin=Count />0<section end=Count />{{#lst:|Count}}<section begin=Count />{{#expr: {{subst:#lst:|Count}} + 1 }}<section end=Count />{{#lst:|Count}}. Somewhat surprisingly, on preview this produced '0 1'. Ahah, I thought, maybe I can build a counter after all. Then I entered <section begin=Count />0<section end=Count />{{#lst:|Count}} <section begin=Count />{{#expr: {{subst:#lst:|Count}} + 1 }}<section end=Count />{{#lst:|Count}}<section begin=Count />{{#expr: {{subst:#lst:|Count}} + 1 }}<section end=Count />{{#lst:|Count}}. On preview this produced: '0 1 1'. Not what I expected. It looks like the extension performs the first redefinition, but not the second. If it acted according to the documentation, it seems to me preview should produce either '0 0 0' or '2 2 2'. Dnessett 16:25, 29 June 2009 (UTC)

Even more confusing behavior: I continue to play around with the functionality of this extension. I had the last bit of markup above in a sandbox (named Second Sandbox). In a third sandbox I entered: =={{#lst:Second Sandbox|Count}} Title==. On preview, this produced: '011 Title' in header 2 styling. This suggests each redefinition of the section "Count" is concatenating the new value with the old value, rather than adding the values. This explains the behavior reported above (the redefinition returns a string and the parser is interpreting the '+' as string concatenation), but it is somewhat surprising. Dnessett 17:09, 29 June 2009 (UTC)

More on this problem: OK, I think I have figured out something. I removed the 'subst:' from the LST calls inside of the '#expr' calls in my most recent experiments, since when you save the experimental text, {{subst:#lst:|Count}} evaluates to the null string. This means 'Count' is null until the whole page is evaluated. {{#expr: {{subst:#lst:|Count}} + 1 }} becomes {{#expr: +1 }}, suggesting the parser is not interpreting the '+' as string concatenation. However, =={{#lst:Second Sandbox|Count}} Title== in a third sandbox still returns '011 Title'. Not sure why this is happening, since contrary to first paragraph in this report, in my experiments the section (re)definitions and LST calls are on separate lines. The output from this is '0 <br> 1 <br> 1'. Transcluding a string with linebreaks should separate the parts of the header onto separate lines, which breaks the heading syntax (i.e., '011 Title' should not appear in heading styling). Furthermore, it isn't clear how the redefinitions of 'Count' produce the string '0 1 1'. During page rendering 'Count' is null until some event occurs. It then should either equal 1 (the most likely possibility) or perhaps 0. So,the behavior of LST in this usage is still confusing. Dnessett 18:41, 29 June 2009 (UTC)

GOT IT After rereading the documentation, it is now clear what is happening. You can have multiple sections with the same name. In that case LST concatenates all of the section text. So, the first <section begin=Count />0<section end=Count /> provides the character 0. The second provides the next character (1) and the third provides the third character (1). Sorry for this somewhat loquacious exploration of LST. However, the experiments did demonstrate one thing not in the documentation. If you attempt to reference the value of a section within a page that defines the section, the result is the null string. Dnessett 18:55, 29 June 2009 (UTC)

[edit] Parser Caching

I'm having a problem with the latest svn and mediawiki 1.13.1 when having parser caching on. The problem is that after I edit a page with #lsth parser directives the page is then rendered such that {{#lst:XXX|YYY}} is rendered as a link as if it were [[XXX]]. This only seems to happen for the user that edited the page. The transclusion happens correctly for other users. Likewise for the user that edited the page the transclusion works when previewing the page, but the submitted page exhibits the problem. I can provide debug logging if needed. For now, I've turned off the parser cache. Any ideas what the problem might be? Eisner 20:00, 11 August 2009 (UTC)

It's not entirely clear what you're experiencing, but I can clarify a bit on how transclusion works. When there is an error transcluding a page, such as something that doesn't exist, or is transcluded from itself, that is rendered as a link to the page and an HTML comment describing the error. So things to check are the exact message in the comment, and whether the behavior is different between using the extension and doing a regular transclusion. -Steve Sanbeg 15:53, 12 August 2009 (UTC)