MediaWiki-l December 2011

mediawiki-l@lists.wikimedia.org

62 participants
55 discussions

How to add new special page group?
by Robert Baruch 13 Dec '11

13 Dec '11

I'd like my extension's new special page to go under a new special page group in Special:SpecialPages, since it doesn't fit in any of the other categories, and it seems a bit silly to just stick it under "Other". However, it looks like you can't just add a new message and expect Special:SpecialPages to pick it up. For example, if my new group were, just for example, "Pages which Manipulate the Space Time Continuum", I would have thought that doing this would be sufficient: 1. Add a new message to your extension's internationalization file: $messages['en'] = array( 'myext' => 'My Bunch of Pages', 'specialpages-group-spacetime' => 'Pages which Manipulate the Space Time Continuum' ); 2. Categorize the special page (in this case, Special:TimeMachine: $wgSpecialPageGroups['TimeMachine'] = 'spacetime'; So why doesn't this work? A quick perusal of the source code in SpecialPageFactory.php doesn't seem to turn up anything additional to do... Thanks, --Rob

5 5

User migration
by Stephen Berg (Contractor) 12 Dec '11

12 Dec '11

I'm rebuilding a wiki that was previously on 1.5.6. I have a good mysql dump of the database but trying to use that didn't work so well. What I ended up doing was a fresh install on the server with mw 1.18 and exported/imported all the pages. (It's not a big wiki). The problem now is getting user accounts migrated to the new wiki. I've looked at the mysqldump's from both versions and there's some big differences. I did attempt to run a manual "INSERT INTO blah blah" on the new server using the format I could discern from the dump, and the user account I created was indeed added. But any attempt to login failed. Tried to "email new password" and the wiki said there is no user by that name. How can I cleanly migrate the user accounts from the old 1.5.6 to the new 1.18? The few references I've seen to extensions that might do this all seem to be out of date so I'm a little wary to attempt them. -- Stephen Berg Systems Administrator NRL Code: 7320 Office: 228-688-5738 stephen.berg.ctr(a)nrlssc.navy.mil

4 4

tip
by Rob Meijeren 12 Dec '11

12 Dec '11

Hello mediawiki, My name is Rob Meijeren and i work at All4Students. For a customer we have made an application which imports several of you articles. However at some articles the layout isn't quite right because there is a tag missing (</div>). This tag misses for the div-class mw-content-ltr. 2 Pages i know for certain that this is the case by the dutch articles for Loopbaanbegeleiding and Ontslagvergoeding. Would you please take a look at that. I look forward to you answer. Kind regards, Rob Meijeren

3 3

tip
by Rob Meijeren 12 Dec '11

12 Dec '11

Hallo mediawiki, Mijn naam is Rob Meijeren en ik werk bij All4Students. Nu hebben wij voor een klant verschillende artikelen van jullie site geïmporteerd. Echter bij sommige artikelen klopt de layout niet helemaal. Daar mist namelijk een tag (</div>) om de div klasse mw-content-ltr te sluiten. 2 pagina's waarvan ik zeker weet dat dit voorkomt is Loopbaanbegeleiding en Ontslagvergoeding. Zouden jullie hiernaar kunnen kijken. Ik kijk uit naar uw antwoord. Met vriendelijke groeten, Rob Meijeren

2 1

12 Dec '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I know you guys are probably getting tired of seeing my name appear on this list by now, but I've run into yet another 1.18.0 upgrade issue. After lots of debugging over at the Bugzilla site, I finally found out my custom skin was the cause of most of my 500 server errors. I now have 1.18.0 running successfully, complete with my own custom skin (now properly derived from MonoBook rather than the hack job I did earlier). Only... now I can't log in. Every time I attempt to log in I receive the following cryptic error: Login error <nocookiesforlogin> I know for a fact that my username and password are correct, and this is my own site so I'm certainly not blocking my own cookies. I'm not using any of the $wgCookie* variables; those are all set to their default values. I've tried tweaking some of these, including setting $wgDisableCookieCheck = true, with no obvious change in the result. The only thing I can possibly think of that might be affecting this is the fact that I use Apache mod_rewrite to force login requests to HTTPS mode so the password will be encrypted. The <form> tag does not include the protocol as part of the action value, so if I submit the form in HTTPS mode it *should* stay in HTTPS. However, as with everything else I've complained about, this worked without a hitch in 1.17.1 and below and stopped working with 1.18.0. Any ideas? I want to make sure it's not something stupid I've done before filing a bug report. - -- Jeff Darlington General Protection Fault http://www.gpf-comics.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ZdhMACgkQVNMIBILmfwEhMwCfTB/tbpbcwZY+/oT/lRRzJL9Q BToAn3TYb1BjN3GFpa73Zwh310JP9rp9 =aOcS -----END PGP SIGNATURE-----

2 6

Context weirdness
by John Foster 11 Dec '11

11 Dec '11

My mediawiki 1.17 installation as gone nuts. It is not correctly identifying things where the first letter context has changed. example: Template: tlx call does not find Template:Tlx In the past this has made no difference. Only recent changes are installation of the Extension:WorkingWiki. The extension seems to be doing its job though there are some issues with Latex (.sty) sheets. I just do not know if the WorkingWiki, which did alter the editing interface, is the cause. I will be contacting the author re: this. Any tips?

3 4

Name- rakesh rana s/o- jagdish rana vill- barkagaon(rana muhalla) Po+ps- barkagaon dist- hazaribag state- jharkhand pin code- 825311
by jitendrarana4＠gmail.com 11 Dec '11

11 Dec '11

---------- Sent from my Nokia phone ------Original message------ From: <mediawiki-l-request(a)lists.wikimedia.org> To: <mediawiki-l(a)lists.wikimedia.org> Date: Saturday, December 10, 2011 11:27:43 PM GMT+0000 Subject: MediaWiki-l Digest, Vol 99, Issue 8 Send MediaWiki-l mailing list submissions to mediawiki-l(a)lists.wikimedia.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/mediawiki-l or, via email, send a message with subject or body 'help' to mediawiki-l-request(a)lists.wikimedia.org You can reach the person managing the list at mediawiki-l-owner(a)lists.wikimedia.org When replying, please edit your Subject line so it is more specific than "Re: Contents of MediaWiki-l digest..." Today's Topics: 1. Re: Problem updating mediawiki (Brion Vibber) 2. Re: runjobs.php question (Fred Bauder) 3. [MediaWiki-l] Skin-Synagonism (Kaseluris-Nikos-1959) 4. Re: [MediaWiki-l] Skin-Synagonism (K. Peachey) 5. Re: Login error,<nocookiesforlogin> (Platonides) 6. Re: Memory Leak Issue (Platonides) 7. Re: incorrect mime type detection (Platonides) 8. Re: Context weirdness (Platonides) 9. Re: incorrect mime type detection (Jens Wille) ---------------------------------------------------------------------- Message: 1 Date: Fri, 9 Dec 2011 10:49:09 -0800 From: Brion Vibber <brion(a)pobox.com> Subject: Re: [Mediawiki-l] Problem updating mediawiki To: MediaWiki announcements and site admin list <mediawiki-l(a)lists.wikimedia.org> Message-ID: <CAFnWYTm1QvbudBHdQXU6HsNdjk4O5WTBC3BJA=z-cpzwts=wZg(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Fri, Dec 9, 2011 at 10:34 AM, Marlen Caemmerer <caemmerer(a)monoro.de>wrote: > > On Fri, 9 Dec 2011, Brion Vibber wrote: > >> > >> Your system has a combination of PHP and libxml2 versions which is buggy > >> and can cause hidden data corruption in MediaWiki and other web apps. > >> Upgrade to PHP 5.2.9 or later and libxml2 2.7.3 or later! > >> ABORTING (see http://bugs.php.net/bug.php?id=45996). > >> > > Funny, > the result is: > > <pre> > Got: bc/b > Expected: <b>c</b> > </pre> > Running on command-line that looks like you are indeed seeing the bug in its original form. (I forgot the / comes through too.) The htmlspecialchars() there escapes the < and > for HTML output, so that's why they come through as < and > -- brion ------------------------------ Message: 2 Date: Fri, 9 Dec 2011 11:58:50 -0700 (MST) From: "Fred Bauder" <fredbaud(a)fairpoint.net> Subject: Re: [Mediawiki-l] runjobs.php question To: jfoster81747(a)verizon.net, "MediaWiki announcements and site admin list" <mediawiki-l(a)lists.wikimedia.org> Message-ID: <40650.66.243.192.69.1323457130.squirrel(a)webmail.fairpoint.net> Content-Type: text/plain;charset=iso-8859-1 > Is there any issues with adding some lines of code to let me know when > the script has finished processing. Currently when I run manually in a > terminal it just stops after a while. However I actually don't know that > it finished its job. Some of the other scripts actually do have a "I'm > done" line when finished. Or an error warning when it craps out. > Thanks! > frosty do this: php runJobs.php php showJobs.php When the showjobs runs it tells you its over. I'm talking about command line commands. Fred ------------------------------ Message: 3 Date: Sat, 10 Dec 2011 08:09:33 +0200 From: Kaseluris-Nikos-1959 <kaseluris.nikos(a)gmail.com> Subject: [Mediawiki-l] [MediaWiki-l] Skin-Synagonism To: MediaWiki-l(a)lists.wikimedia.org Message-ID: <CAN2wPPSEczRRiTs2sGV+zzemVoqEoBONVhAQ57892R_xxJed1w(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 I have created the skin "synagonism" that greatly improvespage-READING by moving the table-of-contents on the left and showingthe position the reader is reading! More specifically:1) The left sidebar now is a drop-down menu, always visible.2) Thelogo, the portlets personal and search and the title of the page arealways visible.3) The table-of-contents (toc) moved on the left in asplittable-pane, always visible.4) The toc is an expandable tree.5)There is two-way communication between the toc and the articles.* Byclicking on the toc, goes to that heading and the user can copy theaddress of any section of an article.* By clicking on a section of anarticle, in the toc is highlited this section and its parents are onlyexpanded, giving to the reader the big picture of the position s|he isreading. Thus improves the readability of big articles.6) If there isno toc in a page (eg less than 3 headings), the toc automaticallycloses and leaves all the space for the article.7) Splitbar has abutton that closes|opens the toc with one click.You can find it at SourceForge: http://synagonism-mw.sourceforge.net/ I don't have much MediaWiki code experience and I am too old to bean expert on it!!! Please, If commiters are interesting in my skin's functionality, docode review and commit my skin for me. Reporting bugs to me, I'll do my best. (my slogan at the end, shows why I call my skin "synagonism"!) -- Kaseluris-Nikos-1959 Synagonism = ALL winners, Antagonism = ONE winner ------------------------------ Message: 4 Date: Sat, 10 Dec 2011 17:00:24 +1000 From: "K. Peachey" <p858snake(a)gmail.com> Subject: Re: [Mediawiki-l] [MediaWiki-l] Skin-Synagonism To: MediaWiki announcements and site admin list <mediawiki-l(a)lists.wikimedia.org> Message-ID: <CADnECnXdgKmUR1rVutjFSZBYO5wDafoLXG1Q-xQayWpt3PJiSA(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Sat, Dec 10, 2011 at 4:09 PM, Kaseluris-Nikos-1959 <kaseluris.nikos(a)gmail.com> wrote: > Please, If commiters are interesting in my skin's functionality, > docode review and commit my skin for me. > Reporting bugs to me, I'll do my best. Have you considered apply for commit access[0] yourself? That way it would be easier to any code review on the code plus any additional commits within our CR interface. Dantman[1] is a fan/into the skinning stuff so no doubt he will by and comment on this email, if not, You can give him a shout on his talk page at MediaWiki wiki. [0]. http://www.mediawiki.org/wiki/Commit_access [1]. http://www.mediawiki.org/wiki/User:Dantman ------------------------------ Message: 5 Date: Sat, 10 Dec 2011 18:18:59 +0100 From: Platonides <Platonides(a)gmail.com> Subject: Re: [Mediawiki-l] Login error,<nocookiesforlogin> To: mediawiki-l(a)lists.wikimedia.org Message-ID: <jc042g$3m3$1(a)dough.gmane.org> Content-Type: text/plain; charset=ISO-8859-1 On 05/12/11 04:02, Jeffrey T. Darlington wrote: > On 12/4/2011 3:58 PM, Platonides wrote: >> That's strange. Do you have the language files up to date? > > I have no idea. I'm starting from a clean yet slightly tweaked copy of > the 1.18.0 code (I have a custom skin derived from MonoBook), and I made > sure to run maintenance/update.php to update my database during the > upgrade. I've also run maintenance/rebuildLocalisationCache.php, which > was requested when someone else was trying to debug my prior upgrade > issues. Beyond these steps, I've never had to "update my language > files" before. I was thinking that instead of the languages/messages/MessagesEn.php shipped with MediaWiki 1.18 you could have there a copy of an older release. You should have there on line 1074: > 'nocookiesforlogin' => '{{int:nocookieslogin}}', # only translate this message to other languages if you have to change it and in line 1072 (you also seem to miss this): > 'nocookiesfornew' => 'The user account was not created, as we could not confirm its source. > Ensure you have cookies enabled, reload this page and try again.', The md5 of the file is: > 59498d33f47acb0a25cb1eec986fad1d languages/messages/MessagesEn.php >> Is your wiki available somewhere? > > It's publicly available in read-only mode; I'm the only one with admin > privileges, and nobody else has or can create a login. I've been > planning on taking on a few volunteer wiki-wranglers, but I haven't > started taking applications yet. You can take a look if you want, but > since you won't be able to log in anyway I don't know if that will help. > > http://www.gpf-comics.com/wiki/ Yes. I just wanted to confirm if it was sending the cookies. Unlike what you report, I do get a wikidb_session cookie (and it is indeed marked as secure, $wgCookieSecure is defaulting to true from the https access) Still, filling a random user & password, I get the same error you reported. Your setup _should_ work, these errors are usually related to php not being able to write in the session_path, but if you didn't touch php and it worked before... The rewrite rule shouldn't matter, either but I'd ask you to remove it, and check if that makes a difference (you don't even need to enter the right credentials, as nocookies has higher priority than badpassword). ------------------------------ Message: 6 Date: Sat, 10 Dec 2011 23:14:49 +0100 From: Platonides <Platonides(a)gmail.com> Subject: Re: [Mediawiki-l] Memory Leak Issue To: mediawiki-l(a)lists.wikimedia.org Message-ID: <jc0ld6$c89$1(a)dough.gmane.org> Content-Type: text/plain; charset=ISO-8859-1 What's your configured memory_limit of php? If a request surpassed it, it would be cancelled, but not the total system memory shouldn't be surpassed (many concurrent requests?). I assume "the server had completely maxed out its memory" refers to the apache process? Note that a php like MediaWiki cannot produce a memory leak in the server, as php frees all the memory used by the request and the end of it. Are you sure there were absulutely no requests that night? Perhaps it was crawled by e.g Googlebot. ------------------------------ Message: 7 Date: Sat, 10 Dec 2011 23:56:31 +0100 From: Platonides <Platonides(a)gmail.com> Subject: Re: [Mediawiki-l] incorrect mime type detection To: mediawiki-l(a)lists.wikimedia.org Message-ID: <jc0nrc$rl4$1(a)dough.gmane.org> Content-Type: text/plain; charset=ISO-8859-1 Those images match the signature of a central directory. unzip -t 01-0557-3.jpg > warning [01-0557-3.jpg]: zipfile claims to be last disk of a multi-part archive; > attempting to process anyway, assuming all parts have been concatenated > together in order. Expect "errors" and warnings...true multi-part support > doesn't exist yet (coming soon). > error [01-0557-3.jpg]: missing 1852006951 bytes in zipfile > (attempting to process anyway) > error [01-0557-3.jpg]: attempt to seek before beginning of zipfile > (please check that you have transferred or created the zipfile in the > appropriate BINARY mode and that you have compiled UnZip properly) unzip -t 05-0995-2.jpg > warning [05-0995-2.jpg]: zipfile claims to be last disk of a multi-part archive; > attempting to process anyway, assuming all parts have been concatenated > together in order. Expect "errors" and warnings...true multi-part support > doesn't exist yet (coming soon). > error [05-0995-2.jpg]: missing 1689894850 bytes in zipfile > (attempting to process anyway) > error [05-0995-2.jpg]: attempt to seek before beginning of zipfile > (please check that you have transferred or created the zipfile in the > appropriate BINARY mode and that you have compiled UnZip properly) Whereas with a normal file: unzip -t 01-0557-2.jpg > Archive: 01-0557-2.jpg > End-of-central-directory signature not found. Either this file is not > a zipfile, (...) 01-0557-3.jpg contains "50 4B 05 06" at offset 0x4E24B and 05-0995-2.jpg at 0x309DE. Since they're just 4 bytes at an arbitrary offset amongst "random" data, it's apparently a statistical false positive. In fact, the more throughly ZipDirectoryReader detects it as 'zip-bad', 'trailing bytes after the end of the file comment'. Maybe we should strength the checks at MimeMagic.php What were you changing in the db? I don't get that "magic change back" that you report. Perhaps it was metadata update was triggering it. Setting these values you should be safe: > img_name img_size img_width img_height img_metadata img_bits img_media_type img_major_mime img_minor_mime img_sha1 > 01-0557-3.jpg 377382 599 800 a:1:{s:22:"MEDIAWIKI_EXIF_VERSION";i:2;} 8 BITMAP image jpeg 1fyq01rqsw47yhvl4sqg66gr4d60j0f > 05-0995-2.jpg 220187 800 565 a:1:{s:22:"MEDIAWIKI_EXIF_VERSION";i:2;} 8 BITMAP image jpeg ghuv3z91zq81vub5v8zj9tmjziojzrh ------------------------------ Message: 8 Date: Sun, 11 Dec 2011 00:05:31 +0100 From: Platonides <Platonides(a)gmail.com> Subject: Re: [Mediawiki-l] Context weirdness To: mediawiki-l(a)lists.wikimedia.org Message-ID: <jc0oc8$ugu$1(a)dough.gmane.org> Content-Type: text/plain; charset=ISO-8859-1 On 05/12/11 02:25, John W. Foster wrote: > On Sun, 2011-12-04 at 22:09 +0100, Platonides wrote: >> On 01/12/11 00:51, John Foster wrote: >>> My mediawiki 1.17 installation as gone nuts. It is not correctly >>> identifying things where the first letter context has changed. example: >>> Template: tlx call does not find Template:Tlx In the past this has made >>> no difference. >> >> Did you change $wgCapitalLinks to false? > > I did indeed, as per the instructions at the WorkingWiki site. I have > been advised by the author that it is actually not necessary, but for > now the damage is already done, so I will just leave it & clean up the > issues. > I would appreciate any advice as to which way is best...context > sensitive or not. It wont matter once I get finished using templates > built by others that I've borrowed from other sites. I intend to never > allow content that depends on shortcuts or acronyms and I like the > titles of everything to begin with caps. Just a personal thing LOL. > Thanks for the reply. It doesn't matter too much. As the default is to have the first letter as capital, some templates you import may call them with different case, but that's all. If you want to switch back $wgCapitalLinks to true; you should then run maintenance/cleanupTitles.php Otherwise, pages created with the first letter lowercase will be unreachable. ------------------------------ Message: 9 Date: Sun, 11 Dec 2011 00:27:40 +0100 From: Jens Wille <jens.wille(a)gmx.org> Subject: Re: [Mediawiki-l] incorrect mime type detection To: MediaWiki announcements and site admin list <mediawiki-l(a)lists.wikimedia.org> Message-ID: <4EE3EAEC.4060804(a)gmx.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Platonides [2011-12-10 23:56]: > 01-0557-3.jpg contains "50 4B 05 06" at offset 0x4E24B and > 05-0995-2.jpg at 0x309DE. Since they're just 4 bytes at an > arbitrary offset amongst "random" data, it's apparently a > statistical false positive. ok, thanks for your input! > What were you changing in the db? I don't get that "magic change > back" that you report. Perhaps it was metadata update was > triggering it. mysql> SELECT img_name FROM image WHERE img_media_type <> 'BITMAP'; +---------------+ | img_name | +---------------+ | 01-0557-3.jpg | | 05-0995-2.jpg | +---------------+ 2 rows in set (0.00 sec) mysql> UPDATE image SET img_media_type = 'BITMAP', img_major_mime = 'image', img_minor_mime = 'jpeg' WHERE img_media_type <> 'BITMAP'; Query OK, 2 rows affected (0.04 sec) Rows matched: 2 Changed: 2 Warnings: 0 mysql> SELECT img_name FROM image WHERE img_media_type <> 'BITMAP'; Empty set (0.01 sec) [...access File:01-0557-3.jpg in browser...] mysql> SELECT img_name FROM image WHERE img_media_type <> 'BITMAP'; +---------------+ | img_name | +---------------+ | 01-0557-3.jpg | +---------------+ 1 row in set (0.00 sec) [...access File:05-0995-2.jpg in browser...] mysql> SELECT img_name FROM image WHERE img_media_type <> 'BITMAP'; +---------------+ | img_name | +---------------+ | 01-0557-3.jpg | | 05-0995-2.jpg | +---------------+ 2 rows in set (0.00 sec) so that seems a bit weird to me. > Setting these values you should be safe: well, that didn't work either :( but what did work, though, is a plain `convert` (without actually changing anything) and uploading that instead. this way it must have gotten rid of any "garbage" there might have been. so, thanks again. for me the problem is solved :) as far as the database issue is concerned i don't know... to be honest, as long as it doesn't affect me, i don't really care. i just don't understand what it's doing there. cheers jens ------------------------------ _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l End of MediaWiki-l Digest, Vol 99, Issue 8 ******************************************

1 0

incorrect mime type detection
by Jens Wille 10 Dec '11

10 Dec '11

hi all! i have two image files i want to upload to my wiki that are detected as zip archives though they in fact are images (which `file` says, too). now i have no idea how to teach mediawiki to identify the files correctly. i can change the metadata in the database, but that only leads to another surprise: those changes are reverted the next time the image pages are accessed. huh? where does this information come from then? why are the metadata even stored in the database when it's not authoritative? can someone please shed some light on this matter. i'm absolutely new to running a mediawiki instance of my own. you can find the two files in question here: <http://linux2.fbi.fh-koeln.de/rdk-smw/Datei:01-0557-3.jpg> <http://linux2.fbi.fh-koeln.de/rdk-smw/Datei:05-0995-2.jpg> cheers jens

2 4

Memory Leak Issue
by Olivier Beaton 10 Dec '11

10 Dec '11

I recently upgraded to from 1.17.0 to 1.18.0, upgraded all my extensions. It seems to be running OK. One extension we use heavily is External Data[1] (I installed the latest), and to solve the problem of dynamic external content it recommends I turn off caching using the instructions in the MW FAQ on meta [2]. I did so yesterday afternoon, and by this morning the server had completely maxed out it's memory (despite not having any users overnight) adn was spitting out errors into the php.ini (could not allocate, etc). Trying to trace things down using top and ps, although I'm not as experienced as I'd like to be in linux, proved fruitless. Is there any tips anyone could give me on figuring out what the problem is? I've turned chaching back on and it seems to be running OK, at a steady 400MB used for the system instead of the 4GB this morning. Restarting apache didn't affect anything. I'm running MW 1.18.0 with Apache 2, PHP 5.3.3 (from redhat) w/ APC on CentOS 5.5 [1] http://www.mediawiki.org/wiki/Extension:External_Data#Common_problems [2] http://meta.wikimedia.org/wiki/MediaWiki_FAQ#How_do_I_completely_disable_ca… Thanks, Olivier Finlay Beaton

3 2

[MediaWiki-l] Skin-Synagonism
by Kaseluris-Nikos-1959 10 Dec '11

10 Dec '11

I have created the skin "synagonism" that greatly improvespage-READING by moving the table-of-contents on the left and showingthe position the reader is reading! More specifically:1) The left sidebar now is a drop-down menu, always visible.2) Thelogo, the portlets personal and search and the title of the page arealways visible.3) The table-of-contents (toc) moved on the left in asplittable-pane, always visible.4) The toc is an expandable tree.5)There is two-way communication between the toc and the articles.* Byclicking on the toc, goes to that heading and the user can copy theaddress of any section of an article.* By clicking on a section of anarticle, in the toc is highlited this section and its parents are onlyexpanded, giving to the reader the big picture of the position s|he isreading. Thus improves the readability of big articles.6) If there isno toc in a page (eg less than 3 headings), the toc automaticallycloses and leaves all the space for the article.7) Splitbar has abutton that closes|opens the toc with one click.You can find it at SourceForge: http://synagonism-mw.sourceforge.net/ I don't have much MediaWiki code experience and I am too old to bean expert on it!!! Please, If commiters are interesting in my skin's functionality, docode review and commit my skin for me. Reporting bugs to me, I'll do my best. (my slogan at the end, shows why I call my skin "synagonism"!) -- Kaseluris-Nikos-1959 Synagonism = ALL winners, Antagonism = ONE winner

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l December 2011