Extension talk:Header Tabs
Instead of asking your questions here, you might want to consider sending them to to mediawiki-l mailing list
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
extension maintainer, active users and contributors are on this list and will be able to help you.
Old messages on this page are archived.
Contents
 First page |
 Previous page |
 Next page |
 Last page |
[HT] 0.9 + MW 1.18 throws exception on "mw.loader::execute > Cannot call method 'toLowerCase' of undefined"
Recent HT (0.9) throws an "mw.loader::execute> Exception thrown by ext.headertabs: Cannot call method 'toLowerCase' of undefined".
I propose developing a function where a </headertabs> call followed by <headertabs> call generates a line break and a new set of headertabs. Potentially a different color too.
when using a mw-collapsed param on a wikitable, the table loads expanded, and the toggle button/link displays "expand" as if it thinks it's collapsed.
This only happens when the table is sitting in a tab that is out of focus at the time of page load.
the border of the tab does not wrap around images or galleries. MW 1.18, latest svn installation with noeditTab patch. I imagine there are other elements that do not follow the schema as well.
We updated to HT 0.9 and tried to use $htEditTabLink = false; but somehow the [edit] link still appears within the HT. We tested HT on MW 1.17 and 1.18 and experienced the same behaviour.
I'm sure it'll be fixed soon, but you can get your version working by adding an if-test in HeaderTabs_body.jq.php. Around line 21, add
$htEditTabLink
to the global declaration list, and around line 224, Change
//! @todo handle __NOEDITTAB__ here (2011-12-12, ofb)
$tabhtml .= '<span class="editsection" id="edittab"> [<a href="" title="'.wfMsg('headertabs-edittab-hint').'">'.wfMsg('headertabs -edittab').'</a>]</span>';
to
//! @todo handle __NOEDITTAB__ here (2011-12-12, ofb)
if ( $htEditTabLink ) {
$tabhtml .= '<span class="editsection" id="edittab"> [<a href="" title="'.wfMsg('headertabs-edittab-hint').'">'.wfMsg('headertabs -edittab').'</a>]</span>';
}
Excellent, it works! Thx.
Thanks people, committed it to Special:Code/MediaWiki/107284
Notice that the patch above is missing adding the variable to the 'global' line. The above patch turns it always-off. If someone can verify that the SVN HEAD version works on their setup, then Yaron maybe we could do a 0.9.1 release?
Hi,
I have Header Tabs 0.8 working on a customized Modern skin. Previously, I was getting nice blue tabs. Now, after upgrading to 1.17, I only get gray tabs and all wiki-links within the section's contents also appear gray and are indistinguishable from rest of the text. I tried upgrading to Header Tabs 0.9, but then I get complete breakdown of the tabs (no tabs seen). So I reverted back to 0.8. Are there any incompatibilities I'm missing? Should I be changing any code?
Example is here. Thanks for any help!
Veryhuman 20:47, 9 January 2012 (UTC)
It would be nice to be able to embed links into tabs. Thus the user could be redirected to a e.g. subpage without having to transclude it into the page. Basically this is working already but some space of about 1 cm is added in the display of the tab to the right of the link. So far pagename#pagesection is not possible as a direct link which is needed for this to work properly too. Perhaps transpagetabs would be a name to describe this. --[[kgh]] 21:09, 14 December 2011 (UTC)
- I'll need you to elaborate. Release 0.9 adds the ability to link to pagename#tabname and also pagename#headername, both of which were broken prior to 0.9 -- Using Section Traclusions (extension needed) you can transclude a section into a tab. Using transclusion you can embed a subpage into a tab. So you should be able to do everything you describe, unless I'm misunderstanding.--Olivier Beaton 22:11, 14 December 2011 (UTC)
- Heiya Olivier, because I did some customisation on my wiki a link within the tab like pagename#pagesection was broken. I should have tried before posting this. I changed this back and it is indeed working. :) Actually this was working in 0.8.3 too. However the space of about 1 cm to the left of the link (<a href=...) is still there which makes the tabs look a bit awkward. Transcluding contents from another page is possible, but this is just what I would like to avoid. In this case I would not need a link within the tab. My request just come done to find a way to avoid this space within the tab. I tried several things with CSS but failed somehow. :( If there is a tip for me I will gladly test and use it. Cheers --[[kgh]] 20:25, 15 December 2011 (UTC)
- Hi kghbln, could you please continue this discussion on the HeaderTabs talk page, this section is for feature requests. you may want to try different styles like 'bare'. Thanks. --Olivier Beaton 19:42, 16 December 2011 (UTC)--99.246.93.219 19:41, 16 December 2011 (UTC)
- Hi Olivier, of cause I will do so. At the time I wrote this initially I thought this would be a feature request. I will check 'bare'. Cheers --[[kgh]] 19:45, 16 December 2011 (UTC)
- Hi kghbln, could you please continue this discussion on the HeaderTabs talk page, this section is for feature requests. you may want to try different styles like 'bare'. Thanks. --Olivier Beaton 19:42, 16 December 2011 (UTC)--99.246.93.219 19:41, 16 December 2011 (UTC)
- Heiya Olivier, because I did some customisation on my wiki a link within the tab like pagename#pagesection was broken. I should have tried before posting this. I changed this back and it is indeed working. :) Actually this was working in 0.8.3 too. However the space of about 1 cm to the left of the link (<a href=...) is still there which makes the tabs look a bit awkward. Transcluding contents from another page is possible, but this is just what I would like to avoid. In this case I would not need a link within the tab. My request just come done to find a way to avoid this space within the tab. I tried several things with CSS but failed somehow. :( If there is a tip for me I will gladly test and use it. Cheers --[[kgh]] 20:25, 15 December 2011 (UTC)
The page says
In addition to user-defined tabs, Header Tabs can convert the Semantic MediaWiki factbox into a tab, and add it as the last tab in the tab view.
That makes it sound like some kind of automatic, possible thing. Or is it just talking about
= Factbox = __SHOWFACTBOX__ <headertabs/>
?
It is automatic - just adding last tab. Someone might want to change that to support __SHOWFACTBOX__ to move it around, but it's no there yet ;)
So what you are saying is that is you have $smwgShowFactbox = SMW_FACTBOX_NONEMPTY; then it will automatically make it a tab?
It depends on what version of MediaWiki you're using - if you have MW 1.16 or lower, then I think the factbox will show up automatically in a tab called "Factbox". If you have 1.17 or higher, then unfortunately I don't think you can get the factbox to show up in a tab, even if you try to do it manually.
That's what I thought. :-(
If you put = Factbox = in with Version 1.17 it does create the Factbox tab and shows the Factbox under the Factbox tab. What is broken is the Factbox showing at the bottom of the page when any other tab is used or the main tab on landing at the page. Kind of defeats the purpose of the Factbox tab if it showing under all the tabs. Then again, I'm not sure if the Factbox is just showing under the Factbox tab because it is under every tab. I have no content under under the tab = Factbox = so that may be the case.
Is there a fix yet, or planned fix for 1.7? Building a new semantic wiki and I would have stayed with 1.16 if I knew this was still a bug. I wonder if you can control it with CSS?
This is the wiki: http://elwiki.net/w/Test_Tabs
MediaWiki 1.17.0 PHP 5.3.6 (apache2handler) MySQL 5.1.58
I downloaded the extension, installed it normally (it appears in Installed Extensions in the version page) but it just doesn't seem to be working for me. It seems like none of the jQuery stuff is working. Can anyone help me with this? Thanks.
I checked your Special:Version and as mentioned in an earlier thread HeaderTabs not Working in MediaWiki 1.17.0, the Usability Initiative Extension does not work with HT and 1.17 due to an jQuery conflict. Please note that the Extension:UsabilityInitiative is deprecated and it is recommended not use it beyond MW 1.16.
Anyone know if updating to 1.18 will break Header Tabs?
I poked around and found some CSS to make this extension clash less with the Vector skin.
#headertabs { font-size:1em; }
#headertabs .ui-widget { font-family: sans-serif; font-size:1em;}
#headertabs .ui-widget .ui-widget { font-size: 1em; }
#headertabs .ui-widget input, .ui-widget select, .ui-widget textarea, .ui-widget button { font-family: sans-serif; font-size: 1em; }
#headertabs .ui-widget-content { border: none; /* @embed */
background: #f2f5f7 url(images/ui-bg_highlight-hard_100_f2f5f7_1x100.png) 50% top repeat-x; color: #362b36; }
#headertabs .ui-widget-content a { color:#0645AD; }
#headertabs .ui-widget-content a:visited { color:#0b0080; }
#headertabs .ui-widget-content a.new { color:#CC2200; }
#headertabs .ui-widget-content a.new:visited { color:#A55858; }
#headertabs .ui-widget-content a.extiw { color:#3366BB; }
#headertabs .ui-widget-content a.redirect { color:#308050; } /*Color redirect links*/
#headertabs .ui-widget-content a.redirect:visited { color:#3070A0; } /*Color redirect links*/
#headertabs .ui-widget-shadow { margin: -7px 0 0 -7px; padding: 7px; /* @embed */
background: #000000 url(images/ui-bg_flat_70_000000_40x100.png) 50% 50% repeat-x; opacity: .20;filter:Alpha(Opacity=20);
-moz-border-radius: 8px; -webkit-border-radius: 8px; border-radius: 8px; }
.ui-tabs { position: relative; zoom: 1; }
.ui-tabs .ui-tabs-panel { display: block; border-width: 0; padding: 0em 0em; background: none; }
Put this in Common.css or some place similar.
This will fix all of the issues I'm aware of. It shouldn't cause any problems with any other extensions using jQuery UI. It survives upgrades. Et cetera et cetera.
It could use some further work -- I'd like to have the tabs look more like the Vector tabs, or at least something less different... but I guess it's a work in progress, and a good start for anyone else who fired up this extension and said WTF.
Note that the last two lines aren't within the #headertabs div. The ui-tabs/ui-tabs-panel stuff screws up the body (IMHO) by putting tremendous padding around it. If you try to apply the CSS to only ui-tabs/ui-tabs-panel within the #headertabs div, it fails and does not get applied. I'm not sure why, and my level of interest (since I don't think I'll be using jQuery UI tabs anywhere else) is so low that I'm not going to spend any time trying to figure it out.
Oops, I ended up duplicating this work. I have a slightly different one, and I'll be integrating some parts of this one (for link colour for example, forgot that). I've posted both at Extension:Header_Tabs/JQueryStyles
AS said...
The Headertabs are displayed on the top and a click on it will show the correct part of the page, but the parts are all drawn below each other and are not hidden, like they should...
please help :-) --Dominik Sigmund
Is this on a public wiki? If not, what MediaWiki version, Header Tabs version, and skin are you using?
Hi Dominik, the sort of behaviour you describe holds true for the current Cavendish skin (though there's a newer, derivative version which appears to be working) and possibly others as well. You could switch between skins in your personal preferences and see if incorrect behaviour persists. It would help diagnose the problem.
using vector, but i appreciate the help :-)
In the past we have seen problems with the UsabilityInitiative extension, as a matter of fact UsabilityInitiative is deprecated beyond 1.16. Please see the notice on the Extension:UsabilityInitiative page. We are using HT 0.8.3 together with 1.17 successfully on private/semi-public wiki.
OK, then i'll try to deactivate the UsabilityExtension after upgrading to 1.17...
Lets hope it works then ;-)
Well, it works :-)
But i've got one more small problem:
In MW 1.16, i was able to click on a Link on a page to switch to another tab (Linked with switchtablink or manually built is the same).
No this doesnt work. When using switchtablink and saving the page from edit, i get a blank screen. When using a Link built by Hand, (Like http://fh-hfv-web02.hf.brnet.int/at-wiki_test/index.php/Bereiche#tab=B2) it simply doesn't do anything when clicking on the Link...
Any Help here?
And Many Thanks for the Help i got since here :-)
Could we get a table of contents generated for a tab? It seems a bit trivial to just break up the TOC onto the respective tabs. Some of our tabs are quiete lengthy and we'd like to still be able to use a TOC just for each tab.
As well is there much thought into making some kind of auto-tab through subpages using say a prefix?
I wouldn't say the first one is trivial - it would require some significant string parsing and manipulation. Still, it's an interesting idea.
The second one, I didn't understand.
The 2nd idea is that if I create a subpage of "Bar", say "Bar/tab-Foo" then "Foo" automatically appears as a tab on Bar. While on "tab-Foo" since it has a the "tab-" prefix it would look for sub-pages on it's parent instead of itself, so that you still have the list of tabs.
Another thing I was wondering is if instead of using JQuery tabs there could be an option to integrate into the Vector/MW tab system. That way it's all unified at the top, instead of having tabs -> header -> more tabs.
Personally I'm using Extension:HeadersFooters right now to insert a =General= before every article and a <headertabs/> into the footer of every page. That way people can just make new = = headings and poof new tab.
Is there a reason it overwrites all the default styles for font size and such?
I'm trying to figure out how an image is added into the tab along side the header. Such as the following example: http://pinataisland.info/viva/Dragonache
It seems like it works for you now.
Sorry, I seem to have explained myself poorly. The example URL was someone who successfully was able to embed an image into the tabs. I'm trying to replicate the same effect on my own wiki. I'm just not sure how it was done.
Anyone have any ideas how I could successfully embed an image in each tab? I've looked all over and haven't a clue where to begin. Again, I saw it done here:
http://pinataisland.info/viva/Dragonache
And haven't been able to duplicate this.
It appears that Dragonache has modified their codebase to support this.
However, adding an image to a tab is completely do-able if you are running MW 1.14 or newer.
The problem stems from the fact that when you do an [[Image:<filename>]], MediaWiki wraps the resulting image tag with an anchor href tag. This anchor href tag competes with the header tab (which uses an anchor name tag).
To get around this, you need to tell MediaWiki not to wrap the image tag with an anchor tag; this is achieved by changing the image tag to [[Image:<filename>|link=]] tag. See http://www.mediawiki.org/wiki/Help:Images#Link_to_another_page
Just leave the link blank.
I'm glad a fix is here, but really this is a poor solution as it involves user retraining either on a case by case basis (every image link types) or user retraining to get them to all use a different template.
Could header tabs be made to be compatible with anchors? I'd still like to be able to use my header and image anchors.
Heiya, as I set up clean action paths on my wiki everything works perfectly except that the header tabs do not get loaded. I just see "* titel of tab2" at the top of the page. I guess the scipt cannot finish loading properly for some reason. Is there a quick fix, hack etc. to solve this? It may also by dirty. ;) Cheers
I've run into an issue where using header tabs in conjunction with multiple instance templates in a form messes up the rendered HTML for some of the form elements. I found this when trying to figure out why autocompletion wouldn't work on fields located not on the first tab. I've been able to duplicate this issue on referata here, and when you view the rendered HTML for the input fields, you'll see that the field on the last tab has the same name as the field in the multiple instance template on the second tab... in other words, data will end up getting saved to a different field than expected.
Thanks in advance for your help,
for me in the latest version the fonts are too small using HeaderTabs and the Vector skin. Interestingly, if you use SemantiForms, the fonts are o.k. but once you just view the page, the fonts are too small.
You can change that putting the following line in a page called MediaWiki:Vector.css
#headertabs{ font-size:1em; }
I've got two versions of my site on the same server, the current 1.16 version and a new 1.17 version. I have a test page (on both) that just loads 8 tabs and has some text under each tap; no queries are done. If I:
- Have the 1.16 and 1.17 versions up in IE9
- Delete temporary internet files
- Hit Refresh in each window at roughly the same time
The 1.17 page always takes longer to finish, and in the process of rendering shows the headertab titles in a bulleted list before showing the tabs. If I hit refresh in both windows again, the 1.17 version is still slower. This is true with Firefox and Chrome also.
The Dexid form link on the extension page also shows this list. I would guess I could block the list from showing up if I take a look at the code. But is the slow speed expected? Is there anything that can be done to speed it up? Thanks.
Headertabs in MM 1.17 onwards uses jQuery, and loading of the jQeury library is managed by MW's internal ResourceLoader. The issue with the bullet list has been discussed earlier on the SMW mailing list [1] and it seems for now there is no work around available that would allow a priority loading of the headertabs library. Any issues in regards with performance might be connected with the handling of the ResourceLoader library.
In addition to the speed issue, I like the look of the YUI version better. I tried forcing it to see how it would look by overriding the is_callable() check in HeaderTabs.php. It looked nice and familiar and rendered faster. But unfortunately, despite code in HeaderTabs_body.yui.php that checks the MW version, the tabs weren't clickable, and all of the tab contents were listed under the first tab like one page. I'm going to play with it more, unless someone wants to volunteer that the YUI version will never work with 1.17. Thanks.
I've had a few opportunities to fool around with it, and so far with my still-growing experience, the straight-forward things I've tried to get the YUI route working under 1.17 are failing. Is there some fundamental reason why it will never work?
We just installed the extension on our wiki ( MW 1.16 ) and whenever we add the tabs to any page, the page shows for a brief second before redirecting to the page "Extensions/HeaderTabs/skins/blank.html".
I'm not sure if anyone knows how this can get fixed, but any help would be greatly appreciated.
Thanks!
That's very odd. What version of Header Tabs are you using, what skin are you using, and do you have any other Javascript-based extensions installed that could be indirectly interfering with the tabs?
We are currently using the 0.8.3 version of header tabs.
We are using a custom skin that is heavily modified off of Modern.
The only extensions that we are using with javascript that I'm thinking could possible interfere are:
- Tabber - the extension we are hoping to replace with Header Tabs
- MenuSidebar - the extension for our auto-expanding sidebar
- CategoryTree - don't think this should cause any issues, but just listing for completeness of js extensions.
Thanks for trying to help!
Okay - I would try switching to the "Vector" skin, and temporarily disabling those three extensions, and seeing if that fixes the problem. If so, then of course you should whittle it down to see where the exact source of the problem is. If not, then you could consider upgrading to MW 1.17 - Header Tabs uses different Javascript for MW 1.17 and higher. Actually, maybe it's worth doing that anyway - you'll presumably want to upgrade at some point, regardless...
First page |
Previous page |
Next page |
Last page |
