On Wed, Sep 17, 2008 at 2:06 PM, Hiram Clawson hiram@soe.ucsc.edu wrote:

Good Afternoon MediaWiki Fans:

I am puzzled by how update.php decides upon which database to work on when it is run. I have a number of wikis that are created merely by making symlinks for the top-level directories and files (except LocalSettings.php) to a master source wiki. When I run the update.php script in any of these sub-wikis the script thinks it is working on the primary master source wiki database. It doesn't seem to be reading the LocalSettings.php script to fetch the database name. The script is operated thusly:

$ cd sub-wiki-directory $ php maintenance/update.php

Any clarification would be much appreciated. Thanks,

--Hiram

$wgDBname controls which database is used; you should usually set it in AdminSettings.php for maintenance scripts. You will have to set it to your first database and run update.php, then set it to your second database and run update.php, and so on (barring a more elegant method).

Good Afternoon MediaWiki Fans:

I see now it works just fine even with the maintenance/ directory being a symlink to the primary source. Simply use the MW_INSTALL_PATH environment:

$ cd a_symlinked_mediaWiki_copy_top_level_directory $ MW_INSTALL_PATH=`pwd` php maintenance/update.php

It now properly reads this specific LocalSettings.php file

What it was doing was determining $IP automatically in maintenance/commandLine.inc:

$IP = ( getenv('MW_INSTALL_PATH') !== false ? getenv('MW_INSTALL_PATH') : realpath( dirname( __FILE__ ) . '/..' ) );

where realpath() was resulting in the master copy source directory.

--Hiram

Michael Daly wrote:

Benjamin Lees wrote:

...

$wgDBname controls which database is used; you should usually set it in AdminSettings.php for maintenance scripts. You will have to set it to your first database and run update.php, then set it to your second database and run update.php, and so on (barring a more elegant method).

FWIW, my preference was to not symlink the maintenance directories and have a separate one for each wiki. Then I set up a unique AdminSettings.php in each wiki's root (renamed when not in use for minimal security). The duplicate directories need only contain the single script of interest (with all scripts in main maintenance directory in the otherwise symlinked dir structure).

This way I can run scripts without thinking too hard about making sure precisely which wiki/db the script runs against.

Mike

On Wed, Sep 17, 2008 at 10:08 AM, Sullivan, James (NIH/CIT) [C] < sullivan@mail.nih.gov> wrote:

Setting those to true should only make the option available, unchecked, in the user preference. For example, if you set them to false, the options would disappear from the user preference. By making them true, they are now available to be checked, but by default are unchecked. I don't know if there is a way to make them checked by default.

-Jim

-----Original Message----- From: david [mailto:dvd@enlloc.org] Sent: Wednesday, September 17, 2008 10:02 AM To: MediaWiki announcements and site admin list Subject: [Mediawiki-l] Enotif by default

Hi;

I want to define by default some Email notification settings in my MW-wiki. I want "user talk" and "watchlist" notifications to be checked by default in users preferences page.

I have in Localsettings.php:

$wgEnableEmail = true; $wgEnableUserEmail = true;

$wgEmailAuthentication = true; $wgEnotifUserTalk = true; # UPO $wgEnotifWatchlist = true; # UPO

And in includes/DefaultSettings.php :

$wgEmailAuthentication = true; # UPO $wgEnotifWatchlist = true; # UPO $wgEnotifUserTalk = true;

Maybe I've something wrong?

Thanks,

dvdgmz

Use $wgDefaultUserOptions < http://www.mediawiki.org/wiki/Manual:$wgDefaultUserOptions%3E.

Thanks for the explanation. But just what I want is to set it checked by default (and available to be unchecked by the user).

Somebody knows if it's possible to set?

-Dvdgmz

El dc 17 de 09 del 2008 a les 10:08 -0400, en/na Sullivan, James (NIH/CIT) [C] va escriure:

Setting those to true should only make the option available, unchecked, in the user preference. For example, if you set them to false, the options would disappear from the user preference. By making them true, they are now available to be checked, but by default are unchecked. I don't know if there is a way to make them checked by default.

-Jim

-----Original Message----- From: david [mailto:dvd@enlloc.org] Sent: Wednesday, September 17, 2008 10:02 AM To: MediaWiki announcements and site admin list Subject: [Mediawiki-l] Enotif by default

Hi;

I want to define by default some Email notification settings in my MW-wiki. I want "user talk" and "watchlist" notifications to be checked by default in users preferences page.

I have in Localsettings.php:

$wgEnableEmail = true; $wgEnableUserEmail = true;

$wgEmailAuthentication = true; $wgEnotifUserTalk = true; # UPO $wgEnotifWatchlist = true; # UPO

And in includes/DefaultSettings.php :

$wgEmailAuthentication = true; # UPO $wgEnotifWatchlist = true; # UPO $wgEnotifUserTalk = true;

Maybe I've something wrong?

Thanks,

dvdgmz

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hiram Clawson wrote:

If you take a look at this hidden value line in the resulting page text, you will note it looks something like this:

<input type='hidden' value="+\" name="wpEditToken" />

Note the extra back-slash in the value="+" string. Something is fishy there, it shouldn't be there.

Nothing fishy there -- the "+" are stuck on the edit token to help protect against bots which don't parse HTML correctly. If it doesn't come back intact, we don't accept the edit -- this prevents the page text from getting corrupted by the bogus bot.

This little bug caused problems in out down-stream processing which was trying to parse this FORM INPUT variable.

The bug is in your processing.

- -- brion

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Steven Dick wrote:

On Wed, Sep 17, 2008 at 3:13 PM, Brion Vibber brion@wikimedia.org wrote:

...

...

<input type='hidden' value="+\" name="wpEditToken" />

Nothing fishy there -- the "+" are stuck on the edit token to help protect against bots which don't parse HTML correctly.

I've had to add & to that list. There's a bot out there that truncates pages containing &

Not a bad idea! Ensuring that '&amp;' in the HTML makes the circuit through '&' in internal processing to '%26' in URL-encoded post submission is a good thing. :)

- -- brion

On Wed, Sep 24, 2008 at 3:24 PM, Platonides Platonides@gmail.com wrote:

There're also bots double-encoding utf-8. Are we intending to catch any broken agent with that?

If I understand how this works, any miscoding of the EditToken will cause the edit to fail. The value should be the same going out and coming back, so an incorrect double encoding will also cause it to not work.