Jump to content

Extension talk:Header Tabs/Archive 2

About this board

Old messages from this page are archived.


OO.ui error with MW1.42.3 and recent extensions

4
Lalquier (talkcontribs)

Hi. I m rebuilding a wiki from scratch with recent versions of everything. I currently have MW1.42.3 as a base, with the latest SMW and Page Forms, and now looking at installing Headertabs for compatibility with imported pages. The 1.42 branch of Headertabs is giving me this error. Any idea what could be causing it? I didn't see any particular requirements on the page.

Uncaught Error: Widget not found
    at mw.loader.impl.OO.ui.Element.static.unsafeInfuse (oojs-ui-core.js:741:9)
    at mw.loader.impl.OO.ui.Element.static.infuse (oojs-ui-core.js:709:35)
    at mw.loader.impl.OO.ui.infuse (oojs-ui-core.js:336:30)
    at HTMLDocument.eval (ext.headertabs.core.js:30:20)
    at mightThrow (jquery.js:3489:29)
    at jquery.js:3557:12
Yaron Koren (talkcontribs)

That error message doesn't look familiar, but I would definitely recommend using the master version of Header Tabs and not the REL1_42 version - as far as I know, the REL1_42 branch doesn't work with MW 1.42, because the fixes only came later.

Lalquier (talkcontribs)

Thanks! Using the master version fixed that error.

Yaron Koren (talkcontribs)

Great!

Reply to "OO.ui error with MW1.42.3 and recent extensions"

Header Tabs sometime fails to load

35
Jongfeli (talkcontribs)

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

Yaron Koren (talkcontribs)

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.

Jongfeli (talkcontribs)

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]
Yaron Koren (talkcontribs)

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?

Jongfeli (talkcontribs)

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
Yaron Koren (talkcontribs)

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?

Jongfeli (talkcontribs)

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.

Jongfeli (talkcontribs)

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');
        }
      }
    };
Yaron Koren (talkcontribs)

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?

Jongfeli (talkcontribs)

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.

Yaron Koren (talkcontribs)

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?

Jongfeli (talkcontribs)

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.

Revansx (talkcontribs)

@Jongfeli - Where did you land on this? I am experiencing it too.

Jongfeli (talkcontribs)

Hello @Revansx. We reverted back to an older version of Header Tabs with the old style tabs not using OOUI.

But also this older version does not work correctly all the time and sometimes only loads the first tab but it does not break the page like the more recent versions and as shown in the screenshot above. This is on MW 1.35.6 I am not sure which version this is, it says 1.3 but that is probably not correct.

I did not investigate any further but the problem is probably still there when using master.

Are you using SMW as well?

Revansx (talkcontribs)

Hi @Jongfeli, thanks for responding. Sounds like we're in the same boat. Yes, I use SMW as well. The HeaderTabs mainatiners don't seem to be able to reproduce this problem and so it has been suggested that this issue may only manifest when HeaderTabs is used with some other extension (maybe SMW, but we can't actually say which until we can reliably re-produce the problem) .. That said it seems clear that the problem has not been solved.

When it does glitch, it doesn't seem to produce any errors or diagnostic info, so my my new strategy is to seek help from the HeaderTab developers for help in adding some debugging tools in the extension. I'll provide an update here if I am able to make any progress on this problem. Please do likewise. Cheers!

Jongfeli (talkcontribs)

Unfortunately the SMW sandbox site is still down. I was able to reproduce it there to.

Revansx (talkcontribs)
Revansx (talkcontribs)
Revansx (talkcontribs)

For MW 1.34.x + HeaderTabs 1.3 + SMW 3.2.3, we were finally able to solve the HeaderTabs issue where the header tabs don't always load. To do so we had modified: /opt/htdocs/mediawiki/extensions/HeaderTabs/HeaderTabs.hooks.php from:

     85                 $resourceLoader->register( [
     86                         "ext.headertabs" => [
     87                                 'localBasePath' => $htDir,
     88                                 'remoteExtPath' => 'HeaderTabs',
     89                                 "scripts" => "skins/ext.headertabs.core.js",
     90                                 "dependencies" => [
     91                                         $jquiTabsModule
     92                                 ]
     93                         ]
     94                 ] );

to

     85                 $resourceLoader->register( [
     86                         "ext.headertabs" => [
     87                                 'localBasePath' => $htDir,
     88                                 'remoteExtPath' => 'HeaderTabs',
     89                                 "scripts" => "skins/ext.headertabs.core.js",
     90                                 "dependencies" => [
     91                                         $jquiTabsModule,
     92                                         "ext.smw.tooltips",
     93                                         "ext.smw.style"
     94                                 ]
     95                         ]
     96                 ] );

specifically we added the SMW resources "ext.smw.tooltips" and "ext.smw.style" as dependencies for Headertabs and that seems to have solved the issue. (fingers crossed)

Fgneba (talkcontribs)

@Revansx does this solution still work for you? I tried and on some pages, HeaderTabs still breaks. In the pages where it breaks, I inspected the page source and realized that the CSS modules for headerTabs does not load on those pages. In particular, this link tag is missing:

<link rel="stylesheet" href="/mediawiki/load.php?lang=en&amp;amp;modules=ext.headertabs.styles%7Cjquery.tablesorter.styles%7Cmediawiki.widgets.styles%7Coojs-ui-core.icons%2Cstyles%7Coojs-ui.styles.indicators%7Cskins.vector.styles.legacy&amp;amp;only=styles&amp;amp;skin=vector">

Krabina (talkcontribs)

We are also running in this problem. Was there in MW 1.31 and is still there in MW 1.35. On arbitrary pages, eg. https://www.geschichtewiki.wien.gv.at/Hofball you should no be able to see the QR code on the right, it should bin in the HeaderTab. Reoloading loads the page just fine. It does not have anything to do with the QRLite extension.

Jongfeli (talkcontribs)

Okay I just want to write this down so I don't forget and in the hope that others will recognize this.

We still have the above problem after upgrading MW and all extensions (MW-1.39.5 / PHP 8.1.24) but we have noticed a couple of things:

  • It is only a real problem when working from home via a (slower) VPN connection compared to a wired office workplace.
  • It "only" happens when using Firefox. Chrome and Edge do not seem to be affected by it.
  • It happens mostly on "heavy" pages that take longer to load because of bigger result sets for SMW and Externaldata queries.
  • When requesting the page again with CTRL-F5, bypassing browser cache it loads just fine.

I can click around in Chrome and Edge but the problem never pops up. In Firefox it is very easy to break the header tabs. So it seems that Firefox is handling what to load when from cache differently then Chrome or Egde. The result, when I am correct, is that the JavaScript libraries are not loaded yet when the tabs are being generated.

JeremiPlazas (talkcontribs)

Hi there, Wanted to add my two cents as we have been struggling with this exact issue for years now. We have just upgraded to 1.39.x with HeaderTabs 2.2.2. We use SMW but not on all tabs. We are currently experiencing this issue. I'm seeing it in chrome regularly so i know it's not a browser issue, but it does seem related to cache. I've noticed that having the Dev tools open in chrome will usually not cause the issue (with or without "disble cache" checked ¯\_(ツ)_/¯ ). When the tabs fail to load properly I have the following error in console:

Exception in module-execute in module ext.headertabs:
load.php?lang=en&modules=startup&only=scripts&raw=1&skin=timeless:1 Error: Widget not found
    at OO.ui.Element.static.unsafeInfuse (load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=timeless&version=1d5er:151:780)
    at OO.ui.Element.static.infuse (load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=timeless&version=1d5er:151:545)
    at OO.ui.infuse (load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=timeless&version=1d5er:148:16)
    at <anonymous>:362:19039
    at mw.loader.implement.css (<anonymous>:364:617)
    at runScript (load.php?lang=en&modules=startup&only=scripts&raw=1&skin=timeless:11:983)
    at Array.<anonymous> (load.php?lang=en&modules=startup&only=scripts&raw=1&skin=timeless:12:948)
    at flushCssBuffer (load.php?lang=en&modules=startup&only=scripts&raw=1&skin=timeless:4:956)

So, yeah, it's still happening! We have the issue on many of our wikis, different skins, lots of different extensions. Hope this helps at all...

JeremiPlazas (talkcontribs)

Another point, maybe an observation that's already been tested. I made a simple page with ONLY tabs and plain text. No issue, ever. I added ONE SMW #show function on one of the tabs. After a couple of page reloads the issue appeared. SMW x HeaderTabs = SometimesTab?

The sad thing is that when we were on 1.35 with HT 2.2, the issue had disappeared for a while. It's only after upgrade to 1.39 that it came back for us.

JeremiPlazas (talkcontribs)

We've been investigating this issue some more with our IT director and we noticed a few more things that are definitely of interest:

  • The issue goes away when dev tools are open in Chrome and the cache is disabled.
  • A similar issue happens with large forms made with PageForms, where the form does not fully load, the loading spinner gets stuck, but the issue also goes away when dev tools are open in Chrome and the cache is disabled.
  • A similar issue happens with this embedded code we have for a Benchmark mailing list, where it gets loaded outside of the dom, at the bottom of the page. This issue also goes away when the dev tools are open in Chrome and the cache is disabled.
  • Looking more closely at HeaderTabs specifically, we noticed that putting a timeout function of 500ms around the call for OO.ui.infuse right at the top of ext.headertabs.core.js ALSO fixes the issue.

CONCLUSION: Something is going on with loading time/order. Is there a away to make sure the tabs are infused into the DOM after oo.ui has fully loaded? Maybe I'm missing the mark but you devs find this useful in some other way?

Thanks so much for all the good work!

Yaron Koren (talkcontribs)

That is very interesting indeed - thanks for doing this detective work. Fixing the timing would indeed be the ideal solution, but, barring that, I'm curious about that last solution you found - delaying the "infuse" call. Could you put here the exact code you used? Maybe it's worth just adding that call if SMW is installed.

JeremiPlazas (talkcontribs)

Literally all we did was wrap it with a setTimeout function:

setTimeout(function(){ 
   var tabs = OO.ui.infuse( $( '.mw-tabs' ) );
}, 500);
Jongfeli (talkcontribs)

After trying this I understand better what is happening. When completely disabling // var tabs = OO.ui.infuse( $( '.mw-tabs' ) ); the actual tabs are build but the content for each tab stays below the first tab. This is of course not the solution but what happens when you add the setTimeout suggested by JeremiPlazas you delay the moment the content of the tabs is "moved" to the related tab. If you increase the timeout to lets say 10 seconds (10000) the page initially loads completely with all the tab content below the first tab. After the timeout, in this case 10 seconds, you see the page content for the different tabs pop into place.

This means that without timeout this "moving" the tab content happens to soon and before the actual tabs are created. I say moving the content because it looks that way. I do not know how Mediawiki (re)generates a page (HTML) with data from the server and cached data but var tabs = OO.ui.infuse( $( '.mw-tabs' ) ); seems to runs client side and is loaded to soon. So disabling caching altogether will solve the problem because all is coming from the server. This is not a workable solution because your wiki will become very slow. Is there not a way to initiate var tabs = OO.ui.infuse( $( '.mw-tabs' ) ); the moment the page is completely loaded instead of the timeout?

JeremiPlazas (talkcontribs)

Yes exactly! +1 to that.

Yaron Koren (talkcontribs)

You could try calling this:

    $( document ).ready(function() {
        var tabs = OO.ui.infuse( $( '.mw-tabs' ) );
    });

Let me know if that works for you.

Jongfeli (talkcontribs)

I have tested this and I can not get it to fail anymore. If other users can confirm this then the $( document ).ready(function() fixes the problem, thanks :-)

JeremiPlazas (talkcontribs)

This seems to resolve the issue for us too. Thanks!

Yaron Koren (talkcontribs)

Okay - that small code change didn't work for all functionality, it turns out; but I just checked in a similar code change that hopefully fully works. If you try out the latest code, please let me know if there are any issues!

Jongfeli (talkcontribs)

With 2.2.2 (46f2ae8) I can not get it to fail anymore. Thanks Yaron :-)

Yaron Koren (talkcontribs)

Great! Sorry it took three years. :) And thanks to everyone for their persistence!

Reply to "Header Tabs sometime fails to load"

$wgHeaderTabsDisableDefaultToc

1
Kghbln (talkcontribs)

Default "true" does not work for me. I still see the default ToC in version 2.2.2 on MW 1.39 when header tabs are used on the page.

Reply to "$wgHeaderTabsDisableDefaultToc"

Hide Level 1 headings in TOC

14
Krabina (talkcontribs)

Usually, Level 1 headings (marked with =) are not used in regular wiki pages. HeaderTabs uses them to define headers. The problem now is that the regular TOC in mediawiki pages also includes the level 1 headings (that already are used and therefore visible on the page in headertabs) are displayes in the TOC again.

Therefore I would need some ability of telling mediawiki NOT to include level 1 headings in the TOC.

As this is only a problem with headertabs it would be great to have a config option...

2.238.45.117 (talkcontribs)

This is my solution.

  1. If you are NOT an expert on mediawiki/semantic read the TOC and SECTIONS related help pages. You will not find at the time I am writing the solution for your problem, but for sure (like in my case) you will end up with a better understanding of it :)
  2. I ended up debugging the code and here the solution.

Considering that the best practice is not to use single "=" for sections this might be taken in consideration as change in the core mediawiki code.. (anyone reading up there?!?)


The solution consists in changing includes/parser/Parser.php.

I left the logic for TOC creation unaltered, otherwise you will end up having problem with the header tabs excentions rendering.

The goal is to declare the Header Tab section within a proper header defined with double "=" and HIDE in the TOC the section declared with single "=".

This last part might be changed in order to show the tabs with an appropriare TOC level, but in this in my opinion/experience is useless because

  1. the header tab section is rendered as unique block
  2. the TOC links are not able to point to the appropriate headed tab.


So..


NOTES:

This change will be applied to every level 1 header defined in your WIKI!!

USAGE:

  1. Declare your section header as == MY SECTION ==
  2. Write within your section your header tab content ( = tab1 = bla bla bla = tab2 = bla2 bla2 bla2 ... <headertabs/>
  3. Add in your page __TOC__ or {{TOC}} (if you are using a template for TOC)

PATCH:

edit your_wiki_path/includes/parser/Parser.php and apply the following changes in the function formatHeadings:

  ....
  4272                 foreach ( $matches[3] as $headline ) {
  4273                         $isTemplate = false;
  4274                         $titleText = false;
  4275                         $sectionIndex = false;
  4276                         $numbering = ;
  4277                         $markerMatches = array();
  4278                         if ( preg_match( "/^$markerRegex/", $headline, $markerMatches ) ) {
  4279                                 $serial = $markerMatches[1];
  4280                                 list( $titleText, $sectionIndex ) = $this->mHeadings[$serial];
  4281                                 $isTemplate = ( $titleText != $baseTitleText );
  4282                                 $headline = preg_replace( "/^$markerRegex\\s*/", "", $headline );
  4283                         }
  4284                         if ( $toclevel ) {
  4285                                 $prevlevel = $level;
  4286                         }
  4287                         $level = $matches[1][$headlineCount];
  4288                         if (
  4289                                 ( $level > $prevlevel && $prevlevel <> 1 )
  4290                                 ||
  4291                                 ( $level == 1 && $prevlevel > 1 )
  4292                         ) {
  4293                                 # Increase TOC level
  4294                                 $toclevel++;
  4295                                 $sublevelCount[$toclevel] = 0;
  4296                                 if ( $toclevel < $wgMaxTocLevel ) {
  4297                                         $prevtoclevel = $toclevel;
  4298                                         if ( $level <> 1 ) { # REMOVE THIS IF IF YOU WANT TO SHOW THE SECTION IN TOC
  4299                                                 $toc .= Linker::tocIndent();
  4300                                         }
  4301                                         $numVisible++;
  4302                                 }
  4303                         } elseif (  $level < $prevlevel && $toclevel > 1 ) {
  4304                                 # Decrease TOC level, find level to jump to
  4305                                 for ( $i = $toclevel; $i > 0; $i-- ) {
  4306                                         if ( $levelCount[$i] == $level ) {
  4307                                                 # Found last matching level
  4308                                                 $toclevel = $i;
  4309                                                 break;
  4310                                         } elseif ( $levelCount[$i] < $level ) {
  4311                                                 # Found first matching level below current level
  4312                                                 $toclevel = $i + 1;
  4313                                                 break;
  4314                                         }
  4315                                 }
  4316                                 if ( $i == 0 ) {
  4317                                         $toclevel = 1;
  4318                                 }
  4319                                 if ( $toclevel < $wgMaxTocLevel ) {
  4320                                         if ( $prevtoclevel < $wgMaxTocLevel ) {
  4321                                                 # Unindent only if the previous toc level was shown :p
  4322                                                 $toc .= Linker::tocUnindent( $prevtoclevel - $toclevel );
  4323                                                 $prevtoclevel = $toclevel;
  4324                                         } else {
  4325                                                 $toc .= Linker::tocLineEnd();
  4326                                         }
  4327                                 }
  4328                         } elseif (  $level > $prevlevel && $prevlevel == 1 ) {
  4329                                 # MIK
  4330                                 # Decrease TOC level for headed tab
  4331                                 for ( $i = $toclevel-1; $i > 0; $i-- ) {
  4332                                         if ( $levelCount[$i] == $level ) {
  4333                                                 # Found last matching level
  4334                                                 $toclevel = $i;
  4335                                                 break;
  4336                                         } elseif ( $levelCount[$i] < $level ) {
  4337                                                 # Found first matching level below current level
  4338                                                 $toclevel = $i + 1;
  4339                                                 break;
  4340                                         }
  4341                                 }
  4342                                 if ( $i == 0 ) {
  4343                                         $toclevel = 1;
  4344                                 }
  4345                                 if ( $toclevel < $wgMaxTocLevel ) {
  4346                                         if ( $prevtoclevel < $wgMaxTocLevel ) {
  4347                                                 # Unindent only if the previous toc level was shown :p
  4348                                                 //$toc .= Linker::tocUnindent( $prevtoclevel - $toclevel );
  4349                                                 $prevtoclevel = $toclevel;
  4350                                         }
  4351                                         //else {
  4352                                         //      $toc .= Linker::tocLineEnd();
  4353                                         //}
  4354                                 }
  4355                         } else {
  4356                                 # No change in level, end TOC line
  4357                                 if ( $toclevel < $wgMaxTocLevel ) {
  4358                                         if ( $level <> 1 ) {  # REMOVE THIS IF IF YOU WANT TO SHOW THE SECTION IN TOC
  4359                                                 $toc .= Linker::tocLineEnd();
  4360                                         }
  4361                                 }
  4362                         }
  4363
  4364                         $levelCount[$toclevel] = $level;
  4365
  ....
  4477                         if ( $enoughToc && ( !isset( $wgMaxTocLevel ) || $toclevel < $wgMaxTocLevel ) ) {
  4478                                 if ( $level <> 1 ) { # REMOVE THIS IF IF YOU WANT TO SHOW THE SECTION IN TOC
  4479                                         $toc .= Linker::tocLine( $anchor, $tocline,
  4480                                                 $numbering, $toclevel, ( $isTemplate ? false : $sectionIndex ) );
  4481                                 }
  4482                         }
  ....
  4550                 if ( $enoughToc ) {
  4551                         if ( $prevtoclevel > 0 && $prevtoclevel < $wgMaxTocLevel ) {
  4552                                 if ( $level <> 1 ) { # REMOVE THIS IF IF YOU WANT TO SHOW THE SECTION IN TOC
  4553                                         $toc .= Linker::tocUnindent( $prevtoclevel - 1 );
  4554                                 }
  4555                         }
  4556                         $toc = Linker::tocList( $toc, $this->mOptions->getUserLangObj() );
  4557                         $this->mOutput->setTOCHTML( $toc );
  4558                         $toc = self::TOC_START . $toc . self::TOC_END;
  4559                 }
  ....
  

ENJOY

This post was posted by 2.238.45.117, but signed as mailto:michele.fella@gmail.com.

Kghbln (talkcontribs)

This is again an issue with recent versions of MediaWiki and HeaderTabs.

Kghbln (talkcontribs)

I had hoped that the new version 2.1 fixes the issue, however it does not. I am on MW 1.35.x

Yaron Koren (talkcontribs)

It seems strange to follow up now on an issue that was first reported nine years ago, but: is the issue that the tabs appear in the TOC, or that they appear more important than everything else? I think this is part of why I ignored this issue before: because it seem to me that tabs should appear in the TOC, since they're part of the page structure. However, I admit that it's strange right now if you have normal section headers below all the tabs, because then you end up with a TOC that looks like:

1. Tab 1
2. Tab 2
2.1 Some tab sub-header
3. Tab 3
3.1 Overview
3.2 See also
3.3 References

Everything in the main page looks like it belongs to Tab 3, but it doesn't. What if the structure were fixed, so it instead looked like:

1. Tab 1
2. Tab 2
2.1 Some tab sub-header
3. Tab 3
4 Overview
5 See also
6 References

Would that be good enough? Or would it still be better to get rid of the tabs entirely in the TOC?

Kghbln (talkcontribs)

For quite some years the tabs were not shown and this was fine. Usually you do not use = to create headings within text but start with ==. The latter and lower level headings should be shown. For me the suggestion does not work.

@Krabina: What about you?

Yaron Koren (talkcontribs)

@Kghbln - thanks for the response. Can you explain why you think tabs should not be included in the TOC? After all, they're a part of the page structure...

Kghbln (talkcontribs)

Predominantly I create tabs to have a tabbed infobox. The tabs of the infobox should therefore not show up in the since they are not part of the regular content structure. Same with forms (had to add NOTOC to every form after the extension changed its behaviour). Probably I am misusing this extension.

Replacing second level headers with first level headers appears to be a wrong solution for the right reason.

Yaron Koren (talkcontribs)

Okay, that's helpful. I wouldn't say it's the wrong solution, just not the right solution for your case.

Krabina (talkcontribs)

I agree with Karsten. Also in my case, the TOC shows the structure of the main text as it should (usually level 1 headings are not used anyway). And HeaderTabs are showing tabs for various infoboxes. They should never be part of the regular TOC. Of course, different usecases are possible, but once you are using HeaderTabs it seems to me that they will almost any time not part of the rest of the page structure.

Yaron Koren (talkcontribs)

I don't think I understood most of that, but it's good to know that you don't want tab names in your TOC.

Krabina (talkcontribs)

I just realized that in the current version of HT there seems to be a configruation option for this. However, for me this does not work. If I put $wgHeaderTabsNoTabsInTOC = true; in LocalSeettings.php, nothing changes, if I put <notabtoc/> in the page, the tabs are not shown in the tabs, but no other headings are shown. After some testing I realized that this only works, if the tabs are below the content which heading should be in the TOC.

If I put first level headings and <headertabs /> BEFORE the other content, this does not work. This is unfortunate, because most of the times I use HeaderTabs for templates, where the template content is usually on the top of the page followed by the rest of the content.

Kghbln (talkcontribs)

I can confirm that the new configuration does not work.

Krabina (talkcontribs)

Unfortunately, the same does not work in V 2.2.2 and MW 1.39

Reply to "Hide Level 1 headings in TOC"

Error message after update to MW 1.39

2
Ahaemmerli (talkcontribs)

After the update of MediaWiki to 1.39 there is a error message on all pages using Header Tabs. I am using the last version of Header Tabs.

The error message is:

Deprecated: Use of ParserOutput::addModules with non-array argument was deprecated in MediaWiki 1.38. [Called from HeaderTabs::tag in (...) .../HeaderTabs/indludes/HeaderTabs.php at line 26] in (...) .../includes/debug/MWDebug.php on line 381

What I am doing wrong? Could anyone help me to find the problem? Thanks!

Yaron Koren (talkcontribs)

Sorry about that - this was a real bug in Header Tabs. I just checked in a fix for this, so if you get the latest Header Tabs code, the problem should go away.

Reply to "Error message after update to MW 1.39"

images no longer usable as link text in #switchtablink

2
Revansx (talkcontribs)

I just upgraded Header Tabs to v2.2 (master) and overall its great, but I did notice the we lost the ability to use images as the link text in the #switchtablink parser function. The older versions allowed for it. Was this capability dropped by design or was that an undocumented feature that got lost unintentionally?

Thanks!

/Rich

Yaron Koren (talkcontribs)

It's the latter.

Reply to "images no longer usable as link text in #switchtablink"

html entities no long render in tabs

1
Revansx (talkcontribs)

I just upgraded Header Tabs to v2.2 (master) and overall its great, but I did notice the we lost the ability to use html entities (like &#128221) in the header tabs. The older versions allowed for it. Was support for html entities dropped by design or was that an undocumented feature that got eliminated unintentionally?

Thanks!

/Rich

Reply to "html entities no long render in tabs"

New 'bootstrap' style

1
Lalquier (talkcontribs)

I edited the 'timeless' stylesheet to fit better in a Bootstrap site (with Chameleon for Mediawiki). How can I make it a proper style recognized by the extension? I tried adding it as a choice from the LocalSettings paremeter for style but I can't figure out how bridge the 'ext.headertabs.bootstrap' value and the right stylesheet.

Reply to "New 'bootstrap' style"

When running scripts I get PHP Notice: Undefined index:

7
Summary by Kghbln

Fixed. Will be released with the next version > 2.1

Kghbln (talkcontribs)
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
Kghbln (talkcontribs)

I had hoped that the new version 2.1 fixes the issue, however it does not. I am on MW 1.35.x

Kghbln (talkcontribs)
Yaron Koren (talkcontribs)

Sorry about that - this was a (slight) bug introduced about a year ago. I just checked in a fix for it.

Kghbln (talkcontribs)

Affirmative, master works fine. A tag will be great if possible.

Helioloureiro (talkcontribs)

Sorry to came back to this issue, but I'm on mediawiki 1.37.1 and right now, during the semantic-mediawiki rebuild, and I can see the same error.

[...]

  ... updating ...                                   19308 / 106374 ( 18%)

PHP Notice:  Undefined index: HTTP_HOST in /var/www/wiki/extensions/HeaderTabs/includes/HeaderTabs.php on line 226

PHP Notice:  Undefined index: REQUEST_URI in /var/www/wiki/extensions/HeaderTabs/includes/HeaderTabs.php on line 229


I checked out from git repo the latest code and changed to branch REL1_37.

Yaron Koren (talkcontribs)

You should use the master code, not the REL1_37 branch.

Reply to "When running scripts I get PHP Notice: Undefined index:"

Notices: Undefined index displayed in latest version

2
Summary by Kghbln

Duplicate of Topic:Vtylsowg12md8cei

Krabina (talkcontribs)

Notice: Undefined index: HTTP_HOST in /extensions/HeaderTabs/includes/HeaderTabs.php on line 228

Notice: Undefined index: REQUEST_URI in /extensions/HeaderTabs/includes/HeaderTabs.php on line 231

Kghbln (talkcontribs)

I had hoped that the new version 2.1 fixes the issue, however it does not. I am on MW 1.35.x