-- Kaseluris-Nikos-1959 Synagonism = ALL winners, Antagonism = ONE winner ------------------------------ Message: 4 Date: Sat, 10 Dec 2011 17:00:24 +1000 From: "K. Peachey" p858snake@gmail.com Subject: Re: [Mediawiki-l] [MediaWiki-l] Skin-Synagonism To: MediaWiki announcements and site admin list mediawiki-l@lists.wikimedia.org Message-ID: CADnECnXdgKmUR1rVutjFSZBYO5wDafoLXG1Q-xQayWpt3PJiSA@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Sat, Dec 10, 2011 at 4:09 PM, Kaseluris-Nikos-1959 kaseluris.nikos@gmail.com wrote: > Please, If commiters are interesting in my skin's functionality, > docode review and commit my skin for me. > Reporting bugs to me, I'll do my best. Have you considered apply for commit access[0] yourself? That way it would be easier to any code review on the code plus any additional commits within our CR interface. Dantman[1] is a fan/into the skinning stuff so no doubt he will by and comment on this email, if not, You can give him a shout on his talk page at MediaWiki wiki. [0]. http://www.mediawiki.org/wiki/Commit_access [1]. http://www.mediawiki.org/wiki/User:Dantman ------------------------------ Message: 5 Date: Sat, 10 Dec 2011 18:18:59 +0100 From: Platonides Platonides@gmail.com Subject: Re: [Mediawiki-l] Login error,<nocookiesforlogin> To: mediawiki-l@lists.wikimedia.org Message-ID: jc042g$3m3$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1 On 05/12/11 04:02, Jeffrey T. Darlington wrote: > On 12/4/2011 3:58 PM, Platonides wrote: >> That's strange. Do you have the language files up to date? > > I have no idea. I'm starting from a clean yet slightly tweaked copy of > the 1.18.0 code (I have a custom skin derived from MonoBook), and I made > sure to run maintenance/update.php to update my database during the > upgrade. I've also run maintenance/rebuildLocalisationCache.php, which > was requested when someone else was trying to debug my prior upgrade > issues. Beyond these steps, I've never had to "update my language > files" before. I was thinking that instead of the languages/messages/MessagesEn.php shipped with MediaWiki 1.18 you could have there a copy of an older release. You should have there on line 1074: > 'nocookiesforlogin' => '{{int:nocookieslogin}}', # only translate this message to other languages if you have to change it and in line 1072 (you also seem to miss this): > 'nocookiesfornew' => 'The user account was not created, as we could not confirm its source. > Ensure you have cookies enabled, reload this page and try again.', The md5 of the file is: > 59498d33f47acb0a25cb1eec986fad1d languages/messages/MessagesEn.php >> Is your wiki available somewhere? > > It's publicly available in read-only mode; I'm the only one with admin > privileges, and nobody else has or can create a login. I've been > planning on taking on a few volunteer wiki-wranglers, but I haven't > started taking applications yet. You can take a look if you want, but > since you won't be able to log in anyway I don't know if that will help. > > http://www.gpf-comics.com/wiki/ Yes. I just wanted to confirm if it was sending the cookies. Unlike what you report, I do get a wikidb_session cookie (and it is indeed marked as secure, $wgCookieSecure is defaulting to true from the https access) Still, filling a random user & password, I get the same error you reported. Your setup _should_ work, these errors are usually related to php not being able to write in the session_path, but if you didn't touch php and it worked before... The rewrite rule shouldn't matter, either but I'd ask you to remove it, and check if that makes a difference (you don't even need to enter the right credentials, as nocookies has higher priority than badpassword). ------------------------------ Message: 6 Date: Sat, 10 Dec 2011 23:14:49 +0100 From: Platonides Platonides@gmail.com Subject: Re: [Mediawiki-l] Memory Leak Issue To: mediawiki-l@lists.wikimedia.org Message-ID: jc0ld6$c89$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1 What's your configured memory_limit of php? If a request surpassed it, it would be cancelled, but not the total system memory shouldn't be surpassed (many concurrent requests?). I assume "the server had completely maxed out its memory" refers to the apache process? Note that a php like MediaWiki cannot produce a memory leak in the server, as php frees all the memory used by the request and the end of it. Are you sure there were absulutely no requests that night? Perhaps it was crawled by e.g Googlebot. ------------------------------ Message: 7 Date: Sat, 10 Dec 2011 23:56:31 +0100 From: Platonides Platonides@gmail.com Subject: Re: [Mediawiki-l] incorrect mime type detection To: mediawiki-l@lists.wikimedia.org Message-ID: jc0nrc$rl4$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Those images match the signature of a central directory. unzip -t 01-0557-3.jpg > warning [01-0557-3.jpg]: zipfile claims to be last disk of a multi-part archive; > attempting to process anyway, assuming all parts have been concatenated > together in order. Expect "errors" and warnings...true multi-part support > doesn't exist yet (coming soon). > error [01-0557-3.jpg]: missing 1852006951 bytes in zipfile > (attempting to process anyway) > error [01-0557-3.jpg]: attempt to seek before beginning of zipfile > (please check that you have transferred or created the zipfile in the > appropriate BINARY mode and that you have compiled UnZip properly) unzip -t 05-0995-2.jpg > warning [05-0995-2.jpg]: zipfile claims to be last disk of a multi-part archive; > attempting to process anyway, assuming all parts have been concatenated > together in order. Expect "errors" and warnings...true multi-part support > doesn't exist yet (coming soon). > error [05-0995-2.jpg]: missing 1689894850 bytes in zipfile > (attempting to process anyway) > error [05-0995-2.jpg]: attempt to seek before beginning of zipfile > (please check that you have transferred or created the zipfile in the > appropriate BINARY mode and that you have compiled UnZip properly) Whereas with a normal file: unzip -t 01-0557-2.jpg > Archive: 01-0557-2.jpg > End-of-central-directory signature not found. Either this file is not > a zipfile, (...) 01-0557-3.jpg contains "50 4B 05 06" at offset 0x4E24B and 05-0995-2.jpg at 0x309DE. Since they're just 4 bytes at an arbitrary offset amongst "random" data, it's apparently a statistical false positive. In fact, the more throughly ZipDirectoryReader detects it as 'zip-bad', 'trailing bytes after the end of the file comment'. Maybe we should strength the checks at MimeMagic.php What were you changing in the db? I don't get that "magic change back" that you report. Perhaps it was metadata update was triggering it. Setting these values you should be safe: > img_name img_size img_width img_height img_metadata img_bits img_media_type img_major_mime img_minor_mime img_sha1 > 01-0557-3.jpg 377382 599 800 a:1:{s:22:"MEDIAWIKI_EXIF_VERSION";i:2;} 8 BITMAP image jpeg 1fyq01rqsw47yhvl4sqg66gr4d60j0f > 05-0995-2.jpg 220187 800 565 a:1:{s:22:"MEDIAWIKI_EXIF_VERSION";i:2;} 8 BITMAP image jpeg ghuv3z91zq81vub5v8zj9tmjziojzrh ------------------------------ Message: 8 Date: Sun, 11 Dec 2011 00:05:31 +0100 From: Platonides Platonides@gmail.com Subject: Re: [Mediawiki-l] Context weirdness To: mediawiki-l@lists.wikimedia.org Message-ID: jc0oc8$ugu$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1 On 05/12/11 02:25, John W. Foster wrote: > On Sun, 2011-12-04 at 22:09 +0100, Platonides wrote: >> On 01/12/11 00:51, John Foster wrote: >>> My mediawiki 1.17 installation as gone nuts. It is not correctly >>> identifying things where the first letter context has changed. example: >>> Template: tlx call does not find Template:Tlx In the past this has made >>> no difference. >> >> Did you change $wgCapitalLinks to false? > > I did indeed, as per the instructions at the WorkingWiki site. I have > been advised by the author that it is actually not necessary, but for > now the damage is already done, so I will just leave it & clean up the > issues. > I would appreciate any advice as to which way is best...context > sensitive or not. It wont matter once I get finished using templates > built by others that I've borrowed from other sites. I intend to never > allow content that depends on shortcuts or acronyms and I like the > titles of everything to begin with caps. Just a personal thing LOL. > Thanks for the reply. It doesn't matter too much. As the default is to have the first letter as capital, some templates you import may call them with different case, but that's all. If you want to switch back $wgCapitalLinks to true; you should then run maintenance/cleanupTitles.php Otherwise, pages created with the first letter lowercase will be unreachable. ------------------------------ Message: 9 Date: Sun, 11 Dec 2011 00:27:40 +0100 From: Jens Wille jens.wille@gmx.org Subject: Re: [Mediawiki-l] incorrect mime type detection To: MediaWiki announcements and site admin list mediawiki-l@lists.wikimedia.org Message-ID: 4EE3EAEC.4060804@gmx.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Platonides [2011-12-10 23:56]: > 01-0557-3.jpg contains "50 4B 05 06" at offset 0x4E24B and > 05-0995-2.jpg at 0x309DE. Since they're just 4 bytes at an > arbitrary offset amongst "random" data, it's apparently a > statistical false positive. ok, thanks for your input! > What were you changing in the db? I don't get that "magic change > back" that you report. Perhaps it was metadata update was > triggering it. mysql> SELECT img_name FROM image WHERE img_media_type <> 'BITMAP'; +---------------+ | img_name | +---------------+ | 01-0557-3.jpg | | 05-0995-2.jpg | +---------------+ 2 rows in set (0.00 sec) mysql> UPDATE image SET img_media_type = 'BITMAP', img_major_mime = 'image', img_minor_mime = 'jpeg' WHERE img_media_type <> 'BITMAP'; Query OK, 2 rows affected (0.04 sec) Rows matched: 2 Changed: 2 Warnings: 0 mysql> SELECT img_name FROM image WHERE img_media_type <> 'BITMAP'; Empty set (0.01 sec) [...access File:01-0557-3.jpg in browser...] mysql> SELECT img_name FROM image WHERE img_media_type <> 'BITMAP'; +---------------+ | img_name | +---------------+ | 01-0557-3.jpg | +---------------+ 1 row in set (0.00 sec) [...access File:05-0995-2.jpg in browser...] mysql> SELECT img_name FROM image WHERE img_media_type <> 'BITMAP'; +---------------+ | img_name | +---------------+ | 01-0557-3.jpg | | 05-0995-2.jpg | +---------------+ 2 rows in set (0.00 sec) so that seems a bit weird to me. > Setting these values you should be safe: well, that didn't work either :( but what did work, though, is a plain `convert` (without actually changing anything) and uploading that instead. this way it must have gotten rid of any "garbage" there might have been. so, thanks again. for me the problem is solved :) as far as the database issue is concerned i don't know... to be honest, as long as it doesn't affect me, i don't really care. i just don't understand what it's doing there. cheers jens ------------------------------ _______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l End of MediaWiki-l Digest, Vol 99, Issue 8 ******************************************