Hi all!
I hope you are doing very well! I’m working on constructing an RDF dataset,
which I’m ingesting to Wikibase and leverage its ecosystem: visualization,
SPARQL endpoint, a script for dump creation, etc. For ingestion, I’m using
the API (explained in https://www.wikidata.org/w/api.php), and it is going
well, except for the time performance.
I was exploring the Quick Statements module of Wikibase, which allows the
ingestion through the UI. However, I need a way to ingest data
automatically. I wonder if Wikibase/Wikidata has any script for bulk loads.
Any comment or suggestion will be welcome.
Best Regards,
Henry Rosales
Hi Everyone,
We’re happy to announce the April 2021 edition of the Technical Community
Newsletter
<https://www.mediawiki.org/wiki/Technical_Community_Newsletter/2021/April>
is now available. The newsletter is compiled by the Wikimedia Developer
Advocacy Team. It aims to share highlights, news, and information of
interest from and about the Wikimedia technical community.
Check it out, and learn about what technical contributors have been up to
this past quarter, upcoming conferences & calls for papers, and how to get
involved.
The Wikimedia Technical Community is large and diverse, and we know we
can't capture everything perfectly. We welcome your ideas for future
newsletters. Let us know what you would like to see or highlights you would
like us to include.
Subscribe to the Technical Community Newsletter
<https://www.mediawiki.org/wiki/Newsletter:Technical_Community_Newsletter>,
if you'd like to keep up with essential updates and information
Kindly,
Sarah R. Rodlund
Senior Technical Writer, Developer Advocacy
<https://www.mediawiki.org/wiki/Developer_Advocacy>
srodlund(a)wikimedia.org
Hello,
I have recently started looking into mediawiki source code and trying to understand various codeflow. I am new to php as well.
I want to see the stacktrace from database functions.
I have put following debug line in the function :
ob_start();
debug_print_backtrace();
$data = ob_get_clean();
fwrite(STDERR, $data . PHP_EOL);
But I don't see any output in /var/log/nginx/mediawiki.error ( in current setup mediawiki is served by nginx).
Any help would be great. Or any other approach to access the stacktrace would also work.
Thanks
Sandeep
https://www.mediawiki.org/wiki/Scrum_of_scrums/2021-04-14
= 2021-04-14 =
Grace/Deb have conflicts today. Please self-organize :)
== Callouts ==
* MediaWiki 1.36-beta has been branched:
https://lists.wikimedia.org/pipermail/wikitech-l/2021-April/094424.html
== Gerrit patches or GitHub Pull Requests for reviews or feedback ==
* None.
=== No updates ===
Community Tech, Anti-Harassment Tools, Library, Site Reliability Engineering
=== '''No notes provided''' ===
Editing, Growth, iOS native app, Android native app, Web, Product
Infrastructure, Parsing, Language, Inuka, Analytics, Cloud Services,
Platform, Quality and Test Engineering, Search Platform, Security
== SoS Meeting Bookkeeping ==
* Updates:
== Product ==
=== Structured Data ===
* Thank yous:
** Jon Robson for getting Vue errors into logstash and helping us identify
some issues in our code
* Updates:
** Working to make the new MediaSearch extension (not yet deployed on
Commons) more usable on other wikis (
https://www.mediawiki.org/wiki/Extension:MediaSearch)
** Image recommendations design work
=== Abstract Wikipedia ===
* Thank yous:
** Thank you to Brennen and Jeena in RelEng for discussing options for
testing MW<->service integrations in CI.
* Updates:
** Working on Phase δ (delta):
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Phases
** Working on our TDMP pitch for asynchronous parser fragments.
=== Vue.js ===
* Updates:
** Working on components design inventory:
https://phabricator.wikimedia.org/T277047
** Starting to work on unifying various component implementations so we can
add them to the experimental WMF component library (WVUI)
*** Button: https://phabricator.wikimedia.org/T278509
*** Binary inputs: https://phabricator.wikimedia.org/T279714
== Technology ==
=== Fundraising Tech ===
* Updates:
** More work on email prefs page https://phabricator.wikimedia.org/T268510
** Planning for integration with new API of backup card processor
** Work to migrate custom CRM code off drupal 7
** CiviCRM contact deduplication enhancements
** Audit / reconciliation file processing improvements:
https://phabricator.wikimedia.org/T277244,
https://phabricator.wikimedia.org/T265545
=== Engineering Productivity ===
==== Performance ====
* Blocking:
** WMSE with performance review of WikiSpeech (in progress, almost finished)
* Thank yous:
** Geno from Abstract Wikipedia for how engaged she is with the matrixing
on our team
* Updates:
** Cancelling our Kobiton subscription, we will build our own device lab
hosted at the office instead
==== Release Engineering ====
* Updates:
** [All] Deployments/Covid-19
https://wikitech.wikimedia.org/wiki/Deployments/Covid-19
** MediaWiki 1.36-beta has been branched:
https://lists.wikimedia.org/pipermail/wikitech-l/2021-April/094424.html
** Train Health
*** Last week: 1.36.0-wmf.38 [[phab:T278343]]<!--
https://phabricator.wikimedia.org/T278344 -->
*** This week: 1.37.0-wmf.1 [[phab:T278344]]<!--
https://phabricator.wikimedia.org/T278345 -->
*** This week: 1.37.0-wmf.2 [[phab:T278345]]<!--
https://phabricator.wikimedia.org/T278346 -->
=== WMDE Technical Wishes ===
* Updates:
** Line numbering was deployed. Currently only on template namespace, due
to feedback by the editing team. Discussion about other namespaces is still
open.
== Cross-cutting ==
* Blocked by:
** [long term] Search Platform: PHP 8.0 work is long-term blocked on the
migration to ElasticSearch 7.0 https://phabricator.wikimedia.org/T263142
(or at least 6.7).
* Thank yous:
* Updates:
** Nothing major.
** CI tools
*** Next release of mediawiki-codesniffer likely soon.
*** CI tools' upgrade status:
https://libraryupgrader2.wmcloud.org/status?branch=master
** PHP 8.0:
*** Our target is REL1_35 (and thus also REL1_36) as well as master.
*** Upstream libraries: Elastica-related PHP code is theoretically the last
one.
*** Core: Some unit and integration tests still fail; thank you to everyone
working on fixing them.
[End]
Yours,
--
*James D. Forrester* (he/him <http://pronoun.is/he> or they/themself
<http://pronoun.is/they/.../themself>)
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi All
There will be no train next week (the week of 2021-04-19) due to a wmf
holiday on 2021-04-22.
There is a long-term calendar of upcoming deployment disruptions available
on Wikitech: https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar
Thanks!
– Tyler
Hello, dear translators!
Your help with a short outreach message is needed. It is the announcement
of the new suggested values feature to be deployed on all wikis. It will
make filling in templates which expect specific inputs much easier to do in
the VisualEditor.
https://meta.wikimedia.org/wiki/User:Timur_Vorkul_(WMDE)/Suggested_values_a…
I plan to send the message to all wikis on April 27, so having many
translations by April 26 would be awesome!
Thanks a lot!
Best,
Timur
--
Timur Vorkul
Technische Wünsche
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23–24 | 10963 Berlin
Tel. (030) 219 158 26-0
https://wikimedia.de
Bleiben Sie auf dem neuesten Stand! Aktuelle Nachrichten und spannende
Geschichten rund um Wikimedia, Wikipedia und Freies Wissen im Newsletter: Zur
Anmeldung <https://www.wikimedia.de/newsletter/>.
Unsere Vision ist eine Welt, in der alle Menschen am Wissen der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
https://spenden.wikimedia.de
Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hello,
in the last few days, for some reason, CI jobs related to the coverage
fails with this reason:
04:16:11 Finding coverage difference in
ede7dc8b68b63373b38fee56facaccf5b7d62589
04:16:11 $ php -d zend_extension=xdebug.so tests/phpunit/phpunit.php
--coverage-clover /tmp/cloverETlRWo --filter
'/MediaWikiIntegrationTestCase|MediaWikiTestCaseTrait|DiffHistoryBlobTest/'
04:16:11 PHP Warning: Failed loading Zend extension 'xdebug.so' (tried:
/usr/lib/php/20180731/xdebug.so (/usr/lib/php/20180731/xdebug.so: cannot
open shared object file: No such file or directory), /usr/lib/php/20180731/
xdebug.so.so (/usr/lib/php/20180731/xdebug.so.so: cannot open shared object
file: No such file or directory)) in Unknown on line 0
04:16:11 Using PHP 7.3.27-9+0~20210227.82+debian10~1.gbpa4a3d6
04:16:14 PHPUnit 8.5.15 by Sebastian Bergmann and contributors.
04:16:14
04:16:14 Error: No code coverage driver is available
04:16:14
04:16:14 ............................S.......SS
38 / 38 (100%)
04:16:14
04:16:14 Time: 3.21 seconds, Memory: 365.00 MB
04:16:14
04:16:14 OK, but incomplete, skipped, or risky tests!
04:16:14 Tests: 38, Assertions: 87, Skipped: 3.
04:16:14
04:16:14
04:16:14 You should really speed up these slow tests (>50ms)...
04:16:14 1. 60ms to run MediaWikiIntegrationTestCaseTest:testEditPage
04:16:14
04:16:14 In CloverXml.php line 69:
04:16:14
04:16:14 String could not be parsed as XML
04:16:14
04:16:14
04:16:14 check [--sha1 [SHA1]] [--test-dir TEST-DIR] [--html [HTML]]
[--command COMMAND]
Example:
https://integration.wikimedia.org/ci/job/mwcore-phpunit-coverage-patch/2841…
Patch: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/675296
I would like to know why is this happening.
Best regards,
Zoran
Hi there,
I am investigating a breakage in my extension that has occurred in MW 1.34
but which didn't seem to be a problem on MW 1.29. (I have not tested
interim versions to see where the issue first arises.)
One of the parser hooks in the extension needs to perform variable
expansion. What is happening is a lot more complicated than this example,
but effectively
<my_hook Foo="What the foo!">{{{Foo}}}</my_hook>
should end up generating the following output, using variable expansion:
What the foo!
The semantics of variable handling need to follow the MW semantics,
including default values (possibly nested), parser functions, etc. therefore
it needs to use the MW parser to perform the expansion.
Assuming the arguments that MW passes into the parser hook are named $Text,
$Vars, $Parser and $Frame, the relevant code looks something like this
(again, a bit more complicated in practice):
$NewFrame = new PPTemplateFrame_DOM($Frame->preprocessor, $Frame,
array(), $Vars, $Frame->title);
return $Parser->replaceVariables($Text, $NewFrame);
(I have included a more detailed listing of the code that I am using for
doing the parse at the end of this message.)
My code was working fine on MW 1.29 and earlier, but when I upgrade to 1.34
I am finding that I get a fatal exception thrown when my tag is encountered:
/index.php?title=Main_Page MWException
from line 373 of ~\includes\parser\PPFrame_DOM.php:
PPFrame_DOM::expand: Invalid parameter type
I have generated a backtrace and the top of the stack is as follows:
#0 ~\includes\parser\Parser.php(3330): PPFrame_DOM->expand(PPNode_Hash_Tree,
integer)
#1 MyExtension.php (434): Parser->replaceVariables(string,
PPTemplateFrame_DOM)
#2 ~\includes\parser\Parser.php(4293): MyExtensionParserHook(string, array,
Parser, PPTemplateFrame_Hash)
(The subsequent call stack entries are the parent functions you would expect
to see in that situation.)
Can anyone see why the above code would no longer work as it did on previous
versions? What is the current recommended method for manually expanding
template variables from within a parser hook?
Kind regards,
- Mark Clements (HappyDog)
----------------------------------
Full example (with extension-specific code omitted):
----------------------------------
function MyExtensionParserHook($Text, $Vars, $Parser, $Frame) {
// 1) Manipulate $Text and $Vars
// (omitted)
// 2) Expand variables in the resulting text.
// Set up a new frame which mirrors the existing one but which also has
the
// field values as arguments.
// If we are already in a template frame, merge the field arguments with
the
// existing template arguments first.
if ($Frame instanceof PPTemplateFrame_DOM) {
$NumberedArgs = $Frame->numberedArgs;
$NamedArgs = array_merge($Frame->namedArgs, $Vars);
}
else {
$NumberedArgs = array();
$NamedArgs = $Vars;
}
$NewFrame = new PPTemplateFrame_DOM($Frame->preprocessor, $Frame,
$NumberedArgs, $NamedArgs,
$Frame->title);
// Perform a recursive parse on the input, using our newly created
frame.
return $Parser->replaceVariables($Text, $NewFrame);
}