Wikitech-l May 2012

136 participants
127 discussions

Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25

Until some weeks ago http://dumps.wikimedia.org/backup-index.html used to show 4 dumps in progress at the same time. That meant that new database dumps normally was available within about 3 weeks for all databases except for enwiki and maybe dewiki where the dump process due to size took longer time. However the 4 dumps processes at one time become 3 some weeks ago. And after massive failures at June 4, only one dump has been in progress at the same time. So at the current speed it will take several months to come thru all dumps. Is it possible to speed up the process again using several dump processes at the same time? Thank you, Byrial

3 2

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

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_Metasyntax http://www.mediawiki.org/wiki/Markup_spec Nothing seems to have happened since January this year. Also the comments on the latter page seem to indicate a lack of clear goal: is this just a fun project, is it to improve the existing parser, or is it to facilititate a new parser? It's obviously a lot of work, so it needs to be of clear benefit. Brion requested the grammar IIRC (and there's a comment to that effect at http://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 alternative plan? Steve

26 217

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 reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

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 the new MediaWiki 1.19 release series. Please try it out and let us know what you think. Don't run it on any wikis that you really care about, unless you are both very brave and very confident in your MediaWiki administration skills. MediaWiki 1.19 is a large release that contains many new features and bug 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 changes in 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 user account with the block privileges to block or unblock another user without providing a token. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34212 It was discovered that the resource loader can leak certain kinds of private data across domain origin boundaries, by providing the data as an executable JavaScript file. In MediaWiki 1.18 and later, this includes the leaking of CSRF protection tokens. This allows compromise of the wiki's user accounts, say by changing the user's email address and then requesting a password reset. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34907 Jan Schejbal of Hatforce.com discovered a cross-site request forgery (CSRF) vulnerability in Special:Upload. Modern browsers (since at least as early as December 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 to further compromise, especially on private wikis where the set of allowed file types is broader than on public wikis. Note that CSRF allows compromise of a wiki from an external website even if the wiki is behind a firewall. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35317 George Argyros and Aggelos Kiayias reported that the method used to generate password reset tokens is not sufficiently secure. Instead we use various more secure random number generators, depending on what is available on the platform. Windows users are strongly advised to install either the openssl extension or the mcrypt extension for PHP so that MediaWiki can take advantage of the cryptographic random number facility provided by Windows. Any extension developers using mt_rand() to generate random numbers in contexts where security is required are encouraged to instead make use of the MWCryptRand class introduced with this release. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35078 A long-standing bug in the wikitext parser (bug 22555) was discovered to have security implications. In the presence of the popular CharInsert extension, it leads to cross-site scripting (XSS). XSS may be possible with other extensions or perhaps even the MediaWiki core alone, although this is not confirmed at this time. A denial-of-service attack (infinite loop) is also possible regardless of configuration. For more details, see https://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 copy piles of generic styles from MonoBook or Vector's css. * The default user signature now contains a talk link in addition to the user 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 interwiki cache 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=RE LEASE-NOTES-1.19;hb=1.19.0beta2 https://www.mediawiki.org/wiki/Release_notes/1.19 Co-inciding with these security releases, the MediaWiki source code repository has moved from SVN (at https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3) to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So the relevant commits for these releases will not be appearing in our SVN repository. If you use SVN checkouts of MediaWiki for version control, you need to migrate these to Git. If you up are using tarballs, there should be no change in the process for you. Please note that any WMF-deployed extensions have also been migrated to Git also, along with some other non WMF-maintained ones. Please bear with us, some of the Git related links for this release may not work instantly, but should later on. To do a simple Git clone, the command is: git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git More information is available at https://www.mediawiki.org/wiki/Git For more help, please visit the #mediawiki IRC channel on freenode.net irc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing list at mediawiki-l(a)lists.wikimedia.org. ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz Patch to previous version (1.19.0beta1), without interface text: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc h.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz.si g http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz. sig http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc h.gz.sig Public keys: https://secure.wikimedia.org/keys.html

5 5

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 gerrit using git review? This is needed when you want to have more then one branch on which you have reviewed code, or if you want different levels of review. For example if you want a novice committer play around with an extension a bit and push new functionality that gets reviewed but is not ready to go onto master until it really has stabilized and finalized. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

10 12

Re: [Wikitech-l] HTMLMultiSelectField as <select multiple="multiple"/>
by Daniel Werner 01 Oct '12

01 Oct '12

> 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'd like to > > use a <select multiple="multiple"/> html element with options. Right now > > MediaWiki always generates a list of selectboxes instead of that when using > > the HTMLMultiSelectField class. We are talking about 280+ selectable items > > 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 select element > > instead. > > > > This would mainly be for the JavaScript-less ui. If javascript were > > enabled, we could still do something nicer, for example with something like > > jQuery chosen plugin here. > > > > My question would just be, how I should implement these changes preferably. > > Is it ok with the new option for HTMLMultiSelectField or should this be a > > 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 additional option > > 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 for now I didn't want to do this since it could for example affect the default search namespace user preference in wikis with many search namespaces. I think the plain multiple select HTML element is not that nice because it is not very obvious that you can do multiple selects by holding the control key. There should be some JavaScript ui element replacing this for users having JS enabled I think before using this as default for huge multiselect options. I think if all of that were implemented, 15 or 20 would be a good default value for the option. Cheers Daniel

5 8

about bots
by Fabian Kaelin 29 Sep '12

29 Sep '12

Hi, Sorry about the length of this mail, it reads faster than it looks. I am working with the recentchanges and the cu_changes (checkuser) mediawiki SQL tables. I would like to be able to filter bot activity, unfortunately I am increasingly confused. Things that I think I know: - In the recentchanges<http://www.mediawiki.org/wiki/Manual:Recentchanges_table> table there is a `rc_bot` flag that should indicate whether the edit comes from a bot. - The checkuser table cu_changes<http://www.mediawiki.org/wiki/Extension:CheckUser> (which is not documented on the mediawiki database layout page<http://www.mediawiki.org/wiki/Manual:Database_layout>) contains mostly the same information as the recentchanges table but for a longer period of time. However, there is no bot flag as there is on the recentchanges table - I don't know why not. - There is a `bot` entry in the user_groups.ug_group<http://www.mediawiki.org/wiki/Manual:User_groups_table> field. A revision/recentchanges/cu_changes entry can be identified as bot by joining the original table with user_groups on the user_id and by setting ug_group=`bot`. - The user_groups method way of identifying bots is inefficient and the data seems incomplete. For some other projects we have used various other bot tables created by hand (on db1047: halfak.bot used during WSOR 2011 or declerambaul.erik_bots containing the bots identified by Erik Zachte). I would like to know the answers to the following questions: 1. *What is the meaning/purpose of the rc_bot flag on recentchanges? *There are entries in the recentchanges table from editors that are flagged as bots in the user_groups and the other bot tables but still have the rc_bot flag set to 0. mysql> select rc.rc_user_text from recentchanges rc join user_groups ug ON (rc.rc_user=ug.ug_user) WHERE ug.ug_group = 'bot' and rc.rc_bot=0 limit 1; +--------------+ | rc_user_text | +--------------+ | ClueBot NG | +--------------+ 2. *Why is there no bot flag in the checkuser table? *A lot of the other fields seem to be copied from the recentchanges table, why not the rc_bot field? The check user table contains both entries that are flagged as bots in the recentchanges table and entries that are flagged as bots in the user_groups. mysql> select cuc.cuc_user_text from recentchanges rc join cu_changes cuc ON (rc.rc_user=cuc.cuc_user) WHERE rc.rc_bot=1 limit 1; +---------------+ | cuc_user_text | +---------------+ | MiszaBot III | +---------------+ mysql> select cuc.cuc_user_text from cu_changes cuc join user_groups ug ON (cuc.cuc_user=ug.ug_user) WHERE ug.ug_group = 'bot' limit 1; +---------------+ | cuc_user_text | +---------------+ | Robbot | +---------------+ 3. *Am I missing some fundamental information about how bots are handled?* This is a frequently recurring request for data analytics and it seems the data is inconsistent. What is the most convenient, sane way to classify bot activity as such? Are there any projects underway that aim to improve the situation? Any input, pointers and recommendations are much appreciated. Thanks a lot! Regards, Fabian

9 8

Set $wgUseCombinedLoginLink = false on WMF cluster?
by Raimond Spekking 15 Aug '12

15 Aug '12

Since MediaWiki 1.18 we have the variable $wgUseCombinedLoginLink [1] which is set to true per default. During edit workshops with students and seniors I registered that new editors are confused about the combined login page. They tried to register new accounts on the login page. Surely, these observations are not representative but I think that the usability could be improved by setting $wgUseCombinedLoginLink=false If I missed a prior discussion about this issue I apologize and would be happy if someone could point me to the discussion. Otherwise I suggest to set $wgUseCombinedLoginLink to false for all WMF wikis. Raimond. [1] https://www.mediawiki.org/wiki/Manual:$wgUseCombinedLoginLink

8 10

BugZilla Portal (NEW)
by Krinkle 07 Jul '12

07 Jul '12

Hey all, Now that we're on a more regular deployment schedule, staying on top of the blocking bugs and deviding lists into smaller, more managable chunks, is more and more important. For that reason I put together a quick tool: https://toolserver.org/~krinkle/wmfBugZillaPortal/ It is already becoming clear that there is a lot of stuff left behind from past versions. We should probably start moving stuff to later verisons and keep an eye on it more regularly. -- Krinkle

6 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l May 2012