gmane.org.wikimedia.mediawiki

Re: build 'next' button

david — 2008-10-07T22:57:27

Thank you Thomas. I have my PREVIOUS and NEXT buttons/links working now: PREVIOUS: {{#ifeq:{{SUBPAGENAME}}|1|[[{{BASEPAGENAME}}| Mainpage]]|[[{{BASEPAGENAME}}/{{ #expr:{{SUBPAGENAME}}-1}}|Previous]]}} NEXT: {{exists | page={{BASEPAGENAME}}/{{#expr:{{SUBPAGENAME}}+1}} | then=[[{{BASEPAGENAME}}/{{ #expr:{{SUBPAGENAME}}+1}}|Next]] | else= }} Here I use the "exist template"* from "meta" because #ifexist didn't evaluate {{BASEPAGENAME}}/{{#expr:{{SUBPAGENAME}}+1}} as a page. * http://meta.wikimedia.org/wiki/Template:Exists I'm using these links in pages like: Title Title/1 Title/2 ... El dt 07 de 10 del 2008 a les 21:26 +0100, en/na Thomas Dalton va escriure:

Re: Bad signature for 1.13.2

Brion Vibber — 2008-10-07T21:24:07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Starling wrote: A malicious replacement of the master files wouldn't then be protected, as the attacker could update the hash files (which, unlike signatures, wouldn't show a different signing key to make them suspicious). Relying solely on the security of the download server and whatever the file permissions on that directory happen to be at the time is nice and all, but posting the damn hashes adds defense in depth and, most importantly, *raises a warning* when a release has been silently changed, which should never happen -- at best it complicates support issues since it's harder for people (who don't know how to check hashes, or who can't find the second announce about the change) to know which version they've got, etc. If hash-based this would be very annoying for people doing any custom patching. :) A general "check all files to make sure PHP parses them correctly" might be nice, though. - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.

Re: MediaWiki 1.12.1 Issue

Russ Lavoy — 2008-10-07T21:09:26

Sorry it took me so long... Here are my settings... $wgMainCacheType = CACHE_MEMCACHED; $wgSessionsInMemcached = true; $wgMemCachedServers = array("server1:11211", "server2:11211", "server3:11211", "server4:11211"); $wgCacheEpoch = max( $wgCacheEpoch, $configdate ); Am I missing anything? Thanks --- On Mon, 10/6/08, Tim Starling public.gmane.org> wrote:

Re: build 'next' button

Thomas Dalton — 2008-10-07T20:26:04

The expr function in http://www.mediawiki.org/wiki/Extension:ParserFunctions might do the job.

build 'next' button

david — 2008-10-07T17:46:49

Hi; I have this pages: Title/1 Title/2 Title/3 ... I would want a Template to have a NEXT button on each page. Is there any way to add +1 to {{SUBPAGENAME}} or something like that? ---- ES Tengo estas páginas: Título/1 Título/2 Título/3 ... Quisiera una Plantilla para tener un botón de PASA-SIGUIENTE en cada página. ¿Hay alguna forma de sumar +1 a {{SUBPAGENAME}} o algo parecido? _______________________________________________ MediaWiki-l mailing list MediaWiki-l< at >lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Issue with usernames in internet explorer

Simon Orr — 2008-10-07T09:28:51

Hi all, Apologies if this is the wrong list for this query but I don't believe so... Installed software listed at the bottom. When creating an account /logging into Mediawiki using firefox, everything works perfectly. when attempting to create a user or login in IE, I get an error about an invalid username. Example Usernames: John.Smith (I've also tried john.smith, johnsmith, Johnsmith, etc...) I've pulled apart the SpecialUserLogin.php page and found that the function authenticateUserData is rejecting the username at the first test as the username appears to be blank. function authenticateUserData() { global $wgUser, $wgAuth; if ( '' == $this->mName ) { return self::NO_NAME; } /*...*/ I've used Fiddler2 to monitor the data POSTed to the wiki and the username and password are both being sent correctly. I've decreased the post_max_size and upload_max_filesize to be 16MB (Instead of 50) as suggested in a thread on the boards but no joy (and yes, I restarted ap

Re: "parse" form output

K. Peachey — 2008-10-07T06:31:39

You could run the output from the form though a php function called str_replace (http://au.php.net/str_replace). Most other languages should also have something similar as well.

"parse" form output

Martin S — 2008-10-07T05:58:46

Not sure which list this should go to, but.... I want to take the output from a Semantic form field and turn the string which is rendered as a,b,c,d,e,f into something very similar to a b c d e f ie. turning "," into "
". Is this possible and how - haven't figured out what to google on, so any hints appreciated. Regards, Martin S

Re: MediaWiki 1.12.1 Issue

Tim Starling — 2008-10-07T04:50:53

What are your cache settings, $wg*CacheType etc.?

Re: Bad signature for 1.13.2

Tim Starling — 2008-10-07T04:42:46

HTTPS has cryptographic block hashes, so the file would be protected against corruption during download. Additionally, we could host hashes on the HTTPS server instead of sending them out by email. That way we could update the tarball without sending out a new release announcement, and reduce the amount of technical clutter in the email. Since uploading the files to storage2 requires root access, I think the scenario of foul play on the server side falls into the "screwed anyway" category. An attacker could just wait for someone to log in with key forwarding enabled, and then edit the source files in SVN. As for inadvertent corruption during upload, it's done by ssh so there's a cryptographic block hash during transport, and there's the gzip checksum as well. All of this misses the most common source of file corruption, which is the FTP upload from a user's computer to their shared hosting account, post-unpack. We often get reports on IRC of files missing or truncated. We had one just today (RingtailedFo

Re: Duplicator

38388149 — 2008-10-07T03:30:24

I can't understand it.Thank you. I like wiki. ------------------ Original ------------------ From: "Frames Project"public.gmane.org>; Date: Mon, Oct 6, 2008 04:04 PM To: "MediaWiki announcements and site admin list"public.gmane.orgedia.org>; Subject: Re: [Mediawiki-l] Duplicator Le lundi 06 octobre 2008 à 00:28 +0200, Platonides a écrit : Good question. Checking my LocalSettings.php I discovered that the two lines I added $wgDuplicatorRevisionLimit = 500; require_once( "{$IP}/extensions/Duplicator/Duplicator.php" ); had disappeared ! By the way, the documentation says : http://www.mediawiki.org/wiki/Extension:Duplicator For MediaWiki 1.11.0 and above, use the trunk version it is not true I got an error with it. For 1.11.0 it is necessary to use Duplicator-MW1.11-r25543.tar.gz and it works fine. Thanks, Fran?ois Colonna _______________________________________________ MediaWiki-l mailing list MediaWiki-l-R

Re: Bad signature for 1.13.2

Brion Vibber — 2008-10-07T01:18:41

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Starling wrote: Hashes and keys are nice for confirming that: a) the file wasn't corrupted in download or on a mirror b) the file didn't get corrupted on the master download server c) the file didn't get surreptitiously replaced by an attacker HTTPS helps with none of these. (A signature file *on the same server* could have been replaced with another signature file with a valid signature... but unless the signer's key was compromised it would be with a different key, likely not a trusted one.) Note also that checksums of source packages are often checked automatically as part of package build systems, to confirm that the right file was downloaded. - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjquPEACgkQwRnhpk1wk44tFACfWtbluFsmvUMO9RQK/GeD9xNj vwMAoJAQX9q+q0VeHfjYr1DG/Xs8naOM =GVRX -----END PGP SIGNATURE-----

Re: Bad signature for 1.13.2

Tim Starling — 2008-10-06T23:50:02

It takes about 10 minutes to upload all the files for a release. I didn't want to wait that long, so I generated them on zwinger instead, where I don't have a GPG key. Maybe we could just serve the uploads via HTTPS and quit this mucking around with hashes and GPG. Hardly anyone checks them anyway.

Re: exporting page with images

Platonides — 2008-10-06T21:17:25

You should just provide the title, no {{ }}. If it's a template prefix with Template: However, if it doesn't recognise prop=images you may be running a mediawiki version with an old api which doesn't have that parameter.

Re: file does not exist: cologneblue?

Brion Vibber — 2008-10-06T21:17:21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Barrett wrote: Cologne Blue is an old-style skin, and keeps its stylesheet in the common directory: skins/common/cologneblue.css Your errors might be from the crappy old code in wikibits.js to load up skin-specific Opera 6, Opera 7, and KHTML fix files. - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjqgGEACgkQwRnhpk1wk451JACfdVqAiHlPyLmZearfug1Zgjp3 h2MAn3pn1M5gf13tI0GP0bG/h1kV23+H =ztlS -----END PGP SIGNATURE-----

Re: Duplicator

Platonides — 2008-10-06T20:58:19

Well, for older versions, you should use the extension at the appropiate branch. In your case, http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_11/extensions/Duplicator/

file does not exist: cologneblue?

Daniel Barrett — 2008-10-06T18:27:20

My Apache error log is filling with this message (MediaWiki 1.13.2): File does not exist: /skins/cologneblue I see skins/CologneBlue.php exists but there is no skins/cologneblue subdirectory. Any idea why this is so? DanB

MediaWiki 1.12.1 Issue

Russ Lavoy — 2008-10-06T18:13:02

After upgrading my 1.12.0 version to 1.12.1 version everything broke with amazing server overloads... I see that the 1.12.1 patch file includes changes to how mediawiki uses memcached and this changed destroyed the site I am over... Any time I tried to bring up the site all the apache processes start flowing in and the frontend webservers hit about 30 load (Linux terms) in less than 2 minutes... I use APC and memcached and have not had an issue with previous upgrades (from 1.9 to now 1.12 currently). But the 1.12.1 upgrade was fine in my staging enviornment and everything worked. But once I put into production and it got a good load... It blew up and would no longer respond. No other upgrades happened during this time. PHP is the same, mysql is the same and so is apache... The only thing I changed was the mediawiki version... I got around this issue by reverting back to 1.12.0 which I did not want to do with the current security patch that is out there... Can anyone help me out with this? Thanks

Re: importTextFile.php: new version

Brion Vibber — 2008-10-06T17:29:00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alessandra wrote: Hi Alessandra -- The best place to put patches is to open a bug/feature request in our bug tracker: https://bugzilla.wikimedia.org/ You can attach the patch or updated file there so we can take a look over it and commit it to source control if things look good. - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjqStwACgkQwRnhpk1wk475lQCdEof/vyKVEcHgUc32YnUmBqsB aJIAni1vlALgK1+wqOpFerIQSSQtu14T =oJc3 -----END PGP SIGNATURE-----

Re: Bad signature for 1.13.2

Brion Vibber — 2008-10-06T17:25:45

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andre Bonhote wrote: There was an error in the original release (version numbers not updated), so it was re-issued: http://lists.wikimedia.org/pipermail/mediawiki-announce/2008-October/000079.html Matches the updated release announce. Looks like Tim forgot to update the GPG signature files when he re-issued the release; we'll make sure they get re-done. The file checksums match, so we're good for now. :) - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjqShkACgkQwRnhpk1wk46K2gCcDWJw7JV8fnhnc/9cq6x/61/I jm8AoKErb2LFdtGf6MVAF/hE+W7PucHZ =HmPc -----END PGP SIGNATURE-----

importTextFile.php: new version

Alessandra — 2008-10-06T16:22:53

Hi all, I revised maintenance/importTextFile.php New version works as old version but it has got a new option: --morepages contents more wiki pages divide by Title for the new page<title> so, if you want insert more pages in one step, then you create one file with all pages divide by <title>Title for the new page<title> and usage command: php importTextFile.php --morepages <options> <filename> How can I insert new version in mediawiki package? Thanks, </article> </main></body></html>