Hi, I'm back :)

Hallo, @BeeBringer,
Thanks for working on this.
I guess your patch would have a better luck of getting merged, had it been realised in Setup.php instead of Webstart.php, because the earlier is where MW_CONFIG_FILE is expected to be setup for all entry points, web, maintenance scripts, etc.

An environment variable such as MW_CONFIG_FILE was indeed on my wishlist! It would simplify some farm setups.

It would be useful to have a parameter to ignore existing LocalSettings.php.

I had already tried that before submitting the report. But thanks for the suggestion, @kostajh.

When I wrote the original ticket, I was assuming a certain shared understanding of the Egyptian hieroglyphic writing system. So let me clarify:

What does this error actually mean?
If we were to try to bring the database to a consistent state, what tables and/or columns will be looking at?

We are facing this error as well. Our setup is not master/slave DB.

Does this entail processing the old revisions of pages to include concurrent revisions of templates and link to concurrent revisions of pages as well?

We faced the same issue (T213841) with CBZ (Comic Book Archive files) and ePub.

An instance of MW 1.31.5 running on PHP 7.3.16-1+ubuntu18.04.1+deb.sury.org+1 (apache2handler) has just started to exhibit this exception after I upgraded from PF 4.7 to 4.8.

[5c424fca0b973708eb4db9b7] /%D9%88%D9%8A%D9%83%D9%8A:%D8%AE%D8%B7%D8%A9_%D8%AA%D8%B7%D9%88%D9%8A%D8%B1_%D8%A7%D9%84%D9%85%D8%AD%D8%AA%D9%88%D9%89 MWException from line 355 of /srv/src/mediawiki/1.31.5/includes/MagicWord.php: Error: invalid magic word 'default_form'

I experienced the issue described by by @Calexit in T55791#3299344 when I wanted to move the temporary directory from the default to /var/tmp/umranica, so I did the following:

1. cp -a /srv/repo/umranica/temp to /var/tmp/umranica
2. set $wgTmpDirectory = "/var/tmp/umranica";

The permissions on both directories where identical: drwxr-sr-x www-data adm.
Attempting to open a Flow discussion page yielded:

Could not open '/var/tmp/umranica/mw-UIDGenerator-UID-88

Yes, it's about Mediawiki.

Shpuldn't this be a 403/Forbidden response?

I looked at the markup documentation but I cannot find a way to escape. I'm sure I'm missing something trivial!

The mention to the commit in the description above was made inadvertently, and should be removed. I don't know how to escape it!

On a related, I just tried to submit a comment in a discussion for the first time, and got:

[ecdba561febffa874b627f87] Exception caught: Request to parsoid for "wikitext" to "html" conversion of content connected to title "Topic:Vhruneelfm63nzim" failed: 406

Even after having relaxed the strictness of Parsoid. Should I downgrade Parsoid?

For reference: https://www.adequate.at/csv-metadata-editor

You are right. The issue with the performance is different from
comments. I just brought it up prompted by your suggestion of a
row_offset option.

It is worth noticing that some non-WMF wikis need to set a locale other than en_US.utf8 to allow for the proper interaction with data stored in external sources.

Thinking of it, I don't think a row offset will help in my case, since I cannot know in advance how many rows are there before the sought one. But it might be useful in other cases.

I do not think there's a way to tell beforehand the number of comment
lines to expect in the header, since the idea is used to include an
arbitrary schema description.

Just in the header, before the rows begin, preceeded by hashes.

In T225475#5506096, @Aklapper wrote:

@ahmad: Then please revert?

In T225475#5497745, @Tenbergen wrote:

@Aklapper - oi, you are right of course, my bad. At least that mystery is solved.
I still don't understand why this was categorized as not a PF issue, though.

In T182863#5477613, @DannyS712 wrote:

To clarify, you want to be able to write something like $wgContentNamespaces[ NS_SRC ] = true;? In that case, you should be able to just write $wgContentNamespaces[] = NS_SRC; to add the namespace to the array

In T227593#5317800, @Aklapper wrote:

@ahmad: This task seems to cover several requests. Note that https://www.mediawiki.org/wiki/How_to_report_a_bug asks to "Include only one problem per task", so this task might be closed as invalid as it's very complicated to track progress and status for each of the requests in this single task.

A use-case form non-wikimedia wikis would be: being able to create notification types to be triggered when pages are created having certain criteria; such as a specific category or in a specific namespace.

I just submitted a patch, referenced above, which can be seen in action at https://arabdigitalexpression.org/wiki/مستخدم:أحمد, featuring two icons added to the title: one is a regular "file:" from the wiki, an the other a string of Unicode codepoints representing an emoji+modifier.

The immediate use-case I currently have is not related to Wikimedia:
An implementation of a glossary of localised terms pertaining to informatics and related fields, where discussions on the choices of localisations are very relevant for documenting the process and justifying the choices currently stabilised in the subject page.

In T201764#4498765, @ahmad wrote:

But there's also the usecase of having a workflow for handling received form submissions by one or more persons.

At least at Wikimedia, we just use mailing lists/distribution lists or OTRS queues

By "arbitary address" I meant one set by the form administrator, instead of having to be that of a wikiuser account as currently is the case. Not one entered by the form user.

I see your point of course.
Unfortunately I cannot reproduce this now as it seems to me more complex than what I can do at this time. I will keep monitoring for this behaviour, and add to this ticket later on. Reopening it, if necessary.
Thanks.

The actions attributed to 127.0.0.1 were not only the result of extension AutoCreatepage's work.
Some of them were human edits that took place at around the same time. See the log https://genderation.xyz/wiki/Special:contributions/127.0.0.1

Actually this is not a problem. It's a feature request.

More discussion in the extension's page in mediawiki.org

The incident was not particular to that extension.
It happened with several regular edits by several reasons.
I don't know if this is related to the fact the editors sessions have been expiring so rapidly and frequently.
But thanks for the explanation.

Yes, what I meant is what @Trizek-WMF understood: The permalink requested is that of the page from the specific moment the comment is made. I.e permalink of page, but displayed with comment metadata.

A bounty is put on the implementation of this: https://www.bountysource.com/issues/39907864-a-mediawiki-extension-to-preview-maff-files

Sorry. Something is wrong with my report. I need to reproduce again and check.