I currently manage two public instances of MediaWiki in a scientific
community. I can't allow just anybody to create an account or edit pages
on either of them, but I don't want to have to do all of the account
creation myself. I am sufficiently trusting of my users that I think it
reasonable for any registered user to be allowed to create new users,
and I can see this as being a fairly common requirement for a semi-open
community. To implement this I enclose a simple patch, which I'd like
to see folded into the MediaWiki distribution, or something equivalent.
I have basically extended the $wgWhitelistAccount array to include an
anonymous option, which now distinguishes a logged in user from someone
who is only known by their IP address (currently enabling 'user' in the
$wgWhitelistAccount array means anyone can get an account). The code to
implement this is in User::isAllowedToCreateAccount()
The default behaviour after adding this patch is the same as before, and
most sites that have $wgWhitelistAccount defined in LocalSettings.php
file should not need to make any changes unless they wish to take
advantage of the new ability to distinguish between anonymous and
registered users.
- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.
--- mediawiki-1.4.8/includes/DefaultSettings.php
+++ mediawiki/includes/DefaultSettings.php
@@ -455,7 +455,7 @@
$wgWhitelistEdit = false; # true = user must login to edit.
$wgWhitelistRead = false; # Pages anonymous user may see, like: =
array ( "Main Page", "Special:Userlogin", "Wikipedia:Help");
-$wgWhitelistAccount = array ( 'user' => 1, 'sysop' => 1, 'developer' =>
1 );
+$wgWhitelistAccount = array ( 'anonymous' => 1, 'user' => 1, 'sysop' =>
1, 'developer' => 1 );
$wgAllowAnonymousMinor = false; # Allow anonymous users to mark
changes as 'minor'
--- mediawiki-1.4.8/includes/User.php
+++ mediawiki/includes/User.php
@@ -1187,8 +1187,10 @@
$allowed = false;
if (!$wgWhitelistAccount) { return 1; }; // default
behaviour
+ $rights = $this->getRights();
+ if ($this->getID() > 0) { $rights[] = 'user'; }
foreach ($wgWhitelistAccount as $right => $ok) {
- $userHasRight = (!strcmp($right, 'user') ||
in_array($right, $this->getRights()));
+ $userHasRight = (!strcmp($right, 'anonymous') ||
in_array($right, $rights));
$allowed |= ($ok && $userHasRight);
}
return $allowed;
Hi,
I'm having a problem with the password reset feature of mediawiki. When
a user tries to reset his or her password on the login page, a message
comes up indicating success, but the password is not reset (the old one
still works) and the user receives no e-mail. I have several wikis served
through apache on a debian box, and this is the case for all of them.
sendmail seems to be working fine, and is used successfully by a number of
other applications, including subversion and bugzilla. Any help would be
much appreciated.
--Chris Casinghino
Hi,
I'm adding content to a new wiki for a research project, and one of the
things we want to do is have lists of useful publications, organized
into various categories (some publications may be in multiple
categories). Each publication will have it's own page with an
abstract. It seems that MediaWiki's category feature is perfect for
this kind of thing, except for one issue -- the publications pages
aren't linked to/from anywhere, so they all appear as orphans. This
really clutters the orphans list, making it impossible to tell what the
"real" orphans are.
Does anyone know of a good workaround to this problem? The only thing I
can think of is creating a dummy page which links to all of the
publications pages, but that's such a hack!
Any ideas?
Thanks,
Bob Marinier
University of Michigan
Artificial Intelligence Laboratory
MediaWiki: 1.4.7
I'm a new user of MediaWiki, and am wanting to render a tree-like table
of contents, where the branches are local categories and sub-categories,
and the leaves are hyperlinks to the pages in each category. Can I
already do this with 'out of the box' MediaWiki capabilities, or must I
write an (?) extension?
Here's an example of what I want:
MyTopLevelCategory
TopLevelChildCategory
PageThatIsInChildCatetory (hyperlinked)
AnotherTopLevelCategory
AnotherChildCategory
AnotherPageThatIsInChildCatetory (hyperlinked)
This way, my main page will remain up to date without edits, and will
help me to ensure that all my pages are categorized properly.
I don't care about possible cycles in the graph - I'll just duplicate
the leaves.
Thanks for any help,
Jason.
> From: jdd <jdd(a)dodin.org>
>
> Mike Valstar wrote:
>
>> you dont need to create a link to make a new page jdd
>>
>> you can just type in the URL where you want it to go, i do it all
>> the time
>
> yes, I know that, but it's not the natural way and this
> gives the problem...
"Natural?" "Problem?"
I do this quite often. I see nothing unnatural about it at all. It
causes me no problem. I would be very against restricting this.
Just because something works differently than you had imagined does
not mean it is broken!
:::: When you change the way you look at things, the things you look
at change. -- Wayne Dyer.
:::: Jan Steinman <http://www.Bytesmiths.com/Item/99AO08-18>
I would like to throw Zope/Zwiki overboard and go with a LAMP based
knowledge base. My reasoning is that with jumping a version number
(from 2 to 3) there is no backward compatibility. Since most of our
content is in 2, and there is a LOT of content, I want to go ahead and
make the transition with something LAMP based. Also, I am more familiar
with LAMP based apps. So, MediaWiki seems to be that choice.
We currently use Zope for knowledge base purposes. As I said
previously, it has a bunch of content. My question is:
Has anyone ever gone from a Zope architecture to MediaWiki? If so, are
there any tools available to export the data from Zope so as to import
it into MediaWiki? Or is this just going to be an ugly cut and paste
nightmare?
Thanks,
Tim
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MediaWiki 1.5rc1 is a preview release of the new 1.5 release series.
Numerous bug fixes since last beta, plus a security fix; see change
log in the release notes for full details.
A flaw in the interaction between extensions and HTML attribute
sanitization was discovered which could allow unauthorized use
of offsite resources in style sheets, and possible exploitation
of a JavaScript injection feature on Microsoft Internet Explorer.
This version expands the returned text and properly checks it
before output.
MediaWiki 1.4.8 is a bug fix and security maintenance release. It fixes
the above bug, plus an update to skins/MonoBook.php ensures that sites
using the default MonoBook skin will display correctly in the Internet
Explorer 7 beta. (1.3 and 1.5 are not affected by this display problem.)
MediaWiki 1.3.14 is a security maintenance release.
The 1.3.x series is no longer maintained except for security fixes;
new users and those seeking bug fixes should upgrade to 1.4.8 or 1.5rc1.
Existing 1.3.x installations not willing to upgrade to the current
stable relase should apply the change manually; details are in the
release notes.
If you are actively using extensions to generate HTML attribute values,
upgrade to 1.4 or 1.5 for a full fix; 1.3.14 simply disables any attempt
to use such.
Release notes:
1.5rc1: http://sourceforge.net/project/shownotes.php?release_id=351260
1.4.8: http://sourceforge.net/project/shownotes.php?release_id=351258
1.3.14: http://sourceforge.net/project/shownotes.php?release_id=351257
Download:
http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.5rc1.tar.gz?downlo…http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.4.8.tar.gz?downloadhttp://prdownloads.sourceforge.net/wikipedia/mediawiki-1.3.14.tar.gz?downlo…
MD5 checksums:
mediawiki-1.5rc1.tar.gz f8b61f0cdac4ed8a7ed7aecf02d3bc78
mediawiki-1.4.8.tar.gz 69112673e0599049dc962d4c904feb6b
mediawiki-1.3.14.tar.gz 2d65015aff380620434e381a4d60b57a
Before asking for help, try the FAQ:
http://meta.wikimedia.org/wiki/MediaWiki_FAQ
Low-traffic release announcements mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-announce
Wiki admin help mailing list:
http://mail.wikipedia.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 Thunderbird - http://enigmail.mozdev.org
iD8DBQFDC6prwRnhpk1wk44RAr3YAJ9Aqw7b3cQ6COpMvixX5ty1NEEJRACgi0rK
c5kgvf2tc/DMeMkFtI8TZqQ=
=oHMy
-----END PGP SIGNATURE-----
Hi
How to remove article,discussion,edit,history tabs for anonymous users ?
Also special pages link also to be removed for anonymous users.
These tabs/links should come only if the user is logged in ?
please let me know which file I need to edit for this ?
I am using the skin monobook.
Thanks
Sandeep A.S
Hi i would like to change the name of my wiki and have the new name
reflected in the url's that are used to access the pages. I tried renaming
all the relevent parts in localsettings.php and also renaming the root
folder containing the wiki. This almost worked accept when ever i try and
click on a link away from the front page the link points to a location
with the old wiki name in it and obviously doesn't find it. Is there
anyway to rebulid the mysql database so that all the links are rewritten
according to the new name?
regards
caspar
===============================================================
National Australia Group Europe Limited (Company Number 02108635, Registered Office 88 Wood Street, London EC2V 7QQ) (NAGE) is a subsidiary of National Australia Bank Limited (an Australian registered company). The following UK companies are authorised and regulated by the Financial Services Authority: Clydesdale Bank PLC (trading as Clydesdale Bank and Yorkshire Bank), MLC Savings Limited, MLC Trust Management Company Limited, Clydesdale Bank Insurance Brokers Limited, Yorkshire Bank Financial Services Limited, National Australia Insurance Services Limited and Custom Fleet Limited.
The views and opinions expressed in this email may not reflect the views and opinions of any member of the group of which NAGE forms part. The information contained in this message is confidential and may also be privileged. It is intended only for the addressee named above. The unauthorised use, disclosure, copying or alteration of this message is strictly prohibited. If you are not the addressee (or responsible for delivery of the message to the addressee), please notify the originator immediately by return message and destroy the original message. This message and any attachments have been scanned for viruses prior to leaving the NAGE network. However, NAGE does not guarantee the security of this message and will not be responsible for any damages arising as a result of any virus being passed on or arising from any alteration of this message by a third party. NAGE may monitor emails sent to and from the NAGE network.