Extension talk:SubPageList3

From MediaWiki.org

[edit] 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 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.

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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] (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)