To fix the figures and compare in the future, there are today on nl.wp:

• 2023 for paragraph-based edit conflict management feature,
• 14974 for content translation,
• 777 for IP Information.

I just closed the referenced task T112944, it was (as I understand it) a different issue: the other one is about the figures not updated in real time but only a few seconds after. This one is about a longer time frame.

I added this paragraph on MediaWiki.org, this might be improved (I’m not a native speaker) but I guess it will answer if other people observe this slightly-misleading behaviour.

Not sure it is really a bug or an unexpected behaviour on some small wikis in some conditions: the counts are updated by a job, so if the job is not executed quickly enough (between the instant the user saves and the updated Special:Preferences page appears and retrieves this number) then the count does not change.

I also experienced this issue.

I discussed with @Nemo_bis about this.
First option would be the CommunityConfiguration reuses the messages from GrowthExperiments, but there might be situations in some languages where slight adaptations like grammar might be needed.
Second option (prefered) is to the CC messages transclude the GrowthExperiments messages, e.g. {{int:growthexperiments-homepage-suggestededits-tasktype-label-expand}}, and mark these messages as ignored in translatewiki. In any case, the CC extension is dependant of the GrowthExperiments, at least partially for managing its configuration, so there is some logic about reusing its messages.

Seeing these new IExpression in 1.42, it recalls me an article I read three years ago about prevention of SQLi, I mention it since it is a step further compared to the discussion here, but it remains a POC/theory. The article (in French) is here, written by a researcher then at Orange Cyberdefense (Judicaël Courant), and an equivalent conference paper in English is here; he wrote a POC in Java and I translated it into a PHP library three years ago.

I executed the test of ve.dm.MWTemplateModel.getTemplateDataQueryTitle() about whitespaces, changing the initial wt from ' SUBST: a' to ' SUBST: a\n' and it indeed fails:

14:00:04 FAILED TESTS:
14:00:04   ve.dm.MWTemplateModel
14:00:04     ✖ getTemplateDataQueryTitle: ignores capitalization and whitespace
14:00:04       Firefox 115.0 (Linux x86_64)
14:00:04     Expected: "Template:A"
14:00:04     Actual: "b"
14:00:04     @http://localhost:9876/load.php?modules=mediawiki.widgets.CategoryMultiselectWidget%2CDateInputWidget%2CMediaSearch%2CTable%2CUserInputWidget%2Cstyles%2CvisibleLengthLimit%7Cmediawiki.widgets.DateInputWidget.styles%7Cmobile.codex.styles%7Cmobile.init.styles%7Cmobile.pagelist.styles%7Cmobile.pagesummary.styles%7Cmobile.startup%7Cmoment%2Coojs%2Coojs-ui%2Coojs-ui-core%2Coojs-ui-toolbars%2Coojs-ui-widgets%2Coojs-ui-windows%2Cpapaparse%2Crangefix%2Csinonjs%2Cspark-md5%2CtreeDiffer%2Cunicodejs%7Coojs-ui-core.icons%2Cstyles%7Coojs-ui-toolbars.icons%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-accessibility%2Cicons-alerts%2Cicons-content%2Cicons-editing-advanced%2Cicons-editing-citation%2Cicons-editing-core%2Cicons-editing-list%2Cicons-editing-styling%2Cicons-interactions%2Cicons-layout%2Cicons-location%2Cicons-media%2Cicons-moderation%2Cicons-movement%2Cicons-user%2Cindicators%7Cskins.minerva.messageBox.styles%7Cskins.vector.clientPreferences%7Csocket.io%7Ctest.CentralAuth%2CCheckUser%2CCite%2CDiscussionTools%2CEcho%2CEventLogging%2CFlow%2CGlobalBlocking%2CGuidedTour%2CMediaWiki%2CMinervaNeue%2CSecurePoll%2CTemplateData%2CThanks%2CVector%2CVisualEditor%2CWikiEditor%2CWikimediaEvents&version=k0myz:5911:579
14:00:04     runTest@node_modules/qunit/qunit/qunit.js:2697:35
14:00:04     run@node_modules/qunit/qunit/qunit.js:2680:16
14:00:04     queue/runTest/<@node_modules/qunit/qunit/qunit.js:2951:16
14:00:04     processTaskQueue@node_modules/qunit/qunit/qunit.js:2271:26
14:00:04     processTaskQueue/<@node_modules/qunit/qunit/qunit.js:2275:29

(console of the failing test)

A small follow-up:

• fr.dicoado was converted yesterday to a farm with the extension MediaWikiFarm for future languages (config will be in the repo https://gitlab.wikimedia.org/repos/wikimedia-ch/wmch-infrastructure)
• fr.dicoado was upgraded to 1.39.8 yesterday

This is already possible with the hook SpecialSearchProfiles instead of a config parameter or a MediaWiki:Sidebar-like alternative, so it should be clearer here what is really wanted (I’m aware the original author probably does not follow this task, so the question is to people interested to this task).

Fixed in https://www.mediawiki.org/wiki/Special:PermanentLink/6603711

This is more or less the same as T40395, I suggest closing this one as a duplicate and continue the discussion on the other one which is older.

There remains to be decided if the selection of the "default" profile is:

1. the last selected profile (as proposed in my previous comment), or
2. a profile the user has explicitely fixed in their preferences, whatever they will then navigate between different profiles during their searches.

We (Wiki Valley) were asked this feature and I just studied the (current, 1.41/1.43-alpha) behaviour. It is in fact partly already implemented but the logic is quite difficult to discover (ref: source code as of 1.43-alpha):

• when a user has used the 'advanced' profile and saved some set of namespaces, then they are sticked with the 'advanced' profile and this set of namespaces, but
• when the same user saves exactly the set of namespaces of some other profile (see below), then this other profile becomes the default displayed profile (i.e. when you enter a search in the search box, or an URL on the page Special:Search without any parameter "nsNNN" or "profile").

Internal links (i.e. from and to the document itself) are generated by MediaWiki as <span id="…"></span> (at least with the traditional parser), but the library mPDF still does not recognise the attributes id as destinations of links (see the issues #111 and #653), only with the legacy HTML <a name="…"></a>.

The linked patch should work on PHP 5.6 → 8.1 according to the requirements of the library mPDF and I tested it on PHP 7.4. I will test it on PHP 8.1 in a few days.

I added a reconstruction script I wrote some time ago to recreate the complete Git repo from the file gitinfo.json (and version to retrieve the branch in the current state). It’s here: https://www.mediawiki.org/wiki/Gitinfo.json/Reconstruction_script

I moved the wiki to https://rm-vl.dicoado.org, changed the config in the farm with the key 'rm-vl' instead of 'rm' (I just did not rename the database, which is still dicoado_rm, it could be done later), and issued an SSL certificate with rm-vl.dicoado.org + www.rm-vl.dicoado.org.

I completed the stacktrace in the description (log_errors_max_len has to be set to a larger value than 1024, like 2048).

I also observe this exception on MW 1.41.1 with VE REL1_41 on PHP 7.4. I wonder how crawlers find these links, they are not displayed by MediaWiki in the history page, so either they appear somewhere I’m not aware, either they are constructed by MediaWiki-optimised crawlers to crawl the histories.

The relevant code in includes/api/ApiQueryUserInfo.php function getCurrentUserInfo is:

if ( isset( $this->prop['registrationdate'] ) ) {
        $regDate = $user->getRegistration();
        if ( $regDate !== false ) {
                $vals['registrationdate'] = wfTimestamp( TS_ISO_8601, $regDate );
        }
}

How it returns the current day:

1. User::getRegistration() returns string|false|null (string = timestamp, false = anonymous user, null = logged-in user but no data),
2. Here $regDate = null,
3. so the condition $regDate !== false is true (because null !== false),
4. and finally wfTimestamp( TS_ISO_8601, null ) returns the current date.

As of now, $parser->getOutput() cannot be used with a fresh Parser because Parser::$mOutput is uninitialised.

I observed this exact error with the extension Lingo, but it comes from a change introduced in MW 1.41.0, see T357686.

See also this small experiment with PHP 7.4.33:

$ php -a
Interactive mode enabled

I’m quite sure this was fixed in 173efe9 (on 2023-05-09) and backported to REL1_35 (56c67a6), REL1_39 (0bd987c), and REL1_40 (35e4521). Do you confirm it works by using the lastest commit of branch REL1_39 (works also with the ExtensionDistributor)?

This seems to be a duplicate of T114532, and there is Gerrit patch waiting for review :)

Thanks!

Here are the actions done on the skin, most are similar to those on previous 1.35 and adapted:

• the skin foreground is now based on REL1_39 and specifically here f485d29, the diff is available with the command git diff when inside skins/foreground (NB: previously the skin foreground was hosted on GitHub, it is now hosted on Gerrit alongside most of other skins)
• assets/scripts/foreground.js is replaced with the same file as in 1.35
• assets/stylesheets/font-awesome.css is replaced with the same file as in 1.35 (FontAwesome Pro 5.15.1)
• assets/stylesheets/foreground.css: removed rules about "#echo-notifications" (replaced by rules in MediaWiki:Foreground.css to be imported in production)
• skin.json: removed "assets/stylesheets/fontawesome.css" (it is achieved with the modified script foreground.js)
• Foreground.skin.php: diff below, the changes are:
  • moved the search bar from #top-bar-right to #top-bar-left
  • moved the Echo notifications and changed from div to ul-li
  • added the script Masonry

Firefox enforces strict-origin-when-cross-origin since Firefox 93 (released in October 2021) when Tracking Protection is enabled. The user can disable it per-site (click on the shield in the address bar) and in this case these logs disappear in the console.

In T257703#8424310, @TK-999 wrote:

More broadly, we may need to revisit the practice of eagerly setting up the session itself in Setup.php as well, since that itself may set cookies even if nothing attempts to interact with the session user during the lifetime of the request.

These two mechanisms are contradictory in the general case:

1. on each new request where there is no cookie "_session" (always subdomain-local) but there is a cookie "Token" (might be domain-global), always define the session cookies;
2. define cachable responses.

In description, @daniel wrote:

It is unclear why session cookies are set here.

I fixed 5 more issues today:

We worked today with @Nicolas_NALLET to fix various issues:

• we silenced the warning Deprecated InternalParseBeforeSanitize hook on top of every page due to the extension Variables, there is a pending patch T250963 (silenced in [mediawiki]/includes/HookContainer/DeprecatedHooks.php
• we disabled in the LocalSettings.php $wgUseFileCache = true; which triggered an error on the main page Fatal exception of type "Error" : this cache mechanism has very few users and is probably not really maintained: TODO it would be better to replace it by an external cache from Apache (NB: Wikimedia uses the software Varnish for this task, but it adds another software to be maintained, so perhaps not the better option here)
• we updated the extension Cargo to its latest version in the branch REL1_39 (it triggered an errro on Special:Drilldown/Article): the few added commits fixes the issue

I added T349115 as a subtask since it is a (minor) bug introduced in rMWbfd4001c6c229657091d866ae51e2cbb5979344a. I proposed a patch.

I also observe this error on 1.40.1. I’m not completely sure, but it seems to appear when the (default?) skin in not Vector ($wgDefaultSkin = 'chameleon'; in my case), I had these notices for only 3 message keys vector-view-(view|edit|history) whose the value is NULL in the $preload array.

I propose my patch, it fixes this issue as well as a similar one for long comments (the second preg_replace). I added 2 units tests inspired from matmarex’s comment above (T345319#9140869), these unit tests did not pass without this fix (triggering type errors) and pass with this fix.

I observed this issue on 1.39.5. Given the simple regex, I replaced it by strpos+substr:

@@ -313 +313,10 @@ class HtmlFormatter {
-               $html = \preg_replace( '/^.*?<body>|<\/body>.*$/s', '', $html );
+               $pos = strpos( $html, '<body>' );
+               if ( $pos !== false ) {
+                       $html = substr( $html, $pos+6 );
+               }
+               $pos = strpos( $html, '</body>' );
+               if ( $pos !== false ) {
+                       $html = substr( $html, 0, $pos );
+               }

I’m not sure why this task has the priority High, it seems there is no work done at least since 3-4 years, is there?

An alternative solution to fix the original issue would be a last grant "Misc. rights" containing all rights which are not attributed to a grant, so that we keep the spirit "only add necessary rights for a given task" as Tgr said above (T150526#2818602) and if some extension has not attributed its rights to a grant (as in subtasks of T142308) there is a transitional solution for users.

For the record, I found the solution and it is unrelated to PageForms.

There is still a 'prefershttps' in MediaWiki, but it is hidden when $wgForceHTTPS is true since rMWc75eef91bf27046ca (T256095).

Fixed by the patch 958530 of @BPirkle and myself.

In T324646#8455341, @Umherirrender wrote:

I have no good idea how to fix this from the updater side. As this state is unexpected (from my point of view) and possible the cause of some previous upgrade error, not sure if the updater should be smart enough to handle the case.

During the update 1.31 → 1.35 → 1.39 of Vikidia, this issue was triggered, either in the original form Can't DROP 'filter_timestamp_full' with some upgrade path either in the form Duplicate key name 'afl_filter_timestamp_full' in another upgrade path (this second one because afl_filter_timestamp_full is created just before by patch-split-afl_filter.sql when there is no column abuse_filter_log.afl_filter_id in 1.39 updater).

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.