Hi Everyone,
During a Mediawiki 1.34.3 to Mediawiki 1.34.4 upgrade... When updating
vendor components using 'php -d extension=phar.so composer.phar
update':
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.
I don't add things to vendor/, and I did not install packages like
password-blacklist or php-parallel-lint. It looks like these are part
of a Mediawiki installation.
/var/www/html/wiki# find . -name password-blacklist
./vendor/wikimedia/password-blacklist
/var/www/html/wiki# find . -name php-parallel-lint
./vendor/jakub-onderka/php-parallel-lint
Jeff
Hi,
Did I restore my database correctly?
Do I need to delete the database first?
Here's what happened:
I had trouble after upgrade of MW1.31.1 to MW1.35.1. I had had success
with this upgrade on the test version of my wiki, but ran into a
problem with the upgrade of the production version of my wiki. I may
post about that later. Meanwhile, to revert back to the 1.31.1 version
of my production wiki I moved the old files back in place:
-$ mv teflpedia teflpediaNEW; mv teflediaOLD teflpedia
And to revert the database and be rid of whatever changes I had done
when I had run MW1.35.1's maintenance/update.php, I did:
-$ gunzip < ~/bu/bilbo_teflpedia.20210130.MW1.31.1.sql.gz | mysql -p
bilbo_teflpedia
The database for the wiki is named bilbo_teflpedia, and I had created
that .sql.gz just prior to my upgrade attempt, with this:
-$ mysqldump -p --default-character-set=binary bilbo_teflpedia | gzip
> ~/bu/bilbo_teflpedia.20210130.MW1.31.1.sql.gz
Few!
Also, I had set my webhost to PHP 7.3.26 via cPanel, which both
MW1.31.1 and 1.35.1 are compatible with, before the upgade attempt.
Now I'm wondering, did I *combine* the new database with the old one
with that: -$ gunzip < ~/bu/bilbo_teflpedia.20210130.MW1.31.1.sql.gz |
mysql -p bilbo_teflpedia
Did I properly *replace* the bilbo_teflpedia database with the old one?
Do I need to delete the bilbo_teflpedia database first?
Thanks for any advice!
Roger Chrisman, venomous spider at teflpedia.com one bug at a time
For reference, here's my
* production wiki: https://teflpedia.com/Special:Version
* test wiki: https://tp.rogerchrisman.com/Special:Version
Hello,
There has been a lot of progress in abstract schema and abstract schema
changes initiative since last time
<https://lists.wikimedia.org/pipermail/wikitech-l/2020-October/093954.html>
I gave an update on it. So here's another one.
*Abstract Schema*
So far, more than 90% (51 out 56) of tables of mediawiki core are now
migrated to abstract schema.
This means much smaller schema drifts between MySQL and Postgres. We have
done more than 250 schema changes in Postgres to fix these drifts.
Including 56 index rename, 66 data type change, setting default to 43
fields and changing nullability of 29 fields. To compare, that's more
schema changes done on Postgres from 2014 until 2020. Once we have migrated
all tables, we can close this four-year old ticket
<https://phabricator.wikimedia.org/T164898>.
Similar improvement has happened on standardizing timestamp fields in MySQL
<https://phabricator.wikimedia.org/T42626>, once all tables are migrated,
we can call this eight-year old ticket done too.
One nice thing about having an abstract schema is that you can generate
documentation automatically, This page is completely made
<https://www.mediawiki.org/w/index.php?title=User:Ladsgroup/Test&oldid=43795…>
automatically from tables.json. We can make it generated in
doc.wikimedia.org on every merge. And also we can make the database layout
diagram
<https://www.mediawiki.org/w/index.php?title=Manual:Database_layout/diagram&…>
created automatically.
Another nice thing. When you have an abstract schema, you can easily write
tests and enforce database conventions. For example, you can write a test
to make sure all tables have exactly five columns (because five is your
lucky number). We haven't written such a test but now there's a test that
enforces a uniform prefix for columns and indexes of tables in core
<https://phabricator.wikimedia.org/T270033>. We are currently fixing its
violations to standardize our schema even more.
I'm planning to make reporting on drifts between the abstract schema and
our production completely automated and make it accessible to DBAs for
further investigations which is now much easier thanks to abstract schema.
You can follow the progress of that work in this ticket.
<https://phabricator.wikimedia.org/T104459>
*Abstract Schema Changes*
Now we have a new maintenance script, it produces schema change sql files
(aka ALTER TABLE files) based on snapshot of abstract schema of before and
after of a table. Here's an example of an index rename.
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/651176> It would make
creating schema change patches much easier (a little bit of work but you
don't need to know internals of Postgres anymore, it's also less prone to
mistakes)
With approval of RFC to drop support of upgrading from versions older than
two LTS releases, we can now drop hundreds and hundreds of sql files. It
would give us room to breath and audit our sql files to find orphan ones
and improve abstract schema change work. That is currently blocked on this
patch landing. <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/648576>
We will work on reshaping the schema changes in general since its current
checks system is less than optimal, its tests are not very updated and so
much more to do.
*What can we do?*
Glad you asked :D The biggest request I have from people is to migrate
their extensions to abstract schema. There's a list of WMF-deployed
extensions that their schema has not migrated yet
<https://phabricator.wikimedia.org/T261912>. This is doubly important as we
want to build a reporting system for drifts in production and it's not
possible to report these drifts for extensions that their schema has not
migrated yet. So if you or your team maintain an extension from that list,
prioritize migrating that please. Reedy wrote a great script
<https://github.com/Ladsgroup/db-analyzor-tools/blob/master/db_abstractor.py>
that takes a sql file and produces its equivalent abstract schema and it
gives you a good starting point (PR is welcome!). Feel free to add me as a
reviewer to patches of migrating extensions to abstract schema.
Another thing is that if you use postgres for mediawiki, you help testing
our postgres schema by trying master (make sure to take a backup first) and
see if everything is alright.
*Thank you!*
I would really like to thank Ammarpad for migrating lots of tables of core
to abstract schema and handling all sorts of edge cases and doing most of
the work of using uniform prefix tests and fixes. Thanks to James Forrester
for reviewing lots of patches. Thanks Reedy for the script and also
abstracting lots of tables in extensions and also Tgr for helping in
reviews and getting the project going. Also a big thank you to DBAs for doing
a lot more schema changes in production
<https://phabricator.wikimedia.org/tag/blocked-on-schema-change/>. You rock!
An apology is also warranted for breaking update.php on master twice
(caused by yours truly).
Until next update!
--
Amir (he/him)
Folks,
MediaWiki:1.35.1 (63b3fbf)
PHP:7.4.13 (fpm-fcgi)
MariaDB:10.3.25-MariaDB-0ubuntu0.20.04.1-log
ICU:66.1
LuaSandbox:3.0.3
Lua:5.1.5
Server version: Apache/2.4.46 (Ubuntu)
Fresh install.
Hoping some one can point me in the right direction. Seems I have a
charset problem. When logged out, all pages display the black
diamond/question mark when characters don't render correctly. Except for
all the Special Pages, Version, Login pages. It's like pages created
after installation have a charset problem.
However, when I log in, all pages return to normal. Not even sure the
right question to ask other than is there a config in the LocalSettings
that would do different charset between logged out and logged in.
Vector Skin at legacy level.
$wgShellLocale = "C.UTF-8";
$wgLanguageCode = "en";
Both apache2 and php7.4 running utf8 charset.
Thanks for your advice!
Chap
Hey Daniel are you around here?
I wanted to follow up with my question regarding media wiki given you said to contact you last week, but you probably were busy and my pings in IRC were Unsucessfull.
Cheers.
Carpe Diem, Alexis
DiEM25.org Exarcheia/Tech.sov DSC
Sent with [ProtonMail](https://protonmail.com) Secure Email.
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2021.01. This bundle is compatible with MediaWiki 1.34 or above
and requires PHP 7.2 or above.
Next MLEB is expected to be released in 3 months. If there are very
important bug fixes, we will do an intermediate release. Please give
us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2021.01.tar…
* sha256sum: 4360572704369e5c1f02ab9df831dd0a6258cbcbae28c61c3c4a551347000b00
* Signature: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2021.01.tar…
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel, cldr, CleanChanges and LocalisationUpdate ==
* Localisation and maintenance updates only.
== Translate ==
* Add script to find unsynchronized definitions ({{Gerrit|655860}})
* Various improvements to the transaction export.php script
* Add a script to find and delete equal translations ({{Gerrit|652543}})
* GoogleTranslateWebService: Add Chinese codes to code map ({{Gerrit|649652}})
* Convert Special:ManageMessageGroups to OOUI ({{Gerrit|647670}})
* Insertables have been moved to the
src/TranslatorInterface/Insertable folder ({{Gerrit|644460}})
* Stop hiding page heading on pages other than Special:Translate
({{Gerrit|644514}})
* Drop non-array based configuration support for Insertables ({{Gerrit|644464}})
* Remove FCFontFinder ({{Gerrit|641189}})
* Bump group loader cache version to re-trigger re-caching of groups
({{Gerrit|644843}})
* Remove Gettext post processing support from export.php script
({{Gerrit|641385}})
== UniversalLanguageSelector ==
* Code refactoring & performance improvements
* Improve handling of opening links to new tab/window for compact
language links ({{Gerrit|639474}})
* Allow skins to register their own button and disable compact
language links ({{Phabricator|T264824}})
=== Fonts ===
* Add Boyo Gagrai for the Ho language in the Warang Citi script
({{Phabricator|T233301}})
--
Kartik Mistry | કાર્તિક મિસ્ત્રી
Hello, Please help me understand the following error I get when I add:
$wgProfiler['class'] = 'ProfilerXhprof';
$wgProfiler['output'] = [ 'ProfilerOutputText' ];
$wgProfiler['visible'] = true;
to my LocalSettings.php per [1] in order to enable "Profiling".
There error is:
"Fatal error: Uncaught Exception: Profiling is already enabled. in /opt/htdocs/mediawiki/includes/libs/Xhprof.php" and then it gives the stack trace [2].
When I disable the "class" line and such that the configuration is just:
$wgProfiler['output'] = [ 'ProfilerOutputText' ];
$wgProfiler['visible'] = true;
I get nothing added to my page to diagnose.
Any insights on this would be great. Thank you!
/Rich
[1] https://www.mediawiki.org/wiki/Manual:Profiling
[2] https://www.mediawiki.org/wiki/Topic:W1ywjmvgve8sk7hw
I'm running MediaWiki v1.34.2 on Linux Mint v20.1.
Three or four days ago I began getting emails like below.
(ImmigrantJohnLakeOfGravesend is my MediaWiki page.) I've received maybe
40-50 such messages. The error type is sometimes different. And
occasionally a message seems to be delivered because I receive a "real
looking" response.
Can someone tell me what's going on, and what I can do about it?
Date: Thu, 14 Jan 2021 05:36:39 -0800 (PST)
From: Mail Delivery Subsystem <mailer-daemon(a)googlemail.com>
To: MarshallELake(a)gmail.com
Subject: Delivery Status Notification (Failure)
Parts/Attachments:
1.1.1 OK 10 lines Text
1.1.2 Shown 38 lines Text
1.2 OK 2.2 KB Image
2 Shown 553 bytes Message, "Delivery Status"
3 Shown 3.3 KB Message, "ImmigrantJohnLakeOfGravesend email address confirmation"
3.1 Shown 15 lines Text
----------------------------------------
Error Icon
RECIPIENT INBOX FULL
Your message couldn't be delivered to
mikenealey23(a)from.crossandgarlic.com. Their inbox is full, or it's getting
too much mail right now.
The response from the remote server was:
550 Mailbox is full / Blocks limit exceeded / Inode limit exceeded
[ Part 1.2, Image/PNG (Name: "icon.png") 2.2 KB. ]
[ Not Shown. Use the "V" command to view or save this part. ]
[ Part 2: "Delivery Status" ]
Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; marshallelake(a)gmail.com
Arrival-Date: Thu, 14 Jan 2021 05:35:57 -0800 (PST)
X-Original-Message-ID:
<JohnLakeOfGravesend.600048bc47dc49.98376540(a)www.mlake.net>
Final-Recipient: rfc822; mikenealey23(a)from.crossandgarlic.com
Action: failed
Status: 5.0.0
Remote-MTA: dns; from.crossandgarlic.com (62.210.104.20, the server for
the domain.)
Diagnostic-Code: smtp; 550 Mailbox is full / Blocks limit exceeded / Inode
limit exceeded
Last-Attempt-Date: Thu, 14 Jan 2021 05:36:39 -0800 (PST)
[ Part 3: "Included Message" ]
Date: Thu, 14 Jan 2021 06:35:56 -0700
From: ImmigrantJohnLakeOfGravesend <marshallelake(a)gmail.com>
To: MikeNealey17 <mikenealey23(a)from.crossandgarlic.com>
Subject: ImmigrantJohnLakeOfGravesend email address confirmation
Someone, probably you, from IP address 104.160.17.148,
has registered an account "MikeNealey17" with this email address on
ImmigrantJohnLakeOfGravesend.
To confirm that this account really does belong to you and activate
email features on ImmigrantJohnLakeOfGravesend, open this link in your
browser:
http://www.mlake.net/wiki/index.php/Special:ConfirmEmail/89052005a33f772785…
If you did *not* register the account, follow this link
to cancel the email address confirmation:
http://www.mlake.net/wiki/index.php/Special:InvalidateEmail/89052005a33f772…
This confirmation code will expire at 06:35, 21 January 2021.
--
Marshall Lake -- marshallelake(a)gmail.com -- http://www.mlake.net