Tasks which have seen a code commit or fix merged into one of the unstable "1.27.0-wmf.xx" development branches. These development branches are included in the final stable MediaWiki 1.27 release.
This project is automatically added to tasks by @ReleaseTaggerBot.
Now it is possible to use the file from Special:UploadStash to start a new upload via Special:Upload, but with this way only the file is known on the server side, all the other information, like file name or file description has to be fill in again.
The upload page does not start with UploadWizard forms or campaigns. It also does not allow to use a batched feature if multiple files needs restart from the stash. Such features must be implemented in UploadWizard directly.
But when the situation with restarts are less, this may help some user to do so.
Change #1196975 merged by jenkins-bot:
[mediawiki/core@master] specials: Start upload with stashed file from Special:UploadStash
Change #1196975 had a related patch set uploaded (by Umherirrender; author: Umherirrender):
[mediawiki/core@master] specials: Start upload with stashed file from Special:UploadStash
Test wiki created on Patch demo by Jon Harald Søby using patch(es) linked to this task:
https://d4d75b07ee.catalyst.wmcloud.org/w/
Change #1195982 had a related patch set uploaded (by Jon Harald Søby; author: Jon Harald Søby):
[mediawiki/extensions/TimedMediaHandler@master] Enable namespace translations for TimedMediaHandler
Change #1183760 abandoned by Agrimasahu:
[mediawiki/tools/ParseWiki@main] parser: Enhance ParserTable to support table attribute parsing
Change #1183760 had a related patch set uploaded (by Agrimasahu; author: GergesShamon):
[mediawiki/tools/ParseWiki@main] parser: Enhance ParserTable to support table attribute parsing
Maybe MediaWiki should introduce a new user right that grants the ability to create a new page with an arbitrary content model, while keeping the editcontentmodel for changing the content model of an existing page. Then grant this new right to all logged in users.
New right
Mistakes still happen. That said, something that direction should probably be in the context of T380691: Page creation should have drop-down to specify content model.
What is the usefulness of changing the content model of an existing page? However, creating a new page with a different content model than the default can be useful. For example, required by MassMessages, TemplateStyles... However, I'm not sure changing the content model once the page has been created and has revision is really useful. Comparing revisions from different content models is probably unsupported or can't be meaningful. And it can be quite disruptive, since the new content model may disallow the use of page histories.
Change #1182924 merged by jenkins-bot:
[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.22.0-a19
Change #1182924 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.22.0-a19
I think this should be reopened but marked as stalled on adding safeguards that make the right harder to abuse. ContentHandler already has ::canBeUsedOn() which can be used to prevent usage in certain namespaces. That way, all content models except wikitext can be disabled on mainspace, user talk, and other places which should always be wikitext (except Flow/LQT should be allowed in user talk of course). Extensions can already hook into the canBeUsedOn() logic of core content models.
@Pppery closed this task as Declined.
I don't think that's a correct read of the patch of interest. Whether the default in core is admins only or whatever is not what the WMF wikis can have (and I note WM-site-requests in the projects list, so this task at least has that meaning).
Change #1182663 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Use admin instead of alice to change contentmodel
Change #1182663 had a related patch set uploaded (by Arlolra; author: Arlolra):
[mediawiki/services/parsoid@master] Use admin instead of alice to change contentmodel
Change #1181160 merged by jenkins-bot:
[mediawiki/core@master] Ship with `editcontentmodel` turned off for ordinary users
Change #1181160 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
[mediawiki/core@master] Ship with `editcontentmodel` turned off for ordinary users
I think we should actually change the defaults we ship to MediaWiki to match what we've deployed in production, and default the editcontentmodel right for user to false.
Change #1178017 merged by jenkins-bot:
[mediawiki/core@master] Untangle HTMLComboboxField class from XmlSelect (re-submit)
Change #1178017 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):
[mediawiki/core@master] Untangle HTMLComboboxField class from XmlSelect (re-submit)
Change #1177145 merged by jenkins-bot:
[mediawiki/core@master] Untangle HTMLComboboxField class from XmlSelect
Change #1177145 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):
[mediawiki/core@master] Untangle HTMLComboboxField class from XmlSelect
Change #1165133 merged by jenkins-bot:
[mediawiki/core@REL1_42] SECURITY: fix IP leak to unverified email
Change #1165114 merged by jenkins-bot:
[mediawiki/core@master] SECURITY: fix IP leak to unverified email
Change #1165073 merged by jenkins-bot:
[mediawiki/core@REL1_43] SECURITY: fix IP leak to unverified email
Change #1165099 merged by jenkins-bot:
[mediawiki/core@REL1_44] SECURITY: fix IP leak to unverified email
Change #1165133 had a related patch set uploaded (by Reedy; author: Michael Große):
[mediawiki/core@REL1_42] SECURITY: fix IP leak to unverified email
Change #1165114 had a related patch set uploaded (by Reedy; author: Michael Große):
[mediawiki/core@master] SECURITY: fix IP leak to unverified email