MediaWiki-l July 2006

mediawiki-l@lists.wikimedia.org

191 participants
295 discussions

New wiki global: $wgOpenExternalLinkInNewWindow
by Hugh Prior 08 Jul '06

08 Jul '06

Dunno who to suggest this to, but this seems like a high value, low work improvement to MediaWiki (excuse me if it has already been added - I'm back on 1.5.7). Say "aye" if you think it is a good idea. Suggest alternate names for the variable if you think this one sucks. Hugh in DefaultSettings.php add: /** Set to true to open external links in a new window $wgOpenExternalLinkInNewWindow = false; in */includes/linker.php* function getExternalLinkAttributes ... After $r = ($class != '') ? " class='$class'" : " class='external'"; add the following code: global $wgOpenExternalLinkInNewWindow; if ($wgOpenExternalLinkInNewWindow) { $r .= " target=\"_blank\""; }

2 5

MediaWiki 1.7.0 released
by Brion Vibber 08 Jul '06

08 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the quarterly release snapshot for Summer 2006. While the code has been running on Wikipedia for some time, installation and upgrade bits may be less well tested. Bug fix releases may follow in the coming days or weeks. MediaWiki is now using a "continuous integration" development model with quarterly snapshot releases. The latest development code is always kept "ready to run", and in fact runs our own sites on Wikipedia. Release branches will continue to receive security updates for about a year from first release, but nonessential bugfixes and feature development happen on the development trunk and appear in the next quarterly release. Those wishing to use the latest code instead of a branch release can obtain it from source control: http://www.mediawiki.org/wiki/Download_from_SVN This is the first version of MediaWiki to require PHP 5. 5.1.x is recommended; 5.0 may work but is not well tested. (PHP 5.0 is no longer maintained; all PHP 5.0 users should upgrade to a current 5.1 release to ensure they have all security fixes.) PHP 4.x is no longer supported by MediaWiki. If you are unable to upgrade PHP, sorry, but you will have to stick with old versions of MediaWiki for now. Full release notes: http://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_7_0/phase3/RELEASE-NOTES http://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_7_0/phase3/HISTORY Download: http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.7.0.tar.gz MD5 checksum: d3b0ed529ae5ac9dfe713fbdbeae8025 mediawiki-1.7.0.tar.gz SHA-1 checksum: 90c484ad4c2c20023ee1dcbd0eb2904e1a6a1727 mediawiki-1.7.0.tar.gz Before asking for help, try the FAQ: http://www.mediawiki.org/wiki/Help:FAQ Low-traffic release announcements mailing list: (Please subscribe to receive announcements of security updates.) http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce Wiki admin help mailing list: http://mail.wikimedia.org/mailman/listinfo/mediawiki-l Bug report system: http://bugzilla.wikimedia.org/ Play "stump the developers" live on IRC: #mediawiki on irc.freenode.net - -- brion vibber (brion @ pobox.com) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErr/xwRnhpk1wk44RAoIoAJ0bj15IFY+Svs0rTnKVbVvZ21kdTgCfYfq2 airYE+1H4ga28uhXTSXNL+k= =o2qo -----END PGP SIGNATURE-----

2 1

problem with ' in sidebar
by jdd 08 Jul '06

08 Jul '06

This may be very outdated, given the near 1.7 :-( - but, just in case http://validator.w3.org/check?uri=http%3A%2F%2Fdodin.org%2Fmediawiki%2Finde… (check of the http://dodin.org/mediawiki/index.php/Accueil page) MediaWiki: 1.6.3 (I wait for 1.7 to update) the source problematic line is that: <li id="n-Vue-d'ensemble"><a href="/mediawiki/index.php/Essai">Vue d'ensemble</a></li> and the problem come from the "id", that don't like the "'". But using code in the mediawiki text is not allowed :-( thanks jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

2 2

Shameless plug: BadImage extension
by Rob Church 08 Jul '06

08 Jul '06

While we argue over at wikitech-l about how best to manage the bad image list in future, I thought it might be prudent to go ahead and write a decent extension for it, using the database, and supporting caching and all sorts of performance niceties. This works with MediaWiki 1.7 and above and is available from Subversion. Take a look at http://www.mediawiki.org/wiki/Bad_Image_List for information on downloading it, installing it and using the damn thing. Background: MediaWiki's "bad image list" allows trusted users to name images which won't ever be allowed to be rendered inline or in categories, etc. The built-in stuff sucks however, and is a real performance bitch when it's got a lot of items on it. Rob Church

1 0

meta.wikimedia.org/wiki/SpecialMultiUploadViaZip (an ugly hack!)
by dme26-mwl＠srcf.ucam.org 08 Jul '06

08 Jul '06

This is the first time I've tried to submit code to the MediaWiki community, so please accept my apologies if I have gone about doing so the wrong way. (and apologies the extension itself is such a hack and/or is already redundant because of others' work I wasn't aware of - I've noted SpecialUploadLocal recently) SpecialMultipleUplaoadViaZip has been added as a meta.wikimedia.org page including the special page extension's source code. As that page describes, this special page provides a form for uploading a ZIP file that is subsequently decompressed and passed directly to a class extended from the existing MediaWiki file upload form. I needed a multiple file uploading tool for a local intranet wiki I manage(ish). I suspect this feature might have already been scheduled to be included for future releases in a manner far cleaner than the hack I've done. Still, I figured it still might be useful for the community even so (e.g. possibly for those running to-be-legacy MediaWiki releases into which this extension might be able to be installed). Best wishes, Dave

2 2

Re: [Mediawiki-l] Restricting write access for a custom namespaceto asingle group
by Isaac Guenard 08 Jul '06

08 Jul '06

Wow. It was a stupid PHP typo. All working now. Sorry for all the text on this, hopefully it helps someone else in the future. The code that finally worked was ------------------ function userCanEdit() { /* return $this->userCan('edit'); */ global $wgUser; if( $wgUser->isAllowed('edit') ) { if( $this->getNamespace() == 100 ) { if( $wgUser->isAllowed('viewforbidden') ) { return true; } else { return false; } } else { return true; } } else { return false; } } --------------- Can anyone think of any reason why this would be a bad idea? Thanks Isaac Guenard Sr. Product Manager - eyeon Software web : www.eyeonline.com email : izyk(a)eyeonline.com phone : 416 686-8411 x300 -----Original Message----- From: mediawiki-l-bounces(a)Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Isaac Guenard Sent: Friday, July 07, 2006 3:59 PM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] Restricting write access for a custom namespaceto asingle group A progress report. I attempted to modify the code from the Preventing_Access page to suit my needs, and ended up with the following function userCanEdit() { global $wgUser; $result = null; wfRunHooks( 'userCan', array( &$this, &$wgUser, 'edit', &$result ) ); if ( $result !== null ) { return $result; } if( $wgUser->isAllowed('edit') ) { if( $this->getNamespace() == 100 ) { if( $wgUser->isAllowed('viewforbidden') ) { return true; } else { return false; } } } else { return false; } } While this does not generate an error, in testing it on pages in my main namespace, it seems all pages become Protected. I have no idea what wfRunHooks does, so I guess that’s what I need to look at next.... Thanks Isaac Guenard Sr. Product Manager - eyeon Software web : www.eyeonline.com email : izyk(a)eyeonline.com phone : 416 686-8411 x300 -----Original Message----- From: mediawiki-l-bounces(a)Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Isaac Guenard Sent: Friday, July 07, 2006 2:48 PM To: mediawiki-l(a)Wikimedia.org Subject: [Mediawiki-l] Restricting write access for a custom namespace to asingle group Hello I am searching the archives for an answer at the moment, but it’s a pretty long task, so I thought I would post the question while I searched in case anyone had an answer. In http://meta.wikimedia.org/wiki/Preventing_Access there is an excellent section detailing how to restrict read access for a custom namespace to a single group. I am attempting to modify the same approach so that I can restrict edit access instead. The idea is that we intend to operate a public wiki, but a small portion of the content is to be set aside to host the official product documentation. I want this custom namespace to only permit edit access to members of a custom group. At first glance, it seems I need to edit Title.php and modify the userCanEdit() function, but my initial attempts generate some pretty gnarly errors. My PHP skills are VERY novice level, and I have only been using Wikipedia for a week, so I feel a bit like a bull in a fine china shop. Can anyone provide a hint or some pointers? Thanks Isaac Guenard Sr. Product Manager - eyeon Software web : www.eyeonline.com email : izyk(a)eyeonline.com phone : 416 686-8411 x300 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006 _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006 _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006

1 0

Re: [Mediawiki-l] Restricting write access for a custom namespace to asingle group
by Isaac Guenard 08 Jul '06

08 Jul '06

A progress report. I attempted to modify the code from the Preventing_Access page to suit my needs, and ended up with the following function userCanEdit() { global $wgUser; $result = null; wfRunHooks( 'userCan', array( &$this, &$wgUser, 'edit', &$result ) ); if ( $result !== null ) { return $result; } if( $wgUser->isAllowed('edit') ) { if( $this->getNamespace() == 100 ) { if( $wgUser->isAllowed('viewforbidden') ) { return true; } else { return false; } } } else { return false; } } While this does not generate an error, in testing it on pages in my main namespace, it seems all pages become Protected. I have no idea what wfRunHooks does, so I guess that’s what I need to look at next.... Thanks Isaac Guenard Sr. Product Manager - eyeon Software web : www.eyeonline.com email : izyk(a)eyeonline.com phone : 416 686-8411 x300 -----Original Message----- From: mediawiki-l-bounces(a)Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Isaac Guenard Sent: Friday, July 07, 2006 2:48 PM To: mediawiki-l(a)Wikimedia.org Subject: [Mediawiki-l] Restricting write access for a custom namespace to asingle group Hello I am searching the archives for an answer at the moment, but it’s a pretty long task, so I thought I would post the question while I searched in case anyone had an answer. In http://meta.wikimedia.org/wiki/Preventing_Access there is an excellent section detailing how to restrict read access for a custom namespace to a single group. I am attempting to modify the same approach so that I can restrict edit access instead. The idea is that we intend to operate a public wiki, but a small portion of the content is to be set aside to host the official product documentation. I want this custom namespace to only permit edit access to members of a custom group. At first glance, it seems I need to edit Title.php and modify the userCanEdit() function, but my initial attempts generate some pretty gnarly errors. My PHP skills are VERY novice level, and I have only been using Wikipedia for a week, so I feel a bit like a bull in a fine china shop. Can anyone provide a hint or some pointers? Thanks Isaac Guenard Sr. Product Manager - eyeon Software web : www.eyeonline.com email : izyk(a)eyeonline.com phone : 416 686-8411 x300 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006 _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006

1 0

Re: [Mediawiki-l] MediaWiki 1.7.0 release candidate
by Jimmy.Collins＠web.de 08 Jul '06

08 Jul '06

Like written in the RELEASE-NOTES: [...] MediaWiki is now using a "continuous integration" development model with quarterly snapshot releases. The latest development code is always kept "ready to run", and in fact runs our own sites on Wikipedia. [...] Cheers, Jimmy > -----Ursprüngliche Nachricht----- > Von: MediaWiki announcements and site admin list <mediawiki-l(a)Wikimedia.org> > Gesendet: 07.07.06 21:02:40 > An: "Wikimedia developers" <wikitech-l(a)wikimedia.org> > Betreff: Re: [Mediawiki-l] MediaWiki 1.7.0 release candidate > Question... I installed 1.4 just over a year ago and now there have been at > least 3 major revs since then. Is there any point of maturity forseeable > on the horizon, or do we just have to expect a new must-have revision every > few months or so? > > -----Original Message----- > From: mediawiki-l-bounces(a)Wikimedia.org > [mailto:mediawiki-l-bounces@Wikimedia.org]On Behalf Of Brion Vibber > Sent: Thursday, July 06, 2006 8:10 PM > To: Wikimedia developers; MediaWiki announcements and site admin list > Subject: [Mediawiki-l] MediaWiki 1.7.0 release candidate > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Earlier today I branched off 1.7 in our subversion repository, and made a > release candidate: > > http://svn.wikimedia.org/snapshots/mediawiki-1.7.0rc.tar.gz > > It's marked as just 1.7.0 internally. If there's no reports of major > breakage by > tomorrow morning I'll re-zip it as 1.7.0 final. I'd appreciate if a few > people > could test installation and upgrading, which don't receive as much testing > from > Wikipedia as other code. > > - -- brion vibber (brion @ pobox.com) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEraZFwRnhpk1wk44RAufHAKC+5HTqyUk4BlolsCXipMSbrjOAbACfXtg6 > sZ4oQ5H84wpZLVYIJ3ESzec= > =N84K > -----END PGP SIGNATURE----- > > > > _______________________________________________ > MediaWiki-l mailing list > MediaWiki-l(a)Wikimedia.org > http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

1 0

Have external user authentication for my Wiki?
by Nick Ellson 07 Jul '06

07 Jul '06

I'd like to have my users authenticate to their Wiki accounts via an external authentication system, like LDAP/RADIUS/SMB, can MediaWiki offload the authentication process in anyway? Nick -- Nick Ellson CCDA, CCNP, CCSP, CCAI, MCSE 2000, Security+, Network+ Network Hobbyist, VFR Private Pilot.

2 2

Strange problem with Cite extension
by Alexander Nofftz 07 Jul '06

07 Jul '06

Hi! I have a very strange problem with the Cite extension in my wiki: http://www.perrypedia.proc.org/Perrypedia:Testseite_für_Cite Footnotes and references work, but a DTD reference is put into the text. I first thought that this was produced by Tidy, but setting $wpUseTidy to false in LocalSettings.php doesn't help at all. Regards, Alex

2 2

← Newer
1
...
20
21
22
23
24
25
26
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l July 2006