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-lJanuary 2023

wikitech-l@lists.wikimedia.org
  • 37 participants
  • 39 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

17 Apr '25
Hoi,This is an inquiry from my friend in academia, researching about Wikipedia.He would like to know whether there's a way to acquire a list of templatesincluding external links. Here are some examples including external links.https://ja.wikipedia.org/wiki/Template:JOI/dochttps://ja.wikipedia.org/wiki/Template:Twitter/docSuch links are stored in externallinks.sql.gz, in an expanded form.When you want to check increase/decrease of linked domains in chronologicalorder through edit history, you have to check pages-meta-history1.xml etc.In a such case, traditional links and links by templates are mixed,Therefore, the latter ones (links by templates) should be expanded totraditional link forms.Sorry if what I am saying does not make sense.Thanks in advance,--Takashi Ota [[U:Takot]]
13 24
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
Phabricator upstream shutdown
by Brian Wolff 21 Mar '25

21 Mar '25
It sounds like phabricator upstream is going away:https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_op…Just curious, are we planning to continue using it long term or move tosomething else?--Brian
10 12
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
I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here.tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.)(Is there a place onmw.org to put this tidbit on?)------- Forwarded message -------From: "Brian Levine" <support(a)github.com> (GitHub Staff)To: matma.rex(a)gmail.comCc:Subject: Re: Commits in mirrored repositories not showing up on my profileDate: Tue, 09 Jul 2013 06:47:19 +0200Hi BartoszIn order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit.The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits.CheersBrian-- Matma Rex
3 3
0 0
Research FAQ gets a facelift
by Dario Taraborelli 25 Jun '24

25 Jun '24
We just released a new version of Research:FAQ on Meta [1], significantlyexpanded and updated, to make our processes at WMF more transparent and tomeet an explicit FDC request to clarify the role and responsibilities ofindividual teams involved in research across the organization.The previous version – written from the perspective of the (now inactive)Research:Committee, and mostly obsolete since the release of WMF's openaccess policy [2] – can still be found here [3].Comments and bold edits to the new version of the document are welcome. Forany question or concern, you can drop me a line or ping my username on-wiki.Thanks,Dario[1]https://meta.wikimedia.org/wiki/Research:FAQ[2]https://wikimediafoundation.org/wiki/Open_access_policy[3]https://meta.wikimedia.org/w/index.php?title=Research:FAQ&oldid=15176953*Dario Taraborelli *Head of Research, Wikimedia Foundationwikimediafoundation.org •nitens.org • @readermeter<http://twitter.com/readermeter>
2 1
0 0
Greetings-With the security/maintenance release of MediaWiki 1.35.9/1.38.4/1.39.1, wewould also like to provide this supplementary announcement of MediaWikiextensions and skins with now-public Phabricator tasks, security patchesand backports [1]:CheckUser+ (T311337 <https://phabricator.wikimedia.org/T311337>, CVE-2022-39193) -Edits with the performer suppressed still show the performer in resultsfrom the CheckUser extensionhttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/879167/CheckUser+ (T316414 <https://phabricator.wikimedia.org/T316414>, CVE-2022-39193) -Special:Investigate can expose supressed information in check resultshttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/879166/CheckUser+ (T318166 <https://phabricator.wikimedia.org/T318166>, CVE-2022-39193) -CheckUser API can expose the suppressed performerhttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/879073/GrowthExperiments+ (T321733 <https://phabricator.wikimedia.org/T321733>, CVE-2023-22945) -Action=growthmanagementorlist makes it possible for blocked users to enrollas mentorshttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/8…CheckUser+ (T315123 <https://phabricator.wikimedia.org/T315123>, CVE-2023-22912) -CheckUser TokenManager insecurely uses AES-CTR encryption with repeatednonce, allowing an adversary to decrypthttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/879074/MobileFrontend+ (T320987 <https://phabricator.wikimedia.org/T320987>, CVE-2023-22909)- Mobile frontend's history makes really slow db querieshttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/8577…Widgets+ (T149488 <https://phabricator.wikimedia.org/T149488>, CVE-2023-22911)- Widgets does widget replacement in html attributes potentially leading toXSShttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/Widgets/+/856035/Wikibase+ (T323592 <https://phabricator.wikimedia.org/T323592>, CVE-2023-22910) -XSS in Wikibase date formattinghttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/879171/The Wikimedia Security Team recommends updating these extensions and/orskins to the current master branch or relevant, supported release branch[2] as soon as possible. Some of the referenced Phabricator tasks above_may_ still be private. Unfortunately, when security issues are reported,sometimes sensitive information is exposed and since Phabricator ishistorical, we cannot make these tasks public without exposing thissensitive information. If you have any additional questions or concernsregarding this update, please feel free to contact security(a)wikimedia.orgor file a security task within Phabricator [3].[1]https://phabricator.wikimedia.org/T318974[2]https://www.mediawiki.org/wiki/Version_lifecycle[3]https://www.mediawiki.org/wiki/Reporting_security_bugs
1 1
0 0

03 Mar '23
TLDR: Invoking maintenance scripts directly will be deprecated in MW 1.40, use maintenance/run.php instead. This affects anyone managing a MediaWiki installation, for development, testing, or production use.Until now, MediaWiki maintenance scripts have been handled standalonePHP scripts - for instance, to run the script that outputs the MediaWiki version, you would use:> php maintenance/version.phpStarting with MediaWiki 1.40, this is deprecated. The preferred way to run maintenance scripts is now by name, using the maintenance runner:> php maintenance/run.php versionSimilarly, the preferred way to run the updater is now:> php maintenance/run.php updateThe script to run cal also be specified using the full path of the script file, or the full PHP class name of a subclass of the Maintenance class. For more details, run> php maintenance/run.php --helpRationale and History:Treating maintenance scripts as standalone PHP scripts requires some boilerplate code to be present at the top and at the bottom of every file. This is error prone and makes it difficult to update the maintenance framework. But more importantly,for this boilerplate to work, the location of the MediaWiki installation has to be known relative to the maintenance script, which is not reliably possible for scripts defined in extensions.A similar problem arises if the maintenance script needs a base class other than the default Maintenance class: since the class is loaded before MediaWiki is initialized, the autoloader is not yet in place, and the file containing the base class needs to be included explicitly.These and similar issues can be avoided by creating a wrapper script that loads and executes the actual maintenance class. This way, the maintenance wrapper can initialize MediaWiki before passing control to the script.I propose creating such a wrapper as an RFC in 2018 (T99268)[^1], which was approved in 2019.  However, implementing the proposal proved challenging, and soon stalled. I picked it up again as a side project after working on overhauling the configuration and bootstrapping code in early 2022: With the introduction of SettingsBuilder, it became much simpler to create a MaintenanceRunner class, because it was no longer necessary to juggle global variables.Several bits and pieces got reviewed and merged over the course of 2022 (shout out to Amir, Tim, Timo, and everyone who contributed). Now the runner is ready, and we should stop calling maintenance scripts directly.For now, existing maintenance scripts will function both ways[^2] : when called using the runner, or directly. However, newly created maintenance scripts should not be required to be callable as standalone scripts. So it's best to change all callers to use the wrapper.This should now work for nearly all[^2] cases, though there are still a couple of rough edges to be smoothed out. If you are running MediaWiki 1.40, please try the new mechanism, and report any isses on Phabricator.Thanks,Daniel[^1]https://phabricator.wikimedia.org/T99268[^2] with the exception over very old-school scripts that do not use the Maintenance base class and rely on CommandLineInc.php instead.-- Daniel KinzlerPrincipal Software Engineer, Platform EngineeringWikimedia Foundation
6 8
0 0
Results per page:
[8]ページ先頭
©2009-2025 Movatter.jp