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
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.
en 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
> :
>>
>>
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
ot;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
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].
rty
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
> 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 no
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
> 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 to
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:
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
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
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
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
>
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
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
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
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(?)
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 -
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 t
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')
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')
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
>
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
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.
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
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
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
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 tr
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
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]
>
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::getFooterIc
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
>
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
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]
> > >
> > >
> 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
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,
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
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
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
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 emai
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:
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
uleContent()
#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
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
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
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:
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
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
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
> --
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
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
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
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 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 per
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
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
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/include
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.
_
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".
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
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
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 announc
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
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
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,
>
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
>
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
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.
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
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:
>>
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:
> >
>
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:
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
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
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
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
>
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
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
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.
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:
wledge 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 vulnerabilitie
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.
> 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
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.
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
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
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
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
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
>
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
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
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.
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
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
> &
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
>
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
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
1 - 100 of 129 matches
Mail list logo
