Movatterモバイル変換

[0]ホーム
URL:

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview
List overview
Download

Wikitech-lJune 2012

wikitech-l@lists.wikimedia.org
  • 138 participants
  • 114 discussions
Start a nNew thread
Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25
Until some weeks agohttp://dumps.wikimedia.org/backup-index.html usedto show 4 dumps in progress at the same time. That meant that newdatabase dumps normally was available within about 3 weeks for alldatabases except for enwiki and maybe dewiki where the dump process dueto size took longer time.However the 4 dumps processes at one time become 3 some weeks ago. Andafter massive failures at June 4, only one dump has been in progress atthe same time. So at the current speed it will take several months tocome thru all dumps.Is it possible to speed up the process again using several dumpprocesses at the same time?Thank you,Byrial
3 2
0 0
User-Agent:
by Domas Mituzas 17 Apr '25

17 Apr '25
Hi!from now on specific per-bot/per-software/per-client User-Agent header is mandatory for contacting Wikimedia sites.Domas
19 61
0 0
EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25
What's the status of the project to create a grammar for Wikitext in EBNF?There are two pages:http://meta.wikimedia.org/wiki/Wikitext_Metasyntaxhttp://www.mediawiki.org/wiki/Markup_specNothing seems to have happened since January this year. Also the comments onthe latter page seem to indicate a lack of clear goal: is this just a funproject, is it to improve the existing parser, or is it to facilititate anew parser? It's obviously a lot of work, so it needs to be of clearbenefit.Brion requested the grammar IIRC (and there's a comment to that effect athttp://bugzilla.wikimedia.org/show_bug.cgi?id=7), so I'm wondering what became of it.Is there still a goal of replacing the parser? Or is there some alternativeplan?Steve
26 217
0 0
Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24
Hello,I have been a WP editor since 2006. I hope you can help me. For some reasonI no longer have Section Heading titles showing in the Articles. This istrue of all Headings including the one that carries the Article subject'sname. When there is a Table of Contents, it appears fine and, when I clickon a particular Section, it goes to that Section, but all that is there is astraight line separating the Sections. There is also no button to edit aSection. If I edit the page and remove the "== ==" markers from the SectionTitles, the Title then shows up, but not as a Section Heading. Also, I don'thave any Date separators on my Want List. This started 2 days ago. Anythoughts?Thanks,Marc Riddell[[User:Michael David]]
10 11
0 0
MediaWiki 1.19.0beta2
by Sam Reed 09 May '14

09 May '14
I'm happy to announce the availability of the second beta release of thenew MediaWiki 1.19 release series.Please try it out and let us know what you think. Don't run it on anywikis that you really care about, unless you are both very brave andvery confident in your MediaWiki administration skills.MediaWiki 1.19 is a large release that contains many new features andbug fixes. This is a summary of the major changes of interest to users.You can consult the RELEASE-NOTES-1.19 file for the full list of changesin this version.Five security issues were discovered.It was discovered that the api had a cross-site request forgery (CSRF)vulnerability in the block/unblock modules. It was possible for a useraccount with the block privileges to block or unblock another user withoutproviding a token.For more details, seehttps://bugzilla.wikimedia.org/show_bug.cgi?id=34212It was discovered that the resource loader can leak certain kinds of privatedata across domain origin boundaries, by providing the data as an executableJavaScript file. In MediaWiki 1.18 and later, this includes the leaking ofCSRFprotection tokens. This allows compromise of the wiki's user accounts, saybychanging the user's email address and then requesting a password reset.For more details, seehttps://bugzilla.wikimedia.org/show_bug.cgi?id=34907Jan Schejbal ofHatforce.com discovered a cross-site request forgery (CSRF)vulnerability in Special:Upload. Modern browsers (since at least as early asDecember 2010) are able to post file uploads without user interaction,violating previous security assumptions within MediaWiki. Depending on the wiki's configuration, this vulnerability could lead tofurthercompromise, especially on private wikis where the set of allowed file typesisbroader than on public wikis. Note that CSRF allows compromise of a wikifroman external website even if the wiki is behind a firewall.For more details, seehttps://bugzilla.wikimedia.org/show_bug.cgi?id=35317George Argyros and Aggelos Kiayias reported that the method used to generatepassword reset tokens is not sufficiently secure. Instead we use variousmoresecure random number generators, depending on what is available on theplatform. Windows users are strongly advised to install either the opensslextension or the mcrypt extension for PHP so that MediaWiki can takeadvantageof the cryptographic random number facility provided by Windows.Any extension developers using mt_rand() to generate random numbers incontextswhere security is required are encouraged to instead make use of theMWCryptRand class introduced with this release.For more details, seehttps://bugzilla.wikimedia.org/show_bug.cgi?id=35078A long-standing bug in the wikitext parser (bug 22555) was discovered tohavesecurity implications. In the presence of the popular CharInsert extension,itleads to cross-site scripting (XSS). XSS may be possible with otherextensionsor perhaps even the MediaWiki core alone, although this is not confirmed atthis time. A denial-of-service attack (infinite loop) is also possibleregardless of configuration.For more details, seehttps://bugzilla.wikimedia.org/show_bug.cgi?id=35315********************************************************************* What's new?*********************************************************************MediaWiki 1.19 brings the usual host of various bugfixes and new features.Comprehensive list of what's new is in the release notes.* Bumped MySQL version requirement to 5.0.2.* Disable the partial HTML and MathML rendering options for Math, and render as PNG by default. * MathML mode was so incomplete most people thought it simply didn't work.* New skins/common/*.css files usable by skins instead of having to copypiles of generic styles from MonoBook or Vector's css.* The default user signature now contains a talk link in addition to theuser link.* Searching blocked usernames in block log is now clearer.* Better timezone recognition in user preferences.* Extensions can now participate in the extraction of titles from URL paths.* The command-line installer supports various RDBMSes better.* The interwiki links table can now be accessed also when the interwikicache is used (used in the API and the Interwiki extension).Internationalization- --------------------* More gender support (for instance in user lists).* Add languages: Canadian English.* Language converter improved, e.g. it now works depending on the page content language.* Time and number-formatting magic words also now depend on the page content language.* Bidirectional support further improved after 1.18.Release notes- -------------Full release notes:https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RELEASE-NOTES-1.19;hb=1.19.0beta2https://www.mediawiki.org/wiki/Release_notes/1.19Co-inciding with these security releases, the MediaWiki source coderepository hasmoved from SVN (athttps://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3)to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So therelevantcommits for these releases will not be appearing in our SVN repository. Ifyou useSVN checkouts of MediaWiki for version control, you need to migrate these toGit.If you up are using tarballs, there should be no change in the process foryou.Please note that any WMF-deployed extensions have also been migrated to Gitalso, along with some other non WMF-maintained ones.Please bear with us, some of the Git related links for this release may notwork instantly,but should later on.To do a simple Git clone, the command is:git clonehttps://gerrit.wikimedia.org/r/p/mediawiki/core.gitMore information is available athttps://www.mediawiki.org/wiki/GitFor more help, please visit the #mediawiki IRC channel onfreenode.netirc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing listat mediawiki-l(a)lists.wikimedia.org.**********************************************************************Download:http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gzPatch to previous version (1.19.0beta1), without interface text:http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gzInterface text changes:http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patch.gzGPG signatures:http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patch.gz.sigPublic keys:https://secure.wikimedia.org/keys.html
5 5
0 0

14 May '13
hi-i'm hopeful this is the appropriate venue for this topic - i recently had occasion to visit #mediawiki on freenode, looking for help. i found myself a bit frustrated by the amount of bot activity there and wondered if there might be value in some consideration for this. it seems to frequently drown out/dilute those asking for help, which can be a bit discouraging/frustrating. additionally, from the perspective of those who might help [based on my experience in this role in other channels], constant activity can sometimes engender disinterest [e.g. the irc client shows activity in the channel, but i'm less inclined to look as it's probably just a bot].to offer one possibility - i know there are a number of mediawiki and/or wikimedia related channels - might there be one in which bot activity might be better suited, in the context of less contention between the two audiences [those seeking help vs. those interested in development, etc]? one nomenclature convention that seems to be at least somewhat of a defacto standard is #project for general help, and #project-dev[el] for development topics. a few examples of this i've seen are android, libreoffice, python, and asterisk. adding yet another channel to this list might not be terribly welcome, but maybe the distinction would be worth the addition?as i'm writing this, i see another thread has begun wrt freenode, and i also see a bug filed that relates at least to some degree [https://bugzilla.wikimedia.org/show_bug.cgi?id=35427], so i may just be repeating an existing sentiment, but i wanted to at least offer a brief perspective.regards-ben
18 47
0 0

26 Feb '13
On Fri, Jun 15, 2012 at 8:48 AM, Sumana Harihareswara<sumanah(a)wikimedia.org> wrote:> If you merge into mediawiki/core.git, your change is considered safe for> inclusion in a wmf branch.  The wmf branch is just branched out of> master and then deployed. We don't review it again.  Because we're> deploying more frequently to WMF sites, the code review for merging into> MediaWiki's core.git needs to be more like deployment/shell-level> review, and so we gave merge access to people who already had deployment> access.  We have since added some more people.  The current list:>https://gerrit.wikimedia.org/r/#/admin/groups/11,membersLet me elaborate on this. As unclear as our process is for givingaccess, it's even less clear what our policy is for taking it away.If we can settle on a policy for taking access away/suspending access,it'll make it much easier to loosen up about giving access.Here's the situation we want to avoid: we give access to someone whoprobably shouldn't have it. They continually introduce deploymentblockers into the code, making us need to slow down our frequentdeployment process. Two hour deploy windows become six hour deploywindows as we need time to fix up breakage introduced during thewindow. Even with the group we have, there are times where thingsthat really shouldn't slip through do. It's manageable now, butadding more people is going to multiply this problem as we get backinto a situation where poorly conceived changes become coredependencies.We haven't had a culture of making a big deal about the case whensomeone introduces a breaking change or does something that brings thedb to its knees or introduces a massive security hole or whatever.That means that if the situation were to arise that we needed torevoke someones access, we have to wait until it gets egregious andawful, and even then the person is likely to be shocked that theirrights are being revoked (if we even do it then). To be lessconservative about giving access, we also need to figure out how to beless conservative about taking it away. We also want to be asreasonably objective about it. It's always going to be somewhatsubjective, and we don't want to completely eliminate the role ofcommon sense.It would also be nice if we didn't have to resort to the nuclearoption to get the point across. One low-stakes way we can use to makesure people are more careful is to have some sort of rotating "oops"award. At one former job I had, we had a Ghostbusters Stay Puft dollnamed "Buster" that was handed out when someone broke the build thatthey had to prominently display in their office. At another job, itwas a pair of Shrek ears that people had to wear when they messedsomething up in production. In both cases, it was something you hadto wear until someone else came along. Perhaps we should institutesomething similar (maybe as simple as asking people to append "OOPS"to their IRC nicks when they botch something).Rob
16 20
0 0

30 Oct '12
Hi everybody,at last weekend's Hackathon I investigated how to get into bugmanagement/triaging in Wikimedia.I'd like to propose some changes in order to streamline, harmonize andcentralize documentation in order to make it easier to get involved:https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Improv…Feedback, comments, criticism on this draft are very welcome.andre-- Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)http://blogs.gnome.org/aklapper/
8 10
0 0
Gerrit question: pushing to another branch
by Jeroen De Dauw 24 Oct '12

24 Oct '12
Hey,Is it possible to push to a branch other then the default one on gerritusing git review?This is needed when you want to have more then one branch on which you havereviewed code, or if you want different levels of review. For example ifyou want a novice committer play around with an extension a bit and pushnew functionality that gets reviewed but is not ready to go onto masteruntil it really has stabilized and finalized.Cheers--Jeroen De Dauwhttp://www.bn2vs.comDon't panic. Don't be evil.--
10 12
0 0
> Message: 8> Date: Wed, 23 May 2012 21:49:57 +0200> From: Platonides <Platonides(a)gmail.com>> To: wikitech-l(a)lists.wikimedia.org> Subject: Re: [Wikitech-l] HTMLMultiSelectField as <select> multiple="multiple"/>> Message-ID: <jpjf1s$b23$1(a)dough.gmane.org>> Content-Type: text/plain; charset=ISO-8859-1>> On 23/05/12 19:16, Daniel Werner wrote:> > Right now I am implementing a new option (as part of> >https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'dlike to> > use a <select multiple="multiple"/> html element with options. Right now> > MediaWiki always generates a list of selectboxes instead of that whenusing> > the HTMLMultiSelectField class. We are talking about 280+ selectableitems> > here, so for now we came to the conclusion that a real multi <select/>> > would be nicer and less space consuming for now> > I have already managed to implement this multiple select,> > modifying HTMLMultiSelectField adding a new option 'usecheckboxes' which> > can be set to false to disable the known behavior and use a selectelement> > instead.> >> > This would mainly be for the JavaScript-less ui. If javascript were> > enabled, we could still do something nicer, for example with somethinglike> > jQuery chosen plugin here.> >> > My question would just be, how I should implement these changespreferably.> > Is it ok with the new option for HTMLMultiSelectField or should this bea> > new class inheriting from HTMLMultiSelectField? I think> > HTMLMultiSelectField sounds more like describing what I just implemented> > rather than a bunch of select boxes, but of course renaming the existing> > one could "break" extensions (even though both are fully compatible and> > interchangeable). So one option would be simply naming the new one> > HTMLMultiSelectField2 if we don't want to stick with an additionaloption> > here.>> No. You shouldn't need to know that HTMLMultiSelectField2 is a> MultiSelect but HTMLMultiSelectField uses checkboxes.> Your useCheckboxes looks good.> I recommend you to make it a tri-state value, so you could force> checkboxes, select or let it decide (eg. checkboxes for < 100 elements,> select for more)Alright, just submitted this for review to gerrit:https://gerrit.wikimedia.org/r/#/c/8924/I implemented it as tri-state now. By default 'usecheckboxes' will be true,not set to a number. This could be changed (would make sense imo) but fornow I didn't want to do this since it could for example affect the defaultsearch namespace user preference in wikis with many search namespaces. Ithink the plain multiple select HTML element is not that nice because it isnot very obvious that you can do multiple selects by holding the controlkey. There should be some JavaScript ui element replacing this for usershaving JS enabled I think before using this as default for huge multiselectoptions. I think if all of that were implemented, 15 or 20 would be a gooddefault value for the option.CheersDaniel
5 8
0 0
Results per page:
[8]ページ先頭
©2009-2025 Movatter.jp