- User Since
- Feb 27 2015, 7:19 PM (421 w, 4 d)
- IRC Nick
- LDAP User
- MediaWiki User
- GregRundlett [ Global Accounts ]
Sat, Mar 11
I'll try to add docs when I get to develop an implementation.
Thu, Mar 9
Jan 25 2023
Oct 20 2022
Sep 21 2022
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.
Sep 20 2022
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?
Jul 1 2022
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.
Jun 30 2022
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.)
Jun 29 2022
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.
Jun 28 2022
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).
Jun 24 2022
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.
Mar 22 2022
Feb 21 2022
By the looks of it, all patches related to this issue have been merged. I believe this task is complete.
Feb 20 2022
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.
Dec 23 2021
Nov 26 2021
Nov 24 2021
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.
Nov 9 2021
Nov 5 2021
I have two concerns:
Sep 21 2021
Aug 10 2021
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.
Jul 13 2021
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?
Jun 25 2021
Jun 24 2021
I think the top two should be Confluence, and SharePoint / SharePoint Wiki
Jun 22 2021
Jun 16 2021
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.
Jun 3 2021
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
Jun 1 2021
I'll try to reproduce this issue on a current MediaWiki and report back.
May 12 2021
Apr 22 2021
Feb 22 2021
Jan 27 2021
Dec 31 2020
Dec 1 2020
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.
Nov 6 2020
@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.
Nov 5 2020
Oct 28 2020
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.
Oct 12 2020
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)
Oct 8 2020
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:
Oct 7 2020
Sep 30 2020
This issue persists in MW 1.34.4 / ApprovedRevs version 'master'
Sep 29 2020
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.
Sep 18 2020
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.
Aug 31 2020
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+
Aug 20 2020
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" . Not one of those log_user (ids) exists in the user table. 
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
Aug 19 2020
Setup fresh 'demo' wiki
Aug 18 2020
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
Aug 14 2020
I uploaded a patch here
Aug 5 2020
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.
Jul 31 2020
New codesearch UI looks great! THANKS!
Jul 1 2020
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;'
I'm trying to upgrade from 1.32 to 1.34 Actor Migration is still failing for me. Using --force with cleanupUsersWithNoId.php did not change the results of my upgrade attempt. Here is what update.php is reporting... lots of errors:
Completed actor creation, added 0 new actor(s) Beginning migration of revision.rev_user and revision.rev_user_text to revision_actor_temp.revactor_actor User name "Crowtherdr" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
Jun 12 2020
For me, migrateActors.php was failing with a duplicate for 'Redirect fixer' https://phabricator.wikimedia.org/T229092. After I manually updated the revision table like Anomie suggested, I re-ran the cleanupUsersWithNoId.php -- which didn't make any changes or corrections. Now when I run migrateActors.php, it fails with
Function: MigrateActors::addActorsForRows Error: 1062 Duplicate entry '' for key 'actor_name'
I can't update revision with rev_user = 0 because rev_user is already zero for the 24 records in question. What can I try next?
Additional Details: Attempting to run php /opt/htdocs/mediawiki/maintenance/migrateActors.php on a large 60GB wiki database.
May 1 2020
I'm running into this problem upgrading from REL1_32 to REL1_34. I'd be happy to provide any additional details.