Extension talk:Header Tabs

Old messages from this page are archived.

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

When you print a page that uses header tabs, it only prints the tab that is selected.

Is there some simple CSS that one can add to Print.css that will print all tabs?

Revansx (talk) 00:30, 8 April 2021 (UTC)

Ever since we upgraded to MW1.35 it sometimes happens that opening a page that uses multiple headers fails to load properly.

Everything is on the page and the tabs are also on top but all the page content is shown below the first header. The tabs do not work.

When you go back one page and click on the link again or use F5 the page loads normally and after that it seems to keep working until time X has passed.

I get the fault Exception in module-execute in module ext.headertabs (see screenshot) and I tried to figure out what is going on but I am not sure where to look first.

Can someone please push me in the right direction :-)

Nice work getting that screenshot ready for public viewing! Are you using the latest version of Header Tabs? Also, I would recommend adding "?debug=true" (or "&debug=true") to the URL, then reloading until the error happens - the error message in the console may be more helpful.

Well it is not up to me, it is our company wiki :-)

I tried lots of times with the links and adding ?debug=true but it does not want to fail.

Then it happened when using &action=purge. On some pages we use a link with &action=purge to force a Sematic update.

The below code was in de Console, maybe this helps. I will try tomorrow with the debug option and dig some more.

POSThttp://internalwiki.blabla.com/internalwiki/index.php?title=Somepage&action=purge
[HTTP/1.1 302 Found 1227ms]

GEThttp://internalwiki.blabla.com/wiki/Somepage
[HTTP/1.1 200 OK 6804ms]

This page uses the non standard property “zoom”. Consider using calc() in the relevant property values, or using “transform” along with “transform-origin: 0 0”. Somepage
GEThttp://internalwiki.blabla.com/internalwiki/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector
[HTTP/1.1 200 OK 0ms]

GEThttp://internalwiki.blabla.com/internalwiki/load.php?lang=en&modules=ext.jquery.async%7Cext.libs.tippy%7Cext.smw%7Cext.smw.purge%2Ctooltips%7Csmw.entityexaminer%2Ctippy&skin=vector&version=1gv35
[HTTP/1.1 200 OK 0ms]

GEThttp://internalwiki.blabla.com/internalwiki/load.php?lang=en&modules=ext.headertabs%7Cext.pageforms.autoedit%7Cjquery%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Cjquery.client%2CmakeCollapsible%2Ctablesorter%7Cmediawiki.String%2CTitle%2Capi%2Cbase%2Ccldr%2CjqueryMsg%2Clanguage%2Cutil%7Cmediawiki.language.months%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.page.watch.ajax%7Coojs-ui-core.icons%2Cstyles%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.indicators%7Cskins.vector.legacy.js%7Cuser.defaults&skin=vector&version=1yorw
[HTTP/1.1 200 OK 0ms]

JQMIGRATE: Migrate is installed with logging active, version 3.1.0 load.php:147:171
Exception in module-execute in module ext.headertabs: load.php:2:530
TypeError: items[i].toggle is not a function
    updateHiddenState jQuery
load.php:2:567
GEThttp://internalwiki.blabla.com/internalwiki/logos/internalwiki.ico
[HTTP/1.1 200 OK 0ms]

GEThttp://internalwiki.blabla.com/internalwiki/resources/src/mediawiki.skinning/images/magnify-clip-ltr.svg?8330e
[HTTP/1.1 200 OK 0ms]

Okay - it's not surprising that this error message does not show up in debug mode. It sounds like a timing problem (some JS is getting called before it is defined), and the timing is quite different in debug mode. What version of Header Tabs are you running?

I updated the all extensions early December 2020, Header Tabs has version: 2.0 (adfd26a)

Wiki config:

Product	Version
MediaWiki	1.35.0
PHP	7.3.23 (cgi-fcgi)
MariaDB	10.4.11-MariaDB
ICU	64.2
Elasticsearch	6.5.4

Alright. My guess is that the Header Tabs lack of display is a symptom of a problem with some other extension or skin... that error message, "items[i].toggle is not a function", doesn't seem to relate to anything in the Header Tabs code. Actually, I have no idea what that is coming from. If you create a wiki page with just tabs, or just tabs and text, do the tabs ever fail to load?

Okay maybe this helps, I can reproduce the fault on our TestWiki by purging a page with ?action=purge.

Then I disabled all extensions one at a time until I found out that when disabling the Page Forms extension the page loads normally and I can not reproduce the fault anymore.

I have done this several times, disabling and enabling Page Forms and the fault can only be reproduced when Page Forms and Headertabs are both enabled.

I tried to do the same on the SMW Sandbox Page but I only managed to reproduce this a couple of times. See screenshots below.

I just tried it again by pressing purge page on https://sandbox.semantic-mediawiki.org/wiki/Utilisateur:Jongfeli and it failed again.

It seems that somehow after "X" time a purge page can results in this fault.

Okay, today I updated both Headertabs and Page Forms to Master and suddenly it does not matter if Page Forms is enabled or not, the fault always appears.

To make a long story short, Page Forms has "nothing" to do with it (but I am not sure about this).

When you use Page Forms Master and Headertabs release 1_35 it works just fine.

The page now reports This page is using the deprecated ResourceLoader module "jquery.ui". Please use OOUI instead. but it works just fine.

I assume the move in Headertabs from jquery.ui to OOUI is somehow causing this problem after a page has been purged with &action=purge.

Maybe it has something to do with the fact that a &action=purge is now done with POST that needs to be confirmed.

I did find the items[i].toggle in the below js script.

For now the 1_35 version of Headertabs fixes the problem with an added bonus, we have our familiar blue tabs back :-)

    OO.ui.StackLayout.prototype.updateHiddenState = function (items, selectedItem) {
      var i,
      len;
      if (!this.continuous) {
        for (i = 0, len = items.length; i < len; i++) {
          if (!selectedItem || selectedItem !== items[i]) {
            items[i].toggle(false);
            items[i].$element.attr('aria-hidden', 'true');
          }
        }
        if (selectedItem) {
          selectedItem.toggle(true);
          selectedItem.$element.removeAttr('aria-hidden');
        }
      }
    };

Thank you for investigating this - including finding that part of the JavaScript code. All of what you're saying makes sense, but I can't reproduce the problem, with MW 1.35 and the latest Header Tabs code. Does this happen for you with every page that uses Header Tabs - even a very simple one?

No it does not happen on every page, only on pages with multiple tabs (6 to 12) which contain SMW queries.

They take relatively long to load +/- 5 to 10 seconds. Like the example on the SMW sandbox.

See: https://sandbox.semantic-mediawiki.org/wiki/Utilisateur:Jongfeli

On the SMW sandbox site it only happens sometimes, not every time you purge a page. So there is definitely something going on.

I will test some more in the SMW sandbox, maybe we can get it to fail all the time.

I doubt that you can ever get some page to fail all the time, since this sounds like a timing-related issue. I wonder, though, if you can figure out what the simplest page is that will sometimes fail. Are SMW queries always required, for example?

I do not know if SMW queries are required, I do not think so. like you said it has probably something to do with timing.

Today I tried to figure out what the difference is between pages that work and pages that don't.

I thought I found it when I noticed there where UseCDNCache: "false" codes in the cookie request when it worked and not when it failed.

Maybe it has something to do with it but I am not sure, it was introduced in MW-1.34 see: Manual:$wgUseCdn

The only thing that really helped was disabling the HTTP cache in the Firefox debug mode, then it always loads correctly (but takes forever).

This would suggest there is sometimes something wrong with caching or cookies.

tried version 2.0 for the first time om MW 1.31 and get this error

[X@CRKp0hUbgJtA6mJBGcLAAAAA8] /User:Admin Error from line 239 of ..extensions/HeaderTabs/includes/HeaderTabs.php: Class 'OOUI\TabPanelLayout' not found

Backtrace:

#0 ../extensions/HeaderTabs/includes/HeaderTabsHooks.php(47): HeaderTabs::replaceFirstLevelHeaders(Parser, string, array)

#1 ..includes/Hooks.php(177): HeaderTabsHooks::replaceFirstLevelHeaders(Parser, string)

#2 ../includes/Hooks.php(205): Hooks::callHook(string, array, array, NULL)

#3 ../includes/parser/Parser.php(1428): Hooks::run(string, array)

#4 ../includes/parser/Parser.php(446): Parser->internalParseHalfParsed(string, boolean, boolean)

#5 ../includes/content/WikitextContent.php(323): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer)

#6 ../includes/content/AbstractContent.php(516): WikitextContent->fillParserOutput(Title, integer, ParserOptions, boolean, ParserOutput)

#7 ../includes/poolcounter/PoolWorkArticleView.php(144): AbstractContent->getParserOutput(Title, integer, ParserOptions)

#8 ../includes/poolcounter/PoolCounterWork.php(123): PoolWorkArticleView->doWork()

#9 ../includes/page/Article.php(604): PoolCounterWork->execute()

#10 ../includes/actions/ViewAction.php(68): Article->view()

#11 ../includes/MediaWiki.php(500): ViewAction->show()

#12 ../includes/MediaWiki.php(294): MediaWiki->performAction(Article, Title)

#13 ../includes/MediaWiki.php(818): MediaWiki->performRequest()

#14 ../includes/MediaWiki.php(524): MediaWiki->main()

#15 ../index.php(42): MediaWiki->run()

#16 {main}

Yes, version 2.0 only supports MediaWiki 1.33 and higher, unfortunately.

MediaWiki 1.35.0, HeaderTabs 2.0

Solution : change that in HeaderTabs\includes\HeaderTabs.php

133 		$s = 0;
134 
135 		$titleCount= array() ;

183                 $tocparser = clone $parser;
184 				$tabtocraw = $tocparser->internalParse( $content );
185 				$tocpattern = '%<div id="toc" class="toc" role="navigation" aria-labelledby="mw-toc-heading"><input type="checkbox" role="button" id="toctogglecheckbox" class="toctogglecheckbox" style="display:none"/><div class="toctitle" lang=".+?" dir="ltr"><h2 id="mw-toc-heading">.+?</h2><span class="toctogglespan"><label class="toctogglelabel" for="toctogglecheckbox"></label></span></div>' . "\n+" . '(<ul>' . "\n+" . '.+?</ul>)' . "\n+" . '</div>' . "\n+" . '%ms';
186 				if ( preg_match( $tocpattern, $tabtocraw, $tabtocmatches ) === 1 ) {
187 					wfDebugLog( 'headertabs', __METHOD__ . ': generated toc for tab' );
188 					$tabtocraw = $tabtocmatches[0];
189 					$tabtoc = $tabtocraw;
190 
191 					if ($parser->mOptions->getNumberHeadings () == true) {             
192 						$itempattern = '/<li class="toclevel-[0-9]+"><a href="(#[^"]+)"><span class="tocnumber">[0-9.]+<\/span> <span class="toctext">(<span><span>[0-9.]+<\/span>([^<]+)<\/span>[^<]+)<\/span><\/a>/';                   
193 					} else {
194 						$itempattern = '/<li class="toclevel-[0-9]+"><a href="(#[^"]+)"><span class="tocnumber">[0-9.]+<\/span> <span class="toctext">(<span>([^<]+)<\/span>[^<]+)<\/span><\/a>/';   
195 					}
196 
197 					if ( preg_match_all( $itempattern, $tabtocraw, $tabtocitemmatches, PREG_SET_ORDER ) > 0 ) {
198 						foreach ( $tabtocitemmatches as $match ) {
199 							$newitem = $match[0];
200 							if ( count( $matches ) == 4 ) {
201 								$titleLink = str_replace("&#160;", "_", trim( $match[3] )); // remplacement des espaces insécables
202 								$titleLink = '#' .str_replace(" ", "_", $titleLink );
203 								if (array_key_exists($titleLink, $titleCount)) { 
204 									$titleCount[$titleLink] = $titleCount[$titleLink] + 1;
205 									$titleLink = $titleLink . "_" . $titleCount[$titleLink];
206 								} else {
207 									$titleCount[$titleLink] = 1;
208 								}
209 								$newitem = str_replace( $match[1], $titleLink, $newitem );
210 								$newitem = str_replace( $match[2], trim( $match[3] ), $newitem );
211 							}
212 							$tabtoc = str_replace( $match[0], $newitem, $tabtoc );
213 						}
214 						$content = $tabtoc . $content;
215 					}
216 				}

MediaWiki 1.35.0, HeaderTabs 2.0

Solution : change this in HeaderTabs\includes\HeaderTabs.php

49 $tocpattern = '%<div id="toc" class="toc" role="navigation" aria-labelledby="mw-toc-heading"><input type="checkbox" role="button" id="toctogglecheckbox" class="toctogglecheckbox" style="display:none" /><div class="toctitle" lang=".+?" dir="ltr"><h2 id="mw-toc-heading">.+?</h2><span class="toctogglespan"><label class="toctogglelabel" for="toctogglecheckbox"></label></span></div>' . "\n+" . '(<ul>' . "\n+" . '.+?</ul>)' . "\n+" . '</div>' . "\n+" . '%ms';

MediaWiki 1.35.0, HeaderTabs 2.0

Problem preventing the page from displaying!

Call to undefined method Parser::formatHeadings()

Problem solved by commenting line 182 in HeaderTabs\includes\HeaderTabs.php

//$tabtocraw = $tocparser->formatHeadings( $content, '' );

Anyone to propose a better solution?

182 $tabtocraw = $tocparser->internalParse( $content );

MediaWiki 1.35.0, HeaderTabs 1.3

If I have a headertabs page where there there is a header title that is a superstring of another header title, when linking to the substring I actually navigate to the superstring tab.

Example page:

= Header Yellow =
This is section one.

= Another Header Red =
This is section two.

= Header Green =
This is section three.

= Header Red =
This is section four.

<headertabs/>

If I link to this page via Page Title#Header Red, it will actually take me to the "Another Header Red" tab.

With the old version of the Header Tabs. I could set links from other pages with bookmarks and it goes to that specific tab with the tab shown. This new version doesn't do that. The only way is to include "#tab=" and followed by bookmark.

But the thing is that I use Semantic Mediawiki subobjects to query for the links, and subobjects used hashtags which I also used as bookmarks to point to the proper tab or (no with tabs) location on the page. Is my only option is to try to manipulate the queries?

Setup

- MediaWiki 1.35.0-rc.2 (5f6c9d1) 17:32, 21 August 2020 - PHP 7.2.24-0ubuntu0.18.04.6 (apache2handler) - Header Tabs 2.0 (36e8e34) 19:30, 25 August 2020

Issue

PHP Notice:  Undefined index: HTTP_HOST in /../w/extensions/HeaderTabs/includes/HeaderTabs.php on line 227
Notice: Undefined index: HTTP_HOST in /../w/extensions/HeaderTabs/includes/HeaderTabs.php on line 227

PHP Notice:  Undefined index: REQUEST_URI in /../w/extensions/HeaderTabs/includes/HeaderTabs.php on line 230
Notice: Undefined index: REQUEST_URI in /../w/extensions/HeaderTabs/includes/HeaderTabs.php on line 230

MW 1.34.2, Header Tabs 1.2. Have a form with a template built out with Page Forms and Cargo. Installed Header Tabs. Tabs pop up but only the last tab shows the Form. It is a single Template and a single Form. I would like to split the Form into tabs. So, link here: https://digitalmatrixgroup.com/index.php/Form:Investor_Asset and here https://digitalmatrixgroup.com/index.php/Template:Investor_Asset. The example link listed in your Extension page does not allow viewing any code and looks like a regular web page. I put links to the photo examples here which document where I put the '=Tab=' info into the Form and I added the end "<headertabs/>" before the Standard sections: https://pasteboard.co/JoXbcZI.png ... https://pasteboard.co/JoXbV6F.png ... https://pasteboard.co/JoXc6C8.png ... I asked over on the IRC but no one really had a response. Thanks for your time!

You should upgrade to the latest version of Header Tabs, 2.0, if possible - it just came out a few weeks ago, and it improves in a few key ways on the previous version.

I have been trying to keep all extensions matching the Stable Version of MW I run, but I upgraded to v2.0 just now and no change. I ran the Purge and Purge Cache on the Form as well. Any other suggestions or points I might be missing? Thanks!

I just looked at the form - I think the issue is that you put the tabs inside a table. That won't work, I don't think - if you're going to have three tabs, you should have three separate tables, each one in its own tab.

Worked like a charm! Thank you very much! There is something different that happens now, though. The tab being used is colored white as opposed to light blue. Do not know if that is important and would be curious how to either change the color from white to "x" when it is active or statically. Regardless, thanks for taking the time to both look and answer and have a great day!

Great! Well, in v2.0 of Header Tabs, the underlying JS library being used changed from jQuery UI to OOUI - which is a MediaWiki-specific library. I don't know how to change any of the colors - I assume it can all be done with CSS. If you really prefer the older look, I guess you could just revert Header Tabs back to the older version - it should still work.

I'll stick with what is working now and delve into CSS down the road. Thanks again for the help!!!