Extension talk:SubPageList3

Difference between this extension and using the prefixindex special page

In an IRC discussion today, Splarka raised a good question about the difference between this extension and the prefixindex special page. In particular, he suggested using the following transclusion {{Special:Prefixindex/{{FULLPAGENAME}}/}} to save about 500 lines of PHP! Here's an attempt to answer:

1. The prefixindex special page cannot do inheritance indents (like a tree).
2. The prefixindex special page cannot do a horizontal bar menu.
3. The prefixindex special page cannot do something like the "kidsonly" option (i.e. show children but not grandchildren).
4. The prefixindex special page cannot cope with pseudo-subpages - i.e. subpages on non-Wikimedia wikis where the admins don't understand that forward slashes aren't all it takes to make a "real" subpage. Coping with pseudo-subpages is more intuitive from the user perspective.
5. I can't get Splarka's transclusion code to exclude the paths (i.e. option of just having the final name without the path).
6. Probably a few other things too.

In short, the SubPageList3 extension is a user-friendly little menu creator more finely attuned to the needs of people on Wikibooks and Wikiversity who need to create content tables for their multi-page projects. (I hope).

--McCormack 12:03, 26 February 2008 (UTC)

Further comment: if {{Special:Prefixindex/{{FULLPAGENAME}}/}} can be used to recreate exactly what this extension does, perhaps someone could demo this below? Thanks! --McCormack 10:40, 28 February 2008 (UTC)

Pseudo-subpages and $wgNamespacesWithSubpages

See: $wgNamespacesWithSubpages. See also Category:Subpage variables just in case anyone ever thinks of any more.

Another point was raised here by Splarka: that by default, subpages are "disabled" in Mediawiki's main namespace but not in the other namespaces. The default settings are kept for most Wikimedia projects, but not for Wikibooks and Wikiversity. Subpage-"disabling" really just means that "/" is just any old character in a page title rather than a subpage indicator. The difference has no meaning at all for ordinary users, but internally the MediaWiki code makes a distinction, so the end result is that there are "real subpages" (where the internal code identifies them as such) and "pseudo-subpages" (where the internal code does not recognize any link with the parent, but where the user sees them as looking just like the real thing). Splarka raised the question whether or not this extension could or should respond just to "real" subpages or "pseudo" subpages. The answer is that the extension is indifferent to the internal code distinction: if it looks like a subpage, then the extension treats it as such. This means that the <splist> tag will always behave as a naive editor expects it too, which is perhaps more user-friendly. Imagine having to explain to your average editor that the <splist> tag worked in a namespace-dependent fashion on some wikis and not others, depending how the $wgNamespacesWithSubpages tag was set! Of course, this then opens the door to the danger that IF the extension was ever activated on (e.g.) Wikipedia (rather than Wikibooks or Wikiversity), then naive editors might start putting <splist> tags into articles and getting rather counter-intuitive results; in response to this: such uses of the <splist> tag would be obviously silly and quickly revertible - i.e. we probably don't need to be worrying about such things at the programmatic level. If the day comes when we do need to worry about such things at the programmatic level, then we can create a $wgIsSensitiveToNamespaceSubpageDisabling variable, set to false by default, which could then be set to true on projects such as Wikipedia in the event that they also adopt the extension. --McCormack 13:14, 26 February 2008 (UTC)

Namespace & "parent" param bug

I tried the following:

<splist parent=Sandbox />

In my "User:" page and it didn't find any subpages, but when I put it in a different page, Sandbox2, it did find subpages. -Paul 18:01, 29 February 2008 (UTC)

I see now the bug listed, but it says it was fixed in the initial release. Either I have an old version of the bug is still there. I pulled it from the SVN link. Is there a new one else where? -Paul 18:45, 29 February 2008 (UTC)

I made a change to the code to fix the problem. On line 381, I changed:

$nsi = $this->title->getNamespace();

to

$nsi = $this->ptitle->getNamespace();

There seemed to be a missing 'p'. -Paul 19:00, 29 February 2008 (UTC)

Hi Paul and thanks for your report. Where did you test this? I would like to look at how you set this up. --McCormack 06:05, 4 March 2008 (UTC)

Hi. I've looked at this further, and discovered that someone changed my code before uploading to SVN. At least 3 lines of code were changed, and this included the introduction of the bug you reported. --McCormack 07:28, 4 March 2008 (UTC)

This has now been corrected on SVN. Many thanks for reporting this, Paul. --McCormack 07:44, 4 March 2008 (UTC)

parent bug again

Using Subpage List 3 1.4 (2ce924c) 09:35, 13. Jul. 2023 with MW 1.40 this parameter is not working after having saved the page with the splist tag, however, previewing the page renders the list of subpages of "parent=Sandbox" correctly.

I am puzzled, what's going wrong here.

Filed as Bug https://phabricator.wikimedia.org/T347351 Wikinaut (talk) 20:06, 25 September 2023 (UTC)

---

Hello, I received (a) the correct report when parent=token (b) an incorrect report when parent=token1 token2 (c) a correct report when parent=token1_token2 and (d) a correct report when parent="token1 token2". I am reminded that this is an xml element, so that multi-token attribute values must be in quotes! Further, if you need magic words in this parameter (eg parent={{PAGENAME}}) then insert this at around line 297:

 } else if( is_string( $options['parent'] ) ) {
   global $wgParser;
   $this->parent = $wgParser->recursiveTagParse( $options['parent'] );
 }

Last, to correct a bug that does not show the correct link when there are no subpages to list, replace line 347 with:

  $plink = "[[" . $this->namespace . ':' . $this->parent . "]]";

---

I tried above modification on MW 1.27 with SubPageList3 v1.4, and it seems like NOT working....

I got error show up, maybe it's the line number is not correct in newest version?--JHK (talk) 08:19, 8 December 2016 (UTC)

Kidsonly In a Subpage

I get the following error when I put

<splist Kidsonly=yes />

in a subpage:

Warning: implode() function.implode: Bad arguments. in /var/lib/mediawiki/extensions/SubPageList3.php on line 478

A quick look at the code shows that the "list" array in makeList is empty so implode chokes on it. --Paul 20:44, 4 March 2008 (UTC)

• Hi. My initial testing does not confirm this. I get "(name_of_current_page) has no subpages to list. " - which is the expected and desired output. See [1] --McCormack 08:34, 9 March 2008 (UTC)
  • Next post: Paul tried it out at the above location and successfully did a recreation. Note: to recreate this, you need to put the extension on a subpage which also has its own subpages - i.e. if there are 3 levels, then the tag must be inserted on the 2nd level. The 1st and 3rd levels still work fine, as does the extension if kidsonly is set to no. --McCormack 15:35, 10 March 2008 (UTC)

Hi..I was wondering if this issue was ever fixed? I have a main page which shows all of the subpages fine but when I try to insert the code in the subpages to continue to show the menu it ends up not displaying at all. Thanks --Demetelski 13:38, 8 April 2010 (UTC)

bug: list type not working when showparent=no or missing.

bug: list type not working when showparent=no or missing. it should work. It an important flaw especially that it does appear on simple usage (no parameters)

Bug fix: single line replacement

In SubPageList3.php (ver 1.05, revision 33881), replace

foreach( $titles as $title ) {
  $lv = substr_count($title, '/') - $parlv;	

with

foreach( $titles as $title ) {
  $lv = substr_count($title->getText(), '/') - $parlv;

Ivan Pepelnjak 10:41, 25 April 2008 (UTC)

Let me second this! This is indeed a bug and needs to be fixed.

Updating cache without disabling cache

I don't understand what brion means by "to correctly handle cache updates, uses on a page should be registered at links-update time, and creation/deletion of a subpage can trigger update jobs for registered pages." However I do have a suggestion on how it might be possible to achievable until a dependency table is created.

SubPageList3 could use a cache consisting of the name of every parent page to watch and the pages that want a listing; than using ArticleDeleteComplete and ArticleInsertComplete, check if the beginning of any page name (example "Foo/") created or deleted matches those of any parent pages (example "Foo") and purge there cache if they do.

The cache could look something like:

$SubPageListCache = array('Topic:Mathematics' => array('Portal:Mathematics', 'Department:Science and Math'), 'Manual:Hooks' => array('Manual:Hooks'));

where Topic:Mathematics and Manual:Hooks are the parent pages to watch out for with ArticleDeleteComplete and ArticleInsertComplete. If any pages are inserted or deleted under Topic:Mathematics/ then the caches of pages Portal:Mathematics and Department:Science_and_Math are purged. While if any pages under Manual:Hook/ would only cause the cache of Manual:Hook to be purged. --Darklama 18:12, 17 April 2008 (UTC)

sortby=created & limit

Ability to sort by article creation date (for news or announcements) and limiting the result (for example, I have about 100 announcements and I want to display only 10) would be very havesome.

Yes, that would be very nice addition, but revision table don't have created field. There's only last edit or smthng like that. --Ander 20:44, 12 May 2008 (UTC)

(RESOLVED) Dymanic Listing

I have read that this extension should now be creating it's list dynamically if the cache is disabled. My installation is not doing this. How do i check the cache setting?

→Found the setting! in file SubPageList3.php, edit about line 47 where it says:

# $parser->disableCache();

To:

$parser->disableCache();

Matt 13:37, 27 June 2008 (UTC)

List style parameter issue

The liststyle parameter does not seem to be working for me. All I see is a list of pages, each within a <p> tag. The bar option seems to be working as expected though. Any advice on this? --Tangled Kid 17:13, 18 June 2009 (UTC)

Skipped subpages

It doesn't recognize skipped subpages. So it should be:

• 1
  • Skip
    • 3

instead of

• 1
  • • Skip/3

But maybe this is to prevent creating pages using a slash? But then it should be

• 1
  • Skip/3

--Subfader 03:27, 6 July 2009 (UTC)

Redirected pages support

Similar the the skipped subpages support (see above), redirects should also be supported. With the tree A/B/C where B redirects to B2, the same behavior as a skipped pages occurs.

Thanks! -- Satri 14:56, 13 October 2009 (UTC)

Links to namespaced empty parents link to non-namespaced parents

If i have a namespace with a parent like ns:Parent1 and this parent has no children(It is setup so the users can create subpages when needed) the created link is wrong. e.g.

<splist
  parent=syslog:bng
  sort=asc
  sortby=title
  liststyle=unordered
  showpath=no
  kidsonly=no
  debug=0
  showparent=no

 />

You would expect is to generate a link to [[syslog:bng]], however the link is created as [[bng]]. The wrong page. I'm using v1.05 and the link works correctly when the parent has children. I've worked around this issue as follows(gnu diff)(i'm not a php devver or programmer for that matter, so it's probably ugly):

user@wikihost:~/w/extensions/SubPageList3$ diff SubPageList3.php.old SubPageList3.php
345c345
<                       $plink = "[[". $this->parent . "]]";
---
>                       $plink = "[[". $this->namespace . ":" . $this->parent . "]]"; //Hacked namespace into this, otherwise pages in a namespace without subpages would be shown as a link to a non-namespaced page. [[This]] instead of [[namespace:This]

bug : variable name conflict with LdapAuthentication

In some cases, LdapAuthentication cannot load because SubpageList3 is using the global variable $dir.

To fix this issue, in the file "SubpageList3.php" modify :

$dir = dirname(__FILE__) . '/';
$wgExtensionMessagesFiles['SubPageList3'] = $dir . 'SubPageList3.i18n.php';

to this :

$wgExtensionMessagesFiles['SubPageList3'] = dirname(__FILE__) . '/SubPageList3.i18n.php';

Omitting specific subpages?

is it possible to omitt some special pages? I do not want to get the pages User:Username/monobook.js and User:Unsername/monobook.css to be displayed in a dynamic list of Subpages in the User-Namespace.

thanks in advance
regards --TurboKanne 14:55, 16 September 2009 (UTC)

BUG: Non-default sort options ignore page/subpage associations

Using sort=desc and/or sortby=lastedit causes subpages to become shuffled around under (potentially) the wrong parent pages. For instance, this usage:

<splist parent=User:CarLuva/SubPageList3Demo sort=asc />

correctly results in the following sort:

• Apple
  • Granny Smith
  • Red Delicious
• Orange

However, this usage:

<splist parent=User:CarLuva/SubPageList3Demo sort=desc />

which should result in this output:

• Orange
• Apple
  • Red Delicious
  • Granny Smith

instead results in this output:

• Orange
  • Red Delicious
  • Granny Smith
• Apple

CarLuva 14:12, 22 October 2009 (UTC)

Category listing in alphabetical order

All the childs of one article, if in the same category, get listed under the same letter in the category listing. See Mediawiki Category:Strategy Task Force for an example of this behaviour.

As example, if we have:

• article/foo
• article/bar
• article/whatever

all in the same category, they will all 3 be listed under the letter a (for article) like:

• A
  • article/foo
  • article/bar
  • article/whatever

Instead of being seen under the letters f (foo), b (bar) and w (whatever). This tends to render the category classification useless when there is a lot of childs belonging to the same category and parent: all the articles get under the letter starting the parent's article name.

Does anyone have a solution to fix that?

Miguel Tremblay 18:13, 5 May 2010 (UTC)

Bug in Parsing Magic Words/Subpage Detection After

Hi,

I hope I've got the right place to report this -- I wasn't sure if it was better to email the developers directly or post here, so I chose the latter. I administrate a mediawiki based wiki, and have tried to set up a template that lets users paste one call to the template to put in splist code. Unfortunately, the parsing of parent="Extension talk:SubPageList3" consistently results in no results, even though the parent page does have subpages. SubPageList3 should parse this instruction and then process the subpages of that result. --Awils1 14:14, 6 December 2010 (UTC)

Mediawiki 1.17.0 - formatting problem

Here's what the page source looks like for unordered (and ordered, just different elements) lists.

<div class="subpagelist">* <a href="/wiki/Foo/Bar" title="Foo/Bar">Bar</a> 
<ul><li> <a href="/wiki/Foo/Baz" title="Foo/Baz">Baz</a> 

'Bar' in this case should be the first element of the list, but it ends up in the DIV. As a result the list gets rendered incorrectly.

Orphaned Pages and <splist />

I am editing this because I just realized my first assumption was incorrect!

Here's the REAL deal:

Seems if you import from another installation that used this extension that pages will appear as Orphaned until you re-save them manually.

BUG: Displayed subpage limit counted incorrectly when using kidsonly

The 200 displayed subpage limit behaves incorrectly when using the kidsonly option. The running count of subpages is calculated based on the number of matched subpages even if they are not direct descendants of the parent page. When more than 200 subpages at any level below the parent match, the resulting list will be missing entries.

Switching the order of two lines in SubPageList3.php fixes this.

477: }
478: $c++;

becomes

477:     $c++;
478: }

This way, only subpages that are going to be displayed will increase the counter towards the limit.

BUG: Compatibility with Mediawiki 1.26

Hello there! I have been using SubPageList3 for the longest time. However after upgrading Php from 5.2 to 5.6 and Mediawiki to 1.26 noticed a few error messages, see below. I am no php expert, and can't solve them all. Seems like this version is not 100% compatible with latest Mediawiki anymore. Which is a shame. Following are the error messages, related code lines and ways I found to fix the issues:

Message 1:

Fatal error: Call to undefined function wfLoadExtensionMessages() in /extensions/SubPageList3/SubPageList3.php on line 45

Code:

wfLoadExtensionMessages('SubPageList3');

Fix:

function wfLoadExtensionMessages(){ }

Explanation:

Add the line in Fix to your LocalSettings.php at the very bottom. The function is no longer required and supported by latest Mediawiki versions, therefore we create an empty shell. We could also edit the extension code and remove all references there, but I find this more elegant. After fixing this issue like so, the next error message appears

Message 2:

Fatal error: Call to undefined method Title::userCanRead() in /extensions/SubPageList3/SubPageList3.php on line 377

Code:

if ( $this->ptitle instanceof Title && $this->ptitle->exists() && $this->ptitle->userCanRead() ) {

Fix:

if ( $this->ptitle instanceof Title && $this->ptitle->exists() ) {

Explanation:

Found no other quick solution than to remove the check alltogether. Not sure what it prevented. This I wanted to test, but then message 3 appears

Message 3:

Fatal error: Call to undefined method DatabaseMysqli::escapeLike() in /extensions/SubPageList3/SubPageList3.php on line 396

Code:

$conditions[] = '`page_title` LIKE ' . $dbr->addQuotes( $dbr->escapeLike($parent) . '/%' );

Fix:

?

Explanation:

At this point I give up. It seems like SQL commands are created dynamically. Not sure why this method is not available anymore. Will have to remove the extension until future debugging has concluded.

Looking forward to your input. Would welcome a new version of the extension. However seems unlikely given the date of the last released version. Looking into Extension:SubPageList now, which had more recent updates. --Kebap (talk) 20:22, 18 November 2016 (UTC)

How can I use a template variable as data for a parameter?

I'd like to write something like this:

<splist
  parent={{{1}}}
  showparent=no
  showpath=no
  kidsonly=yes
  liststyle=bar
  debug=1
/>

Apparently this does not work: The data is not filled into parent as one would expect.

How can I include <splist> with dynamic data?

Compatibility with DisplayTitle

The old SubPageList extension works good with Display_Title and templates (in MW 1.35). Below is an example:

  {{DISPLAYTITLE:My Display Title}}
  {{MyTemplate|<subpages pathstyle=full />}}

where "MyTemplate" is defined like:

  {|align="right" style="width: 40%;"
  |-
  ||
  ||
  |-
  |style="background-color: white;"|
  |style="background-color: white;"|
  {| class="cmbox" style="border: 2px; border-style: solid; border-color: #00a9e0; vertical-align: middle;"
  | colspan="2" style="font-color: red" |This page contains the following subpages:
  |-
  | class="cmbox-image" style="background-color: white;vertical-align: top; width: 70px" |[[File:tree.png|none|link=]]
  | class="cmbox-text" style="background-color: white" |{{{1}}}
  |}
  |}

SubPageList should be backward compatible with the SubPageList3, but when attempt to use this configuration

  {{DISPLAYTITLE:My Display Title}}
  {{MyTemplate|<splist>
    showparent=no
    showpath=full
    kidsonly=yes
    </splist>}}

the display titles won't be displayed, but the page names. Aren't they compatible?

Not using current page for page list

Hello,

When placing this extension on a nested subpage, it still pulls from the top subpage.

Page structure with the current page being "Customer Integration": /wiki/Information_Technology/Integration/Customer_Integration

I've tried the below, I've tried setting the Parent tag to the current page manually with the same results.
<splist sort=asc sortby=title kidsonly=no /><br>

What I receive no matter what I do is the below with all being selectable links... except for the page I am currently on, Customer_Integration.

>Integration

>Customer Integration
 >Internal
  >Custom Processors

Any ideas what I'm missing to have this properly work from the nested subpage and below instead of using the higher subpage?

Edit to make the file tree collapsible

I use this extension to print a complete menu of all the subpages of my wiki. But since I have hundreds of subpages, this is quite unreadable. So I implemented an additional argument to the `list` parameter, `collapsible`, that works as an unordered list, except that every page that has children is collapsible, and collapsed by default.

The edited extension can be found bellow, but also made a diff (containing only the edits I made) in a separate file. There also is an example where I implemented (on my own wiki, you'll also find the CSS there).

• Modified extension: http://testudine.fr/MediaWikiExtensions/
• Differences only: http://testudine.fr/MediaWikiExtensions/SubPageList3-Collapsible edit by SenuaChloe DIFF/
• Example: http://wiki.magnuscodex.net/index.php?title=JdR:La_Couleur_des_Roses

SenuaChloe (talk) 22:03, 2 December 2023 (UTC)