I enabled HTML email on this list, since most people were OK with me
enabling it on wikitech-l in the recent discussion there, and the
audience is much the same.
-- Tim Starling
Hi Everyone,
Our site is at https://www.cryptopp.com/wiki.
Since the Mediawiki 1.34.3 upgrade, the wiki serves each page with the
following at the top:
<br />
<b>Warning</b>: php_uname() has been disabled for security reasons in
<b>/var/www/html/w/includes/GlobalFunctions.php</b> on line
<b>1333</b><br />
<!DOCTYPE html>
<html class="client-nojs" lang="en" dir="ltr">
<head>
...
Any ideas how to fix things?
Thanks in advance.
====================
There seems to be a fair amount of php_uname:
/var/www/html/wiki # grep -IR php_uname ./*
./extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneEngine.php:
if ( php_uname( 's' ) === 'Linux' ) {
./extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneEngine.php:
if ( php_uname( 's' ) == 'Linux' ) {
./extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneEngine.php:
if ( php_uname( 's' ) == 'Windows NT' ) {
./extensions/CodeEditor/modules/ace/mode-php.js:
'php_ini_loaded_file|php_ini_scanned_files|php_logo_guid|php_sapi_name|php_strip_whitespace|php_uname|phpcredits|phpinfo|phpversion|pi|'
+
./extensions/CodeEditor/modules/ace/mode-php.js: "php_uname": [
./extensions/CodeEditor/modules/ace/mode-php.js: "string
php_uname(void)",
./includes/debug/logger/monolog/MwlogHandler.php:
$this->hostname = php_uname( 'n' );
./includes/debug/logger/monolog/SyslogHandler.php:
$this->hostname = php_uname( 'n' );
./includes/debug/logger/MonologSpi.php: * 'args' => [
'mediawiki', php_uname( 'n' ), null, '', 1 ],
./includes/GlobalFunctions.php: return php_uname( 'n' ) ?: 'unknown';
./includes/installer/Installer.php: $os = php_uname( 's' );
./includes/Pingback.php: 'OS' => PHP_OS
. ' ' . php_uname( 'r' ),
./includes/Pingback.php: 'machine' =>
php_uname( 'm' ),
./maintenance/benchmarks/bench_wfIsWindows.php: return substr(
php_uname(), 0, 7 ) == 'Windows';
./maintenance/benchmarks/Benchmarker.php:
php_uname( 'm' ),
./maintenance/benchmarks/Benchmarker.php:
php_uname( 's' ),
./maintenance/benchmarks/Benchmarker.php:
php_uname( 'r' ),
./maintenance/benchmarks/Benchmarker.php:
php_uname( 'v' )
./RELEASE-NOTES-1.34:* (T172060) GlobalFunctions: Use php_uname
instead of posix_uname.
./vendor/pear/pear-core-minimal/src/OS/Guess.php:// php_uname()
without args returns the same as 'uname -a', or a PHP-custom
./vendor/pear/pear-core-minimal/src/OS/Guess.php: * This class uses
php_uname() to grok information about the current OS
./vendor/pear/pear-core-minimal/src/OS/Guess.php: $uname =
php_uname();
./vendor/symfony/console/Output/ConsoleOutput.php:
\function_exists('php_uname') ? php_uname('s') : '',
./vendor/phan/phan/src/Phan/Plugin/Internal/UseReturnValuePlugin.php:
'php_uname' => true,
./vendor/phan/phan/src/Phan/Language/Internal/FunctionDocumentationMap.php:'php_uname'
=> 'Returns information about the operating system PHP is running on',
./vendor/phan/phan/src/Phan/Language/Internal/FunctionSignatureMap.php:'php_uname'
=> ['string', 'mode='=>'string'],
./vendor/phan/phan/src/Phan/Language/Internal/FunctionSignatureMapReal_php73.php:'php_uname'
=> '?string',
./vendor/phan/phan/src/Phan/Language/Internal/FunctionSignatureMapReal.php:'php_uname'
=> 'string',
Hi Everyone,
I updated from Mediawiki 1.34.2 to Mediawiki 1.34.3 on CentOS 7,
x86_64, fully patched.
There were some warnings during the upgrade:
Package wikimedia/password-blacklist is abandoned, you should avoid
using it. Use wikimedia/common-passwords instead.
Package jakub-onderka/php-parallel-lint is abandoned, you should avoid
using it. Use php-parallel-lint/php-parallel-lint instead.
Package jakub-onderka/php-console-color is abandoned, you should avoid
using it. Use php-parallel-lint/php-console-color instead.
Package jakub-onderka/php-console-highlighter is abandoned, you should
avoid using it. Use php-parallel-lint/php-console-highlighter instead.
Package phpunit/php-token-stream is abandoned, you should avoid using
it. No replacement was suggested.
Package phpunit/phpunit-mock-objects is abandoned, you should avoid
using it. No replacement was suggested.
Jeff
Hi all,
Tomorrow we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
- 1.34.3
- 1.31.9
This will resolve eight issues in MediaWiki core (two of which aren't
applicable to MediaWiki 1.31), and also includes some fixes previously
committed to git, including minor security and hardening patches along with
bug fixes included for maintenance reasons.
For those of you waiting on MediaWiki 1.35.0, this will also come either
tomorrow, or at latest Friday (depending on CI load), including the
security fixes applied to these other supported release branches. We thank
you for your patience; the current global situation means things have taken
longer than would have been expected, but it has meant more bug fixes being
incorporated from testing across the board. It also meant not having a
security 1.35.1 release followup only a couple of weeks after 1.35.0 coming
out. Which, for many people would mean extra work to upgrade again, and it
was decided to avoid this.
We will make the fixes available in these respective release branches, and
also master. Tarballs will be available for the above mentioned point
releases as well.
A summary of some of the security fixes that have gone into non-bundled
MediaWiki extensions will also follow.
As per the MediaWiki Version lifecycle [1], November 2020 is the scheduled
EOL date for the REL1_34. 1.34.3 will therefore potentially be the final
release of the MediaWiki 1.34 branch, barring any unforeseen issues. As per
above, MediaWiki 1.35.0 will be released this week, and will be supported
until at least September 2023, and would be the recommended upgrade path.
[1] https://www.mediawiki.org/wiki/Version_lifecycle
Hi,
*Crossposting to Wikimedia-L, Wikitech-L, MediaWiki-L, and
Wikitech-Ambassadors. You can reply to the mailing list, but the ideal
place for further discussion is the talk pages of the wiki pages to which I
link below.*
There's a new proposal to localize Lua modules in a more modern, safe, and
convenient manner: https://www.mediawiki.org/wiki/Translatable_modules .
In the foreseeable future it will only affect multilingual sites, such as
Wikidata, Commons, Meta, and mediawiki.org, but at a later time it may also
be deployed on Wikipedias and other projects.
It will be great if experienced module developers could take a look at the
project page, https://www.mediawiki.org/wiki/Translatable_modules , and its
subpages, especially https://www.mediawiki.org/wiki/Translatable
modules/Proposed solutions . Your feedback will be very helpful in
implementing this project in a way that really benefits all the editors.
Thanks!
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hello,
The second round of voting for the new logo will start soon. In this round,
we are going to vote on different variants of the top design (Proposal
six). Given that 16 different variants of this logo exist (with different
wordmarks, colors, etc.), we need preferential voting instead of the
classic support/oppose. We will use Schulze method [1] for choosing the
final winner.
I hacked together a simple voting gadget that you can test in
https://www.mediawiki.org/wiki/User:Ladsgroup/Round_2?withJS=MediaWiki:Gadg…
Using that, you just order logos based on how much you like them (with drag
and drop), and then click save. The votes will be saved in another page.
Please test and let me know of any issues by the next couple of days (by
September 25). Any edits on the gadget is also welcome. Please put your
suggestions on its talk page if you don't have rights to edit it.
Of course, voting without the gadget will be also possible, it'll be just
slightly cumbersome.
One known issue so far: The gadget on mobile doesn't work because mobile
browsers don't listen to drag events.
[1] https://en.wikipedia.org/wiki/Schulze_method
Best
--
Amir (he/him)
*** Discover the future of knowledge sharing ***
*** at the 17th Semantic MediaWiki Conference ***
24.11. – 26.11.2020, online
---------------------------
Hello MediaWiki maintainers, software developers, consultants, researchers!
Due to the COVID19 pandemic, the SMWCon in fall 2020 will be held online and free of charge. [0]
On three days there will be talks, tutorials and hackathons around the topics
* open knowledge and open data,
* semantics, knowledge graphs,
* open source technology, wikis and collaboration.
Call for Contributions
----------------------
Contributions can be submitted until ** 15. 10. 2020 **
We are looking for use cases and best practices for business and the public sector, news about extensions and features, experiences with templating, development and deployment or debates about knowledge graphs, GLAM, and wikis as research and education tools.
If your topic is not yet mentioned included, submit it anyway :-)
Registration
------------
No registration and no conference fees are required. You will be able to join the online meetings as you like.
But to let others know that you will be attending, please add your name at the conference wiki page.
We look forward to your participation!
The organizers of SMWCon 2020
* Bernhard Krabina (General Chair)
* Richard Heigl (Program chair)
* Eva Vogel (Communication)
[0] https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2020
[---- Long mail - but only relevant to extension developers ----]
Greetings!
As some of you might know, on the Parsing Team [0], we are aspiring to
replace the core wikitext parser with Parsoid [1] on Wikimedia wikis late
next year and start to put to rest the two-parser ghost that has haunted us
for many years. In recent years, we achieved two major milestones along
the way: replace HTML4 tidy with HTML5 Remex [2], and port Parsoid from
Javascript to PHP [3].
Given that context, if you (help) maintain an extension that:
* uses a "parser hook" and/or
* uses the "parser API" (i.e. uses public properties / methods in
Parser.php, ParserOutput.php, ParserOptions.php, etc.)
please read on. If you don't fit that description, you can stop reading
now!
Parsoid models and processes wikitext quite differently from the
core parser - all that Parsoid guarantees is that the rendering is largely
identical, not the specific process of generating the rendering. This
means that extensions that extend the behavior of the parser will need to
adapt to work with Parsoid instead to provide similar functionality. With
that in mind, we have been working to more clearly specify how extensions
need to adapt to the Parsoid regime.
PARSOID & EXTENSIONS:
At a high level, here are the questions we needed to answer, along with
some highly simplified answers:
1. How do extensions "hook" into Parsoid?
A. Extensions need to think in terms of transformations (convert this
to that) instead of parser pipeline events (at this point in the
pipeline, call this listener). An additional detail here is that
extensions cannot maintain global ordered state within extension code
since Parsoid doesn't guarantee handlers will be invoked in the same
order in which they showed up in page source. See the wiki [4] for
more details.
As for the mechanics of registration, Parsoid uses existing mechanisms
based on the extension.json file.
2. When the registered hook listeners are invoked by Parsoid, how do they
process any wikitext they need to process?
A. Parsoid provides all registered listeners with an API object to interact
with it. Direct use of Parsoid internals code is strongly discouraged
and will be enforced in various ways including via code review.
3. How is the extension's output assimilated into the page output?
A. The output is treated as a "fully-processed" page/DOM fragment (with
some caveats which will be clarified on wiki). It is appropriately
decorated with additional markup, and slotted into place into the page.
Extensions need not make any special efforts (aka strip state) to
protect it from the parsing pipeline.
Slides 8-12 of the August 12 2020 Tech Talk [7] goes over the differences.
Check the wiki [4] for more details of Parsoid's Extension API. It also
maps core parser hooks to Parsoid's extension functionality.
CURRENT STATUS:
We consider the current proposal to be in late draft stage. That said, as
we discover unsupported functionality, we will augment the set of hooks and
the Parsoid Extension API as needed.
While there are a wide variety of extensions in the MediaWiki universe
with varied use cases, our initial goal for the next year is just Wikimedia
wikis and hence extensions that are deployed on the Wikimedia wikis.
Once we are done with that, we will turn our attention to supporting
extension use cases in the wider MediaWiki universe. But, now is a
good time for all extension developers to study and review this API
and give us feedback.
Since the beginning of this year, we've refactored all of the extensions
we've written Parsoid versions of (Cite, Gallery, Poem, Pre, JSON) to
now strictly use the Parsoid Extension API without cheating by virtue
of being in the Parsoid codebase. So, this proposal is actually backed
by an implementation that is in production for Wikimedia wikis.
FEEDBACK:
Here is where you come in.
* If you maintain / develop an extension, please review the document
to see if your extension's use case is covered.
Ideally, leave your feedback on the Parsoid Extension API talk page [5]
since it helps keep it all in one place. Alternatively, you can also
leave questions / concerns / other feedback on the Phabricator task
we've filed for TechCom's RFC process [6].
* If you feel bold, start the process of updating your extensions *now*.
Note that your extension will need to operate with both the existing
core parser as well as Parsoid till such time we deprecate and stop
using the core parser.
There are known functionality gaps related to exposing ParserOutput
object and providing setFunctionHook functionality. If your extension
needs those, you should probably wait for us to fill that gap.
DOCS / MORE INFO / CONTACT:
* Check the wiki page [4] for docs and discuss on the talk page [5]
* Check the August 12, 2020 Tech Talk [7]
* Look at Parsoid code for extensions [8]
* Look at Parsoid docs for the Ext/ namespace [9]
* Talk to us on IRC in the #mediawiki-parsoid channel
* Email us at parsing-team(a)wikimedia.org
Thanks!
Subbu (on behalf of the Parsing Team).
-------------------------------------------------------------------------
0. https://www.mediawiki.org/wiki/Parsing
1. https://www.mediawiki.org/wiki/Parsing/Parser_Unification
2. https://blog.wikimedia.org/2018/07/09/tidy-html5-replacement/
3.
https://techblog.wikimedia.org/2020/02/12/parsoid-in-php-or-there-and-back-…
4. https://www.mediawiki.org/wiki/Parsoid/Extension_API
5. https://www.mediawiki.org/wiki/Parsoid/Talk:Extension_API
6. https://phabricator.wikimedia.org/T260714
7. Slides:
https://commons.wikimedia.org/wiki/File:Parsoid_%26_Extensions_August_2020_…
Video: https://www.youtube.com/watch?v=lS1xPkERWCM
8. https://github.com/wikimedia/parsoid/tree/master/src/Ext
9. https://doc.wikimedia.org/Parsoid-PHP/master/