[MediaWiki-l] Mediawiki 1.39.5 updagrade and more Composer problems

[Jeffrey Walton]

Hi Everyone,

We are working on Ubuntu 20.04.6 LTS, x86_64, fully patched. Our
hosting provider does not offer Ubuntu 22 at the moment. Ubuntu 20
provides Composer 1.

I'm trying to upgrade from Mediawiki 1.39.4 to 1.39.5. During
`composer install --no-dev` I am seeing this error
(https://github.com/weidai11/website/blob/master/mediawiki/wiki-upgrade.txt#L117):

Does anyone know how to fix this:

  Problem 1
- Installation request for doctrine/dbal 3.4.2 -> satisfiable by
doctrine/dbal[3.4.2].
- doctrine/dbal 3.4.2 requires composer-runtime-api ^2 -> no
matching package found.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according
to your minimum-stability setting
   see 
for more details.
 - It's a private package and you forgot to add a custom repository to find it

Read  for
further common problems.
Running update with --no-dev does not mean require-dev is ignored, it
just means the packages will not be installed. If dev requirements are
blocking the update you have to resolve those problems.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Delete these wikis, please.

[Jeffrey Walton]

On Tue, Sep 19, 2023 at 1:41 PM bexafe4967--- via MediaWiki-l
 wrote:
>
> Hello, can someone delete these wikis, please?
>
> Please delete:
> 1. http://logosandtvguides.wiki-site.com
> 2. http://timelineoflogos.wiki-site.com
> 3. http://romaniantv.wiki-site.com
> 4. http://fictionalworld.wiki-site.com
>
> Reason: Unneeded.

You want the administrative and technical contacts below.

$ whois wiki-site.com
...

Domain Name: WIKI-SITE.COM
Registry Domain ID: 593108566_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.dynadot.com
Registrar URL: http://www.dynadot.com
Updated Date: 2023-06-04T10:58:13.0Z
Creation Date: 2006-09-14T15:15:08.0Z
Registrar Registration Expiration Date: 2024-09-14T15:15:08.0Z
Registrar: DYNADOT LLC
Registrar IANA ID: 472
Registrar Abuse Contact Email: ab...@dynadot.com
Registrar Abuse Contact Phone: +1.6502620100
Domain Status: clientTransferProhibited
Registry Registrant ID:
Registrant Name: Rami Addady
Registrant Street: keslev 6
Registrant City: Hod-Hasharon
Registrant State/Province: IL
Registrant Postal Code: 45219
Registrant Country: IL
Registrant Phone: +972.97464973
Registrant Email: r...@active.co.il
Registry Admin ID:
Admin Name: Rami Addady
Admin Street: keslev 6
Admin City: Hod-Hasharon
Admin State/Province: IL
Admin Postal Code: 45219
Admin Country: IL
Admin Phone: +972.97464973
Admin Email: r...@active.co.il
Registry Tech ID:
Tech Name: Rami Addady
Tech Street: keslev 6
Tech City: Hod-Hasharon
Tech State/Province: IL
Tech Postal Code: 45219
Tech Country: IL
Tech Phone: +972.97464973
Tech Email: r...@active.co.il
Name Server: ns1.active.co.il
Name Server: ns2.active.co.il
DNSSEC: unsigned
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Disable api.php and rest.php?

[Jeffrey Walton]

On Wed, Aug 23, 2023 at 10:16 PM Amir Sarabadani  wrote:
>
> You could technically decline access in apache (or whatever software you're 
> using).
>
> But I need to warn: Many functionalities of mediawiki are done by calling the 
> API in the backend, e.g. when you log out, it calls an API, when you watch a 
> page, it calls another API, and all of those would break if you disable the 
> api.php or rest.php

If I am understanding things correctly, it sounds like we should
disable the APIs on external interfaces, but allow them on internal
interfaces. For example, when a user clicks "logout", the controller
will invoke an API call. We want the controller to be able to call an
API. We don't want users to be able to call them.

How do we accomplish that?

Jeff

> Am Mi., 23. Aug. 2023 um 23:14 Uhr schrieb Jeffrey Walton 
> :
>>
>> I was looking at our Special:Version page, and got to thinking about
>> api.php [1] and rest.php.[2] I don't believe anyone on our team is
>> using the APIs, and I would like to disable them to reduce attack
>> surface. Or disable them on external interfaces (or maybe allow on
>> localhost/127.0.0.1).
>>
>> I see api.php can be disabled via $wgEnableAPI.[1] But I don't see a
>> similar option for rest.php.[2]
>>
>> I have two questions. First, is it possible to disable api.php and
>> rest.php in practice? Or restrict them to internal interfaces only?
>>
>> Second, what option controls rest.php?
>>
>> And maybe a third question, can we rename api.php and rest.php tosay,
>> api.php.unused and rest.php.unused? Will that produce ill effects?
>>
>> Thanks in advance.
>>
>> [1] https://www.mediawiki.org/wiki/Manual:Api.php
>> [2] https://www.mediawiki.org/wiki/Manual:Rest.php
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Disable api.php and rest.php?

[Jeffrey Walton]

Hi Everyone,

I was looking at our Special:Version page, and got to thinking about
api.php [1] and rest.php.[2] I don't believe anyone on our team is
using the APIs, and I would like to disable them to reduce attack
surface. Or disable them on external interfaces (or maybe allow on
localhost/127.0.0.1).

I see api.php can be disabled via $wgEnableAPI.[1] But I don't see a
similar option for rest.php.[2]

I have two questions. First, is it possible to disable api.php and
rest.php in practice? Or restrict them to internal interfaces only?

Second, what option controls rest.php?

And maybe a third question, can we rename api.php and rest.php tosay,
api.php.unused and rest.php.unused? Will that produce ill effects?

Thanks in advance.

[1] https://www.mediawiki.org/wiki/Manual:Api.php
[2] https://www.mediawiki.org/wiki/Manual:Rest.php
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: determine which Mediawiki component is using doctrine/dbal?

[Jeffrey Walton]

On Mon, Jul 3, 2023 at 2:50 PM Amir Sarabadani  wrote:
>
> Hi,
> Doctrine DBAL is only used for building the schema files out of abstract 
> schema changes (tables.json). If you don't do anything with database schema, 
> just remove it from require-dev or install it with --no-dev option (it's a 
> dev dependency not a production one)
>

Thanks Amir.

Why is it being installed with 'composer install --verbose --no-dev'?
We use `--no-dev`, which should avoid the development configurations.

If I have a misunderstanding of `--no-dev`, then how do I say
"Production/Release only"? This is a production server. We don't want
the development stuff polluting the box.

And finally, where do we remove it from? I don't remember installing it.

Jeff

> Am Mo., 3. Juli 2023 um 20:37 Uhr schrieb Jeffrey Walton :
>>
>> I'm trying to upgrade from Mediawiki 1.38 to Mediawiki 1.39 on Ubuntu
>> 20.04 LTS, x96_64, LTS. Ubuntu 20 provides Composer 1.
>>
>> When I run 'composer install --verbose --no-dev' I get this error:
>>
>> 
>>   Problem 1
>> - Installation request for doctrine/dbal 3.4.2 -> satisfiable by
>> doctrine/dbal[3.4.2].
>> - doctrine/dbal 3.4.2 requires composer-runtime-api ^2 -> no
>> matching package found.
>>
>> Potential causes:
>>  - A typo in the package name
>>  - The package is not available in a stable-enough version according
>> to your minimum-stability setting
>>see <https://getcomposer.org/doc/04-schema.md#minimum-stability>
>> for more details.
>>  - It's a private package and you forgot to add a custom repository to find 
>> it
>> 
>>
>> I want to remove whatever is using doctrine/dbal.
>>
>> How do I determine which Mediawiki component is using doctrine/dbal?
>>
>> Thanks in advance.
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] determine which Mediawiki component is using doctrine/dbal?

[Jeffrey Walton]

I'm trying to upgrade from Mediawiki 1.38 to Mediawiki 1.39 on Ubuntu
20.04 LTS, x96_64, LTS. Ubuntu 20 provides Composer 1.

When I run 'composer install --verbose --no-dev' I get this error:


  Problem 1
- Installation request for doctrine/dbal 3.4.2 -> satisfiable by
doctrine/dbal[3.4.2].
- doctrine/dbal 3.4.2 requires composer-runtime-api ^2 -> no
matching package found.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according
to your minimum-stability setting
   see 
for more details.
 - It's a private package and you forgot to add a custom repository to find it


I want to remove whatever is using doctrine/dbal.

How do I determine which Mediawiki component is using doctrine/dbal?

Thanks in advance.
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: MediaWiki 1.38 is End of Life

[Jeffrey Walton]

On Fri, Jun 30, 2023 at 3:04 PM Brian Wolff  wrote:
>
> You could install composer from its official website instead of using the 
> system package manager. It can be downloaded as a single .phar file.

Thanks Brian.

We don't want to switch hosting providers or download third party
stuff. In the case of Composer, we don't have the expertise to
evaluate it. Hence we rely on the distro.

(I personally don't trust Composer because it is willing to run
arbitrary code. It's very sloppy in its security practices).

Jeff

> On Fri, Jun 30, 2023 at 11:42 AM Jeffrey Walton  wrote:
>>
>> On Fri, Jun 30, 2023 at 12:47 PM Sam Reed  wrote:
>> >
>> > As per the MediaWiki version lifecycle[1], I would like to announce the 
>> > formal end of life (EOL) of MediaWiki 1.38 as of today, Friday June 30, 
>> > 2023.
>> >
>> > 1.38.7 is expected to be the last release for this branch.
>> >
>> > This means that MediaWiki 1.38 will no longer receive maintenance or 
>> > security backports. It is therefore strongly discouraged that you continue 
>> > to use it.
>> >
>> > It is recommended to upgrade either to MediaWiki 1.39 (LTS), which will be 
>> > supported until November 2025 or to 1.40 (released today), which will be 
>> > supported until June 2024.
>>
>> Is there a path available to folks who use MW 1.38 and have hosting
>> providers that only offer Ubuntu 20.04 with Composer 1? My testing
>> revealed we could not update to MW 1.39 because of the Composer 2
>> requirement.
>>
>> I think our options are... we need to wait until our hosting provider
>> offers Ubuntu 22.04, or MediaWiki drops the Composer 2 requirement for
>> MW 1.39.
>>
>> It is an uncomfortable position to be in.
>>
>> Jeff
>> ___
>> MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
>> To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
>> https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: MediaWiki 1.38 is End of Life

[Jeffrey Walton]

On Fri, Jun 30, 2023 at 12:47 PM Sam Reed  wrote:
>
> As per the MediaWiki version lifecycle[1], I would like to announce the 
> formal end of life (EOL) of MediaWiki 1.38 as of today, Friday June 30, 2023.
>
> 1.38.7 is expected to be the last release for this branch.
>
> This means that MediaWiki 1.38 will no longer receive maintenance or security 
> backports. It is therefore strongly discouraged that you continue to use it.
>
> It is recommended to upgrade either to MediaWiki 1.39 (LTS), which will be 
> supported until November 2025 or to 1.40 (released today), which will be 
> supported until June 2024.

Is there a path available to folks who use MW 1.38 and have hosting
providers that only offer Ubuntu 20.04 with Composer 1? My testing
revealed we could not update to MW 1.39 because of the Composer 2
requirement.

I think our options are... we need to wait until our hosting provider
offers Ubuntu 22.04, or MediaWiki drops the Composer 2 requirement for
MW 1.39.

It is an uncomfortable position to be in.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: MySQL backup and consistency of database and dump file

[Jeffrey Walton]

On Sat, Apr 1, 2023 at 2:21 AM Benjamin Lees  wrote:
>
> --lock-tables is enabled by default for mysqldump.  --single-transaction 
> offers a way to get a consistent dump without locking tables, but the tables 
> have to support transactions (which InnoDB does and MyISAM does not).  You 
> should probably use --single-transaction if you can.
>
> The mediawiki.org article you reference tries to ensure consistency by having 
> you set $wgReadOnly to prevent writes to the database (at least from within 
> MediaWiki core).  I'm not sure how much effect it actually has, given that 
> --lock-tables is enabled by default, but it's been on the page for 15 years, 
> so it must be right. :)

Thanks Benjamin.

I updated the Mediawiki backup article at [1]. I felt like the
discussion of Mysqldump was missing some important details. I used
configuration options we have been using for our backup script [2].

This is not my area of expertise. Please fix errors and omissions in
the article. And my apologies in advance.

Jeff

[1] https://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki
[2] https://github.com/weidai11/website/blob/master/systemd/bitvise-backup

> On Sat, Apr 1, 2023 at 1:20 AM Jeffrey Walton  wrote:
>>
>> Hi Everyone,
>>
>> We are trying to workaround failed backups due to
>> https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/2003866 . We
>> used to use --single-transaction, but the option now requires RELOAD
>> or FLUSH_TABLES. We failed to enable the privileges for the mwuser.
>>
>> MediaWiki's backup documentation is at
>> https://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki . Here is the
>> command MediaWiki recommends:
>>
>> mysqldump -h hostname -u userid -p \
>> --default-character-set=whatever dbname > backup.sql
>>
>> But the article does not discuss how to ensure consistency for the
>> database and dump file. For MySQL, that should be --single-transaction
>> or --lock-tables. (If I am reading the MySQL documentation correctly).
>>
>> My question is, what should we use to ensure consistency of the dump file?
>>
>> --single-transaction or --lock-tables or something else?
>>
>> Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] MySQL backup and consistency of database and dump file

[Jeffrey Walton]

Hi Everyone,

We are trying to workaround failed backups due to
https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/2003866 . We
used to use --single-transaction, but the option now requires RELOAD
or FLUSH_TABLES. We failed to enable the privileges for the mwuser.

MediaWiki's backup documentation is at
https://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki . Here is the
command MediaWiki recommends:

mysqldump -h hostname -u userid -p \
--default-character-set=whatever dbname > backup.sql

But the article does not discuss how to ensure consistency for the
database and dump file. For MySQL, that should be --single-transaction
or --lock-tables. (If I am reading the MySQL documentation correctly).

My question is, what should we use to ensure consistency of the dump file?

--single-transaction or --lock-tables or something else?

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: MediaWiki backup failures due to mysqldump

[Jeffrey Walton]

Thanks Brian,

> However the error message suggests something beyond that is going on.

Yeah, that would not surprise me. The initial MySQL database and
mwuser was setup around 2005 or so. It probably missed a lot of
improvements over the years. I don't want to mess with it any more
than necessary because I'm not a MySQL admin. I don't know how to fix
it.

Jeff

On Fri, Mar 31, 2023 at 2:47 AM Brian Wolff  wrote:
>
> I don't know about the error message, but RELOAD is a global right. I dont 
> think you are allowed to grant it to just a specific database instead of all 
> of mysql.
>
> However the error message suggests something beyond that is going on.
>
>
> On Thursday, March 30, 2023, Jeffrey Walton  wrote:
>>
>> Hi Everyone,
>>
>> A quick heads up for others in this situation... We attempted to
>> migrate to MW 1.38.6 tonight. Our first step is a manual backup.
>>
>> We found our manual backup (and backups for the last couple of months)
>> have been failing (yuk!):
>>
>> # /sbin/mw-backup
>> Repair wiki database ok
>> mysqldump: Couldn't execute 'FLUSH TABLES': Access denied; you need
>> (at least one of) the RELOAD or FLUSH_TABLES privilege(s) for this
>> operation (1227)
>> Failed to dump wiki database
>>
>> It appears this is a known issue on Ubuntu:
>> https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/2003866
>>
>> In our case, workarounds like adding RELOAD or FLUSH_TABLES to the
>> backup user also failed:
>>
>> mysql> GRANT FLUSH_TABLES ON my_wiki.* TO 'mwuser'@'%';
>> ERROR 3619 (HY000): Illegal privilege level specified for FLUSH_TABLES
>> mysql> GRANT RELOAD ON my_wiki.* TO 'mwuser'@'%';
>> ERROR 1410 (42000): You are not allowed to create a user with GRANT
>>
>> We reached our limit of knowledge for MySQL administration. I think we
>> will have to wait until the Ubuntu 2003866 bug is fixed.
>>
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] MediaWiki backup failures due to mysqldump

[Jeffrey Walton]

Hi Everyone,

A quick heads up for others in this situation... We attempted to
migrate to MW 1.38.6 tonight. Our first step is a manual backup.

We found our manual backup (and backups for the last couple of months)
have been failing (yuk!):

# /sbin/mw-backup
Repair wiki database ok
mysqldump: Couldn't execute 'FLUSH TABLES': Access denied; you need
(at least one of) the RELOAD or FLUSH_TABLES privilege(s) for this
operation (1227)
Failed to dump wiki database

It appears this is a known issue on Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/2003866

In our case, workarounds like adding RELOAD or FLUSH_TABLES to the
backup user also failed:

mysql> GRANT FLUSH_TABLES ON my_wiki.* TO 'mwuser'@'%';
ERROR 3619 (HY000): Illegal privilege level specified for FLUSH_TABLES
mysql> GRANT RELOAD ON my_wiki.* TO 'mwuser'@'%';
ERROR 1410 (42000): You are not allowed to create a user with GRANT

We reached our limit of knowledge for MySQL administration. I think we
will have to wait until the Ubuntu 2003866 bug is fixed.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: array syntax

[Jeffrey Walton]

On Tue, Feb 14, 2023 at 3:30 PM Bartosz Dziewoński  wrote:
>
> "NS_FILE" was introduced to replace "NS_IMAGE" in MediaWiki 1.14, which
> was released in 2009, fourteen years ago.

And in 14 years, Mediawiki has never warned users about it.

The first time we learn about these things in practice is when
something breaks. Usually after an upgrade.

The devs really need to supply a linter that we can run on
LocalSettings.php so we can discover the problems earlier than "it
broke after an upgrade." And hopefully the linter will suggest the
next step, like renaming NS_IMAGE to NS_FILE.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: array syntax

[Jeffrey Walton]

On Tue, Feb 14, 2023 at 1:57 PM Bartosz Dziewoński  wrote:
>
> The "NS_IMAGE" constant, which you use in your LocalSettings.php, has
> been replaced by "NS_FILE" and removed in MediaWiki 1.34 (a while ago).
> It looks like PHP 7.4 was just ignoring it (and presumably some of the
> configuration you intended for the Image/File namespace was not applying
> correctly), but PHP 8 treats it as an error.
>
> The solution is to just replace all occurrences of NS_IMAGE with NS_FILE
> (and NS_IMAGE_TALK with NS_FILE_TALK).
>
> (Congrats on running MediaWiki for long enough that your configuration
> still used NS_IMAGE ;) )

This is a recurring problem with LocalSettings.php. The devs keep
changing stuff and breaking things. I can't count how many times we've
had to fix unexpected breaks. (Our wiki and LocalSettings.php dates
back to 2005).

Welcome to the world of software development by web developers. Things
are only expected to last 6 months. It's worse than an automobile in
the salt belt.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: How to upgrade old MW Postgres DB backup into much newer MW version?

[Jeffrey Walton]

On Tue, Jan 10, 2023 at 11:50 AM MI  wrote:
>
> We had Mediawiki with PostgreSQL on a Debian 8 server. That machine is
> no longer accessible, but there is a backup of the database.
>
> The old versions were:
> - Postgres v. 9.4
> - Mediawiki v. 1.25 or 1.27 ?
>
> Now we installed Mediawiki and PostgreSQL on a new Debian 11 server. But
> the database schema seems to be quite different so it will not be
> possible to import the backup directly.
>
> Our current versions on Debian 11 are from the "stable" ("bullseye") apt
> repository:
> - Mediawiki  v. 1.35.8
> - Postgresql v. 13.9
>
> Is there a collection of database upgrade scripts somewhere, which I
> could use to upgrade, step by step, our backup DB to the current schema?
> (The import of the SQL backup into Postgres v. 13 works fine. But then
> the schema needs to be adapted to what MW expects)

My non-official answer...

Restore the backup into a VM for testing. Download MW 1.38 and unpack. Then run:

   # Update Mediawiki components
   php -d extension=phar.so composer.phar update --no-dev
   # Update the database
   php /var/www/html/w/maintenance/update.php --quick

If the update script succeeds, then you should be Ok in real life.

If the update fails, then you may need to try incrementally. Proceed
in sequence: 1.27 to 1.28, 1.28 to 1.29, ..., 1.34 to 1.35.

Related to the upgrade process, the steps we perform for our webserver
is located at 
https://github.com/weidai11/website/blob/master/mediawiki/wiki-upgrade.txt
. We try to follow Mediawiki releases, so we proceeded in sequence
over years of time.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Problem migrating from 1.38.5 to 1.39.1 due to Composer dependencies

[Jeffrey Walton]

On Tue, Dec 27, 2022 at 2:26 PM Bartosz Dziewoński  wrote:
>
> MediaWiki requires Composer 2 and will not work with Composer 1 any
> more. I have ran into the same issue myself
> (https://github.com/MatmaRex/patchdemo/issues/501).
>
> It's not clear to me whether this is a bug or an intentional
> compatibility break. Looks like
> https://phabricator.wikimedia.org/T316556 is a bug report about this,
> but it's also connected to a task about dropping compatibility, so I
> wouldn't hold my breath waiting for it to be fixed.
>
> You will need to either:
>
> * Upgrade your Ubuntu to a version that ships with Composer 2 – looking
> at https://packages.ubuntu.com/search?keywords=composer , that would be
> Ubuntu 22.04 Jammy.
>
> * Or install Composer 2 manually instead of from the system repositories
> – https://getcomposer.org/download/

Thanks Bartosz .

Its unfortunate 1.39 is a LTS but it was not well tested.

(We can't upgrade to Jammy because our web host does not provide
it.[1] Our only options are at the moment are Ubuntu 20.04, Ubuntu
18.04, CentOS 8, CentOS 7, Debian 10, Debian 9, OpenSuse Leap 15)

Jeff

[1] https://www.ionos.com/servers/vps
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Problem migrating from 1.38.5 to 1.39.1 due to Composer dependencies

[Jeffrey Walton]

Hi Everyone,

We are trying to migrate from Mediawiki 1.38.5 to 1.39.1. The
webserver is Ubuntu 20.04.5 LTS, x86_64, fully patched.

At the step of installing Composer with its dependencies,[1] 'composer
install' is dying with the error message:


Your requirements could not be resolved to an installable set of packages.

  Problem 1
- Installation request for doctrine/dbal 3.4.2 -> satisfiable by
doctrine/dbal[3.4.2].
- doctrine/dbal 3.4.2 requires composer-runtime-api ^2 -> no
matching package found.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according
to your minimum-stability setting
   see 
for more details.
 - It's a private package and you forgot to add a custom repository to find it


We are running the latest version of Composer:

   # apt-cache search composer | sort
   ...
   composer - dependency manager for PHP

And:

   # apt-cache show composer
   Package: composer
   Architecture: all
   Version: 1.10.1-1
   Priority: optional
   Section: universe/php
   Origin: Ubuntu
   ...

Please advise on how to proceed.

Thanks in advance,

Jeff

[1] 
https://github.com/weidai11/website/blob/master/mediawiki/wiki-upgrade.txt#L104
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Special:PasswordPolicies

[Jeffrey Walton]

Hi Everyone,

I was wandering through
https://www.cryptopp.com/wiki/Special:PasswordPolicies , which comes
from Mediawiki 1.38.2.

The first line for Autoconfirmed Users says:

Password must be at least 1 character long
(MinimalPasswordLength) (suggest change on login)

I think there are several problems with the page in general and text
in particular. First, a 1 character password is not really acceptable
in practice. It is probably time to increase the size of a minimum
password, to something like 16.

Second, the referenced variable, MinimalPasswordLength, is deprecated.
Or $wgMinimalPasswordLength is deprecated.
https://www.mediawiki.org/wiki/Manual:$wgMinimalPasswordLength

It might be a good idea for someone to visit the documentation for
Special:PasswordPolicies and maybe update it.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Create an account for another user

[Jeffrey Walton]

Hi Everyone,

We disabled account creation due to too much spam and bots. I am
trying to manually create an account for a user. I read the docs at
[1] and visited Special:CreateAccount. I then entered the user's
details.

I have not submitted because I'm getting a message:

Your username will be adjusted to "XX"
due to technical restrictions.

I am not sure why I am getting that message. I am trying to create an
account for another user. I am not trying to change my user name.

I have all the wiki privileges and rights. They include bureaucrat and
administrator.

Does anyone know how to proceed?

Thanks,

Jeff

[1] https://www.mediawiki.org/wiki/Manual:Account_creation
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Unable to upgrade to 1.38.x from 1.37.x

[Jeffrey Walton]

On Mon, Jul 4, 2022 at 12:45 PM Jeffrey T. Darlington
 wrote:
>
> ...
> Most often when I get bit by a MediaWiki issue, it's situations like this, 
> where some ancient setting installed 14 years ago falls out of scope.  It's 
> not exactly reasonable to ask users to go digging through 21 major(?) 
> versions of release notes to figure out that something changed 11 years ago 
> and the current version breaks it.  Then again, I don't have any good 
> suggestions on how to improve that situation either.  I maintain sites and 
> APIs that others call, and deprecating old code is both necessary and 
> trouble-inducing.  Just... venting some frustration here.

It would be helpful if Mediawiki put a new LocalSettings.php in the
tarball so we can see what a modern one looks like.

Our upgrade process [1] makes provisions for a Mediawiki-distributed
LocalSettings.php, but one is never provided. Our process says to copy
Mediawiki's tarball LocalSettings.php to LocalSettings.php.orig to
preserve a pristine one for reference. But when things go sideways we
never have a reference to check.

Reusing an existing LocalSettings.php is part of Mediawiki's published
upgrade process. [2] "Adapt your LocalSettings.php" is not really
helpful. [3] For example, it did not tell us to remove a call to
DefaultSettings.php from our LocalSettings.php.

[1] https://github.com/weidai11/website/blob/master/mediawiki/wiki-upgrade.txt
[2] https://www.mediawiki.org/wiki/Manual:Upgrading#Other_files
[3] https://www.mediawiki.org/wiki/Manual:Upgrading#Adapt_your_LocalSettings.php

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Unable to upgrade to 1.38.2 from 1.36.4

[Jeffrey Walton]

On Sun, Jul 3, 2022 at 6:41 PM Jeffrey Walton  wrote:
>
> We are trying to upgrade our Mediawiki from 1.36.4 to 1.38.2. After
> unpacking 1.38 to /var/www/html/w, and while running update.php, we
> encounter:
>
> # /var/www/html/w# php /var/www/html/w/maintenance/update.php --quick
> PHP Fatal error:  Uncaught Exception: Unable to open file
> /ParserFunctions/extension.json:
> filemtime(): stat failed for /ParserFunctions/extension.json in
> /var/www/html/w/includes/
> registration/ExtensionRegistry.php:182
> Stack trace:
> #0 /var/www/html/w/includes/GlobalFunctions.php(52): 
> ExtensionRegistry->queue()
> #1 /var/www/html/w/LocalSettings.php(206): wfLoadExtension()
> #2 /var/www/html/w/includes/Setup.php(204): require_once('/var/www/html/w...')
> #3 /var/www/html/w/maintenance/doMaintenance.php(96):
> require_once('/var/www/html/w...')
> #4 /var/www/html/w/maintenance/update.php(264):
> require_once('/var/www/html/w...')
> #5 {main}
>  thrown in /var/www/html/w/includes/registration/ExtensionRegistry.php
> on line 182
>
> After we commented out every offending line in LocalSettings.php
> (which included most (all?) added-on extensions, like ParserFunctions,
> GlobalFunctions, Gadgets, Admin, SimpleMathJax, EmailInvite), we are
> still left with:
>
> # /var/www/html/w# php /var/www/html/w/maintenance/update.php --quick
> PHP Fatal error:  Uncaught FatalError: $wgBaseDirectory must not be
> modified in settings f
> iles! Use the MW_INSTALL_PATH environment variable to override the
> installation root direc
> tory. in /var/www/html/w/includes/Setup.php:237
> Stack trace:
> #0 /var/www/html/w/maintenance/doMaintenance.php(96): require_once()
> #1 /var/www/html/w/maintenance/update.php(264):
> require_once('/var/www/html/w...')
> #2 {main}
>  thrown in /var/www/html/w/includes/Setup.php on line 237
>
> Fatal error: Uncaught FatalError: $wgBaseDirectory must not be
> modified in settings files!
> Use the MW_INSTALL_PATH environment variable to override the
> installation root directory.
> in /var/www/html/w/includes/Setup.php:237
> Stack trace:
> #0 /var/www/html/w/maintenance/doMaintenance.php(96): require_once()
> #1 /var/www/html/w/maintenance/update.php(264):
> require_once('/var/www/html/w...')
> #2 {main}
>  thrown in /var/www/html/w/includes/Setup.php on line 237
>
> We are not setting $IP in our LocalSettings.php (as others have
> suggested is a problem).
>
> We are left to wonder... why doesn't this stuff just work? If we are
> forced to upgrade on Mediawiki's cadence, the least you could do is
> ensure there's an upgrade path.
>
> We are really struggling with the upgrade problems. Any help would be
> greatly appreciated.

I filed abug report on Phabricator at https://phabricator.wikimedia.org/T311966

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Unable to upgrade to 1.38.x from 1.37.x

[Jeffrey Walton]

On Sun, Jul 3, 2022 at 7:09 PM Jeffrey Walton  wrote:
>
> On Sun, Jul 3, 2022 at 6:57 PM Jeffrey T. Darlington
>  wrote:
> >
> > Each time I upgrade, I unzip the archive to a new directory and copy over 
> > the images and extensions.  So I've been using the "core" version of Vector 
> > for a while.  That said, commenting out the line with wfLoadSkin('Vector') 
> > still generates the following error:
> >
> > 
> > PHP Fatal error:  Uncaught FatalError: $wgBaseDirectory must not be 
> > modified in settings files! Use the MW_INSTALL_PATH environment variable to 
> > override the installation root directory. in 
> > /var/www/gpf/mediawiki-1.38.2/includes/Setup.php:237
> > Stack trace:
> > #0 /var/www/gpf/mediawiki-1.38.2/maintenance/doMaintenance.php(96): 
> > require_once()
> > #1 /var/www/gpf/mediawiki-1.38.2/maintenance/update.php(264): 
> > require_once('/var/www/gpf/me...')
> > #2 {main}
> >   thrown in /var/www/gpf/mediawiki-1.38.2/includes/Setup.php on line 237
> > 
> >
> > I'm not modifying $wgBaseDirectory anywhere in my LocalSettings.php, so I 
> > don't see why it would be generating this error.  (Note that all of the 
> > files in the stack trace are MediaWiki internal files.)
>
> Yeah, we are at this point, too. We experience the error but don't
> know how to proceed.
>
> I'm backing out of the MW 1.38 upgrade now. We can't proceed until the
> Foundation fixes something.

I filed abug report on Phabricator at https://phabricator.wikimedia.org/T311966

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Unable to upgrade to 1.38.x from 1.37.x

[Jeffrey Walton]

On Sun, Jul 3, 2022 at 6:57 PM Jeffrey T. Darlington
 wrote:
>
> Each time I upgrade, I unzip the archive to a new directory and copy over the 
> images and extensions.  So I've been using the "core" version of Vector for a 
> while.  That said, commenting out the line with wfLoadSkin('Vector') still 
> generates the following error:
>
> 
> PHP Fatal error:  Uncaught FatalError: $wgBaseDirectory must not be modified 
> in settings files! Use the MW_INSTALL_PATH environment variable to override 
> the installation root directory. in 
> /var/www/gpf/mediawiki-1.38.2/includes/Setup.php:237
> Stack trace:
> #0 /var/www/gpf/mediawiki-1.38.2/maintenance/doMaintenance.php(96): 
> require_once()
> #1 /var/www/gpf/mediawiki-1.38.2/maintenance/update.php(264): 
> require_once('/var/www/gpf/me...')
> #2 {main}
>   thrown in /var/www/gpf/mediawiki-1.38.2/includes/Setup.php on line 237
> 
>
> I'm not modifying $wgBaseDirectory anywhere in my LocalSettings.php, so I 
> don't see why it would be generating this error.  (Note that all of the files 
> in the stack trace are MediaWiki internal files.)

One thing I noticed is, we did not have problems with Skins but you
did. (We had problems with Extensions).

Our LocalSettings.php has this, which may explain why we had no
problems with Skins:

$wgStylePath= "$wgScriptPath/skins";
$wgStyleDirectory   = "$IP/skins";

According to the manual at
https://www.mediawiki.org/wiki/Manual:$wgStyleDirectory,
wgStyleDirectory is set to null in 1.38. This is new behavior for
1.38.

Maybe you need to set $wgStyleDirectory and that will fix the problems
with your skins.

(I still can't explain our problem with Extensions. Maybe I need to
set $wgExtensionDirectory. The manual says it is null in
1.38.Previously it was set to "$IP/extensions").

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Unable to upgrade to 1.38.x from 1.37.x

[Jeffrey Walton]

On Sun, Jul 3, 2022 at 6:57 PM Jeffrey T. Darlington
 wrote:
>
> Each time I upgrade, I unzip the archive to a new directory and copy over the 
> images and extensions.  So I've been using the "core" version of Vector for a 
> while.  That said, commenting out the line with wfLoadSkin('Vector') still 
> generates the following error:
>
> 
> PHP Fatal error:  Uncaught FatalError: $wgBaseDirectory must not be modified 
> in settings files! Use the MW_INSTALL_PATH environment variable to override 
> the installation root directory. in 
> /var/www/gpf/mediawiki-1.38.2/includes/Setup.php:237
> Stack trace:
> #0 /var/www/gpf/mediawiki-1.38.2/maintenance/doMaintenance.php(96): 
> require_once()
> #1 /var/www/gpf/mediawiki-1.38.2/maintenance/update.php(264): 
> require_once('/var/www/gpf/me...')
> #2 {main}
>   thrown in /var/www/gpf/mediawiki-1.38.2/includes/Setup.php on line 237
> 
>
> I'm not modifying $wgBaseDirectory anywhere in my LocalSettings.php, so I 
> don't see why it would be generating this error.  (Note that all of the files 
> in the stack trace are MediaWiki internal files.)
>

Yeah, we are at this point, too. We experience the error but don't
know how to proceed.

I'm backing out of the MW 1.38 upgrade now. We can't proceed until the
Foundation fixes something.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Unable to upgrade to 1.38.x from 1.37.x

[Jeffrey Walton]

On Sun, Jul 3, 2022 at 6:19 PM Jeffrey T. Darlington
 wrote:
>
> Thanks for the suggestions, but no luck here.  I did indeed have the old "$IP 
> = MW_INSTALL_PATH" block.  But if I comment that out, I still get the same 
> "Unable to open file /Vector/skin.json" error.  Same goes for the 
> "$wgBaseDirectory = MW_INSTALL_PATH" suggestion; that gives me the 
> "$wgBaseDirectory must not be modified in settings files!" error.  Neither 
> option seems to work for me.

I _think_ Vector became part of Core awhile back. Do you have a Vector
in your skins/ directory? If so, you may want to delete it. If not,
look at the offending line in LocalSettings.php, and comment it out.
The stack trace will tell you the offending line in LocalSettings.php.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Unable to upgrade to 1.38.2 from 1.36.4

[Jeffrey Walton]

Hi Everyone,

We are trying to upgrade our Mediawiki from 1.36.4 to 1.38.2. After
unpacking 1.38 to /var/www/html/w, and while running update.php, we
encounter:

# /var/www/html/w# php /var/www/html/w/maintenance/update.php --quick
PHP Fatal error:  Uncaught Exception: Unable to open file
/ParserFunctions/extension.json:
filemtime(): stat failed for /ParserFunctions/extension.json in
/var/www/html/w/includes/
registration/ExtensionRegistry.php:182
Stack trace:
#0 /var/www/html/w/includes/GlobalFunctions.php(52): ExtensionRegistry->queue()
#1 /var/www/html/w/LocalSettings.php(206): wfLoadExtension()
#2 /var/www/html/w/includes/Setup.php(204): require_once('/var/www/html/w...')
#3 /var/www/html/w/maintenance/doMaintenance.php(96):
require_once('/var/www/html/w...')
#4 /var/www/html/w/maintenance/update.php(264):
require_once('/var/www/html/w...')
#5 {main}
 thrown in /var/www/html/w/includes/registration/ExtensionRegistry.php
on line 182

After we commented out every offending line in LocalSettings.php
(which included most (all?) added-on extensions, like ParserFunctions,
GlobalFunctions, Gadgets, Admin, SimpleMathJax, EmailInvite), we are
still left with:

# /var/www/html/w# php /var/www/html/w/maintenance/update.php --quick
PHP Fatal error:  Uncaught FatalError: $wgBaseDirectory must not be
modified in settings f
iles! Use the MW_INSTALL_PATH environment variable to override the
installation root direc
tory. in /var/www/html/w/includes/Setup.php:237
Stack trace:
#0 /var/www/html/w/maintenance/doMaintenance.php(96): require_once()
#1 /var/www/html/w/maintenance/update.php(264):
require_once('/var/www/html/w...')
#2 {main}
 thrown in /var/www/html/w/includes/Setup.php on line 237

Fatal error: Uncaught FatalError: $wgBaseDirectory must not be
modified in settings files!
Use the MW_INSTALL_PATH environment variable to override the
installation root directory.
in /var/www/html/w/includes/Setup.php:237
Stack trace:
#0 /var/www/html/w/maintenance/doMaintenance.php(96): require_once()
#1 /var/www/html/w/maintenance/update.php(264):
require_once('/var/www/html/w...')
#2 {main}
 thrown in /var/www/html/w/includes/Setup.php on line 237

We are not setting $IP in our LocalSettings.php (as others have
suggested is a problem).

We are left to wonder... why doesn't this stuff just work? If we are
forced to upgrade on Mediawiki's cadence, the least you could do is
ensure there's an upgrade path.

We are really struggling with the upgrade problems. Any help would be
greatly appreciated.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: user login issue after upgrade to 1.37.2

[Jeffrey Walton]

On Fri, May 13, 2022 at 1:14 AM Toshi Esumi  wrote:
>
> On 5/12/22 04:31, Jeffrey Walton wrote:
> >
> > I ran into this issue (or a very similar issue) several years ago. Or
> > I had the same symptoms. Verify $wgServer matches the server name in
> > httpd.conf .
> > ...
>
> Thanks Jeff. It was spot on.
>
> First I didn't know they needed to match and I changed $wgServer side
> only. Also I recently installed a certificate to add SSL support then
> forgot to update to $wgServer = https://...

Glad to hear it. It took us a couple of days to work out the problem
when we experienced it.

I _think_ what happened was, the server was serving pages that
violated the browser's Same Origin Policy (SOP). So you would login
over https using host example.com, and then you would get a http page
from www.example.com and that would blow away the cookie.

In the browser's security model, an origin is a {protocol, host, port}
triplet. All requests have to use the same origin. Switching between
http and https, and switching between hosts example.com and
www.example.com would muck things up.

That's why $wgServer, $wgCanonicalServer, ServerName and ServerAlias
had to line-up properly.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: user login issue after upgrade to 1.37.2

[Jeffrey Walton]

On Thu, May 12, 2022 at 1:16 AM Toshi Esumi  wrote:
>
> I successfully upgraded/migrated my old wiki 1.26.0 to a new wiki 1.37.2
> about a month ago. But now I realized I couldn't log in the wiki to edit
> content. I was not sure what my old user password was but assuming the
> old password was less than 8 chars. So I used changePassword.php to
> reset my password and set a new one longer than 8 chars.
>
> But when I used it to log in my wiki, it seems to accept but goes back
> to original page with only "Log in" link on the top right corner, which
> means I'm not logged in. I immediately checked LocalSettings.php if
> $wgReadOnly was still configured after the upgrade, which was commented
> out with the leading '#'.
>
> What could cause this behavior of the wiki?

I ran into this issue (or a very similar issue) several years ago. Or
I had the same symptoms. Verify $wgServer matches the server name in
httpd.conf .

MediaWiki 1.34 changed the default value to '$wgServer = false;' I
think that's what broke logins for us. Also see
https://www.mediawiki.org/wiki/Manual:$wgServer .

Here are my notes in LocalSettings.php and httpd.conf:

$ cat LocalSettings.php
...
# Protocol-relative URLs. The server will serve over HTTP or
#   HTTPS, depending on what the user requested. $wgServer must
#   match the server name in httpd.conf or login will break
$wgServer   = '//www.cryptopp.com';
$wgCanonicalServer  = 'https://www.cryptopp.com';
$wgSitename = 'Crypto++ Wiki';

# Security related administrivia
$wgSecureLogin  = true;
$wgCookieHttpOnly   = true;
$wgCookieSecure = 'detect';

And:

# cat /etc/apache2/sites-enabled/cryptopp.conf

...
ServerName cryptopp.com
ServerAlias www.cryptopp.com *.cryptopp.com

# https://linuxize.com/post/redirect-http-to-https-in-apache/
Redirect permanent / https://cryptopp.com/
...

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: upbrade database mysql 5.5.62 -> MariaDB 10.3.34

[Jeffrey Walton]

On Fri, Apr 8, 2022 at 1:47 AM Toshi Esumi  wrote:
>
> I'm trying to upgrade/migrate my mediawiki from my old Ubuntu VM 14.04
> to a new Ubuntu VM 20.04. The detail of the components are below. I
> managed to set up a new mediawiki 1.37.2 with MariaDB at the new VM and
> copied images directory tree and converted LocalSettings.php to make it
> workable but when I restored mysql DB into mariaDB with "mysql -u root
> -p toshiwiki(my DB name) < toshiwikibackup.sql", I got "Database error"
> at the main page with the detail below:
>
> [a50bfc1261fc29c06a343aec] 2022-04-08 05:32:47: Fatal exception of type
> "Wikimedia\Rdbms\DBQueryError"

Related, we have a lot of luck using mysqldump to backup our wiki
database. I have tested the restores and they are Ok.
https://github.com/weidai11/website/blob/master/systemd/bitvise-backup#L80
and https://stackoverflow.com/q/105776.

I have not tested a MySQL backup followed by a MariaDB restore.

You might try it and see if it works for you.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Lots of PHP Deprecated in Mediawiki 1.36.4

[Jeffrey Walton]

After a migration to Mediawiki 1.36.4, running maintenance scripts
produces a lot of noise. For example:

Running rebuildFileCache.php
PHP Deprecated:  Premature access to service container [Called from
RebuildFileCache::finalSetup in
/var/www/html/w/maintenance/rebuildFileCache.php at line 53] in
/var/www/html/w/includes/debug/MWDebug.php on line 376

Deprecated: Premature access to service container [Called from
RebuildFileCache::finalSetup in
/var/www/html/w/maintenance/rebuildFileCache.php at line 53] in
/var/www/html/w/includes/debug/MWDebug.php on line 376
PHP Deprecated:  Premature access to service 'HookContainer' [Called
from MediaWiki\MediaWikiServices::getInstance in
/var/www/html/w/includes/MediaWikiServices.php at line 252] in
/var/www/html/w/includes/debug/MWDebug.php on line 376

Deprecated: Premature access to service 'HookContainer' [Called from
MediaWiki\MediaWikiServices::getInstance in
/var/www/html/w/includes/MediaWikiServices.php at line 252] in
/var/www/html/w/includes/debug/MWDebug.php on line 376
PHP Deprecated:  Premature access to service 'ObjectFactory' [Called
from Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 535] in
/var/www/html/w/includes/debug/MWDebug.php on line 376

Deprecated: Premature access to service 'ObjectFactory' [Called from
Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 535] in
/var/www/html/w/includes/debug/MWDebug.php on line 376
PHP Deprecated:  Premature access to service 'ReadOnlyMode' [Called
from RebuildFileCache::finalSetup in
/var/www/html/w/maintenance/rebuildFileCache.php at line 53] in
/var/www/html/w/includes/debug/MWDebug.php on line 376

Deprecated: Premature access to service 'ReadOnlyMode' [Called from
RebuildFileCache::finalSetup in
/var/www/html/w/maintenance/rebuildFileCache.php at line 53] in
/var/www/html/w/includes/debug/MWDebug.php on line 376
PHP Deprecated:  Premature access to service 'ConfiguredReadOnlyMode'
[Called from Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 1121] in
/var/www/html/w/includes/debug/MWDebug.php on line 376

Deprecated: Premature access to service 'ConfiguredReadOnlyMode'
[Called from Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 1121] in
/var/www/html/w/includes/debug/MWDebug.php on line 376
PHP Deprecated:  Premature access to service 'MainConfig' [Called from
Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 291] in
/var/www/html/w/includes/debug/MWDebug.php on line 376

Deprecated: Premature access to service 'MainConfig' [Called from
Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 291] in
/var/www/html/w/includes/debug/MWDebug.php on line 376
PHP Deprecated:  Premature access to service 'ConfigFactory' [Called
from Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 734] in
/var/www/html/w/includes/debug/MWDebug.php on line 376

Deprecated: Premature access to service 'ConfigFactory' [Called from
Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 734] in
/var/www/html/w/includes/debug/MWDebug.php on line 376
PHP Deprecated:  Premature access to service 'BootstrapConfig' [Called
from Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 277] in
/var/www/html/w/includes/debug/MWDebug.php on line 376

Deprecated: Premature access to service 'BootstrapConfig' [Called from
Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 277] in
/var/www/html/w/includes/debug/MWDebug.php on line 376
PHP Deprecated:  Premature access to service 'DBLoadBalancer' [Called
from Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 1122] in
/var/www/html/w/includes/debug/MWDebug.php on line 376

Deprecated: Premature access to service 'DBLoadBalancer' [Called from
Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 1122] in
/var/www/html/w/includes/debug/MWDebug.php on line 376
PHP Deprecated:  Premature access to service 'DBLoadBalancerFactory'
[Called from Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 383] in
/var/www/html/w/includes/debug/MWDebug.php on line 376

Deprecated: Premature access to service 'DBLoadBalancerFactory'
[Called from Wikimedia\Services\ServiceContainer::{closure} in
/var/www/html/w/includes/ServiceWiring.php at line 383] in
/var/www/html/w/includes/debug/MWDebug.php on line 376
PHP Deprecated:  Premature access to service 'StatsdDataFactory'
[Called from ObjectCache::newFromParams in
/var/www/html/w/includes/objectcache/ObjectCache.php at line 149] 

[MediaWiki-l] Re: Mediawiki 1.36.4 and Composer failure

[Jeffrey Walton]

On Sat, Apr 2, 2022 at 5:39 AM Jeffrey Walton  wrote:
>
> Hi Everyone,
>
> I am trying to perform the Mediawiki 1.36.3 -> 1.36.4 update. I'm
> following our procedure from
> https://github.com/weidai11/website/blob/master/mediawiki/wiki-upgrade.txt.
> It is usually trouble free.
>
> I've got Mediawiki 1.36.4 unpacked and in place. I am now trying to
> update vendor pieces using Composer. It is step 10 in the procedure.
> Composer is dying with the error shown below.
>
> When I revert to Mediawiki 1.36.3, then Composer runs Ok.
>
> Does anyone know how to proceed?
>
> Thanks in advance.

The instructions to delete the composer.lock file and clear the cache
does not work. That was a step provided at
https://craftcms.stackexchange.com/questions/36551/unknown-package-has-no-name-defined-composer-error-on-upgrade.

Any help?

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Mediawiki 1.36.4 and Composer failure

[Jeffrey Walton]

Hi Everyone,

I am trying to perform the Mediawiki 1.36.3 -> 1.36.4 update. I'm
following our procedure from
https://github.com/weidai11/website/blob/master/mediawiki/wiki-upgrade.txt.
It is usually trouble free.

I've got Mediawiki 1.36.4 unpacked and in place. I am now trying to
update vendor pieces using Composer. It is step 10 in the procedure.
Composer is dying with the error shown below.

When I revert to Mediawiki 1.36.3, then Composer runs Ok.

Does anyone know how to proceed?

Thanks in advance.

==

root@localhost:/var/www/html/w# php -d extension=phar.so composer.phar
update --no-dev
PHP Warning:  Module 'Phar' already loaded in Unknown on line 0

 [UnexpectedValueException]
 Unknown package has no name defined
([{"name":"christian-riesen\/base32","version":"1
 
.4.0","version_normalized":"1.4.0.0","source":{"type":"git","url":"https:\/\/github.c
 
om\/ChristianRiesen\/base32.git","reference":"5777d962c9f55385eefd078a1bf623ce04a4f6c
 
a"},"dist":{"type":"zip","url":"https:\/\/api.github.com\/repos\/ChristianRiesen\/bas
 
e32\/zipball\/5777d962c9f55385eefd078a1bf623ce04a4f6ca","reference":"5777d962c9f55385
 eefd078a1bf623ce04a4f6ca","shasum":""},"require":{"php":"^7.2 ||
^8.0"},"require-dev"
 
:{"friendsofphp\/php-cs-fixer":"^2.17","phpstan\/phpstan":"^0.12","phpunit\/phpunit":
 "^8.5.13 || 
^9.5"},"time":"2020-12-29T20:09:51+00:00","type":"library","extra":{"bran
 
ch-alias":{"dev-master":"1.x-dev"}},"installation-source":"dist","autoload":{"psr-4":
 
{"Base32\\":"src\/"}},"notification-url":"https:\/\/packagist.org\/downloads\/","lice
 nse":["MIT"],"authors":[{"name":"Christian
Riesen","email":"chris.rie...@gmail.com","
 
homepage":"http:\/\/christianriesen.com","role":"Developer"}],"description":"Base32
e
 ncoder\/decoder according to RFC
4648","homepage":"https:\/\/github.com\/ChristianRie
 
sen\/base32","keywords":["base32","decode","encode","rfc4648"],"install-path":"..\/ch
 
ristian-riesen\/base32"},{"name":"composer\/semver","version":"3.2.4","version_normal
 
ized":"3.2.4.0","source":{"type":"git","url":"https:\/\/github.com\/composer\/semver.
 
git","reference":"a02fdf930a3c1c3ed3a49b5f63859c0c20e10464"},"dist":{"type":"zip","ur
 
l":"https:\/\/api.github.com\/repos\/composer\/semver\/zipball\/a02fdf930a3c1c3ed3a49
 
b5f63859c0c20e10464","reference":"a02fdf930a3c1c3ed3a49b5f63859c0c20e10464","shasum":
 ""},"require":{"php":"^5.3.2 || ^7.0 ||
^8.0"},"require-dev":{"phpstan\/phpstan":"^0.
 12.54","symfony\/phpunit-bridge":"^4.2 ||
^5"},"time":"2020-11-13T08:59:24+00:00","ty
 
pe":"library","extra":{"branch-alias":{"dev-main":"3.x-dev"}},"installation-source":"
 
dist","autoload":{"psr-4":{"Composer\\Semver\\":"src"}},"notification-url":"https:\/\
 /packagist.org\/downloads\/","license":["MIT"],"authors":[{"name":"Nils
Adermann","em
 
ail":"nader...@naderman.de","homepage":"http:\/\/www.naderman.de"},{"name":"Jordi
Bog
 giano","email":"j.boggi...@seld.be","homepage":"http:\/\/seld.be"},{"name":"Rob
Bast"
 
,"email":"rob.b...@gmail.com","homepage":"http:\/\/robbast.nl"}],"description":"Semve
 r library that offers utilities, version constraint parsing and
validation.","keyword
 
s":["semantic","semver","validation","versioning"],"funding":[{"url":"https:\/\/packa
 
gist.com","type":"custom"},{"url":"https:\/\/github.com\/composer","type":"github"},{
 
"url":"https:\/\/tidelift.com\/funding\/github\/packagist\/composer\/composer","type"
 
:"tidelift"}],"install-path":".\/semver"},{"name":"cssjanus\/cssjanus","version":"v1.
 
3.0","version_normalized":"1.3.0.0","source":{"type":"git","url":"https:\/\/github.co
 
m\/cssjanus\/php-cssjanus.git","reference":"93db9fb39c2f9bcf287715ae254c088b14a77799"
 
},"dist":{"type":"zip","url":"https:\/\/api.github.com\/repos\/cssjanus\/php-cssjanus
 
\/zipball\/93db9fb39c2f9bcf287715ae254c088b14a77799","reference":"93db9fb39c2f9bcf287
 
715ae254c088b14a77799","shasum":""},"require":{"php":">=5.6.0"},"require-dev":{"jakub
 
-onderka\/php-parallel-lint":"^0.9.2","phpunit\/phpunit":"^4.8.36","squizlabs\/php_co
 
desniffer":"^3.1.1"},"time":"2019-05-10T23:50:10+00:00","type":"library","installatio
 
n-source":"dist","autoload":{"psr-0":{"":"src\/"}},"notification-url":"https:\/\/pack
 agist.org\/downloads\/","license":["Apache-2.0"],"authors":[{"name":"Trevor
Parscal"}
 ,{"name":"Roan Kattouw"},{"name":"Timo
Tijhof"}],"description":"Convert CSS styleshee
 ts between left-to-right and
right-to-left.","install-path":"..\/cssjanus\/cssjanus"}
 
,{"name":"guzzlehttp\/guzzle","version":"7.2.0","version_normalized":"7.2.0.0","sourc
 
e":{"type":"git","url":"https:\/\/github.com\/guzzle\/guzzle.git","reference":"0aa74d
 
fb41ae110835923ef10a9d803a22d50e79"},"dist":{"type":"zip","url":"https:\/\/api.github
 
.com\/repos\/guzzle\/guzzle\/zipball\/0aa74dfb41ae110835923ef10a9d803a22d50e79","refe
 
rence":"0aa74dfb41ae110835923ef10a9d803a22d50e79","shasum":""},"require":{"ext-json":
 "*","guzzlehttp\/promises":"^1.4","guzzlehttp\/psr7":"^1.7","php":"^7.2.5
|| 

[MediaWiki-l] Re: Bug report: Extension DataTransfer

[Jeffrey Walton]

On Thu, Jun 24, 2021 at 5:41 PM otheus uibk  wrote:
>
> OK, so you get error stack-traces in a *debug* log, and in the error log you 
> get warning notices? *facepalm*
>
> I have a stack-trace which may be relevant.
>
> [error] [YNT6JB0y@yYaYYse7zE8PgAAAIc] 
> /neulatein/index.php?title=Spezial:XML_anzeigen%5BLBI-Authors%5D=on%5B0%5D=on
>ErrorException from line 139 of 
> /sites/wiki.uibk.ac.at/app/bluespice-20191215/local/extensions/DataTransfer/includes/DT_PageStructure.php:
>  PHP Notice: Undefined index: 0505261
> #0 $IP/local/extensions/DataTransfer/includes/DT_PageStructure.php(139): 
> MWExceptionHandler::handleError(integer, string, string, integer, array)
> #1 $IP/local/extensions/DataTransfer/includes/DT_PageStructure.php(26): 
> DTPageStructure->parsePageContents(string)
> #2 $IP/local/extensions/DataTransfer/includes/specials/DT_ViewXML.php(138): 
> DTPageStructure::newFromTitle(Title)
> #3 $IP/local/extensions/DataTransfer/includes/specials/DT_ViewXML.php(230): 
> DTViewXML->getXMLForPage(Title, NULL)
> #4 $IP/local/extensions/DataTransfer/includes/specials/DT_ViewXML.php(22): 
> DTViewXML->doSpecialViewXML(NULL)
> #5 $IP/includes/specialpage/SpecialPage.php(565): DTViewXML->execute(NULL)
> #6 $IP/includes/specialpage/SpecialPageFactory.php(568): 
> SpecialPage->run(NULL)
> #7 $IP/includes/MediaWiki.php(288): SpecialPageFactory::executePath(Title, 
> RequestContext)
> #8 $IPincludes/MediaWiki.php(861): MediaWiki->performRequest()
> #9 $IP/includes/MediaWiki.php(524): MediaWiki->main()
> #10 $IP/index.php(42): MediaWiki->run()
> #11 {main}
>
> That index is very suspicious. Perhaps the page content is so big that it 
> triggers some kind of numeric overflow?

It looks like (to me) this is the problem:

PHP Notice: Undefined index ...

The extension needs to be updated for the version of PHP and Mediawiki
you are using.

I would disable it in LocalSettings.php until the author updates it.
Or, if you know PHP, you can fix it yourself.

Also see https://stackoverflow.com/a/4261200 and
https://www.mediawiki.org/wiki/Extension:Data_Transfer .

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
List information: 
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Use of BaseTemplate::getFooterIcons was deprecated ... in /var/www/html/w/skins/Vector

[Jeffrey Walton]

On Thu, Jun 24, 2021 at 1:25 PM Jeffrey Walton  wrote:
>
> We just upgraded from Mediawiki 1.36 to Mediawiki 1.36.1. Mediawiki
> 1.36 was OK. Mediawiki 1.36.1 has the problem. It looks like CSS
> formatting no longer works.
>
> Deprecated: Use of BaseTemplate::getFooterIcons was deprecated in
> MediaWiki 1.35. [Called from VectorTemplate::getFooterData in
> /var/www/html/w/skins/Vector/includes/VectorTemplate.php at line 223]
> in /var/www/html/w/includes/debug/MWDebug.php on line 376

Also see https://phabricator.wikimedia.org/T285491.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
List information: 
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Bug report: Extension DataTransfer

[Jeffrey Walton]

On Thu, Jun 24, 2021 at 9:40 AM otheus uibk  wrote:
>
> Thank Jeffrey, that's a good eye, but unfortunately, the problem persists.
>
> Indeed, update.php had not completed *successfully*. There appears to be a 
> mistake in the documentation (or a shorthand in which it is assumed the admin 
> understands the syntax is not literal). The INSTALL page says to run:
>
> >   composer require "phpoffice/phpexcel:~1.8"
>
> I had ran this command verbatim. Initially, composer would not complete due 
> to another unrelated module which specified unit-tests in its 
> require/manifest, but the module was not deployed with its test directory. 
> Having fixed that problem in multiple places, the composer command ran 
> successfully. Unfortunately the tilde seems to have been the cause of the 
> failure for running update:
>
>  phpoffice/phpexcel: 1.8.2 installed, ~1.8 required.
>  Error: your composer.lock file is not up to date. Run "composer update 
> --no-dev" to install newer dependencies
>
> This is really quite strange. I looked at the composer documentation, and 
> there is definitely some confusion there. In one section, it says that the 
> version attribute must match a regular expression, which does not include the 
> ~. Another section (https://getcomposer.org/doc/articles/versions.md) 
> indicates this is perfectly acceptable, and that "~1.8" should mean 
> ">=1.8.0".  However, none of the following combinations in composer.json 
> worked:
>   - "1.8*"
>   - "1.8.*"
>   - "1.8.0"
>   - ">=1.8.0"
> In the end, I had to change composer.json with the exact version number 
> composer had previously installed. Then I could run update. I also updated 
> the language cache.

Don't get me started on the dev tools on a production server...

Here's what I do for composer:

$ sudo apt-get install -y composer

$ sudo su -
# cd /var/www/html/w
# rm -rf /var/www/html/w/vendor
# php -d extension=phar.so composer.phar update --no-dev
# exit

$ sudo apt-get remove -y composer

Then, fix ownership and permissions on the files. We use
root:www-data, 0750 and friends. Root owns everything and gets
read/write. The webserver is the group owner and only gets read. (The
webserver gets read/write on the upload/ and sessions/ directories).

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
List information: 
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Bug report: Extension DataTransfer

[Jeffrey Walton]

On Thu, Jun 24, 2021 at 4:39 AM otheus uibk  wrote:
>
> I installed the latest release (1.2) of the DataTransfer Extension via Git. I 
> installed it on a 1.31 MW system per the INSTALL file. I went to the 
> Spezial:XMLview page as instructed. I selected one of the  categories and the 
> main namespace and hit 'view XML'. After a few seconds (< 10) I got a 500 
> page. I see the 500 error in the PHP logs (so this isn't a web timeout). The 
> PHP debug logs show only the following:
>
> PHP Notice:  Undefined index: 0505261 in 
> $IP/local/extensions/DataTransfer/includes/DT_PageStructure.php on line 139
>
> ($IP is the full installation path, redacted for security reasons)
>
> Help?

I believe you need to run maintenance/update.php after you install an
extension. Can you confirm you have run it?

(I find it is best to run maintenance/update.php after any
maintenance, including a Mediawiki upgrade, extension installation,
extension removal, etc).

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
List information: 
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Update HitCounters GitHub repo

[Jeffrey Walton]

On Mon, Jun 14, 2021 at 4:04 PM Bryan Davis  wrote:
>
> On Mon, Jun 14, 2021 at 1:33 PM Jeffrey Walton  wrote:
> >
> > > I've updated the HitCounters extension in gerrit[1] and made it 
> > > installable
> > > via composer.[2]
> > >
> > > Please feel free to file bugs against this in phabricator.[3]
> >
> > Awesome, thanks Mark.
> >
> > I think this extension should be included by default in Mediawiki. It
> > is so useful I don't understand why folks have to do something special
> > to get it.
>
> https://www.mediawiki.org/wiki/Requests_for_comment/Removing_hit_counters_from_MediaWiki_core

Thanks Bryan.

I'm not sure about this:
  * useless metric

We find it very useful for the development lifecycle. Specifically,
Step 5, feedback. We use it to determine what pages should be extra
polished, and what users are having problems with.

Hmmm
  * better served by an extension
  * Extension:Google Analytics or similar

I'm not sure it is a good idea to track users or force users to
surrender their data to Google. Wiki administrators should not set
that policy for a user. Agreeing to tracking and surrendering data
should be a user's choice.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
List information: 
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Update HitCounters GitHub repo

[Jeffrey Walton]

> I've updated the HitCounters extension in gerrit[1] and made it installable
> via composer.[2]
>
> Please feel free to file bugs against this in phabricator.[3]

Awesome, thanks Mark.

I think this extension should be included by default in Mediawiki. It
is so useful I don't understand why folks have to do something special
to get it.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
List information: 
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Update HitCounters GitHub repo

[Jeffrey Walton]

Hi Everyone,

We are having a little trouble with HitCounters and deprecated warnings.

We use extensions and skins from the GitHub mirror to easily pull in
changes on the REL1_36 branch. Tracking a branch like REL1_36 is a lot
easier than manually downloading a zip file with a non-relevant name,
like v4.3.5.zip (especially with 30+ extensions and skins).

HitCounter is stale. The author, @WikiForMen, said he updated the
extension to fix the warnings (see the Talk page). It appears the
changes have not trickled into the GitHub repo. Confer,
https://github.com/wikimedia/mediawiki-extensions-HitCounters/tree/REL1_36
.

Would it be possible to update the HitCounters repo, please?

Thanks in advance.
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
List information: 
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: Deprecated: Use of SkinTemplateOutputPageBeforeExec hook ... was deprecated in MediaWiki 1.35

[Jeffrey Walton]

On Mon, May 31, 2021 at 8:32 PM Tim Starling  wrote:
>
> The problem is with the HitCounters extension. There's a bug already:
>
> https://phabricator.wikimedia.org/T282897
>
> You should be able to set $wgDevelopmentWarnings = false (which is the
> default) to disable deprecation warnings in production.

Ack, thanks Tim.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
List information: 
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Deprecated: Use of SkinTemplateOutputPageBeforeExec hook ... was deprecated in MediaWiki 1.35

[Jeffrey Walton]

Hi Everyone,

We recently updated to Mediawiki 1.36. I'm testing some of our
installed skins under it.

Use of Minerva Neue is causing this warning to be printed on the top
of each page. I can't tell if it is a Minerva Neue issue, HitCounter
issue, or HookContainer issue.

Deprecated: Use of SkinTemplateOutputPageBeforeExec hook (used in
HitCounters\Hooks::onSkinTemplateOutputPageBeforeExec) was deprecated
in MediaWiki 1.35. [Called from
MediaWiki\HookContainer\HookContainer::run in
/var/www/html/w/includes/HookContainer/HookContainer.php at line 137]
in /var/www/html/w/includes/debug/MWDebug.php on line 376

I have no idea why we are running debug code on a production server.
That looks like a separate issue. I'll have to check what I have
mis-configured.

Our mediawiki information can be found at
https://www.cryptopp.com/wiki/Special:Version.
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
List information: 
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

[MediaWiki-l] Re: "Premature access" deprecation warnings upgrading from 1.35.2 to 1.36.0

[Jeffrey Walton]

On Sat, May 29, 2021 at 10:10 AM Jeffrey T. Darlington
 wrote:
>
> Just an FYI for any devs on the list:
>
> I just upgraded my 1.35.2 MW to 1.36.0 via a tarball release and received 
> several "premature access" deprecation warnings from PHP in the process.  No 
> fatal errors were thrown, so the upgrade completed successfully.  Still, this 
> might be something to look into.
>
> OS  Fedora 34
> Apache  2.4.46
> PHP 7.4.19 (fpm-fcgi)
> MariaDB 10.5.10
>
> The following warnings we thrown at the start of running "php update.php":
>
> PHP Deprecated:  Premature access to service container [Called from 
> Maintenance::finalSetup in 
> /var/www/gpf/mediawiki-1.36.0/maintenance/includes/Maintenance.php at line 
> 1221] in /var/www/gpf/mediawiki-1.36.0/includes/debug/MWDebug.php on line 376
> PHP Deprecated:  Premature access to service 'HookContainer' [Called from 
> MediaWiki\MediaWikiServices::getInstance in 
> /var/www/gpf/mediawiki-1.36.0/includes/MediaWikiServices.php at line 252] in 
> /var/www/gpf/mediawiki-1.36.0/includes/debug/MWDebug.php on line 376
> PHP Deprecated:  Premature access to service 'ObjectFactory' [Called from 
> Wikimedia\Services\ServiceContainer::{closure} in 
> /var/www/gpf/mediawiki-1.36.0/includes/ServiceWiring.php at line 535] in 
> /var/www/gpf/mediawiki-1.36.0/includes/debug/MWDebug.php on line 376

We are experiencing the issue, too. It is present when we run
maintenance/ rebuildFileCache.php and
maintenance/rebuildtextindex.php.

Our platform is Ubuntu 20.04.2 LTS, x86_64, fully patched. PHP version
is 7.4.3. All dependencies are up to date via Composer.

Jeff
___
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
List information: 
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

Re: [MediaWiki-l] Unknown: file created in the system's temporary directory

[Jeffrey Walton]

On Wed, Apr 14, 2021 at 6:24 PM Andre Klapper  wrote:
>
> On Wed, 2021-04-14 at 05:00 -0400, Jeffrey Walton wrote:
> > Second try without the image...
>
> Is there any difference to your original email from March 8th?
> Second try of what exactly?

Yes.

The original email was blocked because it included an image. The
second try removed the image.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Unknown: file created in the system's temporary directory

[Jeffrey Walton]

Second try without the image...

On Thu, Apr 8, 2021 at 3:47 PM Jeffrey Walton  wrote:
>
> Hi Everyone,
>
> I'm seeing some funny business in our log files.
>
> [Thu Apr 08 10:52:20.225624 2021] [php7:notice] [pid 1823] [client
> 71.179.5.32:29418] PHP Notice:  Unknown: file created in the system's
> temporary directory in Unknown on line 0, referer:
> https://www.cryptopp.com/w/index.php?title=Linux=edit
>
> We override the upload directory for Apache, so nothing should be
> written to the system's temporary directory:
>
> # grep -IR 'temp_dir' /etc
> /etc/php/7.4/cli/php.ini:; Defaults to the system default (see 
> sys_get_temp_dir)
> /etc/php/7.4/cli/php.ini:;sys_temp_dir = "/tmp"
> /etc/php/7.4/apache2/php.ini:; Defaults to the system default (see
> sys_get_temp_dir)
> /etc/php/7.4/apache2/php.ini:sys_temp_dir = "/var/lib/php/tmp"
>
> And:
>
> # ls -Al /var/lib/php
> drwxr-xr-x 3 www-data www-data 4096 Mar 31 17:04 modules
> drwx-wx-wt 2 www-data www-data 4096 Mar 27  2020 sessions
> drwxr-xr-x 2 www-data www-data 4096 Apr  8 11:37 tmp
>
> And:
>
> # grep base /etc/php/7.4/apache2/conf.d/99-security.ini
> open_basedir="/var/www/html/:/var/lib/php/"
>
> We are not sure what is going on. I guess we missed a setting somewhere.
>
> How is the attacker creating files on the system given they are not logged in?
>
> Thanks in advance.

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Syntax Highlighter that does not shell out?

[Jeffrey Walton]

Hi Everyone,

I'm looking for a Syntax Highlighter for MW 1.35. The rub is, the
extension cannot shell out like the current Syntax Highlighter.[1] Our
wiki disables nearly all of those kinds of functions.

[1] https://www.mediawiki.org/wiki/Extension:SyntaxHighlight

Rather, the extension needs to have (or install via Composer), a
Python or PHP compatible library for its use. (Is this considered
"native" in the web world?)

Would someone recommend a Syntax Highlighter that uses PHP libraries
and does not shell out, please?

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Watchlists load is pin-wheeling under MW 1.35.2

[Jeffrey Walton]

This showed up under Firefox's Developer Console:

[YHF-iM3bssmAK8d51LBMIQM]
/w/load.php?lang=en=jquery%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Cjquery.client%2Ccookie%2CmakeCollapsible%7Cjquery.makeCollapsible.styles%7Cmediawiki.String%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2Cuser%2Cutil%2Cwidgets%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.rcfilters.filters.dm%2Cui%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.recentchanges%2Cwatchlist%7Cmediawiki.widgets.styles%7Coojs-ui-core.icons%2Cstyles%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-core%2Cicons-editing-styling%2Cicons-interactions%2Cicons-layout%2Cicons-media%2Cicons-moderation%2Cindicators%7Cskins.vector.legacy.js%7Cuser.defaults=vector=1y7vj

BadMethodCallException from line 848 of
/var/www/html/w/includes/session/SessionManager.php: Sessions are
disabled for this entry point

Backtrace:
#0 /var/www/html/w/includes/session/SessionManager.php(220):
MediaWiki\Session\SessionManager->getSessionFromInfo()
#1 /var/www/html/w/includes/WebRequest.php(826):
MediaWiki\Session\SessionManager->getSessionForRequest()
#2 /var/www/html/w/includes/user/User.php(1221): WebRequest->getSession()
#3 /var/www/html/w/includes/user/User.php(388): User->loadFromSession()
#4 /var/www/html/w/includes/user/User.php(2130): User->load()
#5 /var/www/html/w/includes/user/User.php(3069): User->getId()
#6 /var/www/html/w/includes/user/UserOptionsManager.php(584):
User->isRegistered()
#7 /var/www/html/w/includes/user/UserOptionsManager.php(487):
MediaWiki\User\UserOptionsManager->getCacheKey()
#8 /var/www/html/w/includes/user/UserOptionsManager.php(135):
MediaWiki\User\UserOptionsManager->loadUserOptions()
#9 /var/www/html/w/includes/user/User.php(2670):
MediaWiki\User\UserOptionsManager->getOption()
#10 /var/www/html/w/includes/context/RequestContext.php(416): User->getOption()
#11 /var/www/html/w/includes/context/ContextSource.php(150):
RequestContext->getSkin()
#12 /var/www/html/w/skins/Tweeki/includes/Hooks.php(52):
ContextSource->getSkin()
#13 /var/www/html/w/includes/HookContainer/HookContainer.php(321):
TweekiHooks::onParserFirstCallInit()
#14 /var/www/html/w/includes/HookContainer/HookContainer.php(132):
MediaWiki\HookContainer\HookContainer->callLegacyHook()
#15 /var/www/html/w/includes/HookContainer/HookRunner.php(2960):
MediaWiki\HookContainer\HookContainer->run()
#16 /var/www/html/w/includes/parser/Parser.php(532):
MediaWiki\HookContainer\HookRunner->onParserFirstCallInit()
#17 /var/www/html/w/includes/parser/Parser.php(477): Parser->firstCallInit()
#18 /var/www/html/w/includes/parser/ParserFactory.php(142):
Parser->__construct()
#19 /var/www/html/w/includes/ServiceWiring.php(817): ParserFactory->create()
#20 /var/www/html/w/vendor/wikimedia/services/src/ServiceContainer.php(447):
Wikimedia\Services\ServiceContainer->{closure}()
#21 /var/www/html/w/vendor/wikimedia/services/src/ServiceContainer.php(416):
Wikimedia\Services\ServiceContainer->createService()
#22 /var/www/html/w/includes/MediaWikiServices.php(1000):
Wikimedia\Services\ServiceContainer->getService()
#23 /var/www/html/w/includes/cache/MessageCache.php(1249):
MediaWiki\MediaWikiServices->getParser()
#24 /var/www/html/w/includes/cache/MessageCache.php(1276):
MessageCache->getParser()
#25 /var/www/html/w/includes/language/Message.php(1258): MessageCache->parse()
#26 /var/www/html/w/includes/language/Message.php(889): Message->parseText()
#27 /var/www/html/w/includes/language/Message.php(942): Message->toString()
#28 /var/www/html/w/includes/specialpage/ChangesListSpecialPage.php(976):
Message->parse()
#29 /var/www/html/w/includes/specialpage/ChangesListSpecialPage.php(887):
ChangesListSpecialPage::getChangeTagList()
#30 /var/www/html/w/includes/resourceloader/ResourceLoaderFileModule.php(1308):
ChangesListSpecialPage::getRcFiltersConfigVars()
#31 /var/www/html/w/includes/resourceloader/ResourceLoaderFileModule.php(347):
ResourceLoaderFileModule->getPackageFiles()
#32 /var/www/html/w/includes/resourceloader/ResourceLoaderModule.php(736):
ResourceLoaderFileModule->getScript()
#33 /var/www/html/w/includes/resourceloader/ResourceLoaderModule.php(704):
ResourceLoaderModule->buildContent()
#34 /var/www/html/w/includes/resourceloader/ResourceLoader.php(1191):
ResourceLoaderModule->getModuleContent()
#35 /var/www/html/w/includes/resourceloader/ResourceLoader.php(899):
ResourceLoader->makeModuleResponse()
#36 /var/www/html/w/load.php(51): ResourceLoader->respond()
#37 /var/www/html/w/load.php(38): wfLoadMain()
#38 {main} load.php:44:48
 jQuery
JQMIGRATE: Migrate is installed with logging active, version 3.1.0
load.php:188:171

On Sat, Apr 10, 2021 at 6:46 AM Jeffrey Walton  wrote:
>
> Hi Everyone,
>
> We migrated to MW 1.35.2 yesterday. The migration went well and

[MediaWiki-l] Watchlists load is pin-wheeling under MW 1.35.2

[Jeffrey Walton]

Hi Everyone,

We migrated to MW 1.35.2 yesterday. The migration went well and
everything seems to work as expected.

Today I clicked on Watchlists and found the page load is hanging. I've
got the three pulsating circles and some text, but the page does not
finish loading. The text is:

17 pages are on your Watchlist (plus talk pages). Email notification
is enabled. Changes to pages you haven't visited since the changes
occurred are in bold, with solid markers.

There are no Mediawiki errors from PHP. There is nothing in error.log.
The access.log shows this:

x.x.x.x - - [10/Apr/2021:10:37:17 +] "GET /wiki/Special:Watchlist
HTTP/1.1" 200 7245
x.x.x.x - - [10/Apr/2021:10:37:17 +] "GET
/w/resources/assets/poweredby_mediawiki_132x47.png HTTP/1.1" 304 -
x.x.x.x - - [10/Apr/2021:10:37:17 +] "GET
/w/load.php?lang=en=startup=scripts=1=vector
HTTP/1.1" 200 11895
x.x.x.x - - [10/Apr/2021:10:37:17 +] "GET
/w/load.php?lang=en=jquery%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Cjquery.client%2Ccookie%2CmakeCollapsible%7Cjquery.makeCollapsible.styles%7Cmediawiki.String%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2Cuser%2Cutil%2Cwidgets%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.rcfilters.filters.dm%2Cui%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.recentchanges%2Cwatchlist%7Cmediawiki.widgets.styles%7Coojs-ui-core.icons%2Cstyles%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-core%2Cicons-editing-styling%2Cicons-interactions%2Cicons-layout%2Cicons-media%2Cicons-moderation%2Cindicators%7Cskins.vector.legacy.js%7Cuser.defaults=vector=1y7vj
HTTP/1.1" 304 -

Any thoughts on how to finish load the Watchlist page?

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Auditing use of tempnam

[Jeffrey Walton]

Hi Everyone,

I'm trying to track down what is the cause of the non-logged-in user
and the 0-sized file written to /tmp. I'm having trouble auditing the
use of tempnam for my Mediawiki installation.

I think Mediawiki should provide a wrapper for tempnam, like
$wfTempName(...). Ensure the wrapper uses sys_get_temp_dir().
Additionally, the Mediawiki linter should flag direct use of tempnam
and point authors to use the wrapper function.

Even better, provide a complete wrapper for the tempnam so tempnam is
not used. Allow us to put tempnam on the banned function list.

Here's the PHP documentation in tempname:
https://www.php.net/manual/en/function.tempnam.php.

Here's what we get back when trying to audit the use of tempnam:

# grep -wIR tempnam /var/www/html/w 2>/dev/null | grep -v sys_get_temp_dir
/var/www/html/w/includes/import/WikiImporter.php:$filename =
tempnam( wfTempDir(), 'importupload' );
/var/www/html/w/includes/import/ImportableUploadRevisionImporter.php:
  $tempo = tempnam( wfTempDir(), 'download' );
/var/www/html/w/includes/diff/TextSlotDiffRenderer.php:
$tempName1 = tempnam( $tmpDir, 'diff_' );
/var/www/html/w/includes/diff/TextSlotDiffRenderer.php:
$tempName2 = tempnam( $tmpDir, 'diff_' );
/var/www/html/w/includes/resourceloader/ResourceLoaderImage.php:
 $tempFilenameSvg = tempnam( wfTempDir(), 'ResourceLoaderImage' );
/var/www/html/w/includes/resourceloader/ResourceLoaderImage.php:
 $tempFilenamePng = tempnam( wfTempDir(), 'ResourceLoaderImage' );
/var/www/html/w/includes/GlobalFunctions.php:$oldtextFile = fopen(
$oldtextName = tempnam( $td, 'merge-old-' ), 'w' );
/var/www/html/w/includes/GlobalFunctions.php:$mytextFile = fopen(
$mytextName = tempnam( $td, 'merge-mine-' ), 'w' );
/var/www/html/w/includes/GlobalFunctions.php:$yourtextFile =
fopen( $yourtextName = tempnam( $td, 'merge-your-' ), 'w' );
/var/www/html/w/includes/GlobalFunctions.php:$oldtextFile = fopen(
$oldtextName = tempnam( $td, 'merge-old-' ), 'w' );
/var/www/html/w/includes/GlobalFunctions.php:$newtextFile = fopen(
$newtextName = tempnam( $td, 'merge-your-' ), 'w' );
/var/www/html/w/extensions/CodeEditor/modules/ace/mode-php_laravel_blade.js:tcpwrap_check|tempnam|textdomain|tidy|tidy_access_count|tidy_config_count|tidy_diagnose|tidy_error_count|tidy_get_error_buffer|\
/var/www/html/w/extensions/CodeEditor/modules/ace/mode-php_laravel_blade.js:
   "tempnam": [
/var/www/html/w/extensions/CodeEditor/modules/ace/mode-php_laravel_blade.js:
   "string tempnam(string dir, string prefix)",
/var/www/html/w/extensions/CodeEditor/modules/ace/mode-php.js:tcpwrap_check|tempnam|textdomain|tidy|tidy_access_count|tidy_config_count|tidy_diagnose|tidy_error_count|tidy_get_error_buffer|\
/var/www/html/w/extensions/CodeEditor/modules/ace/mode-php.js:"tempnam": [
/var/www/html/w/extensions/CodeEditor/modules/ace/mode-php.js:
"string tempnam(string dir, string prefix)",
/var/www/html/w/maintenance/mwdocgen.php:$tmpFile = tempnam(
wfTempDir(), 'MWDocGen-' );
/var/www/html/w/vendor/phpunit/phpunit/src/Util/PHP/DefaultPhpProcess.php:use
function tempnam;
/var/www/html/w/vendor/zordius/lightncandy/src/LightnCandy.php:
$fn = tempnam($tmpDir, 'lci_');
/var/www/html/w/vendor/phan/phan/src/Phan/Plugin/Internal/UseReturnValuePlugin.php:
   'tempnam' => true,
/var/www/html/w/vendor/phan/phan/src/Phan/Language/Internal/FunctionSignatureMapReal_php73.php:'tempnam'
=> '?false|?string',
/var/www/html/w/vendor/phan/phan/src/Phan/Language/Internal/FunctionSignatureMap.php:'tempnam'
=> ['string|false', 'dir'=>'string', 'prefix'=>'string'],
/var/www/html/w/vendor/phan/phan/src/Phan/Language/Internal/FunctionSignatureMapReal.php:'tempnam'
=> 'false|string',
/var/www/html/w/vendor/phan/phan/src/Phan/Language/Internal/FunctionDocumentationMap.php:'tempnam'
=> 'Create file with unique file name',
/var/www/html/w/vendor/psy/psysh/src/Configuration.php:return
\tempnam($this->getRuntimeDir(), $type . '_' . $pid . '_');
/var/www/html/w/vendor/psy/psysh/src/Command/EditCommand.php:
  $filePath = \tempnam($this->runtimeDir, 'psysh-edit-command');
/var/www/html/w/vendor/composer/xdebug-handler/src/XdebugHandler.php:
  if (!$this->tmpIni = @tempnam($tmpDir, '')) {
/var/www/html/w/vendor/pear/pear-core-minimal/src/System.php:
$tmp = tempnam($tmpdir, $prefix);

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Unknown: file created in the system's temporary directory

[Jeffrey Walton]

Hi Everyone,

I'm seeing some funny business in our log files.

[Thu Apr 08 10:52:20.225624 2021] [php7:notice] [pid 1823] [client
71.179.5.32:29418] PHP Notice:  Unknown: file created in the system's
temporary directory in Unknown on line 0, referer:
https://www.cryptopp.com/w/index.php?title=Linux=edit

We override the upload directory for Apache, so nothing should be
written to the system's temporary directory:

# grep -IR 'temp_dir' /etc
/etc/php/7.4/cli/php.ini:; Defaults to the system default (see sys_get_temp_dir)
/etc/php/7.4/cli/php.ini:;sys_temp_dir = "/tmp"
/etc/php/7.4/apache2/php.ini:; Defaults to the system default (see
sys_get_temp_dir)
/etc/php/7.4/apache2/php.ini:sys_temp_dir = "/var/lib/php/tmp"

And:

# ls -Al /var/lib/php
drwxr-xr-x 3 www-data www-data 4096 Mar 31 17:04 modules
drwx-wx-wt 2 www-data www-data 4096 Mar 27  2020 sessions
drwxr-xr-x 2 www-data www-data 4096 Apr  8 11:37 tmp

And:

# grep base /etc/php/7.4/apache2/conf.d/99-security.ini
open_basedir="/var/www/html/:/var/lib/php/"

We are not sure what is going on. I guess we missed a setting somewhere.

How is the attacker creating files on the system given they are not logged in?

Thanks in advance.

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] GuzzleHttp requires cURL, the allow_url_fopen ini setting, or a custom HTTP handler.

[Jeffrey Walton]

Hi Everyone,

I'm using MW 1.35.1 release tarball. We migrated to a new VM using
Ubuntu 20, x86_64, fully patched. I also updated composer
dependencies.

Below is a new error when we edit a wiki page and click Submit.
Preview is OK. We did not experience it on our CentOS 7 VM during
Submit.

We are in a hardened state. We can't meet Guzzle's requirements because:

open_basedir="/var/www/html/:/var/lib/php/"
allow_url_fopen=Off
allow_url_include=Off

Looking at Special:Version, Guzzle is described as "Guzzle is a PHP
HTTP client library." I don't believe our Mediawiki should be making
outbound requests like this. We disabled Guzzle by disabling
SpamBlacklist.

This brings a couple of questions:

  * Why is Guzzle filtering Sysops or Administrator actions?
  * Is there another way to get the Spam blacklist? Like a Systemd
service that runs once an hour?

Thanks in advance.

==

[YGi84aU19iAalBwOJ8j4SAU]
/w/index.php?title=Main_Page=submit RuntimeException from line
119 of /var/www/html/w/vendor/guzzlehttp/guzzle/src/functions.php:
GuzzleHttp requires cURL, the allow_url_fopen ini setting, or a custom
HTTP handler.

Backtrace:

#0 /var/www/html/w/vendor/guzzlehttp/guzzle/src/HandlerStack.php(42):
GuzzleHttp\choose_handler()
#1 /var/www/html/w/includes/http/GuzzleHttpRequest.php(164):
GuzzleHttp\HandlerStack::create()
#2 /var/www/html/w/includes/http/HttpRequestFactory.php(186):
GuzzleHttpRequest->execute()
#3 /var/www/html/w/includes/http/HttpRequestFactory.php(208):
MediaWiki\Http\HttpRequestFactory->request()
#4 /var/www/html/w/extensions/SpamBlacklist/includes/BaseBlacklist.php(370):
MediaWiki\Http\HttpRequestFactory->get()
#5 /var/www/html/w/extensions/SpamBlacklist/includes/BaseBlacklist.php(329):
BaseBlacklist->getHttpText()
#6 /var/www/html/w/extensions/SpamBlacklist/includes/BaseBlacklist.php(294):
BaseBlacklist->buildSharedBlacklists()
#7 /var/www/html/w/includes/libs/objectcache/wancache/WANObjectCache.php(1529):
BaseBlacklist->{closure}()
#8 /var/www/html/w/includes/libs/objectcache/wancache/WANObjectCache.php(1376):
WANObjectCache->fetchOrRegenerate()
#9 /var/www/html/w/extensions/SpamBlacklist/includes/BaseBlacklist.php(295):
WANObjectCache->getWithSetCallback()
#10 /var/www/html/w/extensions/SpamBlacklist/includes/BaseBlacklist.php(224):
BaseBlacklist->getSharedBlacklists()
#11 /var/www/html/w/extensions/SpamBlacklist/includes/SpamBlacklist.php(89):
BaseBlacklist->getBlacklists()
#12 
/var/www/html/w/extensions/SpamBlacklist/includes/SpamBlacklistHooks.php(45):
SpamBlacklist->filter()
#13 /var/www/html/w/includes/HookContainer/HookContainer.php(320):
SpamBlacklistHooks::filterMergedContent()
#14 /var/www/html/w/includes/HookContainer/HookContainer.php(131):
MediaWiki\HookContainer\HookContainer->callLegacyHook()
#15 /var/www/html/w/includes/HookContainer/HookRunner.php(1529):
MediaWiki\HookContainer\HookContainer->run()
#16 /var/www/html/w/includes/EditPage.php(1904):
MediaWiki\HookContainer\HookRunner->onEditFilterMergedContent()
#17 /var/www/html/w/includes/EditPage.php(2363): EditPage->runPostMergeFilters()
#18 /var/www/html/w/includes/EditPage.php(1724): EditPage->internalAttemptSave()
#19 /var/www/html/w/includes/EditPage.php(680): EditPage->attemptSave()
#20 /var/www/html/w/includes/actions/EditAction.php(71): EditPage->edit()
#21 /var/www/html/w/includes/actions/SubmitAction.php(38): EditAction->show()
#22 /var/www/html/w/includes/MediaWiki.php(527): SubmitAction->show()
#23 /var/www/html/w/includes/MediaWiki.php(313): MediaWiki->performAction()
#24 /var/www/html/w/includes/MediaWiki.php(940): MediaWiki->performRequest()
#25 /var/www/html/w/includes/MediaWiki.php(543): MediaWiki->main()
#26 /var/www/html/w/index.php(53): MediaWiki->run()
#27 /var/www/html/w/index.php(46): wfIndexMain()
#28 {main}

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Trying to access array offset on value of type bool in Setup.php:563

[Jeffrey Walton]

On Tue, Mar 30, 2021 at 10:37 AM Jeffrey Walton  wrote:
>
> Hi Everyone,
>
> This caught my eye when running one of my maintenance scripts. The
> Setup.php:563 warning is new.
>
> The warning was not present on the old CentOS machine. The new machine
> is Ubuntu 20, PHP 7.4, MySQL 8, Mediawiki 1.35.1.
>
> # php /var/www/html/w/maintenance/generateSitemap.php ...
>
> PHP Notice:  Trying to access array offset on value of type bool in
> /var/www/html/w/includes/Setup.php on line 563

Here is the code in question:

   557  // Set server name
   558  $serverParts = wfParseUrl( $wgCanonicalServer );
   559  if ( $wgServerName !== false ) {
   560  wfWarn( '$wgServerName should be derived from
$wgCanonicalServer, '
   561  . 'not customized. Overwriting $wgServerName.' );
   562  }
   563  $wgServerName = $serverParts['host'];
   564  unset( $serverParts );

Would adding an:

if ( is_array( $serverParts ) )
$wgServerName = $serverParts['host'];

Be the proper fix here?

If not, what is the proper fix?

Thanks in advance.

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] MediaWiki cannot access database after upgrade

[Jeffrey Walton]

On Tue, Mar 30, 2021 at 4:30 PM Bart Everson  wrote:
>
> Happy to report that I fixed the problem described in my previous query. I 
> did it by making a fresh install in a new database, which generated a proper 
> LocalSettings.php file. Edited this to point to the old database and  voila 
> -- everything fixed.
>
> So, it would seem the upgrade process may have some issue with old 
> LocalSettings.php files. Hope this helps somebody.

Yeah, that seems to happen on occasion with old LocalSettings.php from
previous installations. We have experienced it several times because
we started our wiki in 2005 or so.

One other thing you should be sure to do... run 'php
maintenance/update.php' after each upgrade. If the database changes,
then update.php is what handles the changes for you.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Problem granting privileges to mediawiki user

[Jeffrey Walton]

On Tue, Mar 30, 2021 at 10:23 AM Elias Holzmann
 wrote:
>
> Looks like this syntax was removed in MySQL 8.0:
>
> "The following features related to account management have been removed:
> - ...
> - IDENTIFIED BY PASSWORD 'hash_string' syntax for CREATE USER and GRANT. 
> Instead, use IDENTIFIED WITH auth_plugin AS 'hash_string' for CREATE USER and 
> ALTER USER, where the 'hash_string' value is in a format compatible with the 
> named plugin."
>
> https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-11.html
>
> I guess you can just remove the "IDENTIFIED BY 'password'" part from the 
> query as long as the user was already created, but I'm not really a MySQL 
> guru, so YMMV.

Oh, thank you very much. I would not have checked a MySQL change log.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Trying to access array offset on value of type bool in Setup.php:563

[Jeffrey Walton]

Hi Everyone,

This caught my eye when running one of my maintenance scripts. The
Setup.php:563 warning is new.

The warning was not present on the old CentOS machine. The new machine
is Ubuntu 20, PHP 7.4, MySQL 8, Mediawiki 1.35.1.

# php /var/www/html/w/maintenance/generateSitemap.php ...

PHP Notice:  Trying to access array offset on value of type bool in
/var/www/html/w/includes/Setup.php on line 563
Wikimedia\Rdbms\DBConnectionError from line 1420 of
/var/www/html/w/includes/libs/rdbms/loadbalancer/LoadBalancer.php:
Cannot access the database: Unknown error (localhost)
#0 /var/www/html/w/includes/libs/rdbms/loadbalancer/LoadBalancer.php(934):
Wikimedia\Rdbms\LoadBalancer->reportConnectionError()
#1 /var/www/html/w/includes/libs/rdbms/loadbalancer/LoadBalancer.php(901):
Wikimedia\Rdbms\LoadBalancer->getServerConnection()
#2 /var/www/html/w/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1046):
Wikimedia\Rdbms\LoadBalancer->getConnection()
#3 /var/www/html/w/maintenance/includes/Maintenance.php(1371):
Wikimedia\Rdbms\LoadBalancer->getMaintenanceConnectionRef()
#4 /var/www/html/w/maintenance/generateSitemap.php(200): Maintenance->getDB()
#5 /var/www/html/w/maintenance/doMaintenance.php(107):
GenerateSitemap->execute()
#6 /var/www/html/w/maintenance/generateSitemap.php(564):
require_once('/var/www/html/w...')
#7 {main}

I think the exception is expected and due to some troubles with our
system users.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Problem granting privileges to mediawiki user

[Jeffrey Walton]

Hi Everyone,

We switched VPS providers. I am restoring a wiki database via a MySQL
dump. The import/source was successful, but it did not include the
users. The dump only had the wiki database.

The new machine uses:

# mysql --version
mysql  Ver 8.0.23-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

I am working from
https://www.mediawiki.org/wiki/Manual:Installation/Creating_system_accounts.
I am trying to grant privileges on our Mediawiki user account. I
manually created the account.

vm# mysql -u root -p


'my_wiki' and 'mwuser' are correct. They are used in LocalSettings.php.

mysql> show databases;
++
| Database   |
++
| information_schema |
| my_wiki|
| mysql  |
| performance_schema |
| sys|
++
5 rows in set (0.00 sec)

mysql> SELECT user FROM mysql.user;
+--+
| user |
+--+
| debian-sys-maint |
| mwuser   |
| mysql.infoschema |
| mysql.session|
| mysql.sys|
| root |
+--+
6 rows in set (0.00 sec)

Now, following the article:

mysql> GRANT ALL PRIVILEGES ON my_wiki.* TO 'mwuser'@'%' IDENTIFIED BY
'password' WITH GRANT OPTION ;
ERROR 1064 (42000): You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near 'IDENTIFIED BY 'password' WITH GRANT OPTION' at
line 1

I've tried removing pieces of the SQL statement, like omitting 'WITH
GRANT OPTION'. No joy.

Does anyone know what is wrong with the SQL statement?

Thanks in advance.

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Where are all the skins? (a call to action)

[Jeffrey Walton]

On Mon, Dec 21, 2020 at 6:37 PM Jon Robson  wrote:
>
> tldr: If you have built skins or use skins that are not listed on 
> MediaWiki.org, please list them [4] and check that they work with current 
> MediaWiki.org. If you have always wanted to build a skin try the new tool and 
> give me feedback on how you get on! [3].
>
> Longer version:
> As part of my involvement in the desktop improvements project  [1] I with the 
> help of many others have been trying to simplify the development of skins.
>
> As part of this, much-needed maintenance has occurred in MediaWiki core with 
> the intention of making skin development easier.
>
> As a personal goal, I wanted to prototype a tool to showcase the skins 
> available in the ecosystem, and finally with the downtime of the holiday 
> period (no deploys!) I've finally done that. It allows showcasing [2] and 
> building skins [3].
>
> While building this tool I was surprised to find that excluding forks of 
> skins, there are only __55 skins__ listed on MediaWiki.org. Out of those, 
> only 38 have been kept up to date.
>
> I can't believe that given the age of this project there are only 38 usable 
> skins and I am writing to you in the hope that:
>
> 1) You know of others that can be added to MediaWiki.org in the "Skin" 
> namespace [4] Note, any edits to MediaWiki.org will automatically get picked 
> up by the tool and listed.
> 2) If you build skins for closed source wikis, please consider publishing 
> them over the holiday period if you can!
> 3) If you have fix skins that do not work with latest MediaWiki so I can 
> showcase them on the new tool.
> 4) If you are inspired to make a new skin, possibly trying out the starter 
> kit tool I have created [3] which will construct a working zip file that can 
> be added to your local mediawiki and eventually github/gerrit and give me 
> feedback via Phabricator/email/github what can be improved.

I think a nice option for a tool (linter tool?) would be to ensure an
extension or skin using appropriate branch names, like REL1_34,
REL1_35, etc.

Several extensions and skins do not follow Mediawiki conventions. They
tell users to trust the developers' judgment, and not Mediawiki's
conventions. (See some comments for the Foregorund skin page).

They don't realize breaking Mediawiki convention break scripts like:

WIKI_DIR=/var/www/html/w
WIKI_REL=REL1_35

IFS= find "$WIKI_DIR/skins" -type d -name '.git' -print | while read -r dir
do
cd "$dir/.."
echo "Updating ${dir::-4}"
git reset --hard HEAD && git pull && \
  git checkout -f "$WIKI_REL" && git pull
done

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Missing icon since Mediawiki 1.35.1 upgrade

[Jeffrey Walton]

On Thu, Dec 17, 2020 at 9:05 PM Jeffrey Walton  wrote:
>
> Our Logo has gone missing since Mediawiki 1.35.1 upgrade (from
> Mediawiki 1.35.0). We get an image that says "Set the $wgLogos with
> the URL path to your own logo image".

Cancel... It was a permission problem.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Missing icon since Mediawiki 1.35.1 upgrade

[Jeffrey Walton]

Hi Everyone,

Our Logo has gone missing since Mediawiki 1.35.1 upgrade (from
Mediawiki 1.35.0). We get an image that says "Set the $wgLogos with
the URL path to your own logo image". Also see
https://www.cryptopp.com/wiki/Main_Page.

For Mediawiki 1.35.0 and earlier, we simply used $wgLogo. Things
worked well with $wgLogo.

At Mediawiki 1.35.1 we lost it, so we stopped using $wgLogo. Now we
use $wgLogos per
https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/DefaultSettings.php:

$ cat LocalSettings.php
...
$wgLogos= [
"1x" => "$wgScriptPath/resources/assets/wiki.png"
];

The logo is still located at resources/assets/wiki.png, and it is
135x135. That has not changed.

# cd <.../mediawiki>
# ls resources/assets/wiki.png
resources/assets/wiki.png

Any ideas what may be wrong?

Thanks.

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Should the webserver have access to maintenance directory?

[Jeffrey Walton]

Hi Everyone,

Forgive my ignorance... Should the webserver have access to the
maintenance/ directory?

The reason I ask is, I run scripts from maintenance/ manually, like
update.php. But it is not clear to me if the webserver should be
running anything on its own.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Fatal error: Interface 'MediaWiki\Hook\TestCanonicalRedirectHook' not found in /var/www/html/w/includes/HookContainer/HookRunner.php on line 22

[Jeffrey Walton]

On Tue, Dec 15, 2020 at 7:57 PM Jeffrey Walton  wrote:
>
> On Tue, Dec 15, 2020 at 7:27 PM John  wrote:
> >
> > there should be a file located at 
> > /includes/Hook/TestCanonicalRedirectHook.php
> >
> > https://github.com/wikimedia/mediawiki/blob/master/includes/Hook/TestCanonicalRedirectHook.php
>
> Perfect, thank you very much.

John, I have to ask...

Why was it not called RegisterCanonicalRedirect? Where did Test come from?

/**
* This is a hook handler interface, see docs/Hooks.md.
* Use the hook name "TestCanonicalRedirect" to register handlers
implementing this interface.
*
* @stable to implement
* @ingroup Hooks
*/

Based on the comment, it seems like a better name and it avoids
masquerading as a Test component.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Fatal error: Interface 'MediaWiki\Hook\TestCanonicalRedirectHook' not found in /var/www/html/w/includes/HookContainer/HookRunner.php on line 22

[Jeffrey Walton]

On Tue, Dec 15, 2020 at 7:27 PM John  wrote:
>
> there should be a file located at /includes/Hook/TestCanonicalRedirectHook.php
>
> https://github.com/wikimedia/mediawiki/blob/master/includes/Hook/TestCanonicalRedirectHook.php

Perfect, thank you very much.

Jeff

> On Tue, Dec 15, 2020 at 7:21 PM Jeffrey Walton  wrote:
>>
>> On Tue, Dec 15, 2020 at 7:02 PM John  wrote:
>> >
>> > That's not a development "test", rather it's a function interface that 
>> > should be kept.

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Fatal error: Interface 'MediaWiki\Hook\TestCanonicalRedirectHook' not found in /var/www/html/w/includes/HookContainer/HookRunner.php on line 22

[Jeffrey Walton]

On Tue, Dec 15, 2020 at 7:02 PM John  wrote:
>
> That's not a development "test", rather it's a function interface that should 
> be kept.

Thanks.

Would you happen to know the file or directory name of the offender? I
don't seem to have a directory called "TestCanonicalRedirectHook".
"HookRunner.php" will not trigger the removal.

  cd /tmp
  wget https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.tar.gz
  tar -xzf mediawiki-1.35.0.tar.gz
  cd mediawiki-1.35.0
  find . -iname 'TestCanonicalRedirectHook'
  

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Fatal error: Interface 'MediaWiki\Hook\TestCanonicalRedirectHook' not found in /var/www/html/w/includes/HookContainer/HookRunner.php on line 22

[Jeffrey Walton]

Hi Everyone,

I'm working on a Mediawiki 1.34 to 1.35 migration. The migration is
mostly complete. I'm having trouble connecting to the wiki after a
restart. https://www.cryptopp.com/wiki/ results in:

Fatal error: Interface 'MediaWiki\Hook\TestCanonicalRedirectHook' not found
in /var/www/html/w/includes/HookContainer/HookRunner.php on line 22

This is a new issue for us. We did not experience it in previous
versions of Mediawiki. I think the problem may be caused by this in
our maintenance script
(https://github.com/weidai11/website/blob/master/mediawiki/update-wiki.sh#L61):

# Remove all test frameworks in production.
IFS= find "$WIKI_DIR" -iname 'test*' -print | while read -r dir
do
rm -rf "$dir" 2>/dev/null
done

We don't want the additional attack surface on a production server.
Would someone please advise how to remove the unwanted testing gear?

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Mediawiki 1.35 download missing warnings and notes

[Jeffrey Walton]

Hi Everyone,

There are two warnings and one note on the Mediawiki 1.35 page at
https://www.mediawiki.org/wiki/MediaWiki_1.35.

One warning and one note is missing from the Mediawiki 1.35 download
page at https://www.mediawiki.org/wiki/Download.

I don't know how to add the warning and note to the Mediawiki download
page. It is coming from a template from an unknown location [to me].

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] MediaWiki 1.34 is End of Life

[Jeffrey Walton]

On Mon, Nov 30, 2020 at 11:28 PM Jeffrey Walton  wrote:
>
> On Mon, Nov 30, 2020 at 6:26 PM Jeffrey Walton  wrote:
> >
> > On Mon, Nov 30, 2020 at 5:31 PM Sam Reed  wrote:
> > >
> > > As per the MediaWiki version lifecycle,[1] I would like to announce the 
> > > formal end of life (EOL) of MediaWiki 1.34 as of today, Monday November 
> > > 30, 2020.
> > >
> > > This means that MediaWiki 1.34 will no longer receive maintenance or 
> > > security backports. It is therefore strongly discouraged that you 
> > > continue to use it.
> > >
> > > It is recommended to upgrade to MediaWiki 1.35, the current Long Term 
> > > Support (LTS) version which is not due to become EOL until September 
> > > 2023. The legacy Long Term Support version of MediaWiki, MediaWiki 1.31, 
> > > is older and downgrading is not supported.
> > >
> > > MediaWiki 1.35 bumps the required PHP version from 7.2.9 in 1.34 (which 
> > > is unsupported upstream), to PHP 7.3.19 or later.
> >
> > CentOS 7 recently bumped PHP to version 7.3.20 when the SCL is
> > enabled. CentOS 7 users with SCL enabled should be OK to migrate to
> > Mediawiki 1.35.
> >
> > Also see https://bugs.centos.org/view.php?id=17826.
>
> My bad... I just tested CentOS 7 with SCL in my test environment. The
> PHP changes for CentOS 7 with SCL has not landed in production. It is
> still providing the down-level version of PHP.

Red Hat released the PHP 7.3.20 update to production today. It looks
like it is safe to migrate to Mediawiki 1.35.

Also see https://bugs.centos.org/view.php?id=17826.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] database problem

[Jeffrey Walton]

On Fri, Dec 11, 2020 at 2:48 PM Skh sourav Halder
 wrote:
>
> My problem
>
> /home/skhsblsb/bn.gyaanipedia.co.in/wiki/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?

You need to state all the steps you performed that led to the error.

Or, you can try following Jonathan's advice.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] database problem

[Jeffrey Walton]

On Fri, Dec 11, 2020 at 10:56 AM Skh sourav Halder
 wrote:
>
> Wikimedia\Rdbms\DBQueryError from line 1699 of 
> /home/skhsblsb/bn.gyaanipedia.co.in/wiki/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?
>
> How do I update the database

As Jonathan suggested, it sounds like update.php needs to be run. The
script is located in the maintenance/ folder.

In case you don't have a procedure to update a Mediawiki installation,
here's the process we use on a free/open source software project:
https://github.com/weidai11/website/blob/master/mediawiki/wiki-upgrade.txt.

I've never had a Mediawiki upgrade or migration go sideways by
following the instructions.

We have not performed a Mediawiki 1.35 migration yet. We are in a
holding pattern because of the PHP 7.3.19 requirement. CentOS 7 only
provides PHP 7.3.11. We are waiting for relief from either Mediawiki
(lower PHP requirements) or CentOS (provide an updated PHP).

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] MediaWiki 1.34 is End of Life

[Jeffrey Walton]

On Mon, Nov 30, 2020 at 6:26 PM Jeffrey Walton  wrote:
>
> On Mon, Nov 30, 2020 at 5:31 PM Sam Reed  wrote:
> >
> > As per the MediaWiki version lifecycle,[1] I would like to announce the 
> > formal end of life (EOL) of MediaWiki 1.34 as of today, Monday November 30, 
> > 2020.
> >
> > This means that MediaWiki 1.34 will no longer receive maintenance or 
> > security backports. It is therefore strongly discouraged that you continue 
> > to use it.
> >
> > It is recommended to upgrade to MediaWiki 1.35, the current Long Term 
> > Support (LTS) version which is not due to become EOL until September 2023. 
> > The legacy Long Term Support version of MediaWiki, MediaWiki 1.31, is older 
> > and downgrading is not supported.
> >
> > MediaWiki 1.35 bumps the required PHP version from 7.2.9 in 1.34 (which is 
> > unsupported upstream), to PHP 7.3.19 or later.
>
> CentOS 7 recently bumped PHP to version 7.3.20 when the SCL is
> enabled. CentOS 7 users with SCL enabled should be OK to migrate to
> Mediawiki 1.35.
>
> Also see https://bugs.centos.org/view.php?id=17826.

My bad... I just tested CentOS 7 with SCL in my test environment. The
PHP changes for CentOS 7 with SCL has not landed in production. It is
still providing the down-level version of PHP.

$ php --version
PHP 7.3.11 (cli) (built: Dec 10 2019 16:14:50) ( NTS )
Copyright (c) 1997-2018 The PHP Group

You should not upgrade to Mediawiki 1.35.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] MediaWiki 1.34 is End of Life

[Jeffrey Walton]

On Mon, Nov 30, 2020 at 5:31 PM Sam Reed  wrote:
>
> As per the MediaWiki version lifecycle,[1] I would like to announce the 
> formal end of life (EOL) of MediaWiki 1.34 as of today, Monday November 30, 
> 2020.
>
> This means that MediaWiki 1.34 will no longer receive maintenance or security 
> backports. It is therefore strongly discouraged that you continue to use it.
>
> It is recommended to upgrade to MediaWiki 1.35, the current Long Term Support 
> (LTS) version which is not due to become EOL until September 2023. The legacy 
> Long Term Support version of MediaWiki, MediaWiki 1.31, is older and 
> downgrading is not supported.
>
> MediaWiki 1.35 bumps the required PHP version from 7.2.9 in 1.34 (which is 
> unsupported upstream), to PHP 7.3.19 or later.

CentOS 7 recently bumped PHP to version 7.3.20 when the SCL is
enabled. CentOS 7 users with SCL enabled should be OK to migrate to
Mediawiki 1.35.

Also see https://bugs.centos.org/view.php?id=17826.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] update.php "Cannot access the database" after upgrade to 1.31

[Jeffrey Walton]

On Sun, Nov 29, 2020 at 5:24 AM MI  wrote:
>
> I upgraded a Debian 9 "Stretch" server to Debian 10 "Buster", which also 
> upgrades Mediawiki to version 1.31.
>
> Trying to run update.php, it fails with "Cannot access the database: No 
> database connection":

It sounds like you have a MySQL (or Postgres) problem.

There can be a few causes of MySQL problems. An upgrade can overwrite
mysql.conf. The directory permissions are not correct for MySQL
(especially logging).

I think you should first ensure MySQL is started and running.
https://duckduckgo.com/?q=troubleshot+mysql+start+problem.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Script to check prerequisites?

[Jeffrey Walton]

Hi Everyone,

I'm currently on Mediawki 1.34. I want to migrate to Mediawiki 1.35.

I'd like to run a script to verify the machine is in the proper state
for a Mediawiki 1.35 migration. I want to ensure Linux, MySQL, Apache,
PHP, and friends satisfy 1.35's requirements.

https://www.mediawiki.org/wiki/MediaWiki_1.35 discusses the need for a
PHP version but not other requirements. There are too many Changelog's
(there are 33 of them). It is too much work for a simple task.

Does Mediawki provide a script to verify requirements? If so, where
can I find it?

Thanks in advance.

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Noisy Mediawiki 1.34.4 upgrade

[Jeffrey Walton]

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

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] php_uname() has been disabled for security reasons...

[Jeffrey Walton]

On Thu, Sep 24, 2020 at 8:53 PM Brian Wolff  wrote:
>
>
>
> On Thursday, September 24, 2020, Jeffrey Walton  wrote:
>>
>> On Thu, Sep 24, 2020 at 6:37 PM Tim Starling  wrote:
>> >
>> > On 25/9/20 5:34 am, Jeffrey Walton wrote:
>> > > 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:
>> > >
>> > > 
>> > > Warning:  php_uname() has been disabled for security reasons in
>> > > /var/www/html/w/includes/GlobalFunctions.php on line
>> > > 1333
>> > > 
>> > > 
>> > > 
>> > > ...
>> > >
>> > > Any ideas how to fix things?
>> >
>> > Set $wgOverrideHostname.
>>
>> Thanks. I guess that is new. We don't seem to have it in LocalSettings.php:
>>
>> [...]
>
> It normally wouldn't be in LocalSettings.php, you would have to add it 
> yourself. If its not present in LocalSettings.php then its default value is 
> used.

Thanks.

Out of curiosity, why is "unknown" used instead of "localhost"?
localhost is a standard hostname. Are there negative side effects from
using localhost?

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] php_uname() has been disabled for security reasons...

[Jeffrey Walton]

On Thu, Sep 24, 2020 at 6:37 PM Tim Starling  wrote:
>
> On 25/9/20 5:34 am, Jeffrey Walton wrote:
> > 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:
> >
> > 
> > Warning:  php_uname() has been disabled for security reasons in
> > /var/www/html/w/includes/GlobalFunctions.php on line
> > 1333
> > 
> > 
> > 
> > ...
> >
> > Any ideas how to fix things?
>
> Set $wgOverrideHostname.

Thanks. I guess that is new. We don't seem to have it in LocalSettings.php:

# grep -i name /var/www/html/w/LocalSettings.php
$IP = dirname( __FILE__ );
#   match the server name in httpd.conf or logon will break
$wgSitename = 'Crypto++ Wiki';
...
$wgDBname   = "my_wiki";
$wgLocalInterwiki   = $wgSitename;

> ...
> If that's the level of paranoia you're at, you should probably also
> disable Special:Version, which is routinely crawled and can be used to
> rapidly exploit vulnerable MediaWiki installations after a
> vulnerability is announced. In LocalSettings.php:
>
> $wgSpecialPages['Version'] = DisabledSpecialPage::getCallback(
> 'Version' );

Yeah, I've been thinking about that for some time now.

What it comes down to is, when we ask for help, you need accurate
information to help us. If I remove Special:Version then you don't
have the information you need. I don't want to screw you by taking
that information away.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] php_uname() has been disabled for security reasons...

[Jeffrey Walton]

On Thu, Sep 24, 2020 at 5:17 PM Valerio Bozzolan via MediaWiki-l
 wrote:
>
> Well,
>
> In the meanwhile I would suggest to contact your hosting provider: they 
> should remove the php_uname() function from the disabled_functions directive.

That's us. We run a hardened installation:
https://github.com/weidai11/website/blob/master/apache-php/security.ini.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] php_uname() has been disabled for security reasons...

[Jeffrey Walton]

On Thu, Sep 24, 2020 at 3:34 PM Jeffrey Walton  wrote:
>
> 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:
>
> 
> Warning:  php_uname() has been disabled for security reasons in
> /var/www/html/w/includes/GlobalFunctions.php on line
> 1333
> 
> 
> 
> ...
>
> Any ideas how to fix things?

According to https://stackoverflow.com/q/47373937, the '@' can be used
to suppress the warning:

function wfHostname() {
// Hostname overriding
global $wgOverrideHostname;
if ( $wgOverrideHostname !== false ) {
return $wgOverrideHostname;
}

return @php_uname( 'n' ) ?: 'unknown';
}

But I am not sure that is the best approach here. It seems like there
should be an alternative method for this. For example, on [systemd]
startup, run a shell script that executes 'uname -n' and write the
result to a file. Then, have wfHostname() read the value from the
file, if present.

Can anyone confirm it's OK to add the '@' to silence the warning
(rather than fixing the function)?

(And I am not sure about the other transgressions present in an installation).

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] php_uname() has been disabled for security reasons...

[Jeffrey Walton]

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:


Warning:  php_uname() has been disabled for security reasons in
/var/www/html/w/includes/GlobalFunctions.php on line
1333



...

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',

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] (no subject)

[Jeffrey Walton]

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

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] RedirectSpecialPage.php Shared Host File Deletion

[Jeffrey Walton]

On Mon, Aug 17, 2020 at 3:09 PM Tom Hutchison via MediaWiki-l
 wrote:
>
> So, I'm just thinking out loud here to blow off steam.  I've seen
> mod_security block MW edits and some other weird things on shared hosting.
>
> Apparently, a shared host I admin for a project must have enabled some type
> of proactive scanning with ClamAV or more like a ClamAV Frankenstein and it
> is throwing false positive on RedirectSpecialPage.php. Trying to add it back
> manually, I can create the file but as soon as I add in the code. the host
> deletes it. I tried uploading it. Denied with message ->
>
> "The file you uploaded, RedirectSpecialPage.php, contains a virus so the
> upload was canceled: YARA.blackhole_basic.UNOFFICIAL FOUND"
>
> Obvious it is a false positive, but WOW. Posting just in case someone else
> is dealing with a stupid hosting provider who likes to flip switches and
> fails to poll then review the consequences before actually flipping the
> switches.

Yeah, mod_security does get a bit aggressive. The one annoys me is the
horizontal rule I sometimes use as a break instead of a full blown
heading, like H4 or H5:

  -

mod_security blocks that when the first two chars in a line are dash.
I often have to turn off mod_security to submit the page.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Mediawiki on Mint 19.3 (was: Security and maintenance release...)

[Jeffrey Walton]

On Wed, Jun 24, 2020 at 2:16 PM Marshall Lake  wrote:
>
> I'm running an older version of MediaWiki ... 1.27.4
>
> I installed it via the Software Manager on Mint 19.3.  1.27.4 seems to be
> the only version available on the Software Manager.  I attempted to
> install a later version via a tarball but ran into problems.
>
> Is it possible to obtain a current version using the Software Manager?

I don't have a Mint 19.3 release to test, but you can probably get
something more recent if you perform a dist-upgrade. But it probably
won't be the latest, like MW 1.34.2.

When working with distros that provide old software, you will probably
need to do something like this:
https://github.com/weidai11/website/blob/master/mediawiki/wiki-upgrade.txt.
They are the instructions I use to keep a CentOS 7 box current.

If that looks too complex, then consider moving to Fedora. Fedora
provides the latest software available during its release. Fedora
releases every 6 months, so every 6 months you do the equivalent of a
dist-upgrade using
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Mediawiki 1.34.2 upgrade results

[Jeffrey Walton]

Hi Everyone,

I upgraded to Mediawiki 1.34.2 on a CentOS 7 x86_64 server.

The composer update produced some noise:

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/phpunit-mock-objects is abandoned, you should avoid
using it. No replacement was suggested.

The server information is located at
https://www.cryptopp.com/wiki/Special:Version.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] How to hook a 404'd request in an extension?

[Jeffrey Walton]

Hi Everyone,

I've been reading
https://www.mediawiki.org/wiki/Manual:Developing_extensions. I'm not
clear on how to hook a request for a URL. In particular, I want to
hook 404's and examine the URL.

How do I wire-up an extension to examine requests?

Thanks in advance.

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] MW 1.34 cleanupUsersWithNoId.php may be out of sync

[Jeffrey Walton]

Hi Everyone,

We upgraded to MW 1.34.1. maintenance/update.php was run during the
upgrade process.

We are now doing post-install maintenance, like running a cleanup
script (https://github.com/weidai11/website/blob/master/root/cleanup-wiki.sh).
The script is complaining:

Wikimedia\Rdbms\DBQueryError from line 1603 of
/var/www/html/w/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  ar_id,ar_user,ar_user_text,ar_id  FROM
`wikicryptopp_archive`WHERE (1=1)  ORDER BY ar_id LIMIT 100
Function: CleanupUsersWithNoId::cleanup
Error: 1054 Unknown column 'ar_user' in 'field list' (localhost)

#0 /var/www/html/w/includes/libs/rdbms/database/Database.php(1574):
Wikimedia\Rdbms\Database->getQueryExceptionAndLog('Unknown column
...', 1054, 'SELECT  ar_id,a...', 'CleanupUsersWit...')
#1 /var/www/html/w/includes/libs/rdbms/database/Database.php(1152):
Wikimedia\Rdbms\Database->reportQueryError('Unknown column ...', 1054,
'SELECT  ar_id,a...', 'CleanupUsersWit...', false)
#2 /var/www/html/w/includes/libs/rdbms/database/Database.php(1807):
Wikimedia\Rdbms\Database->query('SELECT  ar_id,a...',
'CleanupUsersWit...')
#3 /var/www/html/w/includes/libs/rdbms/database/DBConnRef.php(68):
Wikimedia\Rdbms\Database->select('archive', Array, Array,
'CleanupUsersWit...', Array)
#4 /var/www/html/w/includes/libs/rdbms/database/DBConnRef.php(315):
Wikimedia\Rdbms\DBConnRef->__call('select', Array)
#5 /var/www/html/w/maintenance/cleanupUsersWithNoId.php(153):
Wikimedia\Rdbms\DBConnRef->select('archive', Array, Array,
'CleanupUsersWit...', Array)
#6 /var/www/html/w/maintenance/cleanupUsersWithNoId.php(63):
CleanupUsersWithNoId->cleanup('archive', Array, 'ar_user',
'ar_user_text', Array, Array)
#7 /var/www/html/w/maintenance/Maintenance.php(1746):
CleanupUsersWithNoId->doDBUpdates()
#8 /var/www/html/w/maintenance/doMaintenance.php(99):
LoggedUpdateMaintenance->execute()
#9 /var/www/html/w/maintenance/cleanupUsersWithNoId.php(212):
require_once('/var/www/html/w...')
#10 {main}

The script used to work with MW 1.33.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] How to temp ban hosts based on requests

[Jeffrey Walton]

On Sun, Apr 19, 2020 at 6:38 PM Keith Christian
 wrote:
>
> Try fail2ban, it is an excellent filtering system that blocks IP
> addresses based on what it finds in log files, you'd point fail2ban at
> the web server logs, e.g. Apache logs or whatever http server is on
> your Mediawiki server.

Thanks Keith.

It does not look a fail (to me). The 301's are redirects from http to
https. The 200's are successes.

It seems like Mediawiki should know it is incorrect for someone to
request load.php. The request should be killed in the application.
Mediawiki has the specialized knowledge required to stop the
shenanigans.

Jeff

> On Sun, Apr 19, 2020 at 12:51 PM Jeffrey Walton  wrote:
> >
> > Hi Everyone,
> >
> > We see a continuous flow of requests like shown below. We are fairly
> > certain it is a botnet probing for weaknesses or vulnerabilities. The
> > source IP address slowly moves around. It looks like there was a bug
> > in load.php some time ago [1].
> >
> > I don't have time to manually monitor this. We are looking for one of
> > those wiki plugins to handle it at the application layer.
> >
> > How do we ban the host for making these probes for a day or a week?
> >
> > Thanks in advance.
> >
> > [1] https://www.mediawiki.org/wiki/Topic:Sl0d755pv10sjxl0
> >
> > 92.32.245.123 - - [19/Apr/2020:14:41:12 -0400] "GET
> > /w/load.php?lang=en=mediawiki.helplink%2Cspecial%2Cui%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cmediawiki.special.search.styles%7Cmediawiki.ui.button%2Cinput%7Cmediawiki.widgets.SearchInputWidget.styles%7Cmediawiki.widgets.styles%7Coojs-ui-core.styles%7Coojs-ui.styles.icons-alerts%2Cicons-content%2Cicons-interactions%2Cindicators%2Ctextures%7Cskins.vector.styles=styles=vector
> > HTTP/1.1" 200 28580
> > 92.32.245.123 - - [19/Apr/2020:14:41:13 -0400] "GET
> > /w/load.php?debug=false=en=ext.SmjCDN%7Cjquery%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Cjquery.accessKeyLabel%2CcheckboxShiftClick%2Cclient%2CgetAttrs%2ChighlightText%2Csuggestions%2CtabIndex%2Cthrottle-debounce%7Cmediawiki.RegExp%2CString%2CTitle%2Capi%2Cbase%2Ccldr%2Clanguage%2CsearchSuggest%2Cutil%2Cwidgets%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.special.search%7Cmediawiki.widgets.SearchInputWidget%7Coojs-ui.styles.icons-editing-advanced%2Cicons-moderation%2Cicons-movement%7Cskins.vector.js%7Cuser.defaults=vector=1rf1ap1
> > HTTP/1.1" 200 144182
> > 92.32.245.123 - - [19/Apr/2020:14:41:15 -0400] "GET
> > /wiki/Debug_Symbols HTTP/1.1" 200 7733
> > 92.32.245.123 - - [19/Apr/2020:14:41:16 -0400] "GET
> > /w/load.php?lang=en=mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cmediawiki.toc.styles%7Cskins.vector.styles=styles=vector
> > HTTP/1.1" 200 8880
> > 92.32.245.123 - - [19/Apr/2020:14:41:16 -0400] "GET
> > /w/load.php?debug=false=en=ext.SmjCDN%7Cjquery%2Csite%7Cjquery.accessKeyLabel%2CcheckboxShiftClick%2Cclient%2Ccookie%2CgetAttrs%2ChighlightText%2Csuggestions%2CtabIndex%2Cthrottle-debounce%7Cmediawiki.RegExp%2CString%2CTitle%2Capi%2Cbase%2Ccookie%2CsearchSuggest%2Ctoc%2Cutil%7Cmediawiki.page.ready%2Cstartup%7Cskins.vector.js%7Cuser.defaults=vector=1j07wt1
> > HTTP/1.1" 200 68744
> >
> > ___
> > MediaWiki-l mailing list
> > To unsubscribe, go to:
> > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
> ___
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] How to temp ban hosts based on requests

[Jeffrey Walton]

Hi Everyone,

We see a continuous flow of requests like shown below. We are fairly
certain it is a botnet probing for weaknesses or vulnerabilities. The
source IP address slowly moves around. It looks like there was a bug
in load.php some time ago [1].

I don't have time to manually monitor this. We are looking for one of
those wiki plugins to handle it at the application layer.

How do we ban the host for making these probes for a day or a week?

Thanks in advance.

[1] https://www.mediawiki.org/wiki/Topic:Sl0d755pv10sjxl0

92.32.245.123 - - [19/Apr/2020:14:41:12 -0400] "GET
/w/load.php?lang=en=mediawiki.helplink%2Cspecial%2Cui%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cmediawiki.special.search.styles%7Cmediawiki.ui.button%2Cinput%7Cmediawiki.widgets.SearchInputWidget.styles%7Cmediawiki.widgets.styles%7Coojs-ui-core.styles%7Coojs-ui.styles.icons-alerts%2Cicons-content%2Cicons-interactions%2Cindicators%2Ctextures%7Cskins.vector.styles=styles=vector
HTTP/1.1" 200 28580
92.32.245.123 - - [19/Apr/2020:14:41:13 -0400] "GET
/w/load.php?debug=false=en=ext.SmjCDN%7Cjquery%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Cjquery.accessKeyLabel%2CcheckboxShiftClick%2Cclient%2CgetAttrs%2ChighlightText%2Csuggestions%2CtabIndex%2Cthrottle-debounce%7Cmediawiki.RegExp%2CString%2CTitle%2Capi%2Cbase%2Ccldr%2Clanguage%2CsearchSuggest%2Cutil%2Cwidgets%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.special.search%7Cmediawiki.widgets.SearchInputWidget%7Coojs-ui.styles.icons-editing-advanced%2Cicons-moderation%2Cicons-movement%7Cskins.vector.js%7Cuser.defaults=vector=1rf1ap1
HTTP/1.1" 200 144182
92.32.245.123 - - [19/Apr/2020:14:41:15 -0400] "GET
/wiki/Debug_Symbols HTTP/1.1" 200 7733
92.32.245.123 - - [19/Apr/2020:14:41:16 -0400] "GET
/w/load.php?lang=en=mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cmediawiki.toc.styles%7Cskins.vector.styles=styles=vector
HTTP/1.1" 200 8880
92.32.245.123 - - [19/Apr/2020:14:41:16 -0400] "GET
/w/load.php?debug=false=en=ext.SmjCDN%7Cjquery%2Csite%7Cjquery.accessKeyLabel%2CcheckboxShiftClick%2Cclient%2Ccookie%2CgetAttrs%2ChighlightText%2Csuggestions%2CtabIndex%2Cthrottle-debounce%7Cmediawiki.RegExp%2CString%2CTitle%2Capi%2Cbase%2Ccookie%2CsearchSuggest%2Ctoc%2Cutil%7Cmediawiki.page.ready%2Cstartup%7Cskins.vector.js%7Cuser.defaults=vector=1j07wt1
HTTP/1.1" 200 68744

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Mediawiki 1.33, Apache Event MDM, Wiki displays "run(); "

[Jeffrey Walton]

> Make sure you have Mod_php enabled  in the apache modules.

It looks like php-fpm broke PHP. I installed it because someone said
it was needed for Event MDM. I switched back to that prefork pig. Once
I removed php-fpm  things started working again.

Jeff


On Fri, Apr 17, 2020 at 11:00 AM Jonathan Aquilina
 wrote:
>
> Make sure you have Mod_php enabled  in the apache modules.
>
> -Original Message-
> From: MediaWiki-l  On Behalf Of 
> Bartosz Dziewonski
> Sent: Friday, 17 April 2020 16:47
> To: mediawiki-l@lists.wikimedia.org
> Subject: Re: [MediaWiki-l] Mediawiki 1.33, Apache Event MDM, Wiki displays 
> "run(); "
>
> Your server is not executing the PHP code, rather it just displays the 
> contents of index.php, and your web browser interprets it as HTML.
>
> --
> Bartosz Dziewoński
>
> ___
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> ___
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Mediawiki 1.33, Apache Event MDM, Wiki displays "run(); "

[Jeffrey Walton]

On Fri, Apr 17, 2020 at 10:47 AM Bartosz Dziewoński  wrote:
>
> Your server is not executing the PHP code, rather it just displays the
> contents of index.php, and your web browser interprets it as HTML.

Thanks.

I'll take it to an Apache list to see what is wrong.

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Mediawiki 1.33, Apache Event MDM, Wiki displays "run(); "

[Jeffrey Walton]

Hi Everyone,

I'm trying to configure an Apache/2.4.34 server on CentOS 7 to use
Apache Event MDM. We need to switch because GoDaddy has been
suspending our service for using too much CPU time. Top shows it is
due to Apache processes. In addition we had chronic memory problems
and OOM kills.

I followed https://tecadmin.net/enable-event-mpm-in-apache-2-4/ and
got Event MDM running. Our web page at https://www.cryptopp.com/ loads
lightening fast. That's a nice improvement.

Our Mediawiki server is 1.33. It is located at
https://www.cryptopp.com/wiki/. The Event MDM change seems to have
broken our wiki. It just displays:

run();

Can anyone point out what might be wrong here?

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Installing MW on windows server 2016 browser does not support Unicode

[Jeffrey Walton]

On Mon, Mar 2, 2020 at 7:01 PM Bartosz Dziewoński  wrote:
>
> I can at least explain the error you're getting: when you edit any page,
> MediaWiki includes a hidden form field with the text 'ℳ풲♥퓊퓃풾풸ℴ풹ℯ'
> in the edit form. If this value doesn't arrive when you submit the form,
> it displays that error and prevents you from saving the edit to avoid
> corrupting pages. The error assumes your browser corrupted that text,
> but I guess it's also possible that your server or configuration might
> do it…

That's interesting.

I believe there is also a setting in LocalSettings.php that allows one
to set the character set for the database. This was my first guess:

$wgDBTableOptions   = "ENGINE=InnoDB CHARSET=utf8";

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] MediaWiki 1.32 is End of Life

[Jeffrey Walton]

On Thu, Jan 23, 2020 at 2:48 PM Sam Reed  wrote:
>
> As per the MediaWiki version life cycle [1], I would like to announce the
> formal end of life (EOL) of MediaWiki 1.32 as of tomorrow, Friday January
> 24, 2019.
>
> This means that MediaWiki 1.32 will no longer receive maintenance or
> security backports. It is therefore strongly discouraged that you continue
> to use it.
>
> It is recommended to upgrade to MediaWiki 1.34 (due to become EOL in
> November 2020), or less preferably to MediaWiki 1.33 (due to become EOL in
> June 2020). The current Long Term Support (LTS) version of MediaWiki,
> MediaWiki 1.31, is older (and downgrading is not supported), though the
> next LTS (MediaWiki 1.35) is due to be released in June 2020, and will be
> supported until June 2023.
>
> MediaWiki 1.33 has the same supported PHP version of 7.0 (which is itself
> unsupported upstream), in case you need longer to upgrade your systems.
> MediaWiki 1.34 requires PHP 7.2.9 or later.

This puts some folks in a bad position.

The latest CentOS 7 does not support the versions of Python and PHP
required, even with Software Collections (SCL) enabled.

(In hindsight a Red Hat-based VM was a bad decision. It ships with
antique software, and SCL only provides old software. We need modern
software, and should have selected a Fedora or Ubuntu VM).

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] User name "TammieDeLittle4" is usable, cannot create an anonymous actor for it.

[Jeffrey Walton]

On Fri, Dec 20, 2019 at 3:17 AM Valerio Pelliccioni  wrote:
>
> given that 'BrownHairedGirl'  was one of my 'spammers', you can do something 
> like this:
>
> MariaDB [tta]> select rev_user, rev_user_text  FROM revision WHERE 
> rev_user_text = 'BrownHairedGirl';
>
> and you'll get something like this:
>
> | rev_user  | rev_user_text   |
> --
> |0 |BrownHairedGirl |
> |0 |BrownHairedGirl |
> |0 |BrownHairedGirl |
> |0 |BrownHairedGirl |
> |0 |BrownHairedGirl |
> |0 |BrownHairedGirl |
> --

Thanks.

We found them in the logging table. We deleted the spammer's log entries with:

DELETE FROM wikicryptopp_logging
WHERE NOT EXISTS(SELECT NULL
FROM wikicryptopp_user users
WHERE users.user_name = log_user_text);

The query grabs the user's name from the logging table, and deletes
the row in the logging table if the user's name does not exist in the
user table.

For our wiki, the query deleted about 17,000 entries. After the query
cleanupUsersWithNoId.php ran as expected.

What got us in this state was, a spammer got in. We deleted all users
from the user table with id > 7. We had to recreate a few admin's
accounts, but it nuked all the spam accounts. So users table was clean
but logging table was dirty.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] User name "TammieDeLittle4" is usable, cannot create an anonymous actor for it.

[Jeffrey Walton]

On Thu, Dec 19, 2019 at 3:31 PM Valerio Pelliccioni  wrote:
>
> Jeff,
> I've tried in the maintenance directory (a minute ago):
>
> vmp@tunearch:/var/www/w/maintenance# php cleanupUsersWithNoId.php 
> --dbuser= --dbpass= --force --prefix=* --conf=../LocalSettings.php
> vmp@tunearch:/var/www/w/maintenance# php update.php
>
> ... and it works, at least for me with:

Thanks. Where are they coming from? maintenance/update.php is finding
them, but I can't.

Here is what I see when examining the MySQL tables.

MariaDB [my_wiki]> select count(*) from wikicryptopp_user;
+--+
| count(*) |
+--+
|7 |
+--+
1 row in set (0.00 sec)

MariaDB [my_wiki]> select count(*) from wikicryptopp_actor;
+--+
| count(*) |
+--+
|   13 |
+--+
1 row in set (0.00 sec)

MariaDB [my_wiki]> select count(*) from wikicryptopp_user_groups;
+--+
| count(*) |
+--+
|8 |
+--+
1 row in set (0.00 sec)

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] User name "TammieDeLittle4" is usable, cannot create an anonymous actor for it.

[Jeffrey Walton]

Hi Everyone,

We are getting about 11,000 of these due to a spammer getting in a
couple of years ago:

... log_id=4200
... log_id=4300
... log_id=4400
User name "Awpgkcm9ly0hjqagqrpl" is usable, cannot create an anonymous
actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this
situation.
...

$ grep -c 'anon' mw.txt
11748

I've tried manually cleaning them, but cleanupUsersWithNoId.php seems
to be missing them:

Error:
==

# php maintenance/cleanupUsersWithNoId.php --dbuser=
--dbpass= --force --conf=LocalSettings.php

Notice: Undefined index: SERVER_NAME in
/var/www/html/w/includes/GlobalFunctions.php on line 1388
Notice: Undefined index: SERVER_NAME in
/var/www/html/w/includes/GlobalFunctions.php on line 1388
Param prefix required!

Cleans up tables that have valid usernames with no user ID

Usage: php cleanupUsersWithNoId.php
[--assign|--batch-size|--conf|--dbgroupdefault|--dbpass|--dbuser|--force|--globals|--help|--memory-limit|--mwdebug|--prefix|--profiler|--quiet|--server|--table|--wiki]
...

Try again:
==

# php maintenance/cleanupUsersWithNoId.php --dbuser=
--dbpass= --prefix=* --force --conf=LocalSettings.php

Notice: Undefined index: SERVER_NAME in
/var/www/html/w/includes/GlobalFunctions.php on line 1388
Notice: Undefined index: SERVER_NAME in
/var/www/html/w/includes/GlobalFunctions.php on line 1388

But the entries persist.

I think I am not getting the options right. Here are the docs, but
they have not been helpful:
https://www.mediawiki.org/wiki/Manual:CleanupUsersWithNoId.php .

Does anyone know what switches I should be using to clean the unwanted users?

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Latest Debian version (Buster 10.2) new mediawiki install unable to connect to database

[Jeffrey Walton]

On Thu, Dec 19, 2019 at 2:07 PM Keith Christian
 wrote:
>
> Hello Friendly Mediawiki People,
>
> Fresh format-disk-and-install Buster 64-bit.
> This is my third attempt, with the mediawiki installer having problems
> logging in to MariaDB every time.
> I've installed mediawiki (Jessie?) with zero problems.
>
> NOTE-MariaDB was installed with a simple "sudo apt -y install
> mediawiki" as described below.
> Ran "sudo apt -y install mediawiki" without installing any other software.
> Rebooted.
>
> Opened browser to http://localhost/mediawiki/.
> Got this screen:
> MediaWiki 1.31.4
> LocalSettings.php not found.
> Please set up the wiki first.
>
> Clicked the "set up the wiki" link.
> Got this status "The environment has been checked. You can install MediaWiki."
>
> Clicked Continue.
> Got this:
> Cannot access the database: No such file or directory (localhost).
> Check the host, username and password and try again.
>
> Started MariaDB with this command line:
> sudo mysqld_safe --skip-grant-tables &
>
> Able to log in as the MariaDB root user via mysql -u root.
> Attempted to set the root password since mediawiki setup didn't like
> the login info.
> Unable to reset the root password:
> MariaDB [(none)]> SET PASSWORD FOR 'root'@'localhost' =
> PASSWORD('secret_password');
> ERROR 1131 (42000): You are using MariaDB as an anonymous user
> and anonymous users are not allowed to modify user settings
> MariaDB [(none)]> select user();
> ++
> | user() |
> ++
> | root@  |
> ++
> Exit mysql client.
>
> Ran "sudo apt -y purge mediawiki" hoping to destroy the MariaDB
> databases so I could get a fresh start solving mediawiki's db login
> problems.
> Rebooted.
>
> Ran "sudo apt -y install mediawiki" again, no MariaDB installation
> messages which meant the "purge mediawiki" did not also purge MariaDB
> (which it installed.)
> No success.
>
> Seems that the mediawiki installer has defaults for the 'root'
> database user with a blank password, doesn't work with that either.
>
> What is wrong?

Maybe 
https://www.mediawiki.org/wiki/Manual:Installing_MediaWiki#Create_a_database
?

Keep in mind I am probably one of the the worse guys to give advise
about maintaining MW software.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Next Mediawiki upgrade given CentOS 7 with PHP 7.1.30?

[Jeffrey Walton]

Hi Everyone,

We upgraded to 1.32.6 today. Everything looks OK. The 1.32.6 release
announcement said this is the last upgrade, and we should switch to
1.33 or 1.34.

We rent a CentOS 7 VM. It is fully patched. We enabled Software
Collections (SCL) to get something more modern for Apache and PHP. SCL
provides:

  * Apache 2.4.34
  * PHP 7.1.30
  * MariaDB 5.5.64

Also see https://www.cryptopp.com/wiki/Special:Version.

When we try the next upgrade to 1.34.0, we get the following when
trying to update the Vendor gear:

# php -d extension=phar.so composer.phar update
Do not run Composer as root/super user! See
https://getcomposer.org/root for details
> ComposerHookHandler::onPreUpdate
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
- This package requires php >=7.2.9 but your PHP version (7.1.30)
does not satisfy that requirement.
  Problem 2
- Installation request for mediawiki/mediawiki-codesniffer 28.0.0
-> satisfiable by mediawiki/mediawiki-codesniffer[v28.0.0].
- mediawiki/mediawiki-codesniffer v28.0.0 requires php >= 7.2.0 ->
your PHP version (7.1.30) does not satisfy that requirement.

What is the highest version of Mediawiki we can upgrade to?

Thanks in advance.

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Missing article text after 1.32.5 upgrade?

[Jeffrey Walton]

On Thu, Dec 5, 2019 at 11:22 AM Brian Wolff  wrote:
>
> This isnt consistent with the mobile view part, but this sounds like the 
> issue with imported users that can be fixed by running 
> cleanupUsersWithNoId.php followed by migrateActors.php

Thanks.

Does this look normal? I have never run the script, so I don't know
what normal looks like.

(The SERVER_NAME complaint is normal for this wiki).

-

# php cleanupUsersWithNoId.php --prefix=* --conf=../LocalSettings.php

Notice: Undefined index: SERVER_NAME in
/var/www/html/w/includes/GlobalFunctions.php on line 1416

Notice: Undefined index: SERVER_NAME in
/var/www/html/w/includes/GlobalFunctions.php on line 1416
...Update 'CleanupUsersWithNoId' already logged as completed.

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Missing article text after 1.32.5 upgrade?

[Jeffrey Walton]

On Thu, Dec 5, 2019 at 6:11 AM Jeffrey Walton  wrote:
>
> On Thu, Dec 5, 2019 at 5:35 AM Jeffrey Walton  wrote:
> >
> > I upgraded from MW 1.32.4 to 1.32.5 today. I noticed the body of some
> > articles are missing their text. For example, notice the synopsis for
> > https://www.cryptopp.com/w/index.php?search=Nmake . It has part of the
> > lead paragraph.
> >
> > However, when we follow to the article the text is missing. It is not 
> > isolated:
> >
> > * https://www.cryptopp.com/wiki/Nmake_(Command_Line)
> > * https://www.cryptopp.com/wiki/Scrypt
> > * https://www.cryptopp.com/wiki/P1363_KDF2
> > * https://www.cryptopp.com/wiki/PKCS12_PBKDF
> >   ...
> >
> > We regularly run one of the scripts in maintenance/ to collapse
> > article history. I think the script is deleteOldRevisions.php or
> > deleteArchivedRevisions.php . We don't need history due to our
> > workflows.
> >
> > Does anyone know what might be causing the issue?
>
> Cancel.
>
> This seems to be a Firefox on Windows 8.1 problem.
>
> Firefox on Linux is OK. Private Browsing Windows on Windows is OK.

It appears the problem is MobileView.

I was testing some of the appearance themes after the upgrade. One of
the things I tested was MobileView. After clicking MobileView, all the
article text disappears.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Missing article text after 1.32.5 upgrade?

[Jeffrey Walton]

On Thu, Dec 5, 2019 at 5:35 AM Jeffrey Walton  wrote:
>
> I upgraded from MW 1.32.4 to 1.32.5 today. I noticed the body of some
> articles are missing their text. For example, notice the synopsis for
> https://www.cryptopp.com/w/index.php?search=Nmake . It has part of the
> lead paragraph.
>
> However, when we follow to the article the text is missing. It is not 
> isolated:
>
> * https://www.cryptopp.com/wiki/Nmake_(Command_Line)
> * https://www.cryptopp.com/wiki/Scrypt
> * https://www.cryptopp.com/wiki/P1363_KDF2
> * https://www.cryptopp.com/wiki/PKCS12_PBKDF
>   ...
>
> We regularly run one of the scripts in maintenance/ to collapse
> article history. I think the script is deleteOldRevisions.php or
> deleteArchivedRevisions.php . We don't need history due to our
> workflows.
>
> Does anyone know what might be causing the issue?

Cancel.

This seems to be a Firefox on Windows 8.1 problem.

Firefox on Linux is OK. Private Browsing Windows on Windows is OK.

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Missing article text after 1.32.5 upgrade?

[Jeffrey Walton]

Hi Everyone,

I upgraded from MW 1.32.4 to 1.32.5 today. I noticed the body of some
articles are missing their text. For example, notice the synopsis for
https://www.cryptopp.com/w/index.php?search=Nmake . It has part of the
lead paragraph.

However, when we follow to the article the text is missing. It is not isolated:

* https://www.cryptopp.com/wiki/Nmake_(Command_Line)
* https://www.cryptopp.com/wiki/Scrypt
* https://www.cryptopp.com/wiki/P1363_KDF2
* https://www.cryptopp.com/wiki/PKCS12_PBKDF
  ...

We regularly run one of the scripts in maintenance/ to collapse
article history. I think the script is deleteOldRevisions.php or
deleteArchivedRevisions.php . We don't need history due to our
workflows.

Does anyone know what might be causing the issue?

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] UnexpectedValueException from line 961 of /var/www/html/.../loadbalancer/LoadBalancer.php

[Jeffrey Walton]

On Fri, Jun 7, 2019 at 4:43 PM reedy  wrote:
>
> Would you remind removing it again, and telling us where it's broken/what the
> actual error message is?
>
> $wgResourceLoaderLESSVars was removed in 1.32, but I'm guessing there's some
> extension you're using that still has a usage of it, and should be fixed

As I understand things, it is needed for Mobile FrontEnd.
https://www.mediawiki.org/wiki/Extension:MobileFrontend

Jeff

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l