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   to save about 500 lines of PHP! Here's an attempt to answer: 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).
 * 1) The prefixindex special page cannot do bullets.
 * 2) The prefixindex special page cannot do inheritance indents (like a tree).
 * 3) The prefixindex special page cannot do a horizontal bar menu.
 * 4) The prefixindex special page cannot do something like the "kidsonly" option (i.e. show children but not grandchildren).
 * 5) 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.
 * 6) I can't get Splarka's transclusion code to exclude the paths (i.e. option of just having the final name without the path).
 * 7) Probably a few other things too.
 * --McCormack 12:03, 26 February 2008 (UTC)

Further comment: if   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 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 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 tags into articles and getting rather counter-intuitive results; in response to this: such uses of the 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:  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)

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= ) 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:

Kidsonly In a Subpage
I get the following error when I put  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 --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)

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:

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 &lt;p&gt; 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: instead of But maybe this is to prevent creating pages using a slash? But then it should be --Subfader 03:27, 6 July 2009 (UTC)
 * 1
 * Skip
 * 3
 * 1
 * Skip/3
 * 1
 * Skip/3

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. 

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:



correctly results in the following sort:


 * Apple
 * Granny Smith
 * Red Delicious
 * Orange

However, this usage:



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)