Re: [Wikitech-l] Sections as first-class citizen
2011/6/18 Misdre misdre+mediaw...@gmail.com: Currently all of these cannot be applied to a section. If we edit a section, we do not know the templates used in this section unless we hit the preview button (bug 878 - when you edit a page, you are shown the list of templates used immediately). I never understood why Show preview on first edit is not the default. We cannot check the history of a particular section and we have to dig through all edits of the page. From the social side of wiki editing process, this is one of the things that always made me see the debates about adminship and page deletion as rather ridiculous. To delete a page you have to go through the hell of Request for Adminship and then through the hell of Articles for Deletion, but to delete a section you just click edit, delete it and save, and very often no one will care or indeed even notice. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com We're living in pieces, I want to live in peace. - T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r83285]: New comment added
User Bryan posted a comment on MediaWiki.r83285. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83285#c18347 Commit summary: Follow-up r83282: Re-add the lost $this-getNamespace() == NS_FILE, forgot to test the code for normal pages. Comment: Good question. I don't remember. In fact, I don't remember why I splitted off this code at all. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85911]: New comment added
User Bryan posted a comment on MediaWiki.r85911. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85911#c18348 Commit summary: Add support for importing/exporting files. This can be done by embedding the image as base64 in the XML stream or by copying the images directory manually and pointing the importer to the base images directory. Currently only backend code available and a few member variables need to be modified to enable the functionality. Export.php: * Add rel and sha1base36 elememnts to the XML output * Add optional archivename and contents elements to the XML output. contents contains an encoding attribute, which is currently only set to base64. Import.php: * Add Import::$mImageBasePath which should point to the images/ directory to import from * Add methods to WikiRevision (terrible name btw) to set the rel, hash, archivename and filesrc. * Cleanup and made WikiRevision::importUpload working. It's still quite a mess though OldLocalFiel.php: * Fix a few timestamp related things from r85635 Comment: It's possible to not include the files in the XML stream, and import them from a separate directory. That's in one of the follow-up revisions. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87176]: New comment added
User Bryan posted a comment on MediaWiki.r87176. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87176#c18349 Commit summary: Add --include-files option to dumpBackup.php to include the uploaded files in the XML stream. Uses new backend features from r85911. Comment: As you correctly stated on r85911, embedding files into XML streams might give problems. With r88145 and follow-ups it is possible to import the files from a separate directory if only the bare upload records are available. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90322]: New comment added
User Salvatore Ingala posted a comment on MediaWiki.r90322. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90322#c18350 Commit summary: - Using serialize()/unserialize() to save and retrieve from DB. - Fixed a bug in preference retrieval. Comment: Since ignoring preferences (thus returning defaults) is a safe way to recover from problems of inconsistent state, I thought a debug message was enough. Maybe I was wrong: I admit that I actually don't have in mind a clear distinction between use-cases of wfDebug-messages and E_NOTICEs. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] ICANN expansion, relative URLs
I suppose in theory having apple available is no worse than apple.com (since you *could* have an apple.com.mylocaldomain already and have to worry about which takes precedence), but in practice that sounds like a crappy thing to do. :) Well, yes, this is exactly why you don't usually use TLDs as subdomains on top of company internal search path. I guess this makes us switch back to IP addresses, if there's a constant chance of conflict we can no longer control :-) With IPv6 that will be even easier. And who needs DNS when we have Google. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r90331]: New comment added
User Krinkle posted a comment on MediaWiki.r90331.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90331#c18351
Commit summary:
Implement mw.Title in core
* Based on UploadWizard/resources/mw.Title.js
* Refactored to use local scope and prototypes instead of re-declaring them
per-instance in the private scope through 'this' (re-use by reference, faster
instantiation and performance)
* Fix potential ReferenceError in the check for wgArticlePath (inline if
statements will fail for undeclared variables, needs typeof undefined check).
Using mw.config instead to avoid this problem.
* The following two methods were not ported from UploadWizard because they were
or became redundant and/or merged with another method:
-- setNameText (redundant with the improved setName)
-- setPrefix (redundant wit the improved setNamespace)
* Ported all jasmine tests to QUnit. Left them exactly the same to make sure
it's compatible with UploadWizard. Perhaps I'll expand or adjust the suite
later to be less file-specific, but for now make letting this revision go
through TestSwarm to be sure it's compatible and behaves exactly the same.
* Added getName() method instead, replacing direct access to '_name' This in
order to check for wgCaseSensitiveNamespaces (bug 29441; r90234)
-- Prevents breakages on wiktionary and other wikis with case sensitivity. ie.
on a Wiktionary:
new mw.Title('apple').toString()
Apple
-- This fix will make it return 'apple' instead of 'Apple' (that is, if 0 is in
wgCaseSensitiveNamespaces).
* There used to be a strip-bug in scenarios where a namespace-like string
appears inside of a title. Imagine pagename: Category:Wikipedia:Foo bar
(exist on several wikis; NS_CATEGORY= 14)
new mw.Title( 'Wikipedia:Foo bar', 14 ).toString()
Category:Foo_bar // Stripped Wikipedia: !!
In order to fix this:
-- Removed assumption that every title has a namespace prefix.
UploadWizard/mw.Title has one initialization RegExp (which was ported as-is to
setAll). In addition there is now a setNameAndExtension method (which
doesn't extract or set the namespace). Now the above case:
new mw.Title( 'Wikipedia:Foo bar', 14 ).toString()
Category:Wikipedia_Foo_bar // Better, but now the colon is gone..
-- In order to fix that, \x3a was removed from the clean() function. Colons
are valid in MediaWiki titles, no need to escape.
new mw.Title( 'Wikipedia:Foo bar', 14 ).toString()
Category:Wikipedia:Foo_bar // Yay!
* Last but not least, another little bug fixed due to the previous point. It
also fixed a thrown exception in case a colon is part of the title in the main
namespace (not rare for movies and books):
new mw.Title( 'The Wiki: Awesomeness')
Error: mw.Title Unrecognized canonical namespace: the_wiki
This exception is thrown from setNamespace(). That exception would make sense
if setNamespace() was called by the user direcly, but when called from setAll()
it should gracefully fallback by putting the prefix in the name instead and
assuming NS_MAIN (just like the server side does). To achieve this I added a
try/catch around setAll() and fallback to the new setNameAndExtension().
* Passes JSHint.
* Additional feature: exists(). Return true/false if known, otherwise null.
Extensions can populate this for titles they are interested in and the
front-end can construct url's and UI elements with correct redlink-status.
Gadgets can populate it as well but that would require an API-request to get
the information. A bit of a stub for later use, although I think it works fine.
* Bugfix in jquery.qunit.completenessTest.js (first triggered by the
introduction of mw.Title). Don't traverse the 'constructor' property (recursive
loop, ouch!)
---
(bug 29397) Implement mw.Title module in core
Comment:
On-wiki documentation on [[RL/DM]] and more unit tests for the parts that are
new compared to UploadWizard still need to be written.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90320]: New comment added
User Nikerabbit posted a comment on MediaWiki.r90320. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90320#c18352 Commit summary: Follow-up to r90265: directionality improvements as part of bug 6100 (under $wgBetterDirectionality): * Use ParserOptions()-getTargetLanguage() for setting the page language/direction * Set headings on categories in user language/direction * Only set language/direction when viewing a page (or editing but only preview and textarea) Comment: And I don't think $wgOut's ParserOptions is the correct ParserOptions. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90331]: New comment added
User Nikerabbit posted a comment on MediaWiki.r90331.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90331#c18353
Commit summary:
Implement mw.Title in core
* Based on UploadWizard/resources/mw.Title.js
* Refactored to use local scope and prototypes instead of re-declaring them
per-instance in the private scope through 'this' (re-use by reference, faster
instantiation and performance)
* Fix potential ReferenceError in the check for wgArticlePath (inline if
statements will fail for undeclared variables, needs typeof undefined check).
Using mw.config instead to avoid this problem.
* The following two methods were not ported from UploadWizard because they were
or became redundant and/or merged with another method:
-- setNameText (redundant with the improved setName)
-- setPrefix (redundant wit the improved setNamespace)
* Ported all jasmine tests to QUnit. Left them exactly the same to make sure
it's compatible with UploadWizard. Perhaps I'll expand or adjust the suite
later to be less file-specific, but for now make letting this revision go
through TestSwarm to be sure it's compatible and behaves exactly the same.
* Added getName() method instead, replacing direct access to '_name' This in
order to check for wgCaseSensitiveNamespaces (bug 29441; r90234)
-- Prevents breakages on wiktionary and other wikis with case sensitivity. ie.
on a Wiktionary:
new mw.Title('apple').toString()
Apple
-- This fix will make it return 'apple' instead of 'Apple' (that is, if 0 is in
wgCaseSensitiveNamespaces).
* There used to be a strip-bug in scenarios where a namespace-like string
appears inside of a title. Imagine pagename: Category:Wikipedia:Foo bar
(exist on several wikis; NS_CATEGORY= 14)
new mw.Title( 'Wikipedia:Foo bar', 14 ).toString()
Category:Foo_bar // Stripped Wikipedia: !!
In order to fix this:
-- Removed assumption that every title has a namespace prefix.
UploadWizard/mw.Title has one initialization RegExp (which was ported as-is to
setAll). In addition there is now a setNameAndExtension method (which
doesn't extract or set the namespace). Now the above case:
new mw.Title( 'Wikipedia:Foo bar', 14 ).toString()
Category:Wikipedia_Foo_bar // Better, but now the colon is gone..
-- In order to fix that, \x3a was removed from the clean() function. Colons
are valid in MediaWiki titles, no need to escape.
new mw.Title( 'Wikipedia:Foo bar', 14 ).toString()
Category:Wikipedia:Foo_bar // Yay!
* Last but not least, another little bug fixed due to the previous point. It
also fixed a thrown exception in case a colon is part of the title in the main
namespace (not rare for movies and books):
new mw.Title( 'The Wiki: Awesomeness')
Error: mw.Title Unrecognized canonical namespace: the_wiki
This exception is thrown from setNamespace(). That exception would make sense
if setNamespace() was called by the user direcly, but when called from setAll()
it should gracefully fallback by putting the prefix in the name instead and
assuming NS_MAIN (just like the server side does). To achieve this I added a
try/catch around setAll() and fallback to the new setNameAndExtension().
* Passes JSHint.
* Additional feature: exists(). Return true/false if known, otherwise null.
Extensions can populate this for titles they are interested in and the
front-end can construct url's and UI elements with correct redlink-status.
Gadgets can populate it as well but that would require an API-request to get
the information. A bit of a stub for later use, although I think it works fine.
* Bugfix in jquery.qunit.completenessTest.js (first triggered by the
introduction of mw.Title). Don't traverse the 'constructor' property (recursive
loop, ouch!)
---
(bug 29397) Implement mw.Title module in core
Comment:
PHP Title class is immutable, this is not?
PHP Title class doesn't handle file extensions, this one does and confusingly
calls them just extensions?
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90320]: New comment added
User SPQRobin posted a comment on MediaWiki.r90320. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90320#c18354 Commit summary: Follow-up to r90265: directionality improvements as part of bug 6100 (under $wgBetterDirectionality): * Use ParserOptions()-getTargetLanguage() for setting the page language/direction * Set headings on categories in user language/direction * Only set language/direction when viewing a page (or editing but only preview and textarea) Comment: It does work as intended... I first tried to set the targetlanguage in a different way, but $wgOut is now actually not needed anymore, so I can use code$parserOptions = ParserOptions::newFromUser( $wgUser );/code Would that be better? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90320]: New comment added
User Nikerabbit posted a comment on MediaWiki.r90320. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90320#c18355 Commit summary: Follow-up to r90265: directionality improvements as part of bug 6100 (under $wgBetterDirectionality): * Use ParserOptions()-getTargetLanguage() for setting the page language/direction * Set headings on categories in user language/direction * Only set language/direction when viewing a page (or editing but only preview and textarea) Comment: If I'm not mistaked $wgOut's ParserOptions are only for the interface, not the actual page content. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90320]: New comment added, and revision status changed
User Platonides changed the status of MediaWiki.r90320. Old Status: new New Status: fixme User Platonides also posted a comment on MediaWiki.r90320. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90320#c18356 Commit summary: Follow-up to r90265: directionality improvements as part of bug 6100 (under $wgBetterDirectionality): * Use ParserOptions()-getTargetLanguage() for setting the page language/direction * Set headings on categories in user language/direction * Only set language/direction when viewing a page (or editing but only preview and textarea) Comment: * CategoryPage::formatList() returns (without $wgBetterDirectionality) the undefined variable $list if it doesn't enter on any if * The change to ParserOptions::getTargetLanguage() looks wrong. If you want to get the page language, you should check $wgContLang. Since you want to get the language per-title, adding a new method to the title class seems appropiate. The check to see if $getPageLang is null shouldn't be needed. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89934]: Revision status changed
User Platonides changed the status of MediaWiki.r89934. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89934#c0 Commit summary: Changed some magic __get method calls to accessors, were throwing notices ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89430]: New comment added
User Platonides posted a comment on MediaWiki.r89430.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89430#c18357
Commit summary:
Provisional revert of r89406, r89414: reference-related warnings need cleanup
before applying code like this
Per CR http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89406#c17545 :
'Here is a third one: Strict Standards: Only variables should be passed by
reference in /www/sandwiki/includes/Wiki.php on line 177 '
Offending bit is this:
- SpecialPageFactory::executePath( $this-context-title,
$this-context );
+ SpecialPageFactory::executePath( $this-getTitle(),
$this-getContext() );
That function demands reference paramters for $title and $context, which is
being violated here where we now pass function return values:
public static function executePath( Title $title, RequestContext $context,
$including = false ) {
The $title does sometimes get replaced within the function body, but $context
does not appear to ever be replaced (its *contents* are modified, which does
not require passing by reference)
If replacing it is something it should be doing, then we need to be able to
replace it upstream presumably, so $this-getTitle() probably isn't appropriate.
The $context probably should have the reference simply removed.
Comment:
This seems to have been reverted again?
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88588]: New comment added, and revision status changed
User Platonides changed the status of MediaWiki.r88588. Old Status: fixme New Status: resolved User Platonides also posted a comment on MediaWiki.r88588. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88588#c18358 Commit summary: $wgArticle is deprecated! Possible removal in 1.20 or 1.21! * Encapsulate index.php in wfIndexMain() (similar to r77873) * Kill $wgArticle check in Exception, not necessary anymore * Kill $wgArticle in Setup, also not necessary * Add angry note about $wgArticle to rebuildFileCache. * Remove note about $wgArticle in Parser since it's dying anyway Comment: Marking resolved after r90338 and r90339 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89995]: New comment added, and revision status changed
User Bryan changed the status of MediaWiki.r89995. Old Status: new New Status: resolved User Bryan also posted a comment on MediaWiki.r89995. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89995#c18359 Commit summary: (bug 28556) Remove MacBinary * IE5 for Mac is history. Comment: Bye bye IE5. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90007]: Revision status changed
User Bryan changed the status of MediaWiki.r90007. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90007#c0 Commit summary: ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90263]: New comment added
User Jeroen De Dauw posted a comment on MediaWiki.r90263. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/90263#c18360 Commit summary: Code cleanup for Query Creator Comment: I agree (and am sure Markus will to), these functions should definitely be used, and they can without any compatibility worries. The oldest we need to support is MW 1.15, and while Html was added in 1.16, SMW has it's own copy to fall back on. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90339]: New comment added
User Nikerabbit posted a comment on MediaWiki.r90339. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90339#c18361 Commit summary: Add deprecated $wgArticle again. Fixes r88588. Comment: If you do it like that, doxygen will mark the function deprecated instead. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90340]: New comment added, and revision status changed
User Nikerabbit changed the status of MediaWiki.r90340. Old Status: new New Status: fixme User Nikerabbit also posted a comment on MediaWiki.r90340. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90340#c18362 Commit summary: (bug 29408) Key 'something.' is not in a proper format Fixed this by relaxing the stash key regex. For some files MediaWiki is simply not able to guess an extension. If the wiki has been configured to allow them, we should just let them pass in the stash as well. Comment: You upset cruisecontrol. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Enabling protocol relative URLs on Wikimedia sites week of July 18th
Ryan Lane wrote: There's a bunch of things that we should likely do in the future as well. We should likely set a non-secure cookie for HTTPS logged in users that indicates the user requests HTTPS only (via a preference, enabled by default), that will redirect them to HTTPS if they somehow arrive at an HTTP page. Strict Transport Security (STS) should also be a consideration at some point in time, at least for users that have already logged in. This doesn't protect the user from initial site spoofing attacks, but could protect against later spoofing attacks (thanks Aryeh for this idea). I don't think we'll ever get to a point where we can/should use HTTPS for all anon users, but SPDY could be a consideration in the future for anons. After I finish HTTPS I may look at setting up SPDY for testing. These all sound like good ideas to investigate. Just make sure they're in Bugzilla at some point so they don't get lost in a mailman archive. :-) I think there's a tracking bug for https or secure login somewhere. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r90343]: Revision status changed
User Krinkle changed the status of MediaWiki.r90343. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90343#c0 Commit summary: Follow-up r90007: clarify release notes about MacBinary a bit. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90344]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r90344. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90344#c0 Commit summary: wfProfileIn/wfProfileOut to the whole main() ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90340]: New comment added, and revision status changed
User Bryan changed the status of MediaWiki.r90340. Old Status: fixme New Status: new User Bryan also posted a comment on MediaWiki.r90340. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90340#c18363 Commit summary: (bug 29408) Key 'something.' is not in a proper format Fixed this by relaxing the stash key regex. For some files MediaWiki is simply not able to guess an extension. If the wiki has been configured to allow them, we should just let them pass in the stash as well. Comment: Can't reproduce, but should be fixed by r90349. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Unit testing now working - break it and be reverted
On Fri, Jun 17, 2011 at 3:35 AM, Max Semenik maxsem.w...@gmail.com wrote: On 17.06.2011, 1:08 Bryan wrote: Can somebody on Windows/SQLite try running the tests? I'm consistently getting two failures in XmlTest, which Chad apparently is not getting: Yes, same thing for me. Hoowever. the difs show no real difference, WTF? PHP 5.3.5/XAMPP - these errors aren't related to database. Yeah, pretty WTF, especially since it is the expected that is broken... Anybody has an idea? Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Unit testing now working - break it and be reverted
On Wed, Jun 15, 2011 at 11:02 PM, Chad innocentkil...@gmail.com wrote: Painstakingly, all of the unit tests are now passing on cruise control (Sqlite) and my local install (Sqlite Mysql). This is as of r90150 [0]. Thank you immensely to Brion for finally tracking down and eliminating that pesky BlockTest bug. How often does CC run the tests? Can we make it run after every commit? Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r84718]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r84718. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84718#c0 Commit summary: Move WatchlistEditor.php to /specials since inside it is essentially a complete special page. Make it subclass SpecialPage and do all the usual stuff. Rewrite it to use HTMLForm and other exciting things, and give it a good general clean up. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84814]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r84814. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84814#c0 Commit summary: Topple the last bastion of global-function-based special pages. Also fix HTMLCheckField to work with GET forms. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Sections as first-class citizen
On Fri, Jun 17, 2011 at 5:24 PM, Misdre misdre+mediaw...@gmail.com wrote: The most cumbersome situation is when you want to watch only one section, especially on talk pages. You have no choice but to watch the entire page and that can be really painful. Is there an easy way to improve this situation? My honest recommendations: For talk pages: finish reworking or replacing LiquidThreads into a system that's actually designed for discussion, with sensible notifications. This probably should be a high priority for Wikimedia, but the way things shuffled out under this year's budget it's only partially covered under the '-1 to 100 edits' umbrella project covering UI and process improvements to help integrate new editors. If folks can seriously rally on it though we could get some really great stuff done! For articles: break up giant articles into more reasonably-sized pieces. This should improve search locality, rendering load times, and manageability of editing. This may benefit from more explicit ways to group related pages, which is also desperately needed as a first-class feature for wikibooks and other projects. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r84843]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r84843. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84843#c0 Commit summary: eta shows revs/pages per sec in current interval as well as overall; useful for investigating problems, now that we have logging ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84861]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r84861. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84861#c0 Commit summary: Stop after replaceing the first instance ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84891]: New comment added, and revision status changed
User Aaron Schulz changed the status of MediaWiki.r84891. Old Status: new New Status: ok User Aaron Schulz also posted a comment on MediaWiki.r84891. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84891#c18364 Commit summary: Follow-up r83907: abstract the flatlist mode into a descriptor option, and make it so the label does not linewrap away from the checkbox. Comment: HTMLForm needs more docs. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84905]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r84905. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84905#c0 Commit summary: BREAKING CHANGE: Ignore cmtype when cmsort=timestamp is set, and bypass the per-type queries in the sort=timestamp case; they were causing performance problems, reported as bug 28291. This breaks backwards compatibility (gracefully, the cltype parameter is silently ignored) with earlier deployed versions of 1.17wmf1 but not with any released version, hence no RELEASE-NOTES ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85003]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r85003. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85003#c0 Commit summary: Use unused $fallback_languages ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85011]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r85011. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85011#c0 Commit summary: One last deployment merge: r81956 to trunk ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85026]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r85026. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85026#c0 Commit summary: Follow-up r85020 per CR - use strict comparison ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85020]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r85020. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85020#c0 Commit summary: (bug 18937) avoid broken wikimarkup (four apostrophes together) in MediaWiki:Confirmrecreate when there is no deletion reason, by using a separate message. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85025]: New comment added
User Aaron Schulz posted a comment on MediaWiki.r85025. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85025#c18365 Commit summary: (bug 23408) give admins a warning before letting them block themselves. Also tweak the logic so that loading the interface for one already-blocked user, then actually submitting a block on a different user, shows the confirmation again if the second user is already blocked. Comment: pre$fields['AlreadyBlocked']['default'] = htmlspecialchars( $block-getTarget() );/pre What does the htmlspecialchars do here? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85166]: New comment added
User Aaron Schulz posted a comment on MediaWiki.r85166. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85166#c18366 Commit summary: Follow-up r85025: fix the you're-trying-to-block-yourself-you-twit warning, and make it an actual checkbox confirmation. Also use said confirmation for reblocks, and HideUser (bug 18678). Mark a static function from HTMLForm which is called from SpecialBlock as explicitly public. Comment: pre$data['PreviousTarget'] != htmlspecialchars( $block-getTarget() )/pre I can't quite tell why htmlspecialchars is needed here. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85042]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r85042. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85042#c0 Commit summary: Follow-up r85025 - use strict comparison ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85031]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r85031. Old Status: new New Status: old Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85031#c0 Commit summary: Rename DeleteBatch class to SpecialDeleteBatch ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90339]: New comment added
User Platonides posted a comment on MediaWiki.r90339. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90339#c18367 Commit summary: Add deprecated $wgArticle again. Fixes r88588. Comment: Are you sure? That's the way it was in index.php [http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/index.php?view=markuppathrev=90337#l151], also inside a funcion. I just copied it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90356]: Revision status changed
User Platonides changed the status of MediaWiki.r90356. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90356#c0 Commit summary: (bug 29476) DatabaseBase::deleteJoin fails for Sqlite Added deleteJoin() to DatabaseSqlite, CP from DatabasePostgres ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90363]: Revision status changed
User MaxSem changed the status of MediaWiki.r90363. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90363#c0 Commit summary: All the databases but MySQL were overriding DatabaseBase::deleteJoin() with the same code. Move DatabaseBase::deleteJoin() to DatabaseMysql::deleteJoin() and the common code to DatabaseBase::deleteJoin() Follow up r90356 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90358]: New comment added
User MaxSem posted a comment on MediaWiki.r90358.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90358#c18369
Commit summary:
applying modified SQLite patch by hofoen
Comment:
+ } elseif ( $wgDBtype == 'sqlite' ) { // SQLite: no in-memory
tables available
+ $sql = CREATE TEMPORARY TABLE . $smw_tmp_unusedprops
. ( title VARCHAR(255) );
Use simply ttTEXT/tt. Although SQLite eats most types from other DBs just
fine, it's always better to use native types in SQLite-only context.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90358]: New comment added
User MaxSem posted a comment on MediaWiki.r90358. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90358#c18370 Commit summary: applying modified SQLite patch by hofoen Comment: You can attach an in-memory DB and create a table there, by the way. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90358]: New comment added
User Jeroen De Dauw posted a comment on MediaWiki.r90358. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/90358#c18371 Commit summary: applying modified SQLite patch by hofoen Comment: Definitely feel free to fix ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90366]: Revision status changed
User Bryan changed the status of MediaWiki.r90366. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90366#c0 Commit summary: Typo in release notes, noticed on-wiki by 67.18.208.15. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] How a single commit can go viral
Those working on the install script may want to pay extra attention... https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac#install.sh-P13 :) -- Erwin Dokter ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r90355]: New comment added
User DaSch posted a comment on MediaWiki.r90355. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90355#c18372 Commit summary: applied DE i18n patch by DaSch Comment: There is a small error in this patch I submitted and was applyed The comment should be changed ;) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Special:Search goose chase
http://en.wikipedia.org/wiki/Special:Search?search=Aomiz+Sucharat says Did you mean: Aomiz Suchart so we click it, and then we are asked Did you mean: Aziz Suharto Having been used to Google™, one feels a little like goose chase. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Enabling protocol relative URLs on Wikimedia sites week of July 18th
On Sun, Jun 19, 2011 at 2:35 AM, MZMcBride z...@mzmcbride.com wrote: These all sound like good ideas to investigate. Just make sure they're in Bugzilla at some point so they don't get lost in a mailman archive. :-) I think there's a tracking bug for https or secure login somewhere. MZMcBride We even have a component for it now ;p ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r90346]: Revision status changed
User ^demon changed the status of MediaWiki.r90346. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90346#c0 Commit summary: Only accept $wgArticle in Wiki.php after r90339. Skip $wgConfiguration errors from Conf.php for now. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90336]: Revision status changed
User ^demon changed the status of MediaWiki.r90336. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90336#c0 Commit summary: r89623 added SQLT_CHR. SQLT_* constants are added by Oracle extension. http://php.net/manual/en/oci8.datatypes.php ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
