Hello everybody!
Some time ago, I asked this question on the Wikimedia Development Support forums [1], but unfortunately nobody answered. Mabye here on the mailing list someone can help me.
I want to change the configuration of the Parsoid service dynamically, without modifying the `config.yaml`/`localsettings.js` and restarting the service.
My use case is simple: I need _one_ Parsoid to serve multiple MediaWikis instances. And I need to be able to add new instances without the need to reconfigure/restart Parsoid everytime.
The logic would be "If the calling MediaWiki instance sends 'ABC' as a prefix, the API url of that instance will be 'https://myserver/wikis/ABC/api.php'".
I have the strong feeling that overriding the `parsoidConfig` object in `localsettings.js` will be the way to go. Am I on the right track?
Your hints and suggestions are much appreciated.
[1] https://discourse-mediawiki.wmflabs.org/t/dynamic-parsoid-configuration/775
--
Robert Vogel
Hi,
I'd like to discuss potential improvements to www.mediawiki.org (the
front page itself), both regarding content and presentation, as I see
several issues with the current page.
I propose to discuss this in several stages:
* Defining audiences,
* defining content per group,
* defining presentation and layout.
My main intention are improvements to allow our audiences to better
find the relevant information that they are looking for.
We might not be able to make everything perfect but we can certainly
try to make it better?
If this sounds interesting, please take a look at
https://www.mediawiki.org/wiki/MediaWiki/Homepage_improvements_2018
and let's discuss on the corresponding discussion page and work on
this?
Thank you!
andre
--
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/
When I edit a page with Visual Editor and try to save, I get a HTTP 404 apierror-visualeditor-docserver-http.
It have been working before, but now when I try to set up RESTBase, it doesn't works anymore.
For my configuration, see https://github.com/magol/sag-wiki/tree/master/sag-wiki
//Magnus
________________________________
Capgemini is a trading name used by the Capgemini Group of companies which includes Capgemini Sverige AB, a company registered in Sweden (number 556092-3053) whose registered office is at Gustavslundsv?gen 131 Box 825 ? S-161 24 Bromma.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Hi,
While preparing the last MediaWiki security release, we (Reedy & I)
noticed that the mediawiki-core variant of the tarball that doesn't
include the bundled extensions/skins is treated differently than the
normal tarball. So we have two questions that will help us prioritize
future release process improvements.
If you don't use the special mediawiki-core tarball, you can ignore the
rest of this message.
1. Briefly, why do you use the mediawiki-core tarball instead of the
standard tarball that includes extensions/skins?
2. Would you benefit from having a patch file (example[1]), like the one
we currently generate for the standard mediawiki tarball?
Replies on or off list are fine. This is mostly an informal survey, we
don't have any plans yet and are mostly trying to gauge usage first.
[1] https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.1.patch.gz
Thanks,
-- Legoktm
Hi,
I have mediawiki latest version running on my domain. I was trying to
enable page previews that are descrined here:
https://www.mediawiki.org/wiki/Page_Previews
The first problem I encountered is that there's no Enable/Disable previews
option at the buttom of the pages/site and there's no option to
enable/disable that in the preferences for user accounts.
So I have solved this by installing the Populs extencion from:
https://www.mediawiki.org/wiki/Extension:Popups
I now have page previews enabled for internal links.
Now I am trying to enable the same page previews for interwiki links and
other external links that I have all over my wiki. Is this at all possible
and how do I do it?
Please let me know.
Thanks in advance.
When I edit a page with Visual Editor and try to save, I get a HTTP 404 apierror-visualeditor-docserver-http.
It have been working before, but now when I try to set up RESTBase, it doesn't works anymore.
For my configuration, see https://github.com/magol/sag-wiki/tree/master/sag-wiki
//Magnus
________________________________
Capgemini is a trading name used by the Capgemini Group of companies which includes Capgemini Sverige AB, a company registered in Sweden (number 556092-3053) whose registered office is at Gustavslundsv?gen 131 Box 825 ? S-161 24 Bromma.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
My current setup, under which MW is running swimmingly:
Fedora 27
Apache 2.4.33
MariaDB 10.2.14
MediaWiki 1.30.0
I am attempting to upgrade to MW 1.31.0. I unzipped the tarball into a
fresh directory, copied over my LocalSettings.php file, and changed the
symlink that I use with Apache to point to the new location. I then
attempted to run maintenance/update.php and it cryptically ended with a
whimper:
====================
MediaWiki 1.31.0 Updater
Your composer.lock file is up to date with current dependencies!
Going to run database updates for wikidb
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds (skip this countdown with
--quick) ... 0
Turning off Content Handler DB fields for this part of upgrade.
Adding ipb_id field to table ipblocks ...Set $wgShowExceptionDetails =
true; and $wgShowDBErrorBacktrace = true; at the bottom of
LocalSettings.php to show detailed debugging information.
====================
I added the suggested flags to LocalSettings and got the following in my
browser:
====================
[WyJ-joCjti3zg1lzHPXHqQAAAAM] /wiki/Main_Page Wikimedia\Rdbms\DBQueryError
from line 1457 of
/var/www/gpf/mediawiki-1.31.0/includes/libs/rdbms/database/Database.php: A
database query error has occurred. Did you forget to run your application's
database schema updater after upgrading?
Query: SELECT
user_id,user_name,user_real_name,user_email,user_touched,user_token,user_email_authenticated,user_email_token,user_email_token_expires,user_registration,user_editcount
FROM `mediawiki`.`user` WHERE user_id = '1' LIMIT 1
Function: User::loadFromDatabase
Error: 1142 SELECT command denied to user 'wikiuser'@'localhost' for table
'user' (localhost)
Backtrace:
#0
/var/www/gpf/mediawiki-1.31.0/includes/libs/rdbms/database/Database.php(1427):
Wikimedia\Rdbms\Database->makeQueryException(string, integer, string,
string)
#1
/var/www/gpf/mediawiki-1.31.0/includes/libs/rdbms/database/Database.php(1200):
Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string,
boolean)
#2
/var/www/gpf/mediawiki-1.31.0/includes/libs/rdbms/database/Database.php(1653):
Wikimedia\Rdbms\Database->query(string, string)
#3
/var/www/gpf/mediawiki-1.31.0/includes/libs/rdbms/database/Database.php(1730):
Wikimedia\Rdbms\Database->select(array, array, array, string, array, array)
#4 /var/www/gpf/mediawiki-1.31.0/includes/user/User.php(1407):
Wikimedia\Rdbms\Database->selectRow(array, array, array, string, array,
array)
#5 /var/www/gpf/mediawiki-1.31.0/includes/user/User.php(537):
User->loadFromDatabase(integer)
#6
/var/www/gpf/mediawiki-1.31.0/includes/libs/objectcache/WANObjectCache.php(1240):
User->{closure}(boolean, integer, array, NULL)
#7
/var/www/gpf/mediawiki-1.31.0/includes/libs/objectcache/WANObjectCache.php(1110):
WANObjectCache->doGetWithSetCallback(string, integer, Closure, array)
#8 /var/www/gpf/mediawiki-1.31.0/includes/user/User.php(561):
WANObjectCache->getWithSetCallback(string, integer, Closure, array)
#9 /var/www/gpf/mediawiki-1.31.0/includes/user/User.php(482):
User->loadFromCache()
#10 /var/www/gpf/mediawiki-1.31.0/includes/user/User.php(420):
User->loadFromId(integer)
#11 /var/www/gpf/mediawiki-1.31.0/includes/session/UserInfo.php(88):
User->load()
#12
/var/www/gpf/mediawiki-1.31.0/includes/session/CookieSessionProvider.php(119):
MediaWiki\Session\UserInfo::newFromId(string)
#13 /var/www/gpf/mediawiki-1.31.0/includes/session/SessionManager.php(488):
MediaWiki\Session\CookieSessionProvider->provideSessionInfo(WebRequest)
#14 /var/www/gpf/mediawiki-1.31.0/includes/session/SessionManager.php(191):
MediaWiki\Session\SessionManager->getSessionInfoForRequest(WebRequest)
#15 /var/www/gpf/mediawiki-1.31.0/includes/WebRequest.php(736):
MediaWiki\Session\SessionManager->getSessionForRequest(WebRequest)
#16 /var/www/gpf/mediawiki-1.31.0/includes/session/SessionManager.php(130):
WebRequest->getSession()
#17 /var/www/gpf/mediawiki-1.31.0/includes/Setup.php(847):
MediaWiki\Session\SessionManager::getGlobalSession()
#18 /var/www/gpf/mediawiki-1.31.0/includes/WebStart.php(88):
require_once(string)
#19 /var/www/gpf/mediawiki-1.31.0/index.php(39): require(string)
#20 {main}
====================
Needless to say, I'm pretty confused here. Nothing has changed to my
configuration (and probably to the wiki's contents) since I successfully
upgraded to 1.30.0. If I switch my symlink back to point to my MW 1.30.0
install, the site loads just fine. So it appears the updater is bombing
when it tries to add the field "ipb_id" to table "ipblocks".
What confuses me is the "SELECT command denied to user 'wikiuser'@'localhost'"
error. My wiki has two MariaDB users: "wikuser" (the standard user set in
$wgDBuser) and an admin user set with $wgDBadminuser. Neither user account
has changed, either in the DB or in LocalSettings.
It *almost* looks like the updater is trying to use the standard user to do
admin functions, but even that doesn't make much sense. "wikiuser" has
SELECT access to all tables in the DB, while the admin user has all
permissions to the entire DB. So I don't see why that specific error would
crop up; even "wikiuser" should be able to perform a simple SELECT.
Fortunately, I can switch back to MW 1.30.0 pretty easily, but I thought I
ought to report the problem.
ADDENDUM: I just noticed the following in the 1.31 release notes:
====================
Important pre-upgrade notes for 1.31
- If you're using MySQL, SQLite, or MSSQL, are not using update.php to
apply schema changes, and cannot have downtime to run
migrateArchiveText.php and apply patch-drop-ar_text.sql manually, you'll
have to apply a default value to the ar_text and ar_flags columns of the
archive table or make those columns nullable before upgrading to MediaWiki
1.31. maintenance/archives/patch-nullable-ar_text.sql shows how to do this
for MySQL.
====================
Based on this, I think there's something screwy with update.php. I *am*
using update.php to apply schema changes, but I'm guessing it's not working
correctly. I have *not* tried this manual fix (and would prefer not to
unless absolutely necessary).
Jeffrey T. Darlington
General Protection Fault
https://www.gpf-comics.com/
Hi all,
Tomorrow we will be issuing a security release to all supported
branches of MediaWiki.
The new releases will be:
1.31.1
1.30.1
1.29.3
1.27.5
This will resolve 4 issues in MediaWiki core, and also includes some
previously committed to git minor security and hardening patches.
Fixes will be available in these respective release branches,
and also master. Tarballs will be available for the above mentioned
point releases as well.
1.29 was due to be previously announced as end of life, and as
such 1.29.3 will be the final security and maintenance release
barring any unforeseen issues.
This security release includes fixes for MediaWiki core.
---
Sam Reed
Greetings,
Several people over the last 12+ years have asked -- and not been given an
answer -- why usernames' first character are forced to upper-case. I now
have the same question. The discussion stems from this talk pages:
https://www.mediawiki.org/wiki/Manual_talk:$wgCapitalLinks and
https://www.mediawiki.org/wiki/Manual_talk:$wgCapitalLinkOverrides
To me, this looks like an obsolete, legacy requirement from long before the
time $wgCapitalLinks was introduced.
The relevant code is found in includes/user/User.php:
public static function getCanonicalName( $name, $validate = 'valid'
) {
// Force usernames to capital
global $wgContLang;
$name = $wgContLang->ucfirst( $name );
isValidUserName also checks this condition. But no where do I see *why*.
Proposal:
It seems to me that either $wgCapitalLinks should apply here, or (for
backward compatibility), a new option ( $wgCapitalNames ) should be created
to allow the site-admin to disable the forcing of ucfirst of usernames.
--
Otheus
otheus(a)gmail.com
+43.699.1049.7813