There's a certain set of extensions that are necessary to replicate the
behavior of wikipedia. I would recommend looking at the Special:Version page
on wikipedia and installing the extensions listed there.
On Wed, Aug 20, 2008 at 1:59 PM, Sabina Podjed <sabina.p(a)people4earth.net>wrote:
> Hello!
>
>
>
> I need an advice regarding the MediaWiki extensions.
>
> Which extensions do you recommend us to install?
>
> Should we install all the extensions (
> http://toolserver.org/~vvv/mw-nightly/<http://toolserver.org/%7Evvv/mw-nightly/>
> <http://toolserver.org/%7Evvv/mw-nightly/> ) only the most important one.
> Which extensions are "must have"?
>
>
> We have a 1.13. version of MediaWiki.
>
>
>
>
>
> I would also need some advice how to install the licensing feature to the
> UPLOAD FILE page.
>
>
>
> Cheers,
>
> Sabina
>
> People4earth.net
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Hello!
I need an advice regarding the MediaWiki extensions.
Which extensions do you recommend us to install?
Should we install all the extensions (http://toolserver.org/~vvv/mw-nightly/
<http://toolserver.org/%7Evvv/mw-nightly/> ) only the most important one.
Which extensions are "must have"?
We have a 1.13. version of MediaWiki.
I would also need some advice how to install the licensing feature to the
UPLOAD FILE page.
Cheers,
Sabina
People4earth.net
On Wed, Aug 20, 2008 at 3:40 AM, <brion(a)svn.wikimedia.org> wrote:
> Revision: 39650
> Author: brion
> Date: 2008-08-19 17:40:00 +0000 (Tue, 19 Aug 2008)
>
> Log Message:
> -----------
> Revert r39582 "(bug 12518) Interwiki userrights now reflects remote groups, not local groups."
> This won't actually work -- it checks the InitialiseSettings.php conf array for $wgGroupPermissions, but we don't set $wgGroupPermissions individually for every wiki. We use a system of several override variables which get applied in CommonSettings.php onto the default template.
>
Yes, so I saw when I researched this. However, the patch I applied
will fall back to current behaviour, and I've committed the updates to
SiteConfiguration.php to allow it to work if you update the config
files accordingly. If you'd rather not use the new SiteConfiguration
changes, I can always have another fallback to opening the foreign DB
and SELECTing DISTINCT ug_groups, and combining that with a list of
local groups.
--
Andrew Garrett
I am not sure if this is the right place to post this. I used to have SVN commit
access. As far as I know, I still do/should. However, I haven't used it for some
time due to a rather busy couple of months. Now, I can no longer commit anything
to the repos. When I try to do so, I get the following message:
"svn-commit.5.tmp" 5L, 106C written
svn: Commit failed (details follow):
svn: Can't create directory '/svnroot/mediawiki/db/transactions/39596-1.txn':
Permission denied
svn: Your commit message was left in a temporary file:
svn: '/home/gri6507/Documents/extensions/svn-commit.5.tmp'
I have changed my computers in the mean time, so it's quite possible that my
"secret recipe" for SVN access is now lost. Can someone please point me in the
right direction to get this resolved?
Thank you in advance.
werdna(a)svn.wikimedia.org wrote:
> function extractGlobal( $setting, $wiki, $suffix, $params, $wikiTags = array() ) {
> $value = $this->get( $setting, $wiki, $suffix, $params, $wikiTags );
> if ( !is_null( $value ) ) {
> - $GLOBALS[$setting] = $value;
> + if (substr($setting,0,1) == '+'&& is_array($value)) {
> + $setting = substr($setting,1);
> + if ( is_array($GLOBALS[$setting]) ) {
> + $GLOBALS[$setting] = array_merge( $GLOBALS[$setting], $value );
> + } else {
> + $GLOBALS[$setting] = $value;
> + }
> + } else {
> + $GLOBALS[$setting] = $value;
> + }
> }
> }
* Note that extractGlobal() is not used on Wikimedia.
* extractGlobal() supposes that configuration variable has a "+" prefix,
while get() supposes that target wiki should have it.
* Mergability should be property of a configuration variable (so we use
"+wgGroupPermissions" instead of "wgGroupPermissions" => array(
"+enwiki" => ... ).
* It doesn't seem to merge arrays recursively. That means that in
"wgGroupPermissions" => array(
'default' => array( 'user' => array( 'something' => true ) ),
'enwiki' => array( 'user' => array( 'somthingelse' => true ) ),
) enwiki settings will override defaults, therefore you should use
array_merge_recursive().
* If we want it to be usable for other parts of the code which are ran
when $wgConf is already extracted, we need to know default settings. To
determine default settings it's possible to include DefaultSettings.php
in the local scope and get a value of the configuration variable, but it
does not work with group permissions since they are modified by
extensions + CommonSettings.php also modifies them.
--vvv
brion(a)svn.wikimedia.org schreef:
> Revision: 39622
> Author: brion
> Date: 2008-08-19 00:15:05 +0000 (Tue, 19 Aug 2008)
>
> Log Message:
> -----------
> Revert r39503, 39507 "(bug 14468) Lines in classic RecentChanges and Watchlist now have classes "odd" and "even" to make colouring using css possible."
>
> These alternating background colors are imho not very attractive, and make the display busy and confusing, rather than easier to read.
The fact that you don't think it doesn't look good doesn't mean no one
wants it. Changing the CSS so odd and even have the same style by
default will effectively disable this feature by default, yet making it
very easy to enable.
Roan Kattouw (Catrope)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
demon(a)svn.wikimedia.org wrote:
> +* $wgEnablePersistentCookies has been added. Setting to false disables the
> + setting of persistent cookies. Defaults to true.
Hmm, would it be better to handle this simply by setting
$wgCookieExpiration to 0? This would make all cookies session-limited.
Otherwise I might recommend changing the name a bit; rather than being
specific to *persistent* cookies it should be about setting
*non-session-related* cookies.
- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkipx5EACgkQwRnhpk1wk46BEACfbGKtUwteJP3yuiVRgdWtMDi+
Ka0AoLW12hlYksr23/QabM8q4xJVdGr/
=lIjo
-----END PGP SIGNATURE-----
dantman(a)svn.wikimedia.org schreef:
> Revision: 39568
> Author: dantman
> Date: 2008-08-18 03:56:38 +0000 (Mon, 18 Aug 2008)
>
> Log Message:
> -----------
> Create a placeholder for the LinkHook experimentation.
> This will allow us to develop a new method of parsing links (non-hacky), without breaking current syntax, and also allow us to make sure new methods don't break syntax.
>
> Currently this class merely inherits from the Parser class. Constants and static functions are coppied so that use of self:: won't break when we modify things.
Why don't you just use parent:: wrappers for the static functions, like:
static function func($foo, $bar) { return parent::func($foo, $bar); }
Roan Kattouw (Catrope)
Hi all,
We've spoken a bit about allowing local groups to be changeable by
stewards as global groups are. Well, after an hour or so's work, I
have in my working copy changes to the MediaWiki core which will allow
local groups to be changeable just as global groups are, on a new
special page (I've been able to co-opt the
Special:GlobalGroupPermissions interface for Special:GroupRights,
which is the new interface for changing these rights. The CentralAuth
version is now a subclass of this page.)
The rough working of it is a new source of user rights - group_rights
table. This is heavily cached (in-process, on the filesystem, in
memcached), and will be loaded any time somebody would have otherwise
requested $wgGroupPermissions. $wgGroupPermissions is strictly for
configuration now - all places using it have been converted to use a
static method of the User object called getAllGroupPermissions.
I've still got to import messages, look into making
addgroups/removegroups changeable on-wiki, and a few other things,
but, within a few days, I should be ready to check this in, provided
the schema change is okay with Brion, Tim, et cetera.
Thanks
--
Andrew Garrett