[MediaWiki-CodeReview] [MediaWiki r94486]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r94486. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94486#c0 Commit summary: * Follow-up to r91284: fix error in Action::exists by passing empty array as required second parameter to Action::getClass ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] forking media files
Let me retitle one of the topics nobody seems to touch. On Fri, Aug 12, 2011 at 13:44, Brion Vibber br...@pobox.com wrote: * media files -- these are freely copiable but I'm not sure the state of easily obtaing them in bulk. As the data set moved into TB it became impractical to just build .tar dumps. There are batch downloader tools available, and the metadata's all in dumps and api. Right now it is basically locked: there is no way to bulk copy the media files, including doing simply a backup of one wikipedia, or commons. I've tried, I've asked, and the answer was basically to contact a dev and arrange it, which obviously could be done (I know many of the folks) but that isn't the point. Some explanations were mentioned, mostly mentioning that media and its metadata is quite detached, and thus it's hard to enforce licensing quirks like attribution, special licenses and such. I can guess this is a relevant comment since the text corpus is uniformly licensed under CC/GFDL while the media files are at best non-homogeneous (like commons, where everything's free in a way) and completely chaos at its worst (individual wikipedias, where there may be anything from leftover fair use to copyrighted by various entities to images to be deleted soon). Still, I do not believe it's a good method to make it close to impossible to bulk copy the data. I am not sure which technical means is best, as there are many competing ones. We could, for example, open up an API which would serve media file with its metadata together, possibly supporting mass operations. Still, it's pretty ineffective. Or we could support zsync, rsync and such (and I again recommend examining zsync's several interesting abilities to offload the work to the client), but there ought to be some pointers to image metadata, at least an oneliner file with every image linking to the license page. Or we could connect the bulk way to established editor accounts, so we could have at least a bit of an assurance that s/he knows what s/he's doing. -- byte-byte, grin ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r92009]: New comment added, and revision status changed
User Catrope changed the status of MediaWiki.r92009. Old Status: ok New Status: fixme User Catrope also posted a comment on MediaWiki.r92009. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92009#c20797 Commit summary: Refactored UploadStash and related classes to use the database for file metadata storage instead of the session, see bug 26179 Tweaked the UploadWizard to work properly with the new backend code, updated tests Comment: The rename from mwe-upwiz-api-error-invalid-session-key to mwe-upwiz-api-error-invalid-file-key is incomplete: in the i18n file, you only changed the message name for Finnish (fi) and left all other languages, including English (!!) alone. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94450]: New comment added
User Hashar posted a comment on MediaWiki.r94450. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94450#c20798 Commit summary: Forport from 1.17wmf1 to 1.18 r94252 Wrap site_stats update in a begin()/commit() Comment: Well the original revision is still tagged 'trunk' :-) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94410]: New comment added
User Hashar posted a comment on MediaWiki.r94410. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94410#c20799 Commit summary: svn ignore + README file Comment: Oops. I did not pay attention to the .svnignore ! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94491]: New comment added, and revision status changed
User Hashar changed the status of MediaWiki.r94491. Old Status: new New Status: ok User Hashar also posted a comment on MediaWiki.r94491. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94491#c20800 Commit summary: Remove fixme note since hashar fixed it in r94409. Comment: Which probably means my pkg-config macros works for you :-) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92200]: New comment added
User Catrope posted a comment on MediaWiki.r92200. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92200#c20801 Commit summary: fixed a condition where re-uploading a file that's already stashed causes breakage. This mirrors the previous session-based behavior as closely as possible. Comment: With r92269 in mind, this is fine. However, the error message is misleading. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92200]: New comment added
User Catrope posted a comment on MediaWiki.r92200. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92200#c20802 Commit summary: fixed a condition where re-uploading a file that's already stashed causes breakage. This mirrors the previous session-based behavior as closely as possible. Comment: The database logic is still vulnerable to race conditions: if a key is held by A but has expired, B and C can try to take it over at the same time. Both will be allowed to, both will execute a codeREPLACE/code query, and one will win. You can prevent this by using codeFOR UPDATE/code in your codeSELECT/code. My personal preference for ensuring such things atomically is an codeINSERT IGNORE/code followed by a conditional codeUPDATE/code which includes the user and age criteria in the codeWHERE/code, but it seems to me that codeSELECT FOR UPDATE/code will work fine here, and locking is not a concern here because you're only locking a single row, if that: in the vast majority of cases you'll select and lock zero rows. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92200]: New comment added
User Catrope posted a comment on MediaWiki.r92200. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92200#c20803 Commit summary: fixed a condition where re-uploading a file that's already stashed causes breakage. This mirrors the previous session-based behavior as closely as possible. Comment: Similarly, removeFile() is vulnerable to a race condition if the file is taken over in between checking ownership and deleting it. It's much easier to just to a conditional codeDELETE/code and put the ownership criterion in the codeWHERE/code clause. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94369]: Revision status changed
User Tim Starling changed the status of MediaWiki.r94369. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94369#c0 Commit summary: Expand URLs in the SiteMatrix API. This should fix bug 30171 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94371]: Revision status changed
User Tim Starling changed the status of MediaWiki.r94371. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94371#c0 Commit summary: Expand another URL in the CentralAuth API ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94376]: Revision status changed
User Tim Starling changed the status of MediaWiki.r94376. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94376#c0 Commit summary: Collection: Use wfExpandUrl() instead of prepending $wgServer everywhere. In one instance, just keep the URL relative. Also clean up global declarations, you can put more than one on the same line. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92213]: New comment added
User Catrope posted a comment on MediaWiki.r92213. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92213#c20804 Commit summary: properly handle the case where a file disappears during the uploadwizard process remove database records for files that move out of the stash Comment: pre - + /pre Check your diffs before you commit and you'll notice things like this. In this case, your only change to UploadBase.php was changing an empty line to one with 6 tabs. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92009]: New comment added
User Catrope posted a comment on MediaWiki.r92009.
Full URL:
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92009#c20805
Commit summary:
Refactored UploadStash and related classes to use the database for file
metadata storage instead of the session, see bug 26179
Tweaked the UploadWizard to work properly with the new backend code, updated
tests
Comment:
pre
+ return self::isValidKey( $request-getText( 'wpFileKey' ) ||
$request-getText( 'wpSessionKey' ) );
...
+ $fileKey = $request-getText( 'wpFileKey' ) ||
$request-getText( 'wpSessionKey' );
...
+ $desiredDestName = $request-getText( 'wpUploadFile' )
|| $request-getText( 'filename' );
/pre
This doesn't work. The code||/code operator in PHP doesn't behave like the
one in JavaScript or Python or whatever, but more like the one in C:
pre
$request = new FauxRequest(array('wpFileKey' = 'foo', 'wpSessionKey' =
'bar'));
var_dump($request-getText( 'wpSessionKey' ) || $request-getText(
'wpSessionKey' ))
bool(true)
/pre
Instead, what you want to use is the second parameter to codegetText()/code
(and most of the other getters in WebRequest), which is a default value that is
returned if the key you asked for isn't set. So something like
code$request-getText( 'wpFileKey', $request-getText( 'wpSessionKey',
'defaultValueIfNeitherIsSet,DefaultsToEmptyString' ) )/code would do what you
want.
I'm confused, though: I don't have a very good understanding of the code, but
it seems to me like this accidental creation of booleans that then get
converted back to strings must break '''something''', somewhere. Is there some
devious reason why this doesn't break things, or at least doesn't appear to
during basic testing?
pre
+ if ( !empty( $this-mLocalFile ) ) {
/pre
This looks a lot like an [[Manual:Coding conventions#PHP
pitfalls|inappropriate]] use of codeempty()/code.
The waiting-for-lag behavior is unnecessarily complex, scary and fragile. If
your data doesn't appear due to lag, fetch it from the master instead. This
probably involves adding a parameter to codefetchFileMetadata()/code to use
the master instead of the slave.
pre
public function listFiles() {
...
array( 'us_key' = $key ),
/pre
code$key/code is undefined, and this condition probably breaks
codelistFiles()/code entirely.
pre
+ $this-fileMetadata[$key] = array(
+ 'us_user' = $row-us_user,
+ 'us_key' = $row-us_key,
+ 'us_orig_path' = $row-us_orig_path,
+ 'us_path' = $row-us_path,
+ 'us_size' = $row-us_size,
+ 'us_sha1' = $row-us_sha1,
+ 'us_mime' = $row-us_mime,
+ 'us_media_type' = $row-us_media_type,
+ 'us_image_width' = $row-us_image_width,
+ 'us_image_height' = $row-us_image_height,
+ 'us_image_bits' = $row-us_image_bits,
+ 'us_source_type' = $row-us_source_type,
+ 'us_timestamp' = $row-us_timestamp,
+ 'us_status' = $row-us_status
+ );
/pre
You can also use code$this-fileMetadata[$key] = (array)$row;/code .
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92200]: Revision status changed
User Catrope changed the status of MediaWiki.r92200. Old Status: ok New Status: fixme Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92200#c0 Commit summary: fixed a condition where re-uploading a file that's already stashed causes breakage. This mirrors the previous session-based behavior as closely as possible. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94404]: New comment added
User Tim Starling posted a comment on MediaWiki.r94404. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94404#c20806 Commit summary: Hopefully prevent race conditions in ArticleFeedback by reading from the master rather than the slave and using LOCK IN SHARE MODE. These race conditions probably caused bug 30227. Hopefully this will prevent that from happening again. Comment: Years ago, I tested LOCK IN SHARE MODE on InnoDB and found that it generates a deadlock pretty much every time there are two threads doing the same thing at the same time. I was unable to find a use for it apart from error generation. Maybe it's better in MySQL 5.1, but I wouldn't count on it. I think it's better to design your schema in a way that avoids locking reads, that's what I said in docs/database.txt. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94502]: New comment added
User Tim Starling posted a comment on MediaWiki.r94502.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94502#c20807
Commit summary:
(bug 30269) Strings like foobar//barfoo are linked to become foobar[//barfoo]
* Introduce a boolean parameter to wfUrlProtocols() which, if set to false,
will cause '//' to be dropped from the returned regex so it doesn't match
protocol-relative URLs
* Introduce wfUrlProtocolsWithoutProtRel() as a wrapper for wfUrlProtocols(
false ). The latter should not be used directly because the former is much
clearer
* Use this new function in Parser::doMagicLinks() to fix the original bug. Also
use it in ApiFormatBase::formatHTML() and CodeCommentLinker::link(), which
probably had similar bugs
Comment:
static $retval = array( true = null, false = null );
I think you're better off avoiding trying to index arrays with booleans. If
someone sees you doing it, they might think it actually works as written, and
they'll get into trouble.
Arrays in PHP have a string index. What's happening here is that the boolean
values are being converted to integers and then to strings:
pre
$a = array(true = '', false = '' );
var_dump($a)
array(2) {
[1]=
string(0)
[0]=
string(0)
}
unset($a[1]);
var_dump($a)
array(1) {
[0]=
string(0)
}
/pre
Otherwise OK.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94506]: New comment added
User Hashar posted a comment on MediaWiki.r94506. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94506#c20808 Commit summary: get ride of #c0 in URL Comment: Test plan: trunk/tests/phpunit$ ./phpunit.php --filter CodeReview --testdox PHPUnit 3.5.14 by Sebastian Bergmann. CodeReview [x] Comment wiki formatting [x] Comment full url $ Probably need a backport in 1.17 1.17wmf1 and 1.18 :-) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94289]: New comment added
User Catrope posted a comment on MediaWiki.r94289. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94289#c20809 Commit summary: * Added rev_sha1 and ar_sha1 columns to revision/archive tables (useful for bug 25312) * Created a script to populate these fields (doesn't handle archive rows without ar_rev_id set though) Comment: This has been filed by someone else as bug 30383 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94502]: New comment added
User Catrope posted a comment on MediaWiki.r94502. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94502#c20810 Commit summary: (bug 30269) Strings like foobar//barfoo are linked to become foobar[//barfoo] * Introduce a boolean parameter to wfUrlProtocols() which, if set to false, will cause '//' to be dropped from the returned regex so it doesn't match protocol-relative URLs * Introduce wfUrlProtocolsWithoutProtRel() as a wrapper for wfUrlProtocols( false ). The latter should not be used directly because the former is much clearer * Use this new function in Parser::doMagicLinks() to fix the original bug. Also use it in ApiFormatBase::formatHTML() and CodeCommentLinker::link(), which probably had similar bugs Comment: Good point. I'll just use two caching vars. I was aware that the actual indices wouldn't be booleans, but hadn't really thought about the implications when mixing with non-boolean indices. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] State of page view stats
Erik Zachte erikzachte at infodisiac.com writes: Page view archives are now online at http://dumps.wikimedia.org/other/pagecounts-ez/monthly/ Archives contain description of format (also in previous post) Erik Zachte Very nice! But there seems to be something wrong: pagecounts-2011-07-all_ge5 reports 9063 views on hoofdpagina (initial lowercase) at nl.z and Hoofdpagina at nl.z (with initial uppercase) isn't in the list. The same seems to be the case for other items which are reported with initial lowercase: the reported views are too low. MrBlueSky ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r82577]: New comment added, and revision status changed
User Hashar changed the status of MediaWiki.r82577. Old Status: fixme New Status: new User Hashar also posted a comment on MediaWiki.r82577. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82577#c20811 Commit summary: improve namespace related methods MWNamespace::getTalk() could give erroneus results when using it on specials namespaces (NS_MEDIA, NS_SPECIAL). It now use MWNamespace::isMethodValidFor() which will throw an exception if a special namespace was given. MWNamespace::getSubject() is now returning identity for specials namespaces. New MWNamespace::getAssociated() used to find out the subject page of a talk page and vice versa. Special namespaces will results in an exception. TESTS: Added tests for almost complete code coverage. Functions relying on global $wgCanonicalNamespaces are still incomplete though. MWNamespace::isMovable() needs more assertions. Tests results (ignoring incomplete tests output): $ php phpunit.php --filter MWNamespace PHPUnit 3.5.10 by Sebastian Bergmann. .I.. Time: 1 second, Memory: 31.75Mb OK, but incomplete or skipped tests! Tests: 24, Assertions: 99, Incomplete: 5. Comment: resetting to new. Looks fine in both 1.18 and trunk ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92200]: New comment added
User NeilK posted a comment on MediaWiki.r92200. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92200#c20812 Commit summary: fixed a condition where re-uploading a file that's already stashed causes breakage. This mirrors the previous session-based behavior as closely as possible. Comment: Maybe I'm missing something basic here, but it seems to me you are discussing race conditions that are unlikely to occur in the remaining lifetime of our universe. The keys are random. If our PRNG is broken we have worse problems than a file being overwritten. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92200]: New comment added
User Catrope posted a comment on MediaWiki.r92200. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92200#c20813 Commit summary: fixed a condition where re-uploading a file that's already stashed causes breakage. This mirrors the previous session-based behavior as closely as possible. Comment: Ian suggests it's possible to supply non-random keys: blockquote This was a problem when we were using the content hash as the filekey. The key is a unique string as of r92269, so it's only relevant if the user-supplied key is non-unique. That's a pretty rare edge case, but I figured since it was possible I'd leave the code in. /blockquote I agree that race conditions in the random keys can be considered impossible. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92200]: New comment added
User NeilK posted a comment on MediaWiki.r92200. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92200#c20814 Commit summary: fixed a condition where re-uploading a file that's already stashed causes breakage. This mirrors the previous session-based behavior as closely as possible. Comment: I meant you in the plural sense of both of you. ;) But Ian I discussed this in person and he really wanted to be sure, (perhaps it is worth it, if other things about how we choose the key change?) so I didn't demand that the code be removed. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92200]: New comment added
User Catrope posted a comment on MediaWiki.r92200. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92200#c20815 Commit summary: fixed a condition where re-uploading a file that's already stashed causes breakage. This mirrors the previous session-based behavior as closely as possible. Comment: I'm personally fine with somewhat ungraceful handling of a very rare edge case based on duplicate random keys for which the probability they will ever happen in the remaining lifetime of the universe is very low, as long as the consequences aren't too confusing. Just throwing an error is fine, overwriting things is not. But if you're gonna write code to handle this case and resolve it in a nice way, you should at least write correct code :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92009]: New comment added
User NeilK posted a comment on MediaWiki.r92009. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92009#c20816 Commit summary: Refactored UploadStash and related classes to use the database for file metadata storage instead of the session, see bug 26179 Tweaked the UploadWizard to work properly with the new backend code, updated tests Comment: In UploadStash.php line 50, the function is returning a boolean value. So that's correct to use ||. The other cases (line 77,81) I agree. That is perplexing. Not sure why this even works now. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92009]: New comment added
User Catrope posted a comment on MediaWiki.r92009. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92009#c20817 Commit summary: Refactored UploadStash and related classes to use the database for file metadata storage instead of the session, see bug 26179 Tweaked the UploadWizard to work properly with the new backend code, updated tests Comment: You're misreading the parentheses on line 50. The || is used to compute the parameter to the function instead of being applied to the return value. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92234]: New comment added, and revision status changed
User Hashar changed the status of MediaWiki.r92234. Old Status: fixme New Status: new User Hashar also posted a comment on MediaWiki.r92234. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92234#c20818 Commit summary: NS_MAIN can locally have subpages enabled This workaround test if any local change has been made, if so the test will be skipped. fu r82577 Comment: resetting to 'new' per r94517 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94517]: New comment added
User Hashar posted a comment on MediaWiki.r94517. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94517#c20819 Commit summary: Fix up NS_MAIN subpage tests Per CR on r92234, this correctly test hasSubpages independently from your local configuration. Also test altering the global and having static methods reacting accordingly. Comment: Tagging 1.18. Not really needed but would be nice :-) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94499]: Revision status changed
User Hashar changed the status of MediaWiki.r94499. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94499#c0 Commit summary: Localization update for he. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92009]: New comment added
User NeilK posted a comment on MediaWiki.r92009. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92009#c20820 Commit summary: Refactored UploadStash and related classes to use the database for file metadata storage instead of the session, see bug 26179 Tweaked the UploadWizard to work properly with the new backend code, updated tests Comment: You're right, my fault. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92009]: New comment added
User NeilK posted a comment on MediaWiki.r92009. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92009#c20821 Commit summary: Refactored UploadStash and related classes to use the database for file metadata storage instead of the session, see bug 26179 Tweaked the UploadWizard to work properly with the new backend code, updated tests Comment: Ian - you can check if the listFiles() function is broken by uploading a couple of files, and then not proceeding to describe them. In another tab open: http://yoursite/wiki/Special:UploadStash I think I understand the problem with initializeFromRequest. That code path isn't even touched by UploadWizard, since it uses the API. Only Special:Upload uses it. To trigger it, you have to craft a problem with the file that won't be caught by Special:Upload, which will cause it to be stashed. An example might be to try a file like SANY_12345.JPG, because (if you copied the Commons config) that's a Blacklisted title but isn't caught by any hardcoded checks. Then, even if you fix the stash, nothing seems to happen; you get sent back to an empty upload form. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94260]: New comment added
User Mdale posted a comment on MediaWiki.r94260. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94260#c20822 Commit summary: Remove 'private' version of mediawiki.Uri from MwEmbedSupport. This may possibly break MwEmbedStandalone ? But who cares, it's about time this stuff gets out the door, let this be the point where we remove all the cruft. Comment: thanks, should not have any adverse affects if the api for Mw.Uri did not change. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] forking media files
The problem is that 1) the files are bulky, 2) there are many of them, 3) they are in constant flux, and 4) it's likely that your connection would close for whatever reason part-way through the download.. Even taking a snapshot of the filenames is dicey. By the time you finish, it's likely that there will be new ones, and possible that some will be deleted. Probably the best way to make this work is to 1) make a snapshot of files periodically, 2) create an API which returns a tarball using the snapshot of files that also implements Range requests. The snapshot of filenames would have to include file sizes so the server would know where to restart. Once the snapshot had not been accessed in a week, it would be deleted. As a snapshot got older and older it would be less and less accurate, but hey, life is tough that way. Of course, this would result in a 12-terabyte file on the recipient's host. That wouldn't work very well. I'm pretty sure that the recipient would need an http client which would 1) keep track of the place in the bytestream and 2) split out files and write them to disk as separate files. It's possible that a program like getbot already implements this. From: wikitech-l-boun...@lists.wikimedia.org [wikitech-l-boun...@lists.wikimedia.org] on behalf of Peter Gervai [grin...@gmail.com] Sent: Monday, August 15, 2011 4:45 AM To: Wikimedia developers Subject: [Wikitech-l] forking media files Let me retitle one of the topics nobody seems to touch. On Fri, Aug 12, 2011 at 13:44, Brion Vibber br...@pobox.com wrote: * media files -- these are freely copiable but I'm not sure the state of easily obtaing them in bulk. As the data set moved into TB it became impractical to just build .tar dumps. There are batch downloader tools available, and the metadata's all in dumps and api. Right now it is basically locked: there is no way to bulk copy the media files, including doing simply a backup of one wikipedia, or commons. I've tried, I've asked, and the answer was basically to contact a dev and arrange it, which obviously could be done (I know many of the folks) but that isn't the point. Some explanations were mentioned, mostly mentioning that media and its metadata is quite detached, and thus it's hard to enforce licensing quirks like attribution, special licenses and such. I can guess this is a relevant comment since the text corpus is uniformly licensed under CC/GFDL while the media files are at best non-homogeneous (like commons, where everything's free in a way) and completely chaos at its worst (individual wikipedias, where there may be anything from leftover fair use to copyrighted by various entities to images to be deleted soon). Still, I do not believe it's a good method to make it close to impossible to bulk copy the data. I am not sure which technical means is best, as there are many competing ones. We could, for example, open up an API which would serve media file with its metadata together, possibly supporting mass operations. Still, it's pretty ineffective. Or we could support zsync, rsync and such (and I again recommend examining zsync's several interesting abilities to offload the work to the client), but there ought to be some pointers to image metadata, at least an oneliner file with every image linking to the license page. Or we could connect the bulk way to established editor accounts, so we could have at least a bit of an assurance that s/he knows what s/he's doing. -- byte-byte, grin ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91918]: Revision status changed
User Happy-melon changed the status of MediaWiki.r91918. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91918#c0 Commit summary: Added explicit parse() call to wfMessage object ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92009]: New comment added
User Raindrift posted a comment on MediaWiki.r92009. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92009#c20823 Commit summary: Refactored UploadStash and related classes to use the database for file metadata storage instead of the session, see bug 26179 Tweaked the UploadWizard to work properly with the new backend code, updated tests Comment: You are totally right. So much for search/replace, I guess. Fixed in r94526 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] question about common information templates
I'm going to break this down into several related questions and answer them separately: * Is there a plan to unify the visual style of common layout patterns in Wikipedia, so that the many thousands of separate people creating templates and pages can follow them? Not really; there has been some work on planning a more standardized visual style guide for *MediaWiki* software components -- http://www.mediawiki.org/wiki/Style_guide -- but afaik no Foundation-funded work has been done to rework, unify, or improve the various per-site community-created style guides for content. * Is there / will there soon be a way to store common templates/styles such that they can be used from any Wikipedia or other Wikimedia site, so that single common implementations can be maintained for many of those templates, instead of separately-maintained copies on many wikis that are harder to keep in sync? There's talk about this fairly regularly (interwiki templates, shared gadgets etc). It's on the table to happen at some point, but probably isn't at the top of many activity lists. * Is there a plan to replace particular template implementations that are slow or hard to maintain with native MediaWiki extensions that might be more efficient or easier to maintain in a centralized way? There's sometimes talk about particular ones, but there's no general program to be replacing them. Citation-related templates tend to be at the top of this list as they often are fairly complicated and take a bunch of parameters to format them in a fairly consistent way. * Is there a plan to introduce a different way of implementing templates for infoboxes etc that will be easier for people to maintain, and possibly faster than the current markup-based templates? There's sometimes talk about this; see past threads about possible use of Lua, JavaScript, or a custom mini language for template usage. Not currently at top of list, but both Tim and I would like to see this happen at some point. * There might be invalid HTML somewhere! Fix em if you find em. The wiki system should ensure that output is never invalid as such (though some w3c validator sort of things are errors we'll never care about). Better tools to create and maintain templates will help with real issues like this template breaks half the time because it's got a wrong close tag by making it easier to find and fix them. -- brion On Sat, Aug 13, 2011 at 7:32 AM, Glanthor glant...@gmail.com wrote: Is there any plan according to supersede the old template system with built-in software support in core or in extension, at least partially? I mean there are several common templates, that should be designed once and professionally, and used on all Wikipedias: like amboxes, infoboxes, navboxes, coordinate templates, portal templates, sister project templates, and so on. And I don't mean a „template-commons” with unchanged template syntax, but real software support. Users became more and more „perverse” about creating more complicated and resource-hungry templates, what only a few editor can modify and understand correctly, because their complexity. The current practise is far from ideal, these templates I mentioned above should look uniform, and be informational. Currently they are target to bikeshed operations: on the hungarian Wikipedia, there was even a voting about the font size of the infoboxes. Wikipedia is not a coloring book, and not about constant redesigning of important parts of the articles. As we do not change the default skin in every half a year, we should not allow to change the look of standard informational elements, at least not in that amateur way („my favourite color/font is better than yours!”). And I not even mentioned, that high percentage of the current templates are full of not valid html code, because the average user do not understand (and should not have to understand) html/html5/css/advanced parser functions. So, is there any plan or ongoing debate/developement about this? * * Farewell, *Glanthor* ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r87584]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r87584. Old Status: resolved New Status: fixme User Brion VIBBER also posted a comment on MediaWiki.r87584. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87584#c20824 Commit summary: More versions added to @deprecated tags Couple of inbound calls fixed up Some ancient code removed as it's been marked deprecated Comment: This commit removed LocalFile::recordUpload, apparently causing bug 30355. WHYYY please don't remove things like this... ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92009]: New comment added, and revision status changed
User Raindrift changed the status of MediaWiki.r92009. Old Status: fixme New Status: new User Raindrift also posted a comment on MediaWiki.r92009. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92009#c20825 Commit summary: Refactored UploadStash and related classes to use the database for file metadata storage instead of the session, see bug 26179 Tweaked the UploadWizard to work properly with the new backend code, updated tests Comment: re: || operator, I have no idea where I got the notion that such a thing would work. Looking at it myself, I'm like, WTF? Fixed. I'm not entirely sure why this didn't cause serious problems either, but I've added some tests to cover this code since we needed them anyway. regarding usage of empty(): I was just duplicating the behavior that was there before (Reedy's, I believe--all I changed is the name of the variable). However, I think you're right, and I've changed it to !. re: listfiles(), it should be checking against the user. Fixed. Regarding lag, I based my decision on the following statement in [http://www.mediawiki.org/wiki/Manual:Coding_conventions#PHP_pitfalls Database Access/Working with lag]: To avoid swamping the master every time the slaves lag, use of this approach should be kept to a minimum. In most cases you should just read from the slave and let the user deal with the delay. UploadWizard could generate a page that requires a select for each of many images. I'm concerned about the load that could place on the master. I'll totally change it if you think it's best, but are you sure? Anyway, this is all implemented in r94536 except the lag stuff. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94289]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r94289. Old Status: new New Status: fixme User Brion VIBBER also posted a comment on MediaWiki.r94289. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94289#c20826 Commit summary: * Added rev_sha1 and ar_sha1 columns to revision/archive tables (useful for bug 25312) * Created a script to populate these fields (doesn't handle archive rows without ar_rev_id set though) Comment: Core table change with no discussion on wikitech-l? Needs immediate revert. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94539]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r94539. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94539#c0 Commit summary: cleaned up database query, doesn't have to be aware of column names anymore (thanks Catrope!) followup to r92009 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94517]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r94517. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94517#c0 Commit summary: Fix up NS_MAIN subpage tests Per CR on r92234, this correctly test hasSubpages independently from your local configuration. Also test altering the global and having static methods reacting accordingly. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94289]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r94289. Old Status: fixme New Status: reverted User Brion VIBBER also posted a comment on MediaWiki.r94289. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94289#c20827 Commit summary: * Added rev_sha1 and ar_sha1 columns to revision/archive tables (useful for bug 25312) * Created a script to populate these fields (doesn't handle archive rows without ar_rev_id set though) Comment: Reverted in r94541. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94290]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r94290. Old Status: new New Status: reverted User Brion VIBBER also posted a comment on MediaWiki.r94290. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94290#c20828 Commit summary: Follow-up r94289: code changes to fill the new fields on insertion and select them Comment: undiscussed core schema change, reverted in r94541. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94294]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r94294. Old Status: ok New Status: reverted User Brion VIBBER also posted a comment on MediaWiki.r94294. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94294#c20829 Commit summary: Fix case of the new file added in r94289 Produced the following fatal on Unix systems when trying to update: Warning: require(maintenance/PopulateRevisionSha1.php): failed to open stream: No such file or directory in includes/AutoLoader.php on line 922 Fatal error: require(): Failed opening required 'maintenance/PopulateRevisionSha1.php' in includes/AutoLoader.php on line 922 Comment: undiscussed core schema change, reverted in r94541. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94333]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r94333. Old Status: ok New Status: reverted User Brion VIBBER also posted a comment on MediaWiki.r94333. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94333#c20830 Commit summary: Fix copy-paste mistake in r94289 Comment: undiscussed core schema change, reverted in r94541. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94362]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r94362. Old Status: new New Status: reverted User Brion VIBBER also posted a comment on MediaWiki.r94362. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94362#c20832 Commit summary: Fix for r94289: we want to skip rows with non-empty sha1, not non-NULL (which is impossible) Comment: undiscussed core schema change, reverted in r94541. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94345]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r94345. Old Status: ok New Status: reverted User Brion VIBBER also posted a comment on MediaWiki.r94345. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94345#c20831 Commit summary: Follow-up r94289: SQLite support, unbreaks tests Comment: undiscussed core schema change, reverted in r94541. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94370]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r94370.
Old Status: new
New Status: reverted
User Brion VIBBER also posted a comment on MediaWiki.r94370.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94370#c20833
Commit summary:
* Added LoggedUpdateMaintenance subclass
* Moved PopulateRevisionLength/PopulateRevisionSha1 scripts to
$postDatabaseUpdateMaintenance
* Fixed bogus {$prefix}_sha1 != '' comparison (r94362)
* Removed unneeded NOT NULL check (speeds up script a bit) from
populateRevisionSha1 script
* Various code cleanups
Comment:
undiscussed core schema change, reverted in r94541.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92200]: New comment added
User Raindrift posted a comment on MediaWiki.r92200. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92200#c20834 Commit summary: fixed a condition where re-uploading a file that's already stashed causes breakage. This mirrors the previous session-based behavior as closely as possible. Comment: My code generates the key for all the use cases in UW. The key is guaranteed unique, and I'm not concerned about a race condition there. I wrote this code when that wasn't true. However, it's possible to pass in a key from elsewhere. That is, I don't have any guarantee that this key will be unique at all, since I'm not always generating it. For example, if the externally-generated key is based on the local filename, collisions could arise. Since the key is always owned by the uploading user, it seemed almost certain that a key collision would mean a newer version of the file, which is why the default is to overwrite. I'd be down to remove all this code, though, as long as I also remove the $key param from UploadStash::stashFile(). I'm concerned that doing so might break something external somewhere, though, which is why I left it alone. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94370]: New comment added
User ^demon posted a comment on MediaWiki.r94370.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94370#c20835
Commit summary:
* Added LoggedUpdateMaintenance subclass
* Moved PopulateRevisionLength/PopulateRevisionSha1 scripts to
$postDatabaseUpdateMaintenance
* Fixed bogus {$prefix}_sha1 != '' comparison (r94362)
* Removed unneeded NOT NULL check (speeds up script a bit) from
populateRevisionSha1 script
* Various code cleanups
Comment:
The ideas in this commit are good and should be reapplied :)
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94370]: New comment added
User Aaron Schulz posted a comment on MediaWiki.r94370.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94370#c20836
Commit summary:
* Added LoggedUpdateMaintenance subclass
* Moved PopulateRevisionLength/PopulateRevisionSha1 scripts to
$postDatabaseUpdateMaintenance
* Fixed bogus {$prefix}_sha1 != '' comparison (r94362)
* Removed unneeded NOT NULL check (speeds up script a bit) from
populateRevisionSha1 script
* Various code cleanups
Comment:
Yeah, I'm trying to do that now.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94290]: New comment added
User Duplicatebug posted a comment on MediaWiki.r94290. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94290#c20837 Commit summary: Follow-up r94289: code changes to fill the new fields on insertion and select them Comment: Only for documentation: You can fill rev_sha1 of the new revision in Revision::newNullRevision() with the existing value. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94364]: New comment added
User Brion VIBBER posted a comment on MediaWiki.r94364. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94364#c20838 Commit summary: * Added Revision::getSha1 function * Try to populate mSha1 when a Revision is made from an array (as rev_len does) Comment: Adding to the revert queue for r94289's evil minions ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94541]: Revision status changed
User Hashar changed the status of MediaWiki.r94541. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94541#c0 Commit summary: Revert r94289, r94290, r94294, r94333, r94345, r94362, r94370 -- core schema change with no discussion ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92430]: New comment added
User Duplicatebug posted a comment on MediaWiki.r92430. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92430#c20839 Commit summary: * (bug 29935) Improve formatting of examples in ApiParamInfo Old example string with newlines left for the moment, pending discussion on bug... Comment: Looks bad, when there are no examples, like api.php?action=paraminfopagesetmodule=, having r94448 also for this makes sense. Thanks. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94528]: New comment added
User MZMcBride posted a comment on MediaWiki.r94528. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94528#c20840 Commit summary: add ability to re-enable images once disabled Comment: This feels strange. You already had a boolean parameter. Now you have two? Not that ?disableImages=0 is a great situation to have from a clarity standpoint, but I think it's preferable to an additional parameter. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94547]: Revision status changed
User Hashar changed the status of MediaWiki.r94547. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94547#c0 Commit summary: Followup r94541 (reverts of r94289 undiscussed core schema change and followups), two more that got missed: reverts of r94290, r94364 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94545]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r94545. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94545#c0 Commit summary: Fixup some whitespace Add a couple of FIXMEs where variables are undefined Swap newGood() for Status::newGood() ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94364]: Revision status changed
User Brion VIBBER changed the status of MediaWiki.r94364. Old Status: new New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94364#c0 Commit summary: * Added Revision::getSha1 function * Try to populate mSha1 when a Revision is made from an array (as rev_len does) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92200]: New comment added
User NeilK posted a comment on MediaWiki.r92200. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92200#c20841 Commit summary: fixed a condition where re-uploading a file that's already stashed causes breakage. This mirrors the previous session-based behavior as closely as possible. Comment: We're close to being able to remove the $key parameter entirely. The only way (as far as I can tell) that $key is ever necessarily non-null is the case of includes/job/UploadFromUrlJob.php. In fact UploadFromUrlJob.php is already outmoded, it's making assumptions that the session is where the stashed files are. I believe it can be simplified so that it doesn't pass a key at all, and instead returns the key generated. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94546]: New comment added
User Aaron Schulz posted a comment on MediaWiki.r94546. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94546#c20842 Commit summary: Restored r94370 changes PopulateRevisionLen, moving it to $postDatabaseUpdateMaintenance Comment: Also needed to unbreak PopulateImageSha1. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94088]: New comment added
User Raindrift posted a comment on MediaWiki.r94088. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94088#c20843 Commit summary: Updated to use the copy of Jasmine in core, including extensions added in r93908 Comment: Yeah. It's like morse code or something. Is there a better way? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87154]: New comment added
User MZMcBride posted a comment on MediaWiki.r87154. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87154#c20844 Commit summary: initial import of proof of concept Comment: This revision introduced a very minor inconsistency in the footer HTML. lt;div id=permgt; is using quotation marks when the other code in the footer is using apostrophes. I also have no idea why this revision was marked old. I thought that status was reserved for... old revisions. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Sep11 Wiki
On Mon, Aug 8, 2011 at 10:45 AM, Ryan Lane rlan...@gmail.com wrote: On Sat, Aug 6, 2011 at 2:38 AM, Thomas Morton morton.tho...@googlemail.com wrote: I am note sure who might be in a position to correct this, but this list seems the most likely.. For some reason sep11.wikipedia.org subdomain is forwarding to a spam site - this was pointed out on OTRS earlier. I assume this was set up as a redirect to the 9/11 memories Wiki, and that site has since been taken over. Can someone fix this? I was sitting next to Rob Halsell while I was reading this. I let him know and he fixed it by removing the redirect. Redirect seems to be gone now, but it just shows the generic 'no wiki' page: http://sep11.wikipedia.org/ Welcome to Wikimedia Unfortunately, this wiki does not exist yet, or it has been closed. You may be looking for one of our other projects below. If you would like to request that this wiki be created, see the requests for new languageshttp://meta.wikimedia.org/wiki/Requests_for_new_languagespage on Meta-Wiki. So the site itself is probably no longer in our configurations; it either needs to be set back or replaced with a URL to a mirror that will actually stay around. (It would make sense, I imagine, to just host it ourselves at its own domain?) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r94303]: New comment added
User MZMcBride posted a comment on MediaWiki.r94303. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94303#c20845 Commit summary: fix for Bug 29520 - Ability to turn off images on mobile and wap-mobile page views Comment: The separator (|) is being hardcoded here. I think it's generally not supposed to be? There are several separator messages (including [[MediaWiki:Pipe-separator]]) already to choose from. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Sep11 Wiki
On Mon, Aug 15, 2011 at 2:59 PM, Brion Vibber br...@pobox.com wrote: (It would make sense, I imagine, to just host it ourselves at its own domain?) Would it, though? I thought it was moved off Wikimedia's servers on purpose, because it's not really something that we want to be hosting. It's not really related to our mission and is a little USA-centric. That's what I always thought was the reason it was moved off, at least. You were probably around back then though, so you'd know better. :-) -- Casey Brown Cbrown1023 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r94546]: New comment added
User Aaron Schulz posted a comment on MediaWiki.r94546. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94546#c20846 Commit summary: Restored r94370 changes PopulateRevisionLen, moving it to $postDatabaseUpdateMaintenance Comment: Actually, LoggedUpdateMaintenance was left in Maintenance already. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94482]: New comment added
User Nikerabbit posted a comment on MediaWiki.r94482. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94482#c20847 Commit summary: Follow-up r92559: * Use preg_quote() for arrays going to regexes * Proper escaping for InfoPage-mFormatTitle and status message * Use wgOut-addModuleStyles() to prevent flash of unstyled content * Use $wgExtensionAssetsPath to form extension directory * Remove unneeded isset()s * Also, prevent php notices in onShowMissingArticle() Comment: You should pass second parameter (the used delimeter) to preg_quote. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94484]: Revision status changed
User Nikerabbit changed the status of MediaWiki.r94484. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94484#c0 Commit summary: Added period to end of 'sf_formerrors_header' value, in English ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94289]: New comment added
User MZMcBride posted a comment on MediaWiki.r94289. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94289#c20848 Commit summary: * Added rev_sha1 and ar_sha1 columns to revision/archive tables (useful for bug 25312) * Created a script to populate these fields (doesn't handle archive rows without ar_rev_id set though) Comment: A bit of discussion at bug 21860 and bug 25312. I'm not sure the approval process for core schema changes is documented anywhere. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94479]: New comment added
User Simetrical posted a comment on MediaWiki.r94479. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94479#c20849 Commit summary: Use Html::element instead. Follow up to r94385 Comment: You're missing a space before the closing ), but more importantly, you didn't explain your removal of the alt text here. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92009]: New comment added
User Catrope posted a comment on MediaWiki.r92009. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92009#c20850 Commit summary: Refactored UploadStash and related classes to use the database for file metadata storage instead of the session, see bug 26179 Tweaked the UploadWizard to work properly with the new backend code, updated tests Comment: What you did is not what we meant with let the user deal with the delay. You're supposed to either present the user with a page with the caveat that it might be out of date, or read from the slave first and if you find the data is out of date in a nasty way (like, something doesn't exist yet but you suspect it should), read from the master. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94088]: New comment added
User Reedy posted a comment on MediaWiki.r94088. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94088#c20851 Commit summary: Updated to use the copy of Jasmine in core, including extensions added in r93908 Comment: We can use $IP in php code, but I don't think there is... ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81583]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r81583. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81583#c0 Commit summary: Switch editsection to mw:editsection and start hiding these editsection tags from Tidy so it doesn't break them. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Sep11 Wiki
On Mon, Aug 15, 2011 at 2:59 PM, Brion Vibber br...@pobox.com wrote: So the site itself is probably no longer in our configurations; it either needs to be set back or replaced with a URL to a mirror that will actually stay around. (It would make sense, I imagine, to just host it ourselves at its own domain?) At the risk of sounding callous...do we even want the wiki anymore? -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r84840]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r84840. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84840#c0 Commit summary: (bug 24081, bug 28268) Add tooltip to my new messages in personal tool links, texts consistent with others, 0 new messages shown, too. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92045]: Revision status changed
User Hashar changed the status of MediaWiki.r92045. Old Status: ok New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92045#c0 Commit summary: Add some tests for wfExpandUrl. Definitely not complete (needs some for protocol relativeness) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94554]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r94554. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94554#c0 Commit summary: Use local context rather than global ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Pre-release info for a new version Extension:RSS
If you never intended to use, or if you do not use the RSS extension ... ...then you can stop reading here. http://www.mediawiki.org/wiki/Extension:OpenID When debugging E:RSS, I found some inconsistencies how two templates are used for rendering RSS feeds on mediawiki pages, and fixed this and other issues in a new version (not yet in svn). I would be interested in your _quick_ _feedback_ about the changes (intended to be published today) which are listed in the !!preview of RELEASE-NOTES!! === Version 1.90 2011-08-15 === * removed parsing of each single channel subelement (item) * only the finally constructed feed is sent to the recursive parser: in pre-1.9 versions, each channel subelement (item) was sent to the parser * [[MediaWiki:Rss-item]] default has channel subelement description added This was never present in previous versions * Rss template default name has been changed: until 1.8: [[Template:RSSPost]] 1.9: [[MediaWiki:Rss-feed]], an existing [[Template:RSSPost]] takes precedence to be compatible with pre-1.9 versions * introduced [[MediaWiki:Rss-feed]] with a meaningful default as part of the release. The channel subelements which make the feed are rendered in this standard layout: * title : description : author date * There are several ways to customize the final layout of feed items: 1. Admins can change the [[MediaWiki:Rss-feed]] default page 2. Users can use the optional template= parameter to tell the extension to render the feed with a different layout rss template=Pagename.../rss use layout as in [[Template:Pagename]] 3. rss template=Namespace:Pagename.../rss use [[Namespace:Pagename]] Tom signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r94555]: Revision status changed
User ^demon changed the status of MediaWiki.r94555. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94555#c0 Commit summary: PHPUnit test file must end with 'Test.php' follow up r92045 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Pre-release info for a new version Extension:RSS
http://www.mediawiki.org/wiki/Extension:RSS was meant, of course. sorry signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sep11 Wiki
On Mon, Aug 15, 2011 at 12:01 PM, Chad innocentkil...@gmail.com wrote: On Mon, Aug 15, 2011 at 2:59 PM, Brion Vibber br...@pobox.com wrote: So the site itself is probably no longer in our configurations; it either needs to be set back or replaced with a URL to a mirror that will actually stay around. (It would make sense, I imagine, to just host it ourselves at its own domain?) At the risk of sounding callous...do we even want the wiki anymore? It's fascinating cultural history (both of a country called the USA and - more importantly to some here perhaps? - of Wikipedia's early years) -- if we don't want it, well, I think that's a darn shame. IIRC Erik Moeller was one of the drivers behind moving this tiny collection of pages (much smaller than thousands of other things we host) offsite in '06, and at the time even he seemed to agree that the pages had relevance and should be preserved: I believe our own project history is important and deserves respect and attention, even if we decide that a project is not within the scope of the Wikimedia Foundation, and especially when dealing with a subject such as this. http://web.archiveorange.com/archive/v/peESw2iBig7YE4ZlyQ8x A number of related pages on meta appear to still be around, should anybody care to revisit these 5-year old discussions: http://meta.wikimedia.org/wiki/What_to_do_with_entries_related_to_September_11_casualties -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r76647]: New comment added
User MZMcBride posted a comment on MediaWiki.r76647. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/76647#c20852 Commit summary: Adding emergency short circuit Comment: Emergecny short cut should be Emergency shortcut. It's been about nine months since this revision was committed. Has there been any progress in fixing the underlying issue? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r76647]: New comment added
User Tfinc posted a comment on MediaWiki.r76647. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/76647#c20853 Commit summary: Adding emergency short circuit Comment: I've asked Arthur (tech lead for the fundraiser) to comment on this since i'm not actively developing this code base. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r93906]: New comment added
User Raindrift posted a comment on MediaWiki.r93906. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93906#c20854 Commit summary: Extension that pulls out Neilk's excellent jQuery localization/parsing thingy and makes it generally available. This may get rolled into trunk at some point, but for now turning this on will at least make it usable for development outside UploadWizard. Comment: I've moved and slightly updated [[User:Neilk]]'s existing docs, and added a redirect. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81517]: New comment added, and revision status changed
User Aaron Schulz changed the status of MediaWiki.r81517.
Old Status: new
New Status: ok
User Aaron Schulz also posted a comment on MediaWiki.r81517.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81517#c20855
Commit summary:
Follow-up r81074: turns out {{convert}} is (mostly) case-sensitive after all,
so reclaim case-sensitivity here. Will work on abstracting out SI prefixes
later.
Comment:
I'd agree with the case-sensitivity added in this commit.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94558]: New comment added
User Aaron Schulz posted a comment on MediaWiki.r94558. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94558#c20856 Commit summary: Tests for wfGetIP() follow up r89407 * wfGetIP() now support resetting its internal static variable. Thanks to Platonides which introduced this trick with r92960. * Various tests for $_SERVER['REMOTE_ADDR'] and $wgCommandLineMode. TODO: - implements tests for XFF headers. TEST PLAN: $ ./phpunit.php --filter wfGetIP --testdox PHPUnit 3.5.14 by Sebastian Bergmann. wfGetIP [x] Get loopback address when in command line [x] Get from server remote addr [x] Lack of remote addr throw an exception $ Comment: Can it check if $reset equals reset instead of an opaque boolean? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r76647]: New comment added
User Awjrichards posted a comment on MediaWiki.r76647. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/76647#c20857 Commit summary: Adding emergency short circuit Comment: At the moment, there are no plans to start using ContributionHistory again, although it is certainly possible that it will come up again for this year's fundraiser. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94371]: New comment added
User Catrope posted a comment on MediaWiki.r94371. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94371#c20858 Commit summary: Expand another URL in the CentralAuth API Comment: Untagging 1.17wmf1, the code that outputs the URL is not present in that branch. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Improved RTL support and introduction of page content language
Hi, I usually don't post to mailing lists, but Brion suggested I should do this for the page content language. I suppose most people now that I improved the RTL support. Documentation of that is now at http://www.mediawiki.org/wiki/Directionality_support If it is incomplete or unclear about something, please ask so I can improve the docs. While doing that, I introduced a page content language that defines the language in which a specific page is written. I added docs for that as well, see http://www.mediawiki.org/wiki/Language_in_MediaWiki For special pages it is $wgLang, for MediaWiki namespace pages it depends on the subpage code, for other pages it is $wgContLang. Extensions (like Translate) can change the language a page is supposed to be written in. This affects the direction of the content, the TOC, and (in theory) the grammar. Again, if the docs are missing something important, let me know. But, now that I am writing this anyway, I have a question: should magic words like CURRENTMONTH and NUMBEROFARTICLES use the page content language rather than wgContLang? It would be more logical (and on Incubator even wanted: http://incubator.wikimedia.org/wiki/Template:Wp/lkt/CURRENTMONTHNAMEI ) but I am not sure if it would break things, e.g. when just with a template. (And btw, another i18n thing that needs attention is LanguageConverter (even just for missing docs). I am looking if I can help out there.) Regards, Robin aka SPQRobin ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r94343]: New comment added
User MZMcBride posted a comment on MediaWiki.r94343. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94343#c20859 Commit summary: Add a new type of ballot: Radio range with comment. Solicits the user for comments, and sticks it in the ballot. This means that the size of ballots changes, but not on the basis of the vote they take, which is the important reason why ballot size cannot differ by the user (to avoid revealing the actual votes). Comment: Explicitly Wikimedia-specific code in trunk? Seems strange. I thought the reason for having Wikimedia branches was for code like this. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94343]: New comment added
User ^demon posted a comment on MediaWiki.r94343. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94343#c20860 Commit summary: Add a new type of ballot: Radio range with comment. Solicits the user for comments, and sticks it in the ballot. This means that the size of ballots changes, but not on the basis of the vote they take, which is the important reason why ballot size cannot differ by the user (to avoid revealing the actual votes). Comment: The cool thing about SecurePoll is various ballot types like this don't affect others. If you want to use SecurePoll but don't want this ballot, don't use it :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r82230]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r82230. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82230#c0 Commit summary: Follow-up r81074, r81517: implement SI prefixes as a separate structure. You can now specify which units should take SI, and then they accept *all* SI prefixes centrally. Some care is still needed to avoid unit conflicts, but this substantially reduces the number of messages required. The translations of prefixed units in some languages may be a little tricky if the prefix is inflected etc, but you know what? You can always use ParserFunctions!! :-D ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r82472]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r82472. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82472#c0 Commit summary: Follow-up r82452: need to transform entries sinces some wiki like to use variables or parser functions in the sidebar ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Improved RTL support and introduction of page content language
On Mon, Aug 15, 2011 at 1:23 PM, Robin Pepermans robinp.1...@gmail.comwrote: Hi, I usually don't post to mailing lists, but Brion suggested I should do this for the page content language. Thanks! :D I suppose most people now that I improved the RTL support. Documentation of that is now at http://www.mediawiki.org/wiki/Directionality_support If it is incomplete or unclear about something, please ask so I can improve the docs. While doing that, I introduced a page content language that defines the language in which a specific page is written. I added docs for that as well, see http://www.mediawiki.org/wiki/Language_in_MediaWiki For special pages it is $wgLang, for MediaWiki namespace pages it depends on the subpage code, for other pages it is $wgContLang. Extensions (like Translate) can change the language a page is supposed to be written in. This affects the direction of the content, the TOC, and (in theory) the grammar. Again, if the docs are missing something important, let me know. I am super happy about this going in as a general concept -- we'll want to make sure there's a way for 'generic' multilingual sites (like meta and commons) to tag pages with their languages as well. Note for those not reading through the links ;) -- you can get a language from a Title object with $title-getPageLanguage(). There's no actual storage of the value now; it just handles some standard logic (special pages are user lang; MediaWiki pages use the language, etc) and provides a hook that extensions can grab to override info for any particular page. For Translate and Incubator, language can be easily pulled from the title as language codes get used as a page title component (suffix or prefix or some such). However for more general pages this may end up being better defined as metadata tied to the page, which'll need storage and being kept across export/import, delete/undelete, etc. It's conceivable that we might want to move that interface over from Title to WikiPage or something, though Title seems to fit best with how we tend to index these things for now (editing protections are also accessed via Title). But, now that I am writing this anyway, I have a question: should magic words like CURRENTMONTH and NUMBEROFARTICLES use the page content language rather than wgContLang? It would be more logical (and on Incubator even wanted: http://incubator.wikimedia.org/wiki/Template:Wp/lkt/CURRENTMONTHNAMEI ) but I am not sure if it would break things, e.g. when just with a template. I would tend to expect it to use the page content language; for templates of course you may well have the issue that the template is trying to work in a particular language, say to generate a link, so that may require some pondering. :) If we pull a template into a parent page, does the template have its own inherent languageness? This is all relevant also to tagging output for languages to aid with screen readers, translation tools, search engines etc -- bug 14649 https://bugzilla.wikimedia.org/show_bug.cgi?id=14649 gives an example of this with messages but templates can have the same issues. -- brion (And btw, another i18n thing that needs attention is LanguageConverter (even just for missing docs). I am looking if I can help out there.) Regards, Robin aka SPQRobin ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r94041]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r94041. Old Status: ok New Status: fixme User Brion VIBBER also posted a comment on MediaWiki.r94041. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94041#c20861 Commit summary: Readd basic headers and html.../html arround error contents that was removed in r90993. This caused display errors of UTF-8 characters due to the lack of these things in a DBConnectionError exception. Comment: PHP Notice: Undefined index: SERVER_PROTOCOL in /home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/includes/Exception.php on line 185 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94041]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r94041. Old Status: fixme New Status: reverted User Brion VIBBER also posted a comment on MediaWiki.r94041. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94041#c20863 Commit summary: Readd basic headers and html.../html arround error contents that was removed in r90993. This caused display errors of UTF-8 characters due to the lack of these things in a DBConnectionError exception. Comment: Reverted in r94568. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94041]: New comment added
User Brion VIBBER posted a comment on MediaWiki.r94041. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94041#c20864 Commit summary: Readd basic headers and html.../html arround error contents that was removed in r90993. This caused display errors of UTF-8 characters due to the lack of these things in a DBConnectionError exception. Comment: This code appears to be trying to output something like 'HTTP/1.1 500 MediaWiki Error', but using $_SERVER['SERVER_PROTOCOL']. And it seems to output it on things that run in phpunit tests. Seems pretty broken? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
