[Bug 18571] New: Purging images does not always force image metadata cache to be cleared
https://bugzilla.wikimedia.org/show_bug.cgi?id=18571 Summary: Purging images does not always force image metadata cache to be cleared Product: MediaWiki Version: 1.15-svn Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: Normal Component: Images and files AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: neph...@skyhighway.com Created an attachment (id=6054) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=6054) Purge cache even if cache says file doesn't exist Inevitably, there are occasionally problems that happen when an image is uploaded. Wiki editors have come to expect that if something unexpected happens, one of the first steps to try is purging the image (e.g., enter a URL such as http://www.uesp.net/w/index.php?title=Image:TR3-npc-Brelyn_Dreloth.jpgaction=purge) -- and that the purge should force the generated image summary page to be refreshed. However, purging an image does not always force a refresh. Specifically, some problems can result in memcached metadata for an image that incorrectly states that an image does not exist -- even though metadata for the image exists in the database, and even though the file exists in the local w/images directory and thumbnails exist in the w/images/thumb directory. Once this happens, a purge request on the image is basically ineffective -- there is no way for wiki editors to force the server to clean out its bad memcache information. The problem in the code is that ImagePage::doPurge() first checks to see whether the image exists, and skips all of the purging if the image does not exist -- or rather if it ''thinks'' that the image does not exist. It never explicitly makes sure that the cached information is correct. A purge request should always force the code to verify in one way or another that the cached information is up to date. The attached patch is a simple fix for the problem -- ensuring that PurgeCache is always called. For those wondering how this situation can occur in the first place, it can happen following image upload problems if a wiki is running multiple content servers. If a problem (upload connection timing out, etc) results in a failure to write the image metadata to the database, multiple content servers can subsequently end up caching the image's nonexistence in their individual memcaches of the metadata. When the file is re-uploaded, only the single server that processes the new image upload registers that the file now exists; all of the other content servers are stuck permanently accessing their incorrect cached metadata. Different servers end up returning different results; there is no way for editors to fix the problem; and, diagnoses based on the assumption that purge has regenerated a page are completely misguided (this long discussion is an example of the confusion and false conclusions that result when purge isn't doing what it should: http://www.uesp.net/wiki/User_talk:Daveh#Urgent:_Possible_Disk_Space_Problem ). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 13451] Set new user groups for bswiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=13451 --- Comment #10 from demicx dem...@wikipedia.ba 2009-04-24 08:45:58 UTC --- Please change this. Thanks. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18553] GeSHI highlighting is broken for bashwhen an apostrophe/single quote is encountered inside a comment
https://bugzilla.wikimedia.org/show_bug.cgi?id=18553 Niklas Laxström niklas.laxst...@gmail.com changed: What|Removed |Added CC||niklas.laxst...@gmail.com Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Niklas Laxström niklas.laxst...@gmail.com 2009-04-24 09:35:39 UTC --- Confirmed that these are fixed in new versions. Duping. *** This bug has been marked as a duplicate of bug 10967 *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 10967] Upgrade to the latest version of GeSHi (1.0.8)
https://bugzilla.wikimedia.org/show_bug.cgi?id=10967 Niklas Laxström niklas.laxst...@gmail.com changed: What|Removed |Added CC||facadeofwa...@yahoo.com --- Comment #11 from Niklas Laxström niklas.laxst...@gmail.com 2009-04-24 09:35:39 UTC --- *** Bug 18553 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18511] Remove hiderevision permission from the Oversight group
https://bugzilla.wikimedia.org/show_bug.cgi?id=18511 --- Comment #7 from Happy-melon happy-me...@live.com 2009-04-24 10:14:22 UTC --- Not sure what relevant comments we're expecting, but 'meh' :D -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 14609] User's namespaces to be searched default not updated after adding new namespace
https://bugzilla.wikimedia.org/show_bug.cgi?id=14609 Robert Stojnic rain...@eunet.yu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #3 from Robert Stojnic rain...@eunet.yu 2009-04-24 10:23:00 UTC --- Did a quick testing, found couple of issues with new preferences. Scenario: 1) Take a user created before the merge 2) add some namespace to $wgNamespacesToBeSearchedDefault 3) since old/new namespaces seem to get intersected, the modification of 2) doesn't really influence the user 4) try changing some of namespaces this user searches via preferences by e.g. adding some namespace, error is returned: There are problems with some of your input, changes are not saved -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18195] Allow changing preferences via API
https://bugzilla.wikimedia.org/show_bug.cgi?id=18195 --- Comment #5 from Roan Kattouw roan.katt...@gmail.com 2009-04-24 10:14:14 UTC --- (In reply to comment #3) Created an attachment (id=6053) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=6053) [details] Half-done patch This patch is sort of done, but it's broken because you can't call wfMsgExt from API modules. You seem to have forgotten to svn add ApiPreferences.php -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 14609] User's namespaces to be searched default not updated after adding new namespace
https://bugzilla.wikimedia.org/show_bug.cgi?id=14609 Robert Stojnic rain...@eunet.yu changed: What|Removed |Added AssignedTo|wikibugs- |agarr...@wikimedia.org |l...@lists.wikimedia.org | Status|REOPENED|NEW -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18501] please move namespace
https://bugzilla.wikimedia.org/show_bug.cgi?id=18501 --- Comment #2 from wmr wmr89502...@gmail.com 2009-04-24 10:28:30 UTC --- http://zh.wikisource.org/wiki/Wikisource:%E5%86%99%E5%AD%97%E9%97%B4#.E6.96.B0.E7.9A.84namespace.E5.B7.B2.E7.BB.8F.E5.AE.8C.E6.88.90 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 471] Basic XML Feed support for watchlist (implementation idea: token)
https://bugzilla.wikimedia.org/show_bug.cgi?id=471 Edward Z. Yang edwardzy...@thewritingpot.com changed: What|Removed |Added Keywords|need-review, patch | --- Comment #41 from Edward Z. Yang edwardzy...@thewritingpot.com 2009-04-24 15:44:53 UTC --- Patch is three years old and doesn't apply anymore, removing patch status. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18572] New: Users should be able to delete pages and image files they create/upload accidentally
https://bugzilla.wikimedia.org/show_bug.cgi?id=18572 Summary: Users should be able to delete pages and image files they create/upload accidentally Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Deleting AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: br...@wikimedia.org It's fairly common for folks, especially newbies, to post a page or upload an image file that they didn't really mean to -- testing something, or accidentally on the wrong wiki, or picked the wrong file. Currently a regular visitor can't fully delete his/her own contributions, even seconds after adding it. This ends up leading to confusion, frustration, and burden on admins as the user tries to contact someone to get it deleted, or it just sits around until someone finds it. It probably makes sense to allow a contributor to retract a new upload or page without requiring admin intervention, at least within some sensible time limit. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18573] New: File Cache created for error page
https://bugzilla.wikimedia.org/show_bug.cgi?id=18573 Summary: File Cache created for error page Product: MediaWiki Version: 1.14.0 Platform: All URL: http://tmbw.net OS/Version: All Status: NEW Severity: normal Priority: Normal Component: Page rendering AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: duk...@gmail.com I have filecaching enabled on my wiki ($wgUseFileCache = true) . Today, my server had a hiccup where it ran out of memory, and it was throwing errors, rather than displaying the page. It actually created a page with the text Fatal error: Out of memory (allocated 11796480) (tried to allocate 4864 bytes) in .../public_html/wiki/includes/Xml.php on line 414 The problem though is that it actually outputted this page, and then stored a copy of it in the file cache. (I was able to quickly fix it by purging it.) I would think that it shouldn't store pages in the file cache if mediawiki encounters an error in rendering the page. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16950] Show move log when viewing/creating a deleted page
https://bugzilla.wikimedia.org/show_bug.cgi?id=16950 church.of.emacs...@gmail.com changed: What|Removed |Added Attachment #6044 is|0 |1 obsolete|| --- Comment #16 from church.of.emacs...@gmail.com 2009-04-24 15:57:18 UTC --- Created an attachment (id=6055) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=6055) Fixed (hopefully all :)) issues with the previous patch -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 471] Basic XML Feed support for watchlist (implementation idea: token)
https://bugzilla.wikimedia.org/show_bug.cgi?id=471 Edward Z. Yang edwardzy...@thewritingpot.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #42 from Edward Z. Yang edwardzy...@thewritingpot.com 2009-04-24 16:54:08 UTC --- Initial implementation comments: * There has never been a syndicated Special page in MediaWiki's codebase before, and the existing code assumes that the corresponding feed is accessible at Special:Watchlist?feed=rss, which is not the case (you have to use the feedwatchlist API URL). There are two methods of going about solving this: one is generating a fake request from Special:Watchlist code to feedwatchlist and returning the code directly, and using the regular syndication link calculation code, and the other is special-casing Special:Watchlist in OutputPage. I would prefer the former, but both are fairly hacky. * My preferred implementation approach is to assume that the user is using a feedreader in their browser. If an unauthenticated user hits the RSS feed, we publish an item explaining to them that they are not logged in, and give them instructions on how to enable the public (should be phrased carefully) feed that they can directly give to their feedreader. This means that the discovery cost is minimal: a user can use the usual mechanism for subscribing to a feed, without having to have had twiddled a preference beforehand. * The token to be used can be cast as either a watchlist token, or a read token: that is, a token that can be used to read any private data on MediaWiki (which is really just watchlist). I prefer the latter. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 2257] Template parameters unavailable to XML-style parser tags
https://bugzilla.wikimedia.org/show_bug.cgi?id=2257 neph...@skyhighway.com changed: What|Removed |Added Attachment #576 is|0 |1 obsolete|| Attachment #577 is|0 |1 obsolete|| Attachment #753 is|0 |1 obsolete|| Attachment #2550 is|0 |1 obsolete|| Attachment #3602 is|0 |1 obsolete|| Attachment #4519 is|0 |1 obsolete|| --- Comment #80 from neph...@skyhighway.com 2009-04-24 17:03:25 UTC --- Created an attachment (id=6056) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=6056) Allow PPFrames to be used to truly make template variables available With the introduction of Preprocessor frames to the parsing process, a completely different approach to fixing this issue becomes available -- one which truly fixes the problem, instead of simply bypassing the problem through parser hooks (which do not provide identical functionality to extension tags). The attached patch works by: 1) Passing the current $frame to the extension tag-calling hook ($frame is also passed to the getVariableValue hook, too, in case extension writers have a need for $frame. there. too) $frame is added as an extra parameter, and therefore this change is transparent to existing extensions (which simply won't realize that there's an extra parameter available). 2) Passing the $frame back to the parser through recursiveTagParse Again, $frame is an extra, optional parameter, so there is no effect of this patch on any existing uses of recursiveTagParse; it simply makes additional functionality available to anyone who wishes to use it. 3) Assorted other code tweaks to pass the $frame variable as an optional argument to all necessary parser functions. In terms of usage, it means that all existing tag extensions will continue to work they way they always have. However, tag extensions that wish to expand template variables now have the option to do so, simply by 1) changing the argument list of the extension's implementation function, e.g. change: function efSampleRender( $input, $args, $parser ) to: function efSampleRender( $input, $args, $parser, $frame ) 2) add $frame to any recursiveTagParse calls, e.g., change: $output = $parser-recursiveTagParse( $text ); to: $output = $parser-recursiveTagParse( $text, $frame ); -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16950] Show move log when viewing/creating a deleted page
https://bugzilla.wikimedia.org/show_bug.cgi?id=16950
Aryeh Gregor simetrical+wikib...@gmail.com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
--- Comment #17 from Aryeh Gregor simetrical+wikib...@gmail.com 2009-04-24
17:24:55 UTC ---
Committed as r49821 with the following tweaks:
-* @param $type String: A log type ('upload', 'delete', etc)
+* @param $type String or array: Log types ('upload', 'delete', etc)
$type - $types (in r49822)
+ // If $type is not an array, make it an array
$type - $types
+ $types = array_diff( $types, array( $t ) );
$t - $type
+ if ( count( $types ) == 0 ) {
+ $types = '';
+ }
Removed, array() evaluates to boolean false, so this isn't needed.
Also note for the future that you shouldn't add RELEASE-NOTES changes to your
patches -- they're easy for the committer to add, and they'll virtually always
cause a conflict when the committer tries to apply the patch.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18572] Users should be able to delete pages and image files they create/upload accidentally
https://bugzilla.wikimedia.org/show_bug.cgi?id=18572 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #1 from Roan Kattouw roan.katt...@gmail.com 2009-04-24 17:35:32 UTC --- (In reply to comment #0) at least within some sensible time limit. If this is time-based, a very good eye should be kept on the Apaches' server times remaining synchronized. API login throttling once broke pretty badly because one server's clock was a few hours off, but if this ever gets implemented, even a few minutes of clock drift would be bad (newbies typically don't take the ah, this is probably just clock drift, let's resubmit in the hopes of hitting another Apache approach). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 17020] Chinese needs sensible fallback character encoding set
https://bugzilla.wikimedia.org/show_bug.cgi?id=17020 --- Comment #5 from Shinjiman shinji...@gmail.com 2009-04-24 18:44:21 UTC --- Just added the fallback encoding for the folowing message files (as r49829): Traditional Chinese (zh-Hant): Windows-950 - CP950 - Big5 Simplified Chinese (zh-Hans): Windows-936 - CP936 - GB2312 Hong Kong Chinese (zh-HK) : Big5-HKSCS P.S. For the generic Chinese language (zh), there's more than one codepage are used so an idea to using more than one encoding as fallback is considerable. For example, try the first encoding. If found, go to the page; otherwise try the second encoding and so on. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 471] Basic XML Feed support for watchlist (implementation idea: token)
https://bugzilla.wikimedia.org/show_bug.cgi?id=471 Aryeh Gregor simetrical+wikib...@gmail.com changed: What|Removed |Added CC||simetrical+wikib...@gmail.co ||m --- Comment #44 from Aryeh Gregor simetrical+wikib...@gmail.com 2009-04-24 19:00:12 UTC --- (In reply to comment #42) * There has never been a syndicated Special page in MediaWiki's codebase before, and the existing code assumes that the corresponding feed is accessible at Special:Watchlist?feed=rss, which is not the case (you have to use the feedwatchlist API URL). There are two methods of going about solving this: one is generating a fake request from Special:Watchlist code to feedwatchlist and returning the code directly, and using the regular syndication link calculation code, and the other is special-casing Special:Watchlist in OutputPage. I would prefer the former, but both are fairly hacky. Ideally this would be broken out into nice, clean, reusable code. I ran into this problem too when I was trying to make page history feeds available on article view instead of just page history view. * My preferred implementation approach is to assume that the user is using a feedreader in their browser. If an unauthenticated user hits the RSS feed, we publish an item explaining to them that they are not logged in, and give them instructions on how to enable the public (should be phrased carefully) feed that they can directly give to their feedreader. This means that the discovery cost is minimal: a user can use the usual mechanism for subscribing to a feed, without having to have had twiddled a preference beforehand. Assuming that the feed reader supports logins seems like a really bad idea, TBH. A ton of people use feed readers like Google Reader or whatnot instead of their browser, and this will break horribly AFAICS, unless I'm missing something. I'm not even sure a majority of users use their browser for feed reading -- I don't, anyway. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18531] Hiding can hide a bit too well
https://bugzilla.wikimedia.org/show_bug.cgi?id=18531 Happy-melon happy-me...@live.com changed: What|Removed |Added CC||happy-me...@live.com --- Comment #1 from Happy-melon happy-me...@live.com 2009-04-24 19:18:56 UTC --- Perhaps we should just drop all these show/hide links, and make any deleted attributes be links to RevisionDelete for those who have the permission to see the content? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18536] Category added to article, but it does not appear in category listing
https://bugzilla.wikimedia.org/show_bug.cgi?id=18536 Happy-melon happy-me...@live.com changed: What|Removed |Added CC||happy-me...@live.com Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Happy-melon happy-me...@live.com 2009-04-24 19:22:22 UTC --- Both present in the respective categories for me. In general, making a 'null edit' (click edit, then save, without changing anything) fixes problems like this. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18572] Users should be able to delete pages and image files they create/upload accidentally
https://bugzilla.wikimedia.org/show_bug.cgi?id=18572 Happy-melon happy-me...@live.com changed: What|Removed |Added CC||happy-me...@live.com --- Comment #2 from Happy-melon happy-me...@live.com 2009-04-24 19:25:50 UTC --- If sensible time limit happened to coincide exactly with the maximum age of the recentchanges table, it would make things much easier :D if everything that needs to be deleted is still in the table, then go would be reliable (and it would all need to be deleted anyway). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 8130] Query pages should limit to content namespaces, not just main namespace
https://bugzilla.wikimedia.org/show_bug.cgi?id=8130
--- Comment #4 from neph...@skyhighway.com 2009-04-24 19:31:34 UTC ---
Yes, the code may be ugly. But the patch is not the source of the ugliness --
the existing SpecialPage classes all pass around raw SQL fragments and make
minimal use of the Database class functions. In a nutshell, trying to refactor
the code to make it pretty would be a major code revamp -- with no performance
or functionality benefits -- and refactoring the code would by itself still do
nothing to fix this bug. I'm not trying to provide the ultimate, perfect code;
I'm just trying to provide some progress towards fixing a two-year old bug.
Some of the fundamental obstacles complicating a conversion of all this code to
use the Database class functions include:
* Some 32 special pages are based on QueryPage. Any comprehensive fix requires
revamping all of those pages, plus QueryPage.php and PageQueryPage.php. Even
worse, a comprehensive fix is likely to break any extension special pages that
create special pages derived from QueryPage -- possibly 235 extensions based on
Mediawiki-registered extensions alone.
* QueryPage::getSQL is supposed to return raw SQL. If getSQL is changed to
instead return an array of ($table, $var, $cond, $fname, $options), then every
use of getSQL is made uglier, because it's now passing around 5+ parameters
instead of just one. The other option is that getSQL still returns raw SQL,
but that the various implementations of getSQL use Database functions to
generate that raw SQL -- however, that's not currently possible, because the
Database class does not have functions that construct a raw SQL query and
return it -- without actually executing the SQL query.
* Many of the existing SQL queries cannot be handled by the Database functions.
See SpecialDisambiguations, for example, where the page table is accessed
twice within a single query, and therefore it is aliased (FROM {$page} AS pb,
{$pagelinks} AS la, {$page} AS pa). The database functions are unable to
handle table aliases. Without major revisions to Database, it is impossible to
change all of the special pages to use the database functions -- and changing
half of the special pages to use one syntax and leaving half using the old
syntax is even uglier, in my opinion.
After all of that is done, it's still necessary to figure out how to fix this
bug.
* The prettiest way to do it would seem to be adding it as a flag recognized
by Database::makeSelectOptions. However, burying it that deep within the
Database class then means it's unavailable to queries that are not entirely
constructed by the Database functions -- such as SpecialDisambiguations (unless
the database functions are made fully alias-aware). So then a separate
function is needed outside of makeSelectOptions that spits out raw SQL
fragments -- so why not just introduce that separate function right now instead
of forcing a code revamp that won't even get rid of the separate function?
* I added isContentQuery to the MWNamespace class because the necessary
information is ''not'' part of the database: the list of content namespaces is
defined solely through a global variable, $wgContentNamespaces. With my patch,
all uses of $wgContentNamespaces are centralized in Namespace.php -- only
MWNamespace needs to know the inner details of the content namespaces are
defined.
I'm willing to update my patch if provided with specific suggestions about what
could be done differently within the scope of this approach. But I'm not
prepared to take on a huge project to fix something that's basically unrelated
to this bug. Especially since with my superficial knowledge of the MW
codebase, my efforts to tackle such a huge revamp would inevitably add a whole
new stack of bugs.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 8130] Query pages should limit to content namespaces, not just main namespace
https://bugzilla.wikimedia.org/show_bug.cgi?id=8130
--- Comment #5 from Roan Kattouw roan.katt...@gmail.com 2009-04-24 19:34:06
UTC ---
(In reply to comment #4)
Yes, the code may be ugly. But the patch is not the source of the ugliness --
the existing SpecialPage classes all pass around raw SQL fragments and make
minimal use of the Database class functions. In a nutshell, trying to
refactor
the code to make it pretty would be a major code revamp -- with no performance
or functionality benefits -- and refactoring the code would by itself still do
nothing to fix this bug. I'm not trying to provide the ultimate, perfect
code;
I'm just trying to provide some progress towards fixing a two-year old bug.
Some of the fundamental obstacles complicating a conversion of all this code
to
use the Database class functions include:
* Some 32 special pages are based on QueryPage. Any comprehensive fix
requires
revamping all of those pages, plus QueryPage.php and PageQueryPage.php. Even
worse, a comprehensive fix is likely to break any extension special pages that
create special pages derived from QueryPage -- possibly 235 extensions based
on
Mediawiki-registered extensions alone.
* QueryPage::getSQL is supposed to return raw SQL. If getSQL is changed to
instead return an array of ($table, $var, $cond, $fname, $options), then every
use of getSQL is made uglier, because it's now passing around 5+ parameters
instead of just one. The other option is that getSQL still returns raw SQL,
but that the various implementations of getSQL use Database functions to
generate that raw SQL -- however, that's not currently possible, because the
Database class does not have functions that construct a raw SQL query and
return it -- without actually executing the SQL query.
* Many of the existing SQL queries cannot be handled by the Database
functions.
See SpecialDisambiguations, for example, where the page table is accessed
twice within a single query, and therefore it is aliased (FROM {$page} AS pb,
{$pagelinks} AS la, {$page} AS pa). The database functions are unable to
handle table aliases. Without major revisions to Database, it is impossible
to
change all of the special pages to use the database functions -- and changing
half of the special pages to use one syntax and leaving half using the old
syntax is even uglier, in my opinion.
After all of that is done, it's still necessary to figure out how to fix this
bug.
* The prettiest way to do it would seem to be adding it as a flag recognized
by Database::makeSelectOptions. However, burying it that deep within the
Database class then means it's unavailable to queries that are not entirely
constructed by the Database functions -- such as SpecialDisambiguations
(unless
the database functions are made fully alias-aware). So then a separate
function is needed outside of makeSelectOptions that spits out raw SQL
fragments -- so why not just introduce that separate function right now
instead
of forcing a code revamp that won't even get rid of the separate function?
* I added isContentQuery to the MWNamespace class because the necessary
information is ''not'' part of the database: the list of content namespaces is
defined solely through a global variable, $wgContentNamespaces. With my
patch,
all uses of $wgContentNamespaces are centralized in Namespace.php -- only
MWNamespace needs to know the inner details of the content namespaces are
defined.
I'm willing to update my patch if provided with specific suggestions about
what
could be done differently within the scope of this approach. But I'm not
prepared to take on a huge project to fix something that's basically unrelated
to this bug. Especially since with my superficial knowledge of the MW
codebase, my efforts to tackle such a huge revamp would inevitably add a whole
new stack of bugs.
I'm working on doing all this in the querypage-work branch; and yes, it is
possible to prettify stuff and move away from raw SQL.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18572] Users should be able to delete pages and image files they create/upload accidentally
https://bugzilla.wikimedia.org/show_bug.cgi?id=18572 --- Comment #3 from Splarka h...@goldrush.com 2009-04-24 19:33:55 UTC --- This seems like a dupe of bug 14325 (though that is more about making pages deletable if the current user is the only author) or bug 17309 (which is more about users deleting pages in their own namespace). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18563] Merge new-upload branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=18563 Michael Dale d...@ucsc.edu changed: What|Removed |Added CC||d...@ucsc.edu Status|NEW |ASSIGNED Summary|Enable Upload by URL |Merge new-upload branch |globally on Wikimedia |(tracking) |(tracking) | --- Comment #1 from Michael Dale d...@ucsc.edu 2009-04-24 20:04:46 UTC --- Changed the summary to track all the related new-upload branch updates that are part of the above mentioned fixes. More comments to follow shortly... Other upload-api related bugs in new-upload branch bug 16927 enables firefogg support (adding chunks to the api) this hits on bug 17255 although the protocol is firefogg specific and simpler than described. (although it does not block the possibility of using the simple firefogg protocol with other clients) There does not seem to be a general upload api bug. But the original idea of the new-upload branch was to support api. The api is currently documented as follows: (will be a few updates once we support status checks on http uploads) * action=upload * Upload an File Parameters: filename - Target filename file - File contents chunk - url- Url to upload from comment- Upload comment or initial page text Default: watch - Watch the page ignorewarnings - Ignore any warnings enablechunks - Boolean If we are in chunk mode; accepts many small file POSTs done - When used with chunks, Is sent to notify the api The last chunk is being uploaded. sessionkey - Session key in case there were any warnings. chunksessionkey - Used to sync uploading of chunks -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18563] Merge new-upload branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=18563 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #2 from Roan Kattouw roan.katt...@gmail.com 2009-04-24 20:08:01 UTC --- (In reply to comment #1) chunk - documentme? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18574] New: Using external editor as an optional feature
https://bugzilla.wikimedia.org/show_bug.cgi?id=18574 Summary: Using external editor as an optional feature Product: MediaWiki Version: 1.15-svn Platform: PC OS/Version: Windows Vista Status: NEW Keywords: easy Severity: enhancement Priority: Normal Component: Page editing AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: francisd...@gmail.com Some people may prefer using their own editor rather than using the included editor. When a person chooses to use their editor, it will save a file on their system. The internal editor will also include uploading changes from their system. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18574] Using external editor as an optional feature
https://bugzilla.wikimedia.org/show_bug.cgi?id=18574 Mike.lifeguard mikelifegu...@fastmail.fm changed: What|Removed |Added CC||mikelifegu...@fastmail.fm --- Comment #1 from Mike.lifeguard mikelifegu...@fastmail.fm 2009-04-24 20:26:29 UTC --- Isn't this already a feature? I sure see a preference for that: Use external editor by default (for experts only, needs special settings on your computer) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18574] Using external editor as an optional feature
https://bugzilla.wikimedia.org/show_bug.cgi?id=18574 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #2 from Roan Kattouw roan.katt...@gmail.com 2009-04-24 20:27:07 UTC --- Go to [[Special:Preferences]], click the Editing tab and check Use external editor by default. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 13049] API must be accessed through the primary script entry point error
https://bugzilla.wikimedia.org/show_bug.cgi?id=13049 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Roan Kattouw roan.katt...@gmail.com 2009-04-24 19:51:56 UTC --- Should be fixed in r49833 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18575] New: OTRS doesn't send reminders anymore
https://bugzilla.wikimedia.org/show_bug.cgi?id=18575 Summary: OTRS doesn't send reminders anymore Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: Normal Component: OTRS AssignedTo: tstarl...@wikimedia.org ReportedBy: wikip...@gmail.com When a ticket is closed with Pending reminder, OTRS should send a daily email to the ticket owner starting from the reminder date. It worked before the January update, but hasn't worked since. In ticket histories, SendAgentNotification seems to still happen for NewTicket and FollowUp, but not for PendingReminder. See for example https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketHistoryTicketID=2246715 where the reminders are no longer sent after OTRS was upgraded, and compare with newer tickets that are in the reminder state. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18502] Error: za wp i18n change to Chinese
https://bugzilla.wikimedia.org/show_bug.cgi?id=18502 Siebrand siebr...@wikipedia.be changed: What|Removed |Added CC||siebr...@wikipedia.be Status|NEW |RESOLVED Resolution||WORKSFORME -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18475] Images on the secure connection to OTRS wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=18475 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Keywords||shell --- Comment #2 from Brion Vibber br...@wikimedia.org 2009-04-24 22:13:42 UTC --- Thumb rendering script link isn't being updated properly. Easy fix... -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18515] mediawiki:smw_querytoolarge needs PLURAL support
https://bugzilla.wikimedia.org/show_bug.cgi?id=18515 Siebrand siebr...@wikipedia.be changed: What|Removed |Added Keywords||i18n --- Comment #1 from Siebrand siebr...@wikipedia.be 2009-04-24 22:15:20 UTC --- Adding i18n keyword -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18516] Extension:Securepoll: message Securepoll-too-few-edits needs PLURAL support.
https://bugzilla.wikimedia.org/show_bug.cgi?id=18516 Siebrand siebr...@wikipedia.be changed: What|Removed |Added Keywords||i18n --- Comment #1 from Siebrand siebr...@wikipedia.be 2009-04-24 22:15:20 UTC --- Adding i18n keyword -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18475] Images on the secure connection to OTRS wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=18475 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Brion Vibber br...@wikimedia.org 2009-04-24 22:16:04 UTC --- Fixed! (Note that old page views may need a refresh or purge.) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18277] Message Abusefilter-diff-version needs date/time separated, and GENDER support
https://bugzilla.wikimedia.org/show_bug.cgi?id=18277 Siebrand siebr...@wikipedia.be changed: What|Removed |Added CC||siebr...@wikipedia.be Keywords||i18n --- Comment #1 from Siebrand siebr...@wikipedia.be 2009-04-24 22:16:26 UTC --- +i18n -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 15308] Check Babel extension for compatibility with Wikimedia Wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=15308 Siebrand siebr...@wikipedia.be changed: What|Removed |Added Depends on||16699 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16492] Add rating extentions to Dutch Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=16492 Siebrand siebr...@wikipedia.be changed: What|Removed |Added CC||siebr...@wikipedia.be Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Siebrand siebr...@wikipedia.be 2009-04-24 22:26:19 UTC --- WONTFIX. Please find community consensus before request extension activation. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18194] Enable NewUserMessage extension on Arabic Wikisource
https://bugzilla.wikimedia.org/show_bug.cgi?id=18194 Siebrand siebr...@wikipedia.be changed: What|Removed |Added CC||siebr...@wikipedia.be Keywords||easy -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16492] Add rating extentions to Dutch Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=16492 Aryeh Gregor simetrical+wikib...@gmail.com changed: What|Removed |Added CC||simetrical+wikib...@gmail.co ||m Resolution|WONTFIX |LATER --- Comment #2 from Aryeh Gregor simetrical+wikib...@gmail.com 2009-04-24 22:28:16 UTC --- Switching resolution to LATER, since it will be fixed if community consensus is obtained. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18430] Enable Collection extension on id.wikipedia.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=18430 Siebrand siebr...@wikipedia.be changed: What|Removed |Added CC||siebr...@wikipedia.be Keywords||easy -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 13451] Set new user groups for bswiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=13451 Siebrand siebr...@wikipedia.be changed: What|Removed |Added CC||siebr...@wikipedia.be Keywords||easy -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18576] New: Garbled type on my wikipedia.org site
https://bugzilla.wikimedia.org/show_bug.cgi?id=18576 Summary: Garbled type on my wikipedia.org site Product: Wikimedia Version: unspecified Platform: Macintosh URL: http://wikipedia.org OS/Version: Mac OS X 10.4 Status: NEW Keywords: schema-change Severity: critical Priority: Normal Component: Language setup AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: dvrdes...@yahoo.com CC: dvrdes...@yahoo.com Created an attachment (id=6058) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=6058) garbled type on all wikipedia html text! Please advise how I can get my Wikipedia.org back to read in English. 1. I had googled wikipedia for some info in Italian media and asked Wiki to translate Italian article into English. 2. Ever since then, my wiki browser reads English in Italian mixed up letters! 3. I tried to reset everything, and went into preferences. No luck! Here is a sample of the Italio/English language that comes up as text in all my browsers (Fiefox and Safari).(I am a MAC user. Please advise. thank you! dvrdes...@yahoo.com -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18571] Purging images does not always force image metadata cache to be cleared
https://bugzilla.wikimedia.org/show_bug.cgi?id=18571 ^demon innocentkil...@gmail.com changed: What|Removed |Added CC||innocentkil...@gmail.com Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from ^demon innocentkil...@gmail.com 2009-04-24 23:11:19 UTC --- Done in r49848 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 8130] Query pages should limit to content namespaces, not just main namespace
https://bugzilla.wikimedia.org/show_bug.cgi?id=8130 --- Comment #6 from neph...@skyhighway.com 2009-04-24 23:42:10 UTC --- Aha, that makes it alot easier (especially for a newb like me) to see the direction where you're heading with the special page queries. So, should I wait until the querypage-work branch is complete to proceed? Or could I help by providing a patch for querypage-work? In which case, it looks like what you're suggesting is that the entry in $conds would be changed from page_namespace = NS_MAIN to something like page_namespace = MWNamespace::getContentNamespaces() where getContentNamespaces could return a single value or an array of values (returning a single-value as a non-array seems slightly more efficient for Database::makeList). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18531] Hiding can hide a bit too well
https://bugzilla.wikimedia.org/show_bug.cgi?id=18531 --- Comment #3 from FT2 ft2.w...@gmail.com 2009-04-25 00:22:43 UTC --- But that's a different point. The issue here is specific to hide username in the blocking function (or elsewhere) removing the trail for users who need to be able to follow it. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18563] Merge new-upload branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=18563 --- Comment #3 from Michael Dale d...@ucsc.edu 2009-04-25 00:59:24 UTC --- right...done in r49850 ( chunk is the name of the chunk file present in the $_FILES array. ) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 17275] database error occurs while saving a page
https://bugzilla.wikimedia.org/show_bug.cgi?id=17275 --- Comment #4 from Aaron Schulz jschulz_4...@msn.com 2009-04-25 02:06:57 UTC --- Some tweaks in r49851 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18531] Hiding can hide a bit too well
https://bugzilla.wikimedia.org/show_bug.cgi?id=18531 FT2 ft2.w...@gmail.com changed: What|Removed |Added CC||ft2.w...@gmail.com --- Comment #2 from FT2 ft2.w...@gmail.com 2009-04-25 00:18:58 UTC --- A nicer idea would be to replace the show/hide links, by a standard RevDel icon next to any applicable row or item: * If the entry/diff/edit summary etc has SOME RevDel action, a user who CAN view or change the RevDel flags and view the edit (admin or oversighter etc), can click the icon to access RevDel for the revision, or hover to view the RevDel info. * If the entry/diff/edit summary etc has SOME RevDel action, a user who CANNOT view or change the RevDel flags and view the edit gets a similar icon in a darker shade or with an x motif, and a hover saying Some items in this edit have been removed from view. * If the entry/diff/edit summary etc has NO RevDel action, a user who CAN view or change the RevDel flags sees a similar icon with an h motif. Clicking leads to the revDel view for that revision, hovering shows the message Click to hide data in this edit. * If the entry/diff/edit summary etc has NO RevDel action, a user who CANNOT view or change the RevDel flags is not shown any icon next to it. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18568] hideuser doesn't check all log types
https://bugzilla.wikimedia.org/show_bug.cgi?id=18568 --- Comment #3 from Aaron Schulz jschulz_4...@msn.com 2009-04-25 02:33:08 UTC --- (In reply to comment #2) AFAICT, the block was before the rename. Seems like a duplicate of 18383. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18531] Hiding can hide a bit too well
https://bugzilla.wikimedia.org/show_bug.cgi?id=18531 Aaron Schulz jschulz_4...@msn.com changed: What|Removed |Added CC||jschulz_4...@msn.com --- Comment #4 from Aaron Schulz jschulz_4...@msn.com 2009-04-25 02:35:37 UTC --- (In reply to comment #0) REQUEST: If the user viewing material is an oversighter or otherwise would be allowed to see or modify the hide username setting, then the username appears as [deleted] (show/hide) or [hidden] (show/hide) in lists and other places, not just be omitted. The only place where the name is just omitted is the sp:listusers page AFAIK. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18313] Add 'hideuser' right to CheckUser group Wikimedia-wide
https://bugzilla.wikimedia.org/show_bug.cgi?id=18313 Aaron Schulz jschulz_4...@msn.com changed: What|Removed |Added CC||jschulz_4...@msn.com Status|NEW |RESOLVED Resolution||LATER --- Comment #8 from Aaron Schulz jschulz_4...@msn.com 2009-04-25 02:39:30 UTC --- Mixing the two may not be the best idea for smaller wikis, were there is little need for it and less people to oversee its usage. This should have some sort of consensus if it is to be implemented. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18531] Hiding can hide a bit too well
https://bugzilla.wikimedia.org/show_bug.cgi?id=18531 --- Comment #5 from FT2 ft2.w...@gmail.com 2009-04-25 02:39:45 UTC --- (In reply to comment #4) The only place where the name is just omitted is the sp:listusers page AFAIK. Thanks, that's what I wasn't sure of. Can it be made a [deleted/hidden] (show/hide) there as well? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18568] hideuser doesn't check all log types
https://bugzilla.wikimedia.org/show_bug.cgi?id=18568 Aaron Schulz jschulz_4...@msn.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Aaron Schulz jschulz_4...@msn.com 2009-04-25 02:40:39 UTC --- *** This bug has been marked as a duplicate of bug 18383 *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18383] RevisionDelete: hidden users appear in log entries created after the hiding
https://bugzilla.wikimedia.org/show_bug.cgi?id=18383 Aaron Schulz jschulz_4...@msn.com changed: What|Removed |Added CC||mikelifegu...@fastmail.fm --- Comment #8 from Aaron Schulz jschulz_4...@msn.com 2009-04-25 02:40:39 UTC --- *** Bug 18568 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18577] New: replace show/hide by an icon
https://bugzilla.wikimedia.org/show_bug.cgi?id=18577 Summary: replace show/hide by an icon Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Deleting AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: ft2.w...@gmail.com The show/hide links take up a lot of space. Can they be replaced by a neat RevDel icon when there is something hidden or an option to hide? Advantages - neatness, space, improved interface. Detail: The icon and its action/hover would depend on whether the user CAN or CANNOT view/change the revDel settings for the item, and whether there IS or ISN'T some hiding already in that item. 1/ Entry/diff/edit summary etc has SOME RevDel action, user CAN view or change the RevDel flags and view the edit (admin or oversighter etc): - User shown an icon next to the item, can click the icon to access RevDel for the revision, or hover to view the RevDel info. 2/ Entry/diff/edit summary etc has SOME RevDel action, user CANNOT view or change the RevDel flags and view: - User shown icon in a darker shade or with an x motif, and a hover saying Some items in this edit have been removed from view. 3/ Entry/diff/edit summary etc has NO RevDel action, user CAN view or change the RevDel flags: - User shown a similar icon with an h motif. Clicking leads to the RevDel view for that revision, hovering shows the message Click to hide data in this edit. 4/ Entry/diff/edit summary etc has NO RevDel action, user CANNOT view or change the RevDel flags: - User is not shown any RevDel icon next to the item. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18531] Hiding can hide a bit too well
https://bugzilla.wikimedia.org/show_bug.cgi?id=18531 --- Comment #6 from FT2 ft2.w...@gmail.com 2009-04-25 02:50:05 UTC --- I copied the unrelated stuff in comment 1-2 to bug 18577 instead, to keep this one simple. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18577] replace show/hide by an icon
https://bugzilla.wikimedia.org/show_bug.cgi?id=18577 FT2 ft2.w...@gmail.com changed: What|Removed |Added CC||ft2.w...@gmail.com --- Comment #1 from FT2 ft2.w...@gmail.com 2009-04-25 02:53:32 UTC --- And possibly if there is no RevDel action now, but was in the past, a different icon, to allow admins/oversighters to quickly spot revisions where hiding/suppression has been employed even if it's not hidden now. Ie, admins can see there have been past admin RevDel actions, and oversighters can see there have been past admin or oversight RevDel actions. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 13840] Zh traditional/simplified conversion for NON rendered HTML too
https://bugzilla.wikimedia.org/show_bug.cgi?id=13840 --- Comment #2 from Shinjiman shinji...@gmail.com 2009-04-25 03:34:06 UTC --- Can you please provide a URL to reproduce this issue? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
