I'll try to add docs when I get to develop an implementation.

I've used it in the past, and was contemplating using it again. I do find it useful. I can't make any commitment because I don't see when I'll have time to work on a clean room implementation, but I'll check back in here if I do.

Or, IANAL, but Tim is just one contributor. If i understand correctly, wouldn't there need to be a contributor agreement signed by ALL contributors if I add a GNU GPL license file?

Can we just use a reply from @siebrand?

I think all MediaWiki extensions should have a valid composer.json. I tagged those projects I could identify as "affected". Not all extensions have a phabricator tag.

I'm going to re-open this ticket because I do think it is both valid, and separate from T250406

composer validate --no-check-publish

In Element chat I raised this same issue. (Sorry for forking the thread.)

We used to add name/description/license/etc. to composer.json with the intent of leaving them unpublished and then people went ahead and published them to packagist anyways, so we had to take them out.

I'm a 3rd-party (corporate) user of MediaWiki and we use Docker for local sandbox development while hosting official environments (DEV, QA, PROD) in AWS using their analog called ECS (Elastic Container Service).

Publishing is not required. In fact, you can't publish a package with an invalid composer.json file.
There is no reason why MediaWiki extensions should have invalid composer.json files.

By the looks of it, all patches related to this issue have been merged. I believe this task is complete.

I added the 'enablable - semantic markup' icon / status for the <details> <summary> tags because I believe this query on Code Search doesn't show any concerns. The follow-up would be https://phabricator.wikimedia.org/T31118#6989769 suggesting the use of <details> <summary> in place of using mw-collapsible.

Thanks anyway @Majavah , and for pointing to the docs. I wasn't sure if it was possible and didn't find the wikitech info previously.

I have two concerns:

Is the mode self-contained enough to be able to be contributed back to the CodeMirror project? I don't see MediaWiki in the supported modes for CodeMirror itself. I'm thinking that if CodeMirror itself supports MediaWiki as a mode, then at least any CodeMirror product (e.g. MediaWiki widget) would be capable of editing WikiText.

I believe that there was a GSOC 2020 project. I can see many references to OOUI in the extension source. Is there remaining work to be done?

I think the top two should be Confluence, and SharePoint / SharePoint Wiki

As much as I love FOSS, we shouldn't be left to our own devices if we choose not to use Emacs to contribute to MediaWiki code. I disagree with @Ricordisamoa's position. I believe a key requirement for fulfillment of this task is to pick one of the most popular IDE's available. The idea is to have the greatest impact.

I setup a default MediaWiki-Docker environment:

Product	Version
MediaWiki	1.37.0-alpha (d1219fa)
17:56, 2 June 2021
PHP	7.2.31-1+0~20200514.41+debian9~1.gbpe2a56b+wmf1 (fpm-fcgi)
SQLite	3.16.2
ICU	57.1

I'll try to reproduce this issue on a current MediaWiki and report back.

In T194901#5378291, @MarkAHershberger wrote:

Wikia said something on RIOT about having an extension for this that was published but probably not usable by others.

I'm OK with this being declined but I would expect it not to have a limit really. Shouldn't a search tool just page results? E.g. What if you wanted to search for every occurrence of 'wg'. I understand you can use other tools, but I figured this one would be at least as powerful.

@tstarling I believe I do -- from 9/11/2020, but the main DB backup is 12GB compressed. Due to space constraints, I only have these on a 'snapshot' -- not a live system. If you give me a public SSH key, I could spin up an environment temporarily (cost us $20/day) from one of these snapshots, and give you direct SSH access. I do believe that I already deleted some records from the logging table (where log_user_text = '') prior to snapshot. I don't have earlier backups.

In T229092#6502562, @freephile wrote:

Ultimately, I was able to complete an upgrade by 1) using maintenance/eval.php to create the missing User; and 2) deleting some old entries from the logging table.

php ./maintenance/eval.php
User::createNew( 'Redirect fixer', [ 'id' => 7425 ] )
Ctrl + c
mysql wiki_en -e 'select * from user where user_id = 7425;'
mysql wiki_en -e 'delete from `wiki_en`.`logging` where log_user_text = "";' -- 21733 rows deleted

Then I was able to run update.php

Just a little more info on what a 'broken image' looks like in the database.

-- A broken image
select img_name, img_actor from image where img_name = 'Flag_of_Norway.png'; -- img_actor = 0
select page_id from page where page_title = 'Flag_of_Norway.png'; -- the page id is 15395
select rev_user, rev_user_text from revision where rev_page = 15395; -- There are 4 entries in revisions, while page info says the second one 20027 Claudiaj64 is the Creator
select rev_user, rev_user_text from revision where rev_page = 15395 having min(rev_id); -- the original creator was user 145 Jtrev
select * from user where user_id in (145, 20027); -- Between Jtrev and Claudia, Claudia is the only one in the user table
select * from user where user_name = 'Jtrev'; -- Jtrev is just plain missing. Not found by name or id
select * from actor where actor_user = 20027; -- Claudia has actor id of 29 on beta, 30 on prod
update image set img_actor = 30 where img_name = 'Flag_of_Norway.png'; -- one row affected, but img still not visible (due to caching)

@Reedy @Ciencia_Al_Poder Thanks for the heads up on purgePage v. purgeList (If there's a 50/50 chance of doing the wrong thing, I do the wrong thing 100% of the time!)

No shared tables. Just shared file repo.

If this is meant to compare to MediaWiki-Docker (distributed now with core), then I'd say I'm more inclined to use MediaWiki-Docker because it's more lightweight (using LXC instead of VirtualBox), and because it is probably easier to setup (my estimation) in popular cloud environments like AWS, Google Cloud Platform, Microsoft Azure. I ran into problems with MediaWiki-Vagrant back in 2015 when I first tried it in earnest on AWS (documented on my wiki at https://wiki.freephile.org/wiki/MediaWiki-Vagrant)

Duplicate of T254647 reported for Extension:PageForms

When you try to create a new property (using the normal Form Interface at Special:CreateProperty), you get the following error when previewing or saving the edit:

This issue persists in MW 1.34.4 / ApprovedRevs version 'master'

Ultimately, I was able to complete an upgrade by 1) using maintenance/eval.php to create the missing User; and 2) deleting some old entries from the logging table.

I'm still struggling with this. I am unable to upgrade a 1.32 wiki to 1.34 because no matter what I have tried, I still get multiple errors; with fatal errors relating to duplicate Actors.

In T259771#6367006, @Izno wrote:

So just for concrete example's sake (please rebut each as appropriate):

Upgrading to 1.35 (LTS)

1. There would not be support for 1.23 (-3 LTS) to 1.35 (LTS)
2. There would not be support for 1.24, 1.25, or 1.26 to 1.35 (LTS)
3. There would be support for 1.27 (-2 LTS) to 1.35 (LTS)
4. There would be support for 1.28, 1.29, 1.30 to 1.35 (LTS)
5. There would be support for 1.31 (-1 LTS) to 1.35 (LTS)
6. There would be support for 1.32, 1.33, or 1.34 to 1.35 (LTS)

Upgrading to 1.36 (LTS +1)

1. There would not be support for 1.23 (-3 LTS) to 1.36 (LTS +1)
2. There would not be support for 1.24, 1.25, or 1.26 to 1.36 (LTS +1)
3. There would not be support for 1.27 (-2 LTS) to 1.36 (LTS +1)
4. There would not be support for 1.28, 1.29, 1.30 to 1.36 (LTS +1)
5. There would be support for 1.31 (-1 LTS) to 1.36 (LTS +1)
6. There would be support for 1.32, 1.33, or 1.34 to 1.36 (LTS +1)

I think you got this wrong. The way the proposal is worded, support for upgrades would continue for old LTS releases until a new LTS release bumps the oldest supported LTS release off the list.
In other words, I believe the release of 1.36 (non-LTS) doesn't affect the migration support for 1.27+

Expanding on the above, using a different larger wiki database with the same issue, there are 1,571 records in the logging table having an empty log_user_text (aka username) where the type is "newusers" and action = "create" [1]. Not one of those log_user (ids) exists in the user table. [2]

I noticed something interesting about the nature of records in the logging table with empty log_user_text: There are many with the 'log_action' = 'create' and the 'log_title' appears to be the username. Eg.

select log_type, log_action, log_timestamp, log_user, log_title from logging where log_user_text = "" AND log_action = "create" ORDER BY log_timestamp LIMIT 10;

Hoping that logic improvements in the latest Actor Migration codebase could save me, I setup MediaWiki-Docker (with MySQL backing),

Product	Version
MediaWiki	1.36.0-alpha (2cc3d4f)
15:13, 19 August 2020
PHP	7.2.31-1+0~20200514.41+debian9~1.gbpe2a56b+wmf1 (fpm-fcgi)
MariaDB	10.5.4-MariaDB-log
ICU	57.1

Latest example:
Setup fresh 'demo' wiki

Thanks Mark @MarkAHershberger, but I already fixed the style issues in the latest commit. There are now assertions in the unit tests that are failing, due to the new class attribute not conforming to the declared / expected output of the parser tags for InputBox.

Based on test failures, it looks like I need to update the unit tests for InputBox.

I uploaded a revised patch at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/InputBox/+/620780

I uploaded a patch here

I would like to see MediaWiki core, libraries, extensions and skins installable by composer -- just like you can do with Drupal (introduced in Drupal Core 8.8 and mentioned earlier in this RFC). "But wiki extensions don't use semantic versioning." Drupal modules (mostly) don't follow semantic versioning, but there's a shim to accomodate that. End users aren't forced to use composer - because it's not the only way to download/install/manage Drupal. In fact, it's not even mentioned on the project download page. The point is, I wholeheartedly support this RFC in terms of improving and clarifying composer support in the MediaWiki ecosystem.

New codesearch UI looks great! THANKS!

It seems to be choking on the logging table. When I look at those records, there are many with empty log_user_text
mysql wiki_fr -e 'select distinct log_user from logging where log_user_text = "" order by log_user;'