Extension talk:SectionHide/Flow

Previous page history was archived for backup purposes at Extension talk:SectionHide/LQT Archive 1 on 2015-07-10.

can't upload an image yet, so my illustration will have to wait

(this comment was originally posted by Hoggle42 as wikitext in the header)

sorted now, and added to page. Tried adding it to the template but it's too large. Will put together a smaller one for that.

Is there a way to change the "show" and "hide" toggles to images (like arrows)? I've tried editing SectionHideHooks.php to remove the brackets (worked), and then SectionHide.i18n.php to replace the text with HTML img src links, but I'm not very good with PHP and JS: while the images do display, there's a bunch of garbled text around them, so I'm guessing there's something going on where I can't just insert images there that easily. I looked through SectionHideHooks.php and tried various things but nothing worked. Thanks!

I think the language files would need either a wiki code image link or an html image link - will have a play and work something out.

Done - had to change the javascript as the many layers of quotes mucks things up else.

Thank you SO MUCH!

I have noticed two odd things in MediaWiki 1.22...

• MediaWiki normally indents subsections slightly (at least with the Vector skin I am using) and I like this feature. With the extension installed, however, subsections are no longer indented, apparently because the divs have a new class name. I'm not sure if you can do much about this, but in case anyone else noticed the same thing, I fixed this by adding the following line to Common.css:

div.sectionblocks {padding-left: 20px}

You can adjust the px measurement to make the indentations bigger or smaller, of course.

• The extension is somehow inserting the following block of white space between headers (right before a new header), which is disorienting and looks bad:

Worse still, if you're moving from a lower-numbered header to a higher-numbered header -- e.g. you have an H2 header, then you have an H3 header -- then it inserts it twice before the higher-numbered header. Needless to say, that's quite a lot of blank space.

I... cannot for the life of me figure out how that's happening. I'm not great with PHP or JavaScript but nothing obvious in the extension code sticks out to me. If I disable the extension, that goes away. I am using the Vector skin.

Sorry, the page hangs when I try to edit the code... here is the white space that gets inserted:

<p><br />
</p>

I have also tested it with MonoBook and Modern skins, with the same result.

I figured it out! It's some instances of /n in SectionHideHooks.php.

I deleted them in lines 20 and 21, so that they read as follows:

$sectionContent = preg_replace( '/<\/h[2-6]>/', "$0$divstart", $sectionContent);
$sectionContent = $sectionContent."$divend";

I'm not sure what was intended with the /n in the original code, but I suspect most people would rather not have extra white space inserted that way, especially since it's relatively easy to use CSS to edit the padding of div.sectionblocks.

Anyway, THANK YOU SO MUCH FOR THIS EXTENSION. It does everything I want it to!

And now that's broken the nesting, i.e. H2 divs get closed before the H3 divs they contain are opened, so collapsing the H2 div only collapses the text up until the H3 header... So I'm guessing the \n is important somehow but I really cannot live with all that white space. I'll keep tinkering with it...

Okay, apparently the \n in this line are crucial to preserving the nesting:

$sectionContent = preg_replace( '/<\/h[2-6]>/', "$0\n$divstart\n", $sectionContent);

I got rid of a considerable amount of white space just by removing the \n around $divend but I would really, really like to not have the other whitespace as well... is there any way to get rid of it without breaking the nesting?

I'll have a look - I suspect it is the interaction between wiki code and parser but we'll see.

Resolved with version 1.5

The issue was the move from classname editsection to mw-editsection. I've also moved the link to after the edit link so it comes after the title too, and that allows me to use a single preg-replace operation.

I have also removed the editsection class name from the hide all link as that was causing it to indent.

I'm not sure why, but before the latest version the show/hide was displaying to the left of the header text for me (despite the extension screenshots showing it to the right), and I liked it that way: it seems less clunky and more intuitive there, especially now that I have a set of collapsible arrow images as a toggle. It looks a bit weird to have the arrow in a different place every header (depending on the length of the header text) and after the edit link for that section.

Is there a way I could move it back to the left side? Or maybe have it be an option? Thank you so much for all your work!

I moved it to after the edit link as that was the original place (monobook shifted it in the css, so the order was irrelevant), but I can add an option to have it before the title. Look out for version 1.6 :)

Version 1.6 as requested :)

I also gave the option to not have the square brackets, or replace them with something else.

It works perfectly! Thank you SO MUCH!

I discovered that having the sectionblock ID attribute in the close div tag can run into conflict with the parser, particularly with other extensions installed: Thread:Extension talk:Lingo/It's messing with HTML? It seems like the sort of thing that might come up in other contexts too.

I guessed that labeling the close div was probably important to the nesting though, and sure enough, changing $divend to just be a close div tag did break the nesting. If I have to choose an extension I'll choose SectionHide, but I did find this other approach using comments to label what div is being closed. I don't know if that would work for SectionHide since the attribute is actually functional and not a mere reminder, but I also don't know enough about extensions to know if you can scan for an HTML comment directly after a close div to get the same effect, so figured I would bring it up.

Thanks for all your hard work!

I use the id to correct the nesting, but I can just as well use a comment - working on a fix.

Version 1.7 - parser issue sorted, hopefully

You are amazing, it works perfectly! Thanks so much for all the prompt responses!

Given the changes to the section edit code for this release, this needs testing on the new edition. If anyone can do this and finds any issues, please report them here. I'll try to do the upgrade myself and do some testing too.

It seems to work fine on MW 1.22 so far.

The Orain wiki farm's All The Tropes wiki uses their own modified variant of Section Hide that also works well.

You can find it here:

https://allthetropes.orain.org/wiki/Main_Page

https://github.com/Orain/mediawiki-core/tree/REL1_22/extensions/SectionHide

popped on there - show/hide links don't appear to be working at the moment

Uncaught TypeError: Cannot read property 'style' of null

Not sure how the style property can be null (am using Chrome btw)

Looks fine to me in Firefox, but yeah, it does seem to be messed up badly in Chrome.

You'll want to contact Vorticity with a bug report (you can either leave that on the GitHub account, his talk page on ATT, his email, or the Tech Wishlist and Bug Reports forum board, your choice). Also, since I saw you've updated your code with some features the ATT fork doesn't have, maybe you guys can swap notes on dovetailing features from both into a unified codebase.

will have to learn github :( Am maintaining this the easy way atm as it only takes a minute, but time is nicked from other things and I won't get time to learn new systems in foreseeable future.

It would be nice if there were a way to disable the hide all and show all options. While I'm sure it's a useful feature for the people who need it, it seems like it would have limited utility for most wikis. For now, I have edited out the appropriate code because on my wiki there is no reason to hide an entire article: it just makes the page pretty much blank, and the toggle text looks out of place on the expanded page.

I'll look at adding a configuration option, but it would be global (not sure how to do it per user, and per article means adding a magic word, I think)

Have you changed

$wgSectionHideShowtop = 0; //default

to 1? - this makes the hideall feature keep anything above the first heading visible. It was added for someone who wanted the option to hide everything but I realise now it should default to 1. I can add another option to disable the feature completely, but this may be all you need.

added check for = 0 so now if you set the $wgSectionHideShowtop to -1 it will not show at all

I have tested this extension on both a production wiki running mw:Header Tabs and a localhost wiki, and when both are enabled, any page with header tabs will not render properly, which results in the headers near the bottom of the page not rendering properly and the text being grossly enlarged.

I suspect the root cause is the fact that both extensions alter section behavior, and the corruption of the data results from MediaWiki trying to make both extensions work at the same time.

I'm not sure how this error could be resolved, but given it only affects pages with the headertabs parser hooks, I would suggest introducing a condition that disables SectionHide if the Header tabs parser hook is detected on the page.

Otherwise, it seems these two extensions are completely incompatible at present.

I've added a test to throw an error - it's not practical to go fishing around in the article looking for the parser tag as these two extensions are never going to be compatible. They should be viewed as alternatives.

Given how they affect section behavior, that seems to be the best alternative. Thanks for your response.

As the title says, a show/hide all sections at once button would be a nice feature. Not sure where you would add it (right next to the page title or just under it towards the very right would be my first two ideas., but for pages where all someone wants to read is the very first section or wants to just see the introduction and the categories and doesn't want to have to scroll down very much, that would be a quite useful feature.

Also, while I'm not an expert on Javascript, I just tested this on MediaWiki 1.19 and it worked flawlessly, and given the rather simple hooks you've used, this extension looks very downward compatible.

Also, even if you don't want to use the Wikimedia Git Repository, it probably wouldn't hurt to put this extension on a free Github account in a downloadable zip file with the install instructions and the information needed for the MediaWiki:Common.js file.

I don't have anymore advice or suggestions at the moment, but I did want to say I believe that you are a genius, as I have long searched in vain for an extension that does what yours does, and to say I'm quite happy with it is a major understatement.

Thank you very much :)

A hide all should be quite simple to add to the parseafterparse hook function, wrapping the whole article in a <p><span><a javascript="toggle id zero">hideall</a></span></p><div id zero>[artile goes here]</div id zero>

It should be backwards compatible as far as the two hooks and various other standards go, but as I dev'd it on 1.21.1 to replace a version that no longer worked and was dev'd on 1.16 I didn't feel I could guarantee more.

I could do a zip file but found the introductory help on the gerrit site impenetrable and aimed at main code developers rather than extension writers. As I said I'm happy for anyone with more experience to transfer it to the source control system.

Once again, thank you for your endorsement! :)

hide all link added, pending changes

Just tested it, feature works beautifully.

I've been testing the extension on a localhost wiki and have found it extremely responsive. It may need further tweaking on a live website environment, though given the simplicity of the code, I doubt it.

However, I am also quite pleased to report that it has no compatibility problems with the mw-collapsible class in any way. I haven't tested it with all types of collapsible code yet, but I doubt there will be conflicts.

I am also pleased to report the code is very skin agnostic, and has worked in most of the basic skins included with MediaWiki, and even several custom skins.

My only possible suggestion is to see if tweaking the show/hide all button could hide all but the first section of page, since it currently hides everything but the page title and category bar at present. I'm not sure if this will work well, but the current version hides ALL levels of section headings (including the text between the title bar and first proper section heading), which may be overkill for some people.

You'd need to insert the id zero div alongside the id 1 div to keep the text before the first heading visible. I'll have a play and make it an option in version 1.2.

done, pending changes

There's a new global variable to set how many sections you want to keep - set it to 1 to hide everything from the first heading down. I'm not sure it should be set any higher, but it seems to work in Chrome.

I've been using Firefox, and it seems to be working fine for me as well.

However, could you show me exactly which lines I need to tweak to use the new variable?

in SectionHide.php - expanded instructions for localsettings.php

 * add the following line to localsettinge.php to use
 * require_once("$IP/extensions/SectionHide/SectionHide.php");
 * // Set this option to 1 to show the text before the first section when hiding all
 * // Set to X to show the top x-1 sections (use with caution - some browsers may complain)
 * $wgSectionHideShowtop = 0; //default

In SectionHideHooks.php

        public static function onParserAfterParse( &$parser, &$text, &$sstate )
                {
                global $wgSectionHideShowtop;
                // need to nest sections by levels by moving around the closing tags
                $numberofmatches = preg_match_all('#<h[2-6].*<\/h[2-6]>\n<div class="sectionblocks"#', $text, $matches, PREG_OFFSET_CAPTURE);
                $closingdivmatches = preg_match_all('#<\/div id=#', $text, $divmatches, PREG_OFFSET_CAPTURE);

                if($numberofmatches == $closingdivmatches && $numberofmatches > 1)
                        {
                        if( $wgSectionHideShowtop > $numberofmatches) $wgSectionHideShowtop = $numberofmatches; // cannot exceed the number of matches
                        $headlevel = array();

and

                        // new hide all link
                        if ( $wgSectionHideShowtop > 0 )
                                {
                                // insert a section zero opening div before the first section heading
                                $text = insertAtLoc($text, '<div class="sectionblocks" id="sectionblock0">', $matches[0][($wgSectionHideShowtop-1)][1]);
                                $text = '<p><span class="editsection visibilitytoggle">[<a href="#" onclick="toggleSectionVisibility(this, 0,'."'"
                                        .wfMsg( 'sectionhide-showall' )."','".wfMsg( 'sectionhide-hideall' )."'".')">'.wfMsg( 'sectionhide-hideall' )
                                        .'</a>]</span></p>'
                                        .$text
                                        .'</div id="sectionblock0">';
                                }
                            else
                                {
                                $text = '<p><span class="editsection visibilitytoggle">[<a href="#" onclick="toggleSectionVisibility(this, 0,'."'"
                                        .wfMsg( 'sectionhide-showall' )."','".wfMsg( 'sectionhide-hideall' )."'".')">'.wfMsg( 'sectionhide-hideall' )
                                        .'</a>]</span></p><div class="sectionblocks" id="sectionblock0">'
                                        .$text
                                        .'</div id="sectionblock0">';
                                }
                        }
                return true;

or use the history diff

....derp, now I see what you mean.

Sorry, my brain was half asleep when you informed me of the updated global variable.

Just tested the new variable, runs beautifully in Firefox (exactly how I envisioned it working too!), was planning to test it in IE and Chrome, will get back to you if I find any anomalies.

I've followed the instructions exactly to get this extension working, and while I do see the "hide" links next to each section on my pages, clicking on them doesn't seem to do anything.

I'm running MW 1.21.1, have attempted to disable any extensions (this didn't fix anything), and have made sure I added the JS code to my MediaWiki:Common.js.

Can you check the javascript console to see if an error is generated on page load or when you click the link?

Also, which browser and version are you using as that may have an impact.

Got it fixed, turns out I was missing a ";" on a line on my MediaWiki:Common.js file.

curse you C-derived languages!!!! ;)