As said above, this task makes [[Special:DisambiguationPageLinks]] useless on most wikis given there are legitimate links to disambiguations pages, often in header templates.

Imvuong provided a solution in the linked topic on MediaWiki.org, and I aggree with them: when full level prefix is not defined, it should be defined to the empty string, which is the default value in the powerful parser function {{counter:}}.

There may be situations where the user connects in a semi-trusted device and don’t want to let some secondary authentication token, e.g. when s/he uses a public library computer or a colleague’s computer. For instance it happened to me recently during a editathon where I had to use a public library computer (the WiFi was too secure and not available to visitors). Of course, a private browsing is preferable in this situation, when available.

This bug is fixed from version 1.40 (branch REL1_40).

This is now fixed in branch master, so it will in branches REL1_40 and further, and in versions 0.5.4+.

This bug is with the default LegacySpi, there is also T114532 with MonologSpi.

Fixed in branch REL1_39+ (version 1.39+). I updated MW.org.

For reference this was fixed in Git commit 90759fa8a1a5187d881763ea89f9ca2f0a5f8a4a.

I remarked there are two unserializations in IconManager, and removing the internal unserialization seems to fix the failing tests.

The extension TitleIcon has a wrong unserialization since 96e4f5d8402 (more exactly the class MediaWiki\Extension\TitleIcon\Icon): see for instance the patch I am preparing, but the failing tests are independent of the patch and fail exactly when MediaWiki has 96e4f5d8402.

And here is the corresponding patch

In T168783#8439674, @Kghbln wrote:

@Seb35 Will it be possible to back-port this to MW 1.39 since this the the LTS branch? Will be cool I believe.

In T311449#8465770, @Egel wrote:

[e2b82f9bd017f414a556d7a9] /load.php?lang=en&modules=startup&only=scripts&raw=1&skin=chameleon TypeError: Argument 1 passed to MediaWiki\Extension\ConfirmEdit\hCaptcha\Hooks\ResourceLoaderHooks::getHCaptchaResourceLoaderConfig() must be an instance of MediaWiki\ResourceLoader\Context, instance of ResourceLoaderContext given, called in ----/includes/resourceloader/ResourceLoaderFileModule.php on line 1312

This is caused by rEHTC6827d8cdd7420074c50d38a8724c72fac5feac32: the SQL query constructed by MediaWiki is SELECT … FROM page p,hit_counter h ORDER BY … instead of SELECT … FROM hit_counter h JOIN page p ON ((p.page_id = h.page_id)) ORDER BY … (I removed the backticks here for readability), so a cross product is computed by MySQL instead of a JOIN.

Fixed in current master, so it will be available in REL1_40+ (version 1.40+).

Example of file generated:

{
  "head": "refs/heads/REL1_39",
  "headSHA1": "9ddf52d2df69634f558d6a3c04d4daa0b06dc4ff",
  "headCommitDate": 1660112594,
  "branch": "REL1_39",
  "remoteURL": "https://gerrit.wikimedia.org/r/mediawiki/extensions/Dashiki"
}

In the linked patch, I changed the following entries in gitinfo.json to make them correspond to the GitInfo class of MediaWiki:

• branch: changed from the HEAD’s SHA1 to the branch name (e.g. "REL1_39")
• head: changed from the HEAD’s SHA1 to the branch reference (e.g. "refs/heads/REL1_39")
• headCommitDate: changed from a string to an int
• headSHA1: removed the trailing \n

There are no more issue with the mentionned repo SemanticPageSeries (the renaming from semantic-forms to page-forms is finished), but if we want to fix it for an hypothetical other case, including when a repo will be deleted (it will probably happen one day), I have the following proposition:

I remove the tag MediaWikiFarm since page-forms only appears in test/phpunit/, not the root composer.json.

I modified mw:at-ease to reflect this decision, even if the library is strictly-speaking independent of MediaWiki.

I propose the linked patch, adding on each right a preliminary condition ( $wgGroupPermissions[$group][$right] ?? false ) && … to be sure no right can be added but only removed.

I reopen this task given I reached this bug in another code path (MW 1.38.2, PF 5.4 and current master a308554b9). I propose a complementary patch below.

migrateActors.php was added in 1.31 and this the beginning the option IGNORE is not present, so theoretically it could be backported in all versions. I did not request other backports since other versions are no more supported, but perhaps there are exceptions for upgrade-related patches?

I close this task since the patch has been merged in master (future 1.39.0) and REL1_35 (future 1.35.8), which are both LTS versions.
NB: it is not fixed in 1.36, 1.37, or 1.38.

Wrong task number in my patch, I reaffected it. But related to this task to permit the removal of EntityContent::getNativeData().

TextContent::getText() was introduced in 1.33, here: rMW54c70c3551ea2b19a8967135fce5913c65e4bfbd.

Currently AbstractContent::getNativeData() is an abstract method given it is defined in the interface Content but not defined in AbstractContent.

In T283686#7769587, @RussRogovetz wrote:

Hello team,
I'm working on those sub-tasks to replace Content::getNativeData() to TextContent::getText().
For me is not clear how to replace it in EntityContent as it didn't have any dependency with TextContent.
So we have public method getNativeData in EntityContent that implements from Content, we call this method in getSize(). As we deprecate Content::getNativeData we should remove any usage of this method there.
And as I understand well the propose was to replace it with TextContent::getText().
Could you please provide more details about better way to replace it?

I re-tried yesterday in a lab environment to upgrade a wiki created in 2004 and in version 1.27. Probably someone did a hard cleanup (linked to spam?) because many users were missing in the user table and a few log_user_text or rev_user_text were an empty string, leading to this issue. In this case it is hard to re-create these data, even if sometimes possible (see T229092#7730875).

This is fixed and deployed in production (1.39.0-wmf.26), isn’t it?

I was bitten by this bug and found this issue. Here it is the fix as described by @Anomie (I added Co-Authored-by given it is the direct fix you proposed).

I documented this on MediaWiki.org.

In T315740#8172067, @ssastry wrote:

Thanks for catching this and submitting a patch. What is the expectation regarding these empty tags? Do we want to lint them away in the future? Or do we want to continue accepting them?

I submit my current proposition as a WIP because it might be sub-optimal if the options of the current user are not loaded (and possibly detrimental to the performance in this specific case).

In my observations, I assumed the properties of the current user are always loaded, but I’m not completely sure of this in all types of requests.

• An option is to prove this by checking all code paths.
• Another option would be to opportunistically ask UserOptionManager::getOption( $wgUser, 'gender' ) in the sense that, if it has the information it’s great, else it doesn’t matter and the information will be retrieved by GenderCache possibly with other requested users. I propose this opportunistic solution because I think (but I might be mistaken) that it should be prefered the SQL request in GenderCache instead of the SQL request of UserOptionManager (at this point we don’t need all user options, only the gender). The downside is that UserOptionManager currently does not implement such opportunistic behaviour.

There is another task quite near of this one, but centered on LinkCache T297914.

I remove Translate since I reproduced this locally on both Translate and non-Translate pages.

I just see T315657: it could be the same bug or perhaps slightly different.

I documented on the user manual this feature.

And BTW this is fixed in master since 27 July 2022 with 3f5e60bd22139c1bc8ebd73a596dccbbb0f03f76.

Fixed in 3f5e60bd22139c1bc8ebd73a596dccbbb0f03f76.

In T106994#8023815, @PleaseStand wrote:

Percent-encoding makes the URL with the non-ASCII characters much longer, so using a string of 255 a's would break the size check. Another option would be to instead replace the 4-byte characters with twice the number of 2-byte characters. The check may still be flawed though because of the gendered User namespace issue (aliases may be of different byte lengths), and there are better ways to implement such a size check. The patch set I uploaded (see above) is one of them.

I see this was independently documented on Manual:$wgMemCachedServers, so perhaps this task could be marked as solved.

De facto it works when configured directly in LocalSettings.php in $wgMemCachedServers, but the Web installer mandates the form IP:PORT or DOMAIN:PORT.

I confirm the patch merged on July 6 fixes the issue, to this task can be closed.

I also observe this issue with SemanticMetaTags adding an og:image according to a specific semantic (SMW) property.

I also tried on MW 1.39 behind an SSL client authentication, it works great! Thanks @cscott!

Duplicate of T296435, opened before and contains a Gerrit patch for 1.37.

I configured an SSL client certificate on nginx in front of MediaWiki 1.37, it mostly works except the VisualEditor due to this issue, and at the contrary of basic auth it’s absolutely impossible to forward authentication tokens for this configuration.

$wgMemoryLimit can be increased. I don’t have a precise method to set it to a sensible value, except try-observe-adjust.

I see two different actions to mitigate this issue:

We (Wiki Valley) had recently this error on MW 1.36, together with something like T280147 (we have $wgMainCacheType = CACHE_MEMCACHED like others here).

I hereby candidate to become maintainer of the extension, on behalf of the MediaWiki consulting company Wiki Valley.

Here is a patch as a Git commit: (name and email redacted to avoid harvesting of my email address)

commit dda8ac5ca2d8f6ff595f1a2e641bda4c2057bfc4
tree 7492d30ceab679b68d72c026ecbddc7987085202
parent 044614d60c30cbbd7d3882f836905796bc1ade06
author xxxx <xxxx> 1650395410 +0200
committer xxxx <xxxx> 1650395410 +0200

I reopen this task since I got this issue when I executed Phan locally.

Another Gerrit patch was submitted I271e3babd231e855412ede02931a7ac85ecd9569 one week before mine.
It fixes the default case when SQLStore is used but is a bit less complete than mine (no handling of SPARQLStore).

This sentence was removed in INSTALL file on 2022-03-15 in 41569b4cdb27c65288fd19aa1940b3bac46b6546 by @Umherirrender, so this task is resolved.

Was fixed by @RazeSoldier in June 2019 : 4f41672bc2b4.