Page MenuHomePhabricator
Search Advanced Search
    • Task
    Currently, the proofreading status is stored in the Wikitext of the Page namespace main slot content. This is undesirable because it makes it awkward to present the page in various editors and binds the content and metadata uncomfortably. Moving the proofreading status to a multi-content-revision (MCR) slot will allow us to keep the revision data in the revision, but also allow us to separate the content and status. By using, e.g. a serialised JSON format, it will also be possible to easily add more data to the page metadata in future. This is a separate issue to using change-tags (T290578) for a query-able and filterable view into page histories, which are currently derived from the `<pagequality>` tag, but moving it to a new MCR slot will not affect them. See T290578#7357138 for more comments to this effect.
    • Task
    A typical scenario on Commons: a vandal removes a claim then a bot adds the same claim again. Instead of simple "no changes" some strange comparison is shown, e.g. https://commons.wikimedia.org/w/index.php?title=File%3AAlyssa_Miller_2013_TIFF.jpg&type=revision&diff=517461919&oldid=482524761. This is very annoying and seems to be counterintuitive. But first of all it makes patrolling of recent changes really hard, especially when a few claims were removed and then added: e.g. https://commons.wikimedia.org/w/index.php?title=File%3AWikimedia%27s_traffic_-_Unique_Visitor_data_from_comScore_%28September_2014%29.pdf&action=historysubmit&type=revision&diff=520838490&oldid=449803355.
    • Task
    RevisionStore::updateSlotsOn() is passed a RevisionSlotsUpdate that could contain derived slots to be removed. However, RevisionStore::updateSotsOn() does not currently have logic to remove derived slots. This capability would need to be designed if needed.
    • Task
    From https://www.mediawiki.org/wiki/Multi-Content_Revisions/Derived_slots: Derived slots are an an addition to MCR that would allow information that is derived from the content of a page (or more precisely, from the content of the slots of a revision) to be stored alongside that content (as part of the same revision), even if the derived content is generated asynchronously or updated later on. Derived slots would work much like regular slots, with a few important differences: - their size is not included in the revision size, and their hash does not contribute to the revision's hash. - they can be updated at any time, using a new updateRevision() method that lives alongside saveRevision. - updating a derived slot is a destructive operation, the previous content of that slot (on the same revision) is lost. - updating derived slots is transparent for users. No entry is generated in the revision history or in RecentChanges or on the watchlist. The update is a purely technical operation, not an event from the perspective of the user. - If a derived slot is updated for the current revision of a page, this would however cause the page to be re-rendered (perhaps we want to make this optional), and derived page data (such as entries in the links tables) to be regenerated, similar to the way pages get rerendered when a template changes. - Derived slots should not show in diff views, at least not per default. The purpose of a diff view is to show what a user changed.
    • Task
    Hello, I tried to use `deleteArchivedRevisions.php` To test how it worked, I created new page, make several revisions. Then I deleted the page. Then I run `php deleteArchivedRevisions.php --delete` The table `archive` became empty. But the tables `content` and `text` were not modified. This is actual behavior. Expected behavior: rows in tables `content` and `text` which corresponds to deleted page should be removed. I tried other different scenarios, but I was not able to get `content` and `text` tables trimmed. It looks like the file deleteArchivedRevisions.php (https://github.com/wikimedia/mediawiki/blob/master/maintenance/deleteArchivedRevisions.php) is outdated after introducing "Multi-Content Revisions/Content Meta-Data" described at https://www.mediawiki.org/wiki/Multi-Content_Revisions/Content_Meta-Data. I also asked question at https://www.mediawiki.org/w/index.php?title=Topic:Vuex8d5m1kc441wo&topic_showPostId=w180el4we20epl79#flow-post-w180el4we20epl79
    • Task
    • ·Closed
    Currently, users of the Wikimedia Commons action API cannot create new `MediaInfo` entity on an existing commons page through the Wikibase interface while using the page's baserevid. An investigation is required to determine how to make this possible. **AC**: - We know where this operation is blocked (Wikibase or WikibaseMediaInfo?). - A way forward to implement this functionality is defined - A ticket (or tickets) have been created to tackle this topic or, if the dev considers the fix quick enough (meaning it fits in the remaining time in timebox), fix it **Reproduction:** # Upload a new file (and do NOT add any structured data) # Use `wbsetclaim` to add a statement and set the baserevid to the latest page revision # Receive an error **Current Behavior**: The request results in an error: ```lang=json,counterexample { "errors": [ { "code": "nosuchrevid", "text": "Revision with ID not found.", "data": { "messages": [ { "name": "wikibase-api-nosuchrevid", "parameters": [], "html": "Revision with ID not found." } ] }, "module": "main" } ], "docref": "See http://localhost/wiki1/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at &lt;https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce&gt; for notice of API deprecations and breaking changes." } ``` **Expected behavior**: The edit would be allowed, and is successful. **Hints**: - The issue identified in the ticket is with the `wbsetclaim` API, but this likely affects ALL APIs when used in this mode. - Although the bug is likely in Wikibase or MediaWiki the MediaInfo extension will be greatly beneficial when debugging as it is the only entity type currently setup to work with MCR (Multi-Content Revision). **Reading:** - https://www.mediawiki.org/wiki/Requests_for_comment/Multi-Content_Revisions - https://www.mediawiki.org/wiki/Extension:WikibaseMediaInfo **Original Note:** > In T263298 one of the issue at play is that you can't provide a baserevid to Wikibase API endpoints to create a mediainfo entity, if it didn't already exist. >This is discovered and confirmed in T263298#6494034 > >> When a file on commons does not get have a media info entity attached to it, you can not use a baserevid in Wikibase API calls >> This is a small issue with the MCR integration that someone will need to tackle for the edit conflict rules to be able to work in all cases. Timeboxed to 12 hours
    • Task
    • ·Closed
    The error "Main slot of revision (number) not found in database!", documented in T212428, has been present for some time. While this error should be fixed, the current logging is problematic for train triage, conductors, and deployers, who have to change how it is filtered on a weekly basis. Revise the logging to be more straightforward to filter. From a comment on the original task: "How about a log call to a custom channel for the revision ID and a generic exception message for error logs? The latter would be much easier for deployers to filter / ignore."
    • Task
    • ·Closed
    https://commons.wikimedia.beta.wmflabs.org/ fatal. This is preventing me testing some things on the beta cluster and given I'm not sure if this is isolated to beta cluster marking as UBN until somebody who understands this code better can comment. ``` [XupjZqwQBHcAAAaR1i8AAAAR] / LogicException from line 88 of /srv/mediawiki/php-master/includes/Revision/SlotRoleRegistry.php: Role mediainfo is already defined Backtrace: #0 /srv/mediawiki/php-master/includes/Revision/SlotRoleRegistry.php(115): MediaWiki\Revision\SlotRoleRegistry->defineRole(string, Closure) #1 /srv/mediawiki/php-master/extensions/WikibaseMediaInfo/src/WikibaseMediaInfoHooks.php(68): MediaWiki\Revision\SlotRoleRegistry->defineRoleWithModel(string, string) #2 [internal function]: Wikibase\MediaInfo\WikibaseMediaInfoHooks::Wikibase\MediaInfo\{closure}(MediaWiki\Revision\SlotRoleRegistry, MediaWiki\MediaWikiServices) #3 /srv/mediawiki/php-master/includes/libs/services/ServiceContainer.php(458): call_user_func_array(Closure, array) #4 /srv/mediawiki/php-master/includes/libs/services/ServiceContainer.php(419): Wikimedia\Services\ServiceContainer->createService(string) #5 /srv/mediawiki/php-master/includes/MediaWikiServices.php(1193): Wikimedia\Services\ServiceContainer->getService(string) #6 /srv/mediawiki/php-master/includes/ServiceWiring.php(1040): MediaWiki\MediaWikiServices->getSlotRoleRegistry() #7 /srv/mediawiki/php-master/includes/libs/services/ServiceContainer.php(451): Wikimedia\Services\ServiceContainer->{closure}(MediaWiki\MediaWikiServices) #8 /srv/mediawiki/php-master/includes/libs/services/ServiceContainer.php(419): Wikimedia\Services\ServiceContainer->createService(string) #9 /srv/mediawiki/php-master/includes/MediaWikiServices.php(1128): Wikimedia\Services\ServiceContainer->getService(string) #10 /srv/mediawiki/php-master/includes/ServiceWiring.php(1022): MediaWiki\MediaWikiServices->getRevisionStoreFactory() #11 /srv/mediawiki/php-master/includes/libs/services/ServiceContainer.php(451): Wikimedia\Services\ServiceContainer->{closure}(MediaWiki\MediaWikiServices) #12 /srv/mediawiki/php-master/includes/libs/services/ServiceContainer.php(419): Wikimedia\Services\ServiceContainer->createService(string) #13 /srv/mediawiki/php-master/includes/MediaWikiServices.php(1120): Wikimedia\Services\ServiceContainer->getService(string) #14 /srv/mediawiki/php-master/includes/cache/MessageCache.php(546): MediaWiki\MediaWikiServices->getRevisionStore() #15 /srv/mediawiki/php-master/includes/cache/MessageCache.php(448): MessageCache->loadFromDB(string, NULL) #16 /srv/mediawiki/php-master/includes/cache/MessageCache.php(371): MessageCache->loadFromDBWithLock(string, array, NULL) #17 /srv/mediawiki/php-master/includes/cache/MessageCache.php(1091): MessageCache->load(string) #18 /srv/mediawiki/php-master/includes/cache/MessageCache.php(1018): MessageCache->getMsgFromNamespace(string, string) #19 /srv/mediawiki/php-master/includes/cache/MessageCache.php(988): MessageCache->getMessageForLang(LanguageEn, string, boolean, array) #20 /srv/mediawiki/php-master/includes/cache/MessageCache.php(930): MessageCache->getMessageFromFallbackChain(LanguageEn, string, boolean) #21 /srv/mediawiki/php-master/includes/language/Message.php(1305): MessageCache->get(string, boolean, LanguageEn) #22 /srv/mediawiki/php-master/includes/language/Message.php(860): Message->fetchMessage() #23 /srv/mediawiki/php-master/includes/Message/TextFormatter.php(51): Message->toString(string) #24 /srv/mediawiki/php-master/includes/user/UserNameUtils.php(189): MediaWiki\Message\TextFormatter->format(Wikimedia\Message\MessageValue) #25 /srv/mediawiki/php-master/includes/user/User.php(987): MediaWiki\User\UserNameUtils->isUsable(string) #26 /srv/mediawiki/php-master/extensions/CentralAuth/includes/session/CentralAuthSessionProvider.php(166): User::isUsableName(string) #27 /srv/mediawiki/php-master/includes/session/SessionManager.php(492): CentralAuthSessionProvider->provideSessionInfo(WebRequest) #28 /srv/mediawiki/php-master/includes/session/SessionManager.php(215): MediaWiki\Session\SessionManager->getSessionInfoForRequest(WebRequest) #29 /srv/mediawiki/php-master/includes/WebRequest.php(830): MediaWiki\Session\SessionManager->getSessionForRequest(WebRequest) #30 /srv/mediawiki/php-master/includes/session/SessionManager.php(137): WebRequest->getSession() #31 /srv/mediawiki/php-master/includes/Setup.php(725): MediaWiki\Session\SessionManager::getGlobalSession() #32 /srv/mediawiki/php-master/includes/WebStart.php(89): require_once(string) #33 /srv/mediawiki/php-master/index.php(44): require(string) #34 /srv/mediawiki/w/index.php(3): require(string) #35 {main} ```
    • Task
    • ·Closed
    The following schema changes should be applied to the revision table when updating to 1.35: * Drop `rev_text_id`, `rev_content_model`, and `rev_content_format` that MCR obsoleted. * Drop `ar_text_id`, `ar_content_model`, and `ar_content_format` that MCR obsoleted. * Replace `rev_comment` with `rev_comment_id`. * Replace `rev_user` and `rev_user_text` with `rev_actor`, plus associated index changes.
    • Task
    • ·Closed
    Steps to Reproduce: # set a content model in `$wgNamespaceContentModels[NS]['content_model']` # run `maintenance/populateContentModel.php -- ns=NS` for archive and revision Actual Results: # go on a page in that namespace in the wiki, no page is using the set content model. When browsing the code in `populateContentModel.php`, it seems it's only updateing the revision (or archive) table but that seems to be a deprecated way of specifying the content_model. In recent versions, this has been moved to the `content` table. Expected Results: # all pages in that namespace should be using the configured content model. I actually encountered the error while moving flow talk pages from one namespace to another. For some reason, all content_models were reset to wikitext. In trying to fix the issue by calling the maintenance script, I noticed it had no effect. I then used SpecialChangeContentModel to fix the issue page by page.
    • Task
    • ·Closed
    But, rather than deprecating just not passing a user, the whole function should be deprecated as part of MCR migration to RevisionRecord, which already requires a user for the equivalent function
    • Task
    • ·Closed
    **Steps to Reproduce: ** - Just did a migration from 1.31 to 1.34 - In the migration process towards [[ https://www.mediawiki.org/wiki/Requests_for_comment/Multi-Content_Revisions| Multi-Content Revisions ]], the content model of NS_TALK pages was reset to wikitext. However the content model of NS_USER_TALK and other talk namespaces was correctly migrated (in this case, flow-board) - In LocalSettings.php, `$wgNamespaceContentModels[NS_TALK] = 'flow-board';` is set - running `php maintenance/populateContentModel.php -- ns=1` on table, revision and archive has no effect. **Actual Results:** Pages in NS_TEXT are still displayed using wikitext ContentHandler. **Expected Results:** Pages in NS_TEXT should be displayed using the flow-board ContentHandler. **Thoughts:** This bug has two issues: # Migration was not correctly done since NS_TALK's contentHandler was reset to wikitext during migration. # populateContentModel.php was not updated to reflect changes in content model handling introduced in MW > 1.31. Setting $wgNamespaceContentModel and running it has no effect. On inspection of a //content// table row for a NS_TALK page, the content_model field is set to 1, which is the id for wikitext. However, rev_content_model in the table //revision// is set to flow-board ( from what I understand `revision.rev_content_model` was dropped in favor of `content.content_model`) For NS_USER_TALK `content.content_model` is correctly set to 3. **Note: ** This does not appear to be a problem with the Flow extension but rather a problem of MediaWiki core migration and handling of ContentHandler. Forcing `'flow-board'` in `WikiPage::getContentModel()` fixes the issue.
    • Task
    • ·Closed
    The structure data diff that displays @ https://commons.m.wikimedia.org/wiki/Special:MobileDiff/388741403 is confusing. There might be two bugs here but I want to focus on the lead paragraph issue. I suggest the #structured-data-backlog team also look at this diff and create a new task if necessary for anything other than the move paragraph issue I am describing here. The diff can somewhat be reproduced on desktop using diff-type=inline parameter. https://commons.wikimedia.org/w/index.php?title=File:%D0%A4%D0%BE%D1%82%D0%BE_%D0%90%D0%BB%D0%B8%D1%88%D0%B5%D1%80_%D0%A2%D0%B0%D1%88%D0%BC%D0%B0%D1%82%D0%BE%D0%B2_%D0%91%D0%BE%D0%B3%D0%B0%D1%80%D0%B4%D0%B8%D0%B5%D0%B2%D0%B8%D1%87.jpg&diff=388741403&diff-type=inline Related to this, on https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileDiff/411429 the move paragraph doesn't seem to match the mocks in T197491 anymore. Mock: https://wikimedia.invisionapp.com/public/share/3HEQCYR25#/screens/266827752 Current behaviour: {F31518403} = Developer notes I think the issue here is that the `mediawiki.diff.styles` module is loading and wasn't loaded before, so desktop and mobile styles are conflicting. These rules (and possibly other) should be disabled on Minerva Option 1) moved to skinStyles in core so that they are substituted by the Minerva ones; 2) override in Minerva: ``` .mw-diff-movedpara-right::after, .rtl .mw-diff-movedpara-left::after { content: '↩'; } .mw-diff-movedpara-left::after, .rtl .mw-diff-movedpara-right::after { content: '↪'; } ``` = QA steps https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileDiff/412207 should match the mock. == QA Results | **AC** | **Status** | **Details** | | ----- | ----- | ----- | | 1 | ✅ | T243235#5841699 |
    • Task
    • ·Closed
    The patch that removes compatibility code for the pre-MCR schema needs to be tested for issues with the updater. Updates from different versions of MediaWiki need to still work after we remove the compat layer. This tests the assumption that all code that is needed to convert from the old schema to the new is still present in the migration scripts. The basic procedure for testing is: * Switch to the release branch of the old version to test * Configure the wiki to match the setup to test * Edit the main page, so there is at least one old revision * Create another page with at least two revisions, then delete it. * Check out the change to test: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/552339 * Run maintenance/update.php * Assert that no errors were reported during the update * Assert that the page is still readable * Assert that the content of old revisions can still be read * Assert that the content of deleted revisions can still be read * Assert that pages can still be edited * Assert that pages can successfully be undeleted This should be checked for at least the following versions and setups: [x] MW 1.31 installed from scratch (last LTS, pre-MCR). [perhaps make a db dump after the installation is complete, so it's easy to go back here] / upgraded to patched master [x] MW 1.32 vanilla, installed from scratch / upgraded to patched master [x] MW 1.33 vanilla, installed from scratch / upgraded to patched master [x] MW 1.34 vanilla, installed from scratch / upgraded to patched master [x] MW 1.31 installed from scratch / upgraded to 1.34 with $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_NEW set before the update / upgraded to patched master [] ~~MW 1.31 installed from scratch / upgraded to 1.34 with $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_OLD set before the update / upgraded to patched master (cannot upgrade to MW 1.34 with $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_OLD)~~ [x] MW 1.31 vanilla, installed from scratch / upgraded to 1.32 with $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_OLD before the update / upgraded to 1.34 with no value set for $wgMultiContentRevisionSchemaMigrationStage / upgraded to patched master (create/edit/edit/delete a test page at each stage) [x] MW 1.31 vanilla, installed from scratch / upgraded to 1.32 with $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_OLD before the update / upgraded to 1.34 with $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_NEW before the update / upgraded to patched master (create/edit/edit/delete a test page at each stage) [x] MW 1.32 installed from scratch with $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_OLD before the update / upgraded to 1.34 with no value set for $wgMultiContentRevisionSchemaMigrationStage before the update / upgraded to patched master (create/edit/edit/delete a test page at each stage) [x] MW 1.32 installed from scratch with $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_OLD before the update / upgraded to 1.34 with $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_NEW before the update / upgraded to patched master (create/edit/edit/delete a test page at each stage) When installing from scratch, make sure you target a database name that does not yet exist!
    • Task
    ### Setup and configuration - MediaWiki 1.33.2 (4d49bc3) 14:30, 19 December 2019 - PHP | 7.2.24-0ubuntu0.18.04.1 (apache2handler) - MariaDB | 10.1.43-MariaDB-0ubuntu0.18.04.1 - VisualEditor | 0.1.1 (6f1fd3d) 23:13, 30 November 2019 - Semantic MediaWiki | 3.1.1 (143488d) 10:11, 17 November 2019 - Abuse Filter – (e054f2e) 18:49, 4 December 2019 ### Issue When running "update.php" or "setupStore.php" I get a failure if not using the `--skip-import` flag. I am not sure why this happens. ``` Importing from smw.groups.json ... ... replacing smw/schema:Group:Schema properties importer was last editor ... [f4fc8747b73543c93b00e612] [no req] MediaWiki\Storage\NameTableAccessException from line 42 of /../w/includes/Storage/NameTableAccessException.php: Failed to access name from content_models using id = 2 ``` User 2 is Abuse Filter created by the respective extension. Originally reported for [[ https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/4386 | Semantic MediaWiki ]]. ### Backtrace ``` #0 /../w/includes/Storage/NameTableStore.php(308): MediaWiki\Storage\NameTableAccessException::newFromDetails(string, string, integer) #1 /../w/includes/Revision/RevisionStore.php(1633): MediaWiki\Storage\NameTableStore->getName(integer) #2 /../w/includes/Revision/RevisionStore.php(1680): MediaWiki\Revision\RevisionStore->loadSlotRecords(string, integer) #3 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}() #4 /../w/includes/Revision/RevisionSlots.php(165): call_user_func(Closure) #5 /../w/includes/Revision/RevisionSlots.php(136): MediaWiki\Revision\RevisionSlots->getSlots() #6 /../w/includes/Revision/RevisionRecord.php(219): MediaWiki\Revision\RevisionSlots->getSlotRoles() #7 /../w/includes/Revision/MutableRevisionRecord.php(57): MediaWiki\Revision\RevisionRecord->getSlotRoles() #8 /../w/includes/Storage/DerivedPageDataUpdater.php(773): MediaWiki\Revision\MutableRevisionRecord::newFromParentRevision(MediaWiki\Revision\RevisionStoreCacheRecord) #9 /../w/includes/Storage/PageUpdater.php(694): MediaWiki\Storage\DerivedPageDataUpdater->prepareContent(User, MediaWiki\Storage\RevisionSlotsUpdate, boolean) #10 /../w/includes/page/WikiPage.php(1915): MediaWiki\Storage\PageUpdater->saveRevision(CommentStoreComment, integer) #11 /../w/extensions/SemanticMediaWiki/src/Importer/ContentCreators/TextContentCreator.php(124): WikiPage->doEditContent(SMW\MediaWiki\Content\SchemaContent, CommentStoreComment, integer) #12 /../w/extensions/SemanticMediaWiki/src/Importer/ContentCreators/TextContentCreator.php(110): SMW\Importer\ContentCreators\TextContentCreator->doCreateContent(WikiPage, Title, SMW\Importer\ImportContents) #13 [internal function]: SMW\Importer\ContentCreators\TextContentCreator->SMW\Importer\ContentCreators\{closure}(integer, Wikimedia\Rdbms\DatabaseMysqli) #14 /../w/includes/libs/rdbms/database/Database.php(3588): call_user_func(Closure, integer, Wikimedia\Rdbms\DatabaseMysqli) #15 /../w/includes/libs/rdbms/database/Database.php(3436): Wikimedia\Rdbms\Database->runOnTransactionIdleCallbacks(integer) #16 /../w/includes/libs/rdbms/database/DBConnRef.php(53): Wikimedia\Rdbms\Database->onTransactionCommitOrIdle(Closure) #17 /../w/includes/libs/rdbms/database/DBConnRef.php(572): Wikimedia\Rdbms\DBConnRef->__call(string, array) #18 /../w/extensions/SemanticMediaWiki/src/MediaWiki/Connection/Database.php(764): Wikimedia\Rdbms\DBConnRef->onTransactionCommitOrIdle(Closure) #19 /../w/extensions/SemanticMediaWiki/src/Importer/ContentCreators/TextContentCreator.php(111): SMW\MediaWiki\Connection\Database->onTransactionIdle(Closure) #20 /../w/extensions/SemanticMediaWiki/src/Importer/ContentCreators/DispatchingContentCreator.php(75): SMW\Importer\ContentCreators\TextContentCreator->create(SMW\Importer\ImportContents) #21 /../w/extensions/SemanticMediaWiki/src/Importer/Importer.php(133): SMW\Importer\ContentCreators\DispatchingContentCreator->create(SMW\Importer\ImportContents) #22 /../w/extensions/SemanticMediaWiki/src/Importer/Importer.php(109): SMW\Importer\Importer->doImportContents(SMW\Importer\ImportContents) #23 /../w/extensions/SemanticMediaWiki/src/MediaWiki/Hooks.php(1352): SMW\Importer\Importer->doImport() #24 /../w/includes/Hooks.php(174): SMW\MediaWiki\Hooks->onAfterCreateTablesComplete(SMW\SQLStore\TableBuilder\MySQLTableBuilder, Onoi\MessageReporter\ObservableMessageReporter, SMW\Options) #25 /../w/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL) #26 /../w/extensions/SemanticMediaWiki/src/SQLStore/Installer.php(191): Hooks::run(string, array) #27 /../w/extensions/SemanticMediaWiki/src/SQLStore/SQLStore.php(437): SMW\SQLStore\Installer->install(SMW\Options) #28 /../w/extensions/SemanticMediaWiki/src/Elastic/ElasticStore.php(326): SMW\SQLStore\SQLStore->setup(SMW\Options) #29 /../w/extensions/SemanticMediaWiki/src/Store.php(506): SMW\Elastic\ElasticStore->setup(SMW\Options) #30 /../w/includes/installer/DatabaseUpdater.php(489): SMW\Store::setupStore(boolean, SMW\Options) #31 /../w/includes/installer/DatabaseUpdater.php(457): DatabaseUpdater->runUpdates(array, boolean) #32 /../w/maintenance/update.php(203): DatabaseUpdater->doUpdates(array) #33 /../w/maintenance/doMaintenance.php(96): UpdateMediaWiki->execute() #34 /../w/maintenance/update.php(275): require_once(string) #35 {main} ```
    • Task
    • ·Closed
    The DifferenceEngine class in core can now handle inline diffs (provided wikidiff2 is installed). We will drop InlineDiffFormatter and InlineDifferenceEngine from MobileFrontend which cater for 3rd parties. The deprecation notice was added a while back and we've been running this code in production for several months now. All we need to do is remove it. = Acceptance criteria [x] The deprecation notice has been pushed out. [x] InlineDifferenceEngine is gone from MobileFrontend [x] InlineDiffFormatter is gone from MobileFrontend [x] No change in display before and after to Special:MobileDiff. = Developer notes When testing note you'll need wikidiff2 installed. If you don't after the code removal you will realise that you've been testing code locally that is never used in production and will need to set it up :-). Note: The removal of MobileDiff will happen later. We are not ready to do that just yet!
    • Task
    A new inline diff mode is available for diffs alongside the traditional side by side mode - this is the traditional mobile diff view. It should be made available on desktop. URL: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Spain&type=revision&diff=400071&oldid=397846&diff-type=inline {F31474008} A `visualdiff` mode/control is also provided by VisualEditor I think this is the code: https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/1d3386b8ac703e27893821dc6dfc285b73cf0bb4/includes/VisualEditorHooks.php#147 Proposal: We move this control into core and allow extensions to extend it. By default the control would contain inline and side-by-side I didn't know about visual diff recently so I had proposed a simple drop down for the control at the bottom of the diff {F31474015} {F31474017} = Acceptance criteria [] When inlinediff or visualdiff mode is not available the control should not show. = Open questions * Designers: Is the ButtonWidget appropriate here or should a dropdown be used (think of mobile screens)? * Designers: If we are using ButtonWidger what should the inline icon be? * Designers: Where to place the control on the diff? * Is diffmode the right parameter or should diff-type be used? * Designers if diffmode is not available and the user requests inline mode should there be some sort of feedback that it's not available?
    • Task
    • ·Closed
    Rarely, some revisions seem to have `rev_sha1` and/or `rev_len` derived from the parent revision instead of the revision itself. When the revision has only a 'main' slot, `rev_sha1` should match `content_sha1` and `rev_len` should match `content_size`; this allows affected revisions to be easily found. Finding them for revisions on Commons that have a mediainfo slot may be more difficult. I found 49 such revisions on enwiki in 2019. The "h1" and "h2" columns reflect the hypothesis that the bug is in use of the parent revision's data rather than some less specific corruption. ``` wikiadmin@10.64.48.13(enwiki)> select rev_id, rev_timestamp, c.content_sha1, rev_sha1, p.content_sha1 as "parent_sha1", rev_sha1=c.content_sha1 or rev_sha1=p.content_sha1 as h1, c.content_size, rev_len, p.content_size as "parent_size", rev_len=c.content_size or rev_len=p.content_size as h2 from revision join slots as cs on (slot_revision_id=rev_id) join content as c on (content_id=slot_content_id) left join slots as ps on(ps.slot_revision_id = rev_parent_id) left join content as p on(p.content_id=ps.slot_content_id) where rev_timestamp like '2019%' and (rev_sha1!=c.content_sha1 or rev_len!=c.content_size) order by rev_timestamp asc; +-----------+----------------+---------------------------------+---------------------------------+---------------------------------+------+--------------+---------+-------------+------+ | rev_id | rev_timestamp | content_sha1 | rev_sha1 | parent_sha1 | h1 | content_size | rev_len | parent_size | h2 | +-----------+----------------+---------------------------------+---------------------------------+---------------------------------+------+--------------+---------+-------------+------+ | 878065208 | 20190112195110 | gs63e5lmwdr3r6bcmakqm3splx2dotk | gs63e5lmwdr3r6bcmakqm3splx2dotk | pt97gntma90ay2f918ec67ta2306a86 | 1 | 1284 | 283 | 283 | 1 | | 880278781 | 20190126143001 | 69dax4okof0aqqbgr0xx4tgf96097sl | 69dax4okof0aqqbgr0xx4tgf96097sl | 3ld8wi5h0agnp6d2wjul33gslfgyk5n | 1 | 249548 | 248528 | 248528 | 1 | | 880316669 | 20190126192223 | ivva4s7jb2wwwgbfjdga93sd180vswe | ivva4s7jb2wwwgbfjdga93sd180vswe | pkx9tqkv0ch3lrwykuk09zy7x3anzwg | 1 | 159837 | 158817 | 158817 | 1 | | 881691109 | 20190204045427 | t5mqa3jq0uqljo03vuttoovfb98r0mc | t5mqa3jq0uqljo03vuttoovfb98r0mc | mngvoamqyneafy4v6fhcxxfryjzup97 | 1 | 135571 | 134381 | 134381 | 1 | | 882203781 | 20190207141836 | nln6jxs7zj2v1xlmat1yjkc4u037eb9 | nln6jxs7zj2v1xlmat1yjkc4u037eb9 | kdnrvumo6pr7ym6s2i5aabwwp53fm88 | 1 | 136110 | 134653 | 134653 | 1 | | 884446740 | 20190221180820 | iaildmbosvkjt28c3d0w7w0lnyz5qbr | iaildmbosvkjt28c3d0w7w0lnyz5qbr | prk0gj1y4y0be8zyofocmbw0lthp0nr | 1 | 868927 | 867905 | 867905 | 1 | | 885238763 | 20190226205814 | eoep1y6b7wy5mtb93mul90erm1t4a6i | eoep1y6b7wy5mtb93mul90erm1t4a6i | a3mvcafynaia75e1q3gbsp2uj2fakbf | 1 | 102494 | 100715 | 100715 | 1 | | 885707174 | 20190301194626 | 1kph6xlbrpenv5arqhny919swsyt6hd | 1kph6xlbrpenv5arqhny919swsyt6hd | 74wi4g649hwllf7a54yx4adgensd0uu | 1 | 769095 | 767941 | 767941 | 1 | | 885854102 | 20190302194031 | fvfd50jxu4szy452s64q3ska2t935k8 | fvfd50jxu4szy452s64q3ska2t935k8 | 74uxabf6wf9nwtkgvlo687p9dt0l1uv | 1 | 88306 | 86738 | 86738 | 1 | | 886675374 | 20190307195325 | 9ano2c6slaax2rcjyidl843rt1ld2c0 | 9ano2c6slaax2rcjyidl843rt1ld2c0 | hutjdc7pv8036fr46iqkdoc0wgl9uv7 | 1 | 98640 | 97104 | 97104 | 1 | | 887350302 | 20190312023019 | 84kq2usqtgou6vp0h1326nlh2ceih9o | 84kq2usqtgou6vp0h1326nlh2ceih9o | 3m6049rljb0caaq8sr5469xsrwrzmtv | 1 | 133170 | 132154 | 132154 | 1 | | 888198383 | 20190317155853 | 56ozincizoce1txc7aji3nxcjjvwxjd | 56ozincizoce1txc7aji3nxcjjvwxjd | fwe6ammfhs8ffq0eq2jtfj1liorq2bh | 1 | 1810 | 798 | 798 | 1 | | 891994409 | 20190411140939 | iueaz79drf5jh74txhwnh4pcgbbptg3 | iueaz79drf5jh74txhwnh4pcgbbptg3 | k6ot6gv73k4r4htc7sf1dcedzw17oak | 1 | 268082 | 267071 | 267071 | 1 | | 893149264 | 20190419101712 | hdrh2qtf0v84714esvj7n08qftuhn66 | hdrh2qtf0v84714esvj7n08qftuhn66 | h07b6tjdh66l1qqbvr762rluzmjyukp | 1 | 157779 | 156768 | 156768 | 1 | | 894046563 | 20190425081530 | q24ep55i0s7zr2syr5pj0117yjifp00 | q24ep55i0s7zr2syr5pj0117yjifp00 | bryfuomtcwoddy8do69cz4bbabptjbp | 1 | 399760 | 398750 | 398750 | 1 | | 896116760 | 20190508120152 | k241qz91f27uslwklfu2tdexkzmm5f9 | k241qz91f27uslwklfu2tdexkzmm5f9 | kszqovdqvpcefbsw57i7ajfa0jv895f | 1 | 153299 | 152369 | 152369 | 1 | | 899683728 | 20190531170232 | sxghdhe1pyiqt4ou0j6pbqc8v9mwqsd | sxghdhe1pyiqt4ou0j6pbqc8v9mwqsd | scd5qc9ju91rhrf0npzhzvwiexzri2n | 1 | 130199 | 129010 | 129010 | 1 | | 900287348 | 20190604170540 | cwun44t3ar6d0883t5nlqif56sevy4p | cwun44t3ar6d0883t5nlqif56sevy4p | jiytkvx10m3qhiy5c3mhpthghmffle5 | 1 | 1102421 | 1101321 | 1101321 | 1 | | 907678319 | 20190724143618 | 6vfrdwrpegtgp8gf1uojjya3hasai2k | 6vfrdwrpegtgp8gf1uojjya3hasai2k | sa6yx5f1eimfpx5h1o6mzkaut4u6lhg | 1 | 42233 | 40216 | 40216 | 1 | | 908579513 | 20190730162959 | jact05uz88b2buqj8v2g8slj6t3ev5r | oq5m5s5zdco74a4e9q2bfxu379d0hxo | oq5m5s5zdco74a4e9q2bfxu379d0hxo | 1 | 110493 | 109316 | 109316 | 1 | | 908579605 | 20190730163040 | trmnobpn0xi54zdcblj3rabzgp75r2p | jact05uz88b2buqj8v2g8slj6t3ev5r | jact05uz88b2buqj8v2g8slj6t3ev5r | 1 | 110492 | 110493 | 110493 | 1 | | 909769741 | 20190807140250 | 4kk862f2cpy0dwcj6d1mk904uc9hawx | 9l9emwdbg06u3uxao6855m2zxgsz242 | 9l9emwdbg06u3uxao6855m2zxgsz242 | 1 | 144826 | 143797 | 143797 | 1 | | 910369588 | 20190811161646 | j2rynutv4c4gwgrp3vzvh60dy6ef2j0 | h15qf4r5nm63iynq42lzn2c33ml1lzz | h15qf4r5nm63iynq42lzn2c33ml1lzz | 1 | 47026 | 45809 | 45809 | 1 | | 910667477 | 20190813164503 | n6ge458p9wfzhjsrjotp3n3pc8l11zm | r71bdzldoi3ecsxvzo0q65jav86bgbz | r71bdzldoi3ecsxvzo0q65jav86bgbz | 1 | 117016 | 115998 | 115998 | 1 | | 910810302 | 20190814161501 | dl2ux65zrxcqpcvldgzb4fo29ojyxqf | trfu19olf2fpg69pbjleiezjdrjkw93 | trfu19olf2fpg69pbjleiezjdrjkw93 | 1 | 538044 | 537026 | 537026 | 1 | | 910841318 | 20190814204033 | s1w6l1v4rqxbeepovo9j0b3voiaqsgq | 6rgvdai1krj9vdipr802uyojz08nfvv | 6rgvdai1krj9vdipr802uyojz08nfvv | 1 | 118627 | 117426 | 117426 | 1 | | 914059363 | 20190904222026 | c0326zjkxpihx207uu6jxrqzkz8p3a3 | rqu5ssib0imxai8q6figlnmyhso6zmw | rqu5ssib0imxai8q6figlnmyhso6zmw | 1 | 59146 | 57940 | 57940 | 1 | | 914143304 | 20190905130827 | o2x0deb4jb75jkta7w15qom9ru1xt3o | 24d1ohqeoffietvozlnt9uqjxijhcca | 24d1ohqeoffietvozlnt9uqjxijhcca | 1 | 99330 | 98310 | 98310 | 1 | | 917568240 | 20190924122520 | 477xnqbzla1ntbzfkx5c8p2gtg06q2o | gmqd2ze6hg01h1bde3knvvlbzctkivv | gmqd2ze6hg01h1bde3knvvlbzctkivv | 1 | 205449 | 204388 | 204388 | 1 | | 918024535 | 20190926165957 | 3jm6ivh8tmu1wa44hurmrla0ulo8iaf | heokqho43hw3k5xcwuoowdyuooy8yhu | heokqho43hw3k5xcwuoowdyuooy8yhu | 1 | 106948 | 105931 | 105931 | 1 | | 921476910 | 20191015232601 | fstn29cxm5x8bsszylfukag9blxsdp3 | bw9lfj7c2c6966c95alpidrvbm6wiel | bw9lfj7c2c6966c95alpidrvbm6wiel | 1 | 836962 | 835937 | 835937 | 1 | | 921476985 | 20191015232634 | 658v4ayup36j6d78pst2udt5e7mcs5a | fstn29cxm5x8bsszylfukag9blxsdp3 | fstn29cxm5x8bsszylfukag9blxsdp3 | 1 | 837987 | 836962 | 836962 | 1 | | 922120198 | 20191020022108 | jnh4feyz7gt2arybq5ip6pvoeicpvna | 27gmmfihnl8jpjicwx2kdp8uhdyjifq | 27gmmfihnl8jpjicwx2kdp8uhdyjifq | 1 | 3651 | 3651 | 3358 | 1 | | 922434213 | 20191022031337 | 9e9d7n84f6i30d93odkx3kn8bzivqm2 | k8xgdvbv9wtxcp6g9b42ec3e0wrn0ai | k8xgdvbv9wtxcp6g9b42ec3e0wrn0ai | 1 | 2132 | 2132 | 1820 | 1 | | 923519434 | 20191029013917 | 8dp0677fiuf1ovhyl7rb3h1qg7tw63w | jcgyuczygobkqvn2hk8f76oqd93djuk | jcgyuczygobkqvn2hk8f76oqd93djuk | 1 | 500705 | 500705 | 166859 | 1 | | 923758684 | 20191030161741 | 6sa9llkpqydznu4w8hncc3rnf55c5m8 | iw2gtid35ytmb0vdw55u7eghrteiq7f | iw2gtid35ytmb0vdw55u7eghrteiq7f | 1 | 178870 | 176496 | 176496 | 1 | | 924070125 | 20191101162527 | sv5akjpo3qdm98k3ofxezc882jfow0e | 1hp406lv00tx8x3lj9pewm5lk6hs5r2 | 1hp406lv00tx8x3lj9pewm5lk6hs5r2 | 1 | 9769 | 9769 | 4877 | 1 | | 924329064 | 20191103050233 | gx025z9e0cz44qa9l3xirvaugr7is0c | dl1xls9wngylhokkrchq7teabj42j5h | dl1xls9wngylhokkrchq7teabj42j5h | 1 | 664355 | 664355 | 132869 | 1 | | 924329202 | 20191103050348 | t8mnlr6h55hdrmj7g2lx1u7d3nscur4 | gx025z9e0cz44qa9l3xirvaugr7is0c | gx025z9e0cz44qa9l3xirvaugr7is0c | 1 | 2657523 | 2657523 | 664355 | 1 | | 924329471 | 20191103050703 | e5hjned41vu4ix6yyd1p1xygcct14aw | akz4epfeme0yng9vq8obyrz03ou8i08 | akz4epfeme0yng9vq8obyrz03ou8i08 | 1 | 624760 | 624760 | 104125 | 1 | | 924329537 | 20191103050736 | exlxmedxh66mqouala9w5sgpsbul898 | e5hjned41vu4ix6yyd1p1xygcct14aw | e5hjned41vu4ix6yyd1p1xygcct14aw | 1 | 2499141 | 2499141 | 624760 | 1 | | 924338026 | 20191103064749 | 0gtk1w7017fbb61xj1crd9tiw5kv4an | q2h5nush5gole2id0bpwt2vlrudohrg | q2h5nush5gole2id0bpwt2vlrudohrg | 1 | 95213 | 95213 | 19039 | 1 | | 924338085 | 20191103064824 | n0q5ict733si79d6tklhfqoetn4s8dv | 0gtk1w7017fbb61xj1crd9tiw5kv4an | 0gtk1w7017fbb61xj1crd9tiw5kv4an | 1 | 1142566 | 1142566 | 95213 | 1 | | 924338116 | 20191103064859 | 5zcv4m13s9fbitevwiade39qk7rd9u3 | n0q5ict733si79d6tklhfqoetn4s8dv | n0q5ict733si79d6tklhfqoetn4s8dv | 1 | 2285146 | 2285146 | 1142566 | 1 | | 924343130 | 20191103075551 | pyt4ndpwuwtdsqavbidh4ufowo6v4gf | kldmuy57hlns0ai197wifzaa95iud5y | kldmuy57hlns0ai197wifzaa95iud5y | 1 | 3505 | 3505 | 3291 | 1 | | 926706706 | 20191118050344 | pmy4isrwj77tngncui8ch3zlhp39uvh | gd4ogk7u669s84ixlb9l9pxmgpklirp | gd4ogk7u669s84ixlb9l9pxmgpklirp | 1 | 57450 | 57450 | 50470 | 1 | | 926707018 | 20191118050757 | nik1bugm5avnwmtmt21gm1qva8urex3 | gldvvttxdhgxt9i4un0frvg92xdu932 | gldvvttxdhgxt9i4un0frvg92xdu932 | 1 | 37979 | 37979 | 44713 | 1 | | 927216163 | 20191121020935 | 1row3ey1m79v6h2yeqwhgdxd5mt073l | c0q6wp1hrbeg9bw3a30v4mh98hytqxp | c0q6wp1hrbeg9bw3a30v4mh98hytqxp | 1 | 103094 | 103094 | 100133 | 1 | | 928622565 | 20191130152646 | jm2o43w5c4ok6lm54xzxf05ymoclea7 | 5p3q5kzdgll0akxrw9i7tzm9fs5hccw | 5p3q5kzdgll0akxrw9i7tzm9fs5hccw | 1 | 184778 | 183755 | 183755 | 1 | +-----------+----------------+---------------------------------+---------------------------------+---------------------------------+------+--------------+---------+-------------+------+ 49 rows in set (11 min 1.75 sec) ``` This was originally reported at https://en.wikipedia.org/wiki/Wikipedia:Help_desk#Weird_bytecount_in_page_history and https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Weird_bytecount_in_page_history
    • Task
    • ·Closed
    **Steps to Reproduce:** Open a Multi-Content Revisions undo form, like https://commons.wikimedia.org/w/index.php?title=File:Powered_by_MediaWiki.svg&action=mcrundo&undo=377299843&undoafter=374177203 **Actual Results:** > [XdllSApAADoAABlS1oIAAABH] 2019-11-23 16:58:48: Fatal exception of type "InvalidArgumentException" **Expected Results:** The revert form appears.
    • Task
    • ·Closed
    TextPassDumperTest relies on the 0.10 schema and needs updating to make it work with the 0.11 schema.
    • Task
    T184615 talks about removing `rev_text_id` in favor of the multi-slot architecture of MCR. We don't do much with the rev_text_id, but it is selected and propagated throughout our mediawiki history pipeline. So at the very least we need to change sqoops and refinery-source code. We can start this work immediately and park it for when this change is deployed. If we don't have it ready, the mediawiki history jobs will fail.
    • Task
    • ·Closed
    WikiExporter has an explicit check that makes it fail if the SCHEMA_COMPAT_WRITE_OLD flag is not set in $wgMultiContentRevisionMigrationStage. This causes all exports to fail in SCHEMA_COMPAT_NEW mode. This check was needed to avoid breakage while WikiExporter was still relying on the old schema for bulk operations. This has has however been however been resolved by {T198706} and {T198341}. This check is now obsolete and should be removed to allow us to switch to SCHEMA_COMPAT_NEW everywhere.
    • Task
    • ·Closed
    Hi, This is really two or three separate problems in one, but they all relate to the same hook, so I figured I'd make one bug report for all of them. The ArticleRevisionViewCustom hook was added in MW 1.32: https://www.mediawiki.org/wiki/Manual:Hooks/ArticleRevisionViewCustom It is meant to replace two existing hooks, ArticleContentViewCustom and ArticleAfterFetchContentObject, both of which were deprecated when that hook was added: https://www.mediawiki.org/wiki/Manual:Hooks/ArticleContentViewCustom https://www.mediawiki.org/wiki/Manual:Hooks/ArticleAfterFetchContentObject Here's the commit where it all happened, by the way: https://phabricator.wikimedia.org/rMW4835a75ec56444c61c5d0cfbc9e98ceb420fc513 I have two extensions that use ArticleAfterFetchContentObject to modify the text displayed for particular pages: Approved Revs and an upcoming one, tentatively titled Diagrams. (These might be the only two extensions right now that use any of these three hooks, by the way, as far as I know.) I want to replace the use of the deprecated ArticleAfterFetchContentObject with ArticleRevisionViewCustom in my extensions. However, there are some problems that prevent me from doing this. The first is that this hook is called in two different places in the code, with a different set of arguments in each: https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/page/Article.php$756 https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/diff/DifferenceEngine.php$871 I believe that just adding $this->mOldid as a new third argument in the DifferenceEngine.php call will fix this problem. The potentially more difficult problem is that it doesn't seem like ArticleRevisionViewCustom really allows for modifying the page display - in either the article or the diff page. In the article display (Article.php), this hook seems to be called *before* the body text variable (OutputPage::$mBodytext) is populated - which means that you can prepend text (ironically, both $output->prependHTML() and $output->addHTML() do this), but you can't append text, and you can't modify the original text. If this hook were called after $mBodytext is generated, I believe all three of these could be done. In DifferenceEngine.php, the hook is called after the main diff display is generated, but before the "Revision as of ..." part is added - and, I would think, if anything, that the hook should be modifying that second part. (No?) So, I think this hook needs to be fixed. Of course, a simpler solution, at least for now, is just to de-deprecate ArticleAfterFetchContentObject... but maybe there's some good reason not to do that.
    • Task
    • ·Closed
    Unable to restore https://pl.wikipedia.org/wiki/Lista_kolor%C3%B3w Some revisions can't be previewed: https://pl.wikipedia.org/w/index.php?title=Specjalna:Odtw%C3%B3rz&target=Lista+kolor%C3%B3w&timestamp=20060330184135&diff=prev ```name=message [XbXHpgpAMFYAAJsVC4AAAACN] /w/index.php?title=Specjalna:Odtw%C3%B3rz&action=submit MediaWiki\Revision\IncompleteRevisionException from line 404 of /srv/mediawiki/php-1.35.0-wmf.3/includes/Revision/RevisionStore.php: user_text field must not be ''! ```
    • Task
    Currently, EditPage has the 'EditFilterMergedContent' hook, which provides the new *text* of the edit, along with other data such as the summary. While that's OK for some consumers, others may need the *PSTed* text of the page. Right now I'm thinking of AbuseFilter (some variables will return the links contained in the new text), and especially SpamBlacklist. SB will effectively PST all edits, because it always needs the added links to filter them. Fortunately, we have a Parser cache and the new text of the edit will only be parsed once. However, I don't think that we should rely on this in the long term. It's also a little confusing, if you look e.g. at the performance flame graphs (it could seem that SpamBlacklist is very time-consuming). Hence, I propose that EditPage[1] should run a hook after having PSTed the text, passing the result in. This would deny the need to run PST in extensions when needed. Also, such a hook should be executed only if the page is going to be saved (i.e., not if the PSTed content is the same as before), so that extensions don't have to check for that. The EditFilterMergedContent hook should remain in place, for consumers that do not need the PSTed text. [1] - Or a related class, as long as it's guaranteed that the hook will only ever be called on page edits.
    • Task
    • ·Closed
    RevisionStore should offer a way to retrieve the raw (serialized) content of a batch of revisions. This is similar to BlobStore::getBlobBatch(), but would take as an input revision IDs and slot names, not blob addresses. The result must include the content model associated with each blob, to enable the caller to properly unserialize and interpret the content. Rationale: Work on {T228675} showed that a high level interface for loading a batch of RevisionRecords as defined by T228988 does not meet performance requirements, degrading performance by a factor of 2.5. AS the cause we identified overhead caused by the instantiation of a great number of instances of RevisionRecord, RevisionSlots, SlotRecord, and Content - all of which were immediately discarded after extracting the raw text of the page. A batch interface that bypasses the construction of all these objects seems like the obvious solution.
    • Task
    • ·Closed
    The extension should not rely on pre-MCR fields in the revision table, and should not assume that the text table is used. Specifically: * remove all references to rev_text_id or ar_text_id. * remove usages of Revision::getRevisionText() * remove reliance on the 'text' flag to Revision::getQueryInfo() See the parent task(s) for more details. Care should be taken to maintain backwards compatibility with older versions of MediaWiki, as declared in extension.json. NOTE: RevisionStoreFactory should be used here to get a RevisionStore instance suitable for cross-wiki revision loading!
    • Task
    • ·Closed
    The extension should not rely on pre-MCR fields in the revision table, and should not assume that the text table is used. Specifically: * remove all references to rev_text_id or ar_text_id. * remove usages of Revision::getRevisionText() * remove reliance on the 'text' flag to Revision::getQueryInfo() See the parent task(s) for more details. Care should be taken to maintain backwards compatibility with older versions of MediaWiki, as declared in extension.json.
    • Task
    • ·Closed
    The extension should not rely on pre-MCR fields in the revision table, and should not assume that the text table is used. Specifically: * remove all references to rev_text_id or ar_text_id. * remove usages of Revision::getRevisionText() * remove reliance on the 'text' flag to Revision::getQueryInfo() See the parent task(s) for more details. Care should be taken to maintain backwards compatibility with older versions of MediaWiki, as declared in extension.json.
    • Task
    • ·Closed
    The extension should not rely on pre-MCR fields in the revision table, and should not assume that the text table is used. Specifically: * remove all references to rev_text_id or ar_text_id. * remove usages of Revision::getRevisionText() * remove reliance on the 'text' flag to Revision::getQueryInfo() See the parent task(s) for more details. Care should be taken to maintain backwards compatibility with older versions of MediaWiki, as declared in extension.json.
    • Task
    • ·Closed
    The extension should not rely on pre-MCR fields in the revision table, and should not assume that the text table is used. Specifically: * remove all references to rev_text_id or ar_text_id. * remove usages of Revision::getRevisionText() * remove reliance on the 'text' flag to Revision::getQueryInfo() See the parent task(s) for more details. Care should be taken to maintain backwards compatibility with older versions of MediaWiki, as declared in extension.json.
    • Task
    • ·Closed
    The extension should not rely on pre-MCR fields in the revision table, and should not assume that the text table is used. Specifically: * remove all references to rev_text_id or ar_text_id. * remove usages of Revision::getRevisionText() * remove reliance on the 'text' flag to Revision::getQueryInfo() See the parent task(s) for more details. Care should be taken to maintain backwards compatibility with older versions of MediaWiki, as declared in extension.json.
    • Task
    We've introduced `BlobStore::getBlobBatch` to fetch a bulk of blobs given the array of blob addresses. Blob metadata is already fetched from the database in a batch query, however the actual content is expanded from external store one-by one. We need to use existing `ExternalStoreAccess::fetchFromURLs` instead and fetch actual blob contents in a batch as well.
    • Task
    WikiExporter creates revision object in batches, so it's a perfect use-case for the new RevisionStore::newRevisionsFromBatch method.
    • Task
    • ·Closed
    We have introduced [[ https://gerrit.wikimedia.org/r/c/mediawiki/core/+/531308 | RevisionStore::newRevisionsFromBatch ]] that is capable of creating a batch of RevisionRecord instances given the batch of database rows. Additionally, in T230834 we've introduced BlobStore::getBlobBatch to fetch a batch of blobs given the addresses. This task is about connecting the two. RevisionStore::newRevisionsFromBatch has a `content` option, that indicates that the content of certain slot of all the revisions within the batch should be preloaded. Ideally if this flag is set, we don't want to use the BlobStore::getBlobsBatch for all the slots and then provide them into `RevisionStore::newRevisionFromRowAndSlots`. Perhaps expanding the public interface of this method wouldn't be too helpful, so an internal version of the method should be created.
    • Task
    • ·Closed
    BlobStore does not provide a way to access data in bulk. Code that has been using the 'text' for getQueryInfo() for bulk access to data blobs can no longer be used, because we no longer have rev_text_id to go by in the new (MCR) schema. As a replacement, we need a way to retrieve a set of data blobs in a way that optimizes the query. NOTE: at the moment, ExternalStore doesn't offer a bulk interface. That could be added as well, but that would be outside the scope of this ticket. This ticket is about avoiding queries against individual rows of the text table. A later iteration could further optimize to also batch queries to the external store databases. **Draft:** Introduce `BlobStore::getBlobBatch( $blobAddresses, $queryFlags = 0 ): string[]` as the batch analog to `BlobStore::getBlob`. Note that the return value should be associative, indexed by blob address. Implementation ideas: * `BlobStore::getBlobBatch` will have to first see which blobs are already cached, and then only fetch (and then cache) the uncached ones. * `BlobStore::fetchBlob` should probably be rewritten to support fetching multiple blobs at once. * `BlobStore::expandBlob` will have to be called for each blob individually for now. * In the future, when we have multiple different BlobStore implementation, the top level "dispatching" BlobStore would have to divide the batch by address schema, and forward each sub-batch to the appropriate BlobStore for that schema. For now though, we can just fail if any of the addresses has a schema different from "tt".
    • Task
    The live preview does not work on multi-content revision edit, like when [[https://commons.wikimedia.org/w/index.php?title=File:Powered_by_MediaWiki.svg&action=mcrundo&undo=360235235&undoafter=360169487|reverting Commons Wikibase edits]]. Acceptance criteria: [ ] Live preview uses appropriate API calls and appropriate ways to get revision contents for MCR edit previews/diffs. [ ] Live preview is actually loaded on MCR edit pages.
    • Task
    • ·Closed
    RevisionStore does not provide a way to access page content (or slot meta-data) in bulk. Code that has been using the 'text' for getQueryInfo() for bulk access to page content can no longer be used, because now there can be multiple slots for each revision. As a replacement, we need a way to construct a list if RevisionRecord objects in a way that optimizes the query for the associated information from the slots and content tables. **Design draft:** (rewritten 2019-08-20 after discussion with Anomie on this ticket) Introduce a new method in RevisionStore: `RevisionStore::newRevisionsFromBatch( $rows, array $options = [] ): RevisionRecord[]`. Contract: Construct a RevisionRecord instance for each row in $rows, and return them as an associative array indexed by revision ID. Signature: * `$rows` is a Traversable of anonymous objects representing rows from a query result. Each row is expected to conform to the requirements of `RevisionStore::newRevisionFromRow()`. In practice, `$rows` is typically an IResultWrapper containing the result of a query that was based on `RevisionStore::getQueryInfo`. * `$options` is an associative array supporting the following options: ** `'slots'`: whether meta-data about slots (and slot content) should be loaded immediately, instead of relying on the lazy loading mechanism in RevisionStoreRecord. This allows all the meta-data for all slots to be loaded in a single query. The value is either //truthy// to indicate that all slot should be preloaded, or //falsy// to indicate that no slot meta data should be preloaded, or a list (array) or slot role names, to indicate for which slots the meta data should be preloaded. The default is //false//. ** `'content'`: whether the actual content blobs should be preloaded, instead of relying on lazy loading as usual. The value is //truthy// or //falsy//, default is //false//. Only applies to slots which have been selected for preloading via the `'slots'` option. This option has no effect until `BlobStore` also gets a batch interface (see {T230834}). * returns an associative array of Revision(Store)Records, indexed by revision ID. Implementation idea: * At first, just loop over `$rows` and call `RevisionStore::newRevisionFromRow` on each row. This would be the baseline version of the method. This already satisfies the contract, but passes on the opportunity to optimize by preloading. * In the next iteration, if preloading of slot meta-data is requested: ** first pull out the revision ID from each row in `"$rows"`. Remember the row in an associative array indexed by revision ID ** Run a query that selects all the requested slot (and slot content) meta-data; let's call the result of that query `$slots`. ** Loop through the result set, grouping together slot meta-data belonging to the same revision. Use `RevisionStore::newRevisionFromRowAndSlots` to construct a RevisionStoreRecord from that plus the respective row from $rows. * In a following iteration, use a batch query to also preload the Content objects for each slot, by content ID. Details TBD, see T230834. * Old stale patch implementing something similar for use in `WikiExporter` https://gerrit.wikimedia.org/r/c/mediawiki/core/+/513073 * WikiExporter should be changed to use the new system as well. Doing that should validate the approach and the interface.
    • Task
    • ·Closed
    The Translate extension relies on direct access to the text table, though joining against rev_text_id, in several places. This will no longer be possible with the new MCR schema, and should be replaced as described in T198341, T198342, and T198343. The Translate extension is a somewhat special case as the transition to the new schema may cause problems with respect to backwards compatibility with older versions of MediaWiki, as well as performance issues, since bulk queries of page content are no longer possible.
    • Task
    • ·Closed
    The Duplicator extension is unaware of the MCR slots table, and duplicated pages will therefore lose the content on wikis set to read the new schema. Additionally, uses of the deprecated Revision class should be refactored. These issues were noticed in T198341.
    • Task
    Content can become orphaned, with no slot pointing to it. For example, the DeletePagesForGood extension can cause this. Create a maintenance script to detect and delete orphaned content. The idea is that if no slot references a given row in the content table, that row and the associated blob in the blob store can be deleted. This is based on the assumption that, while the same content row may be referenced by different revisions (possibly even of different pages), the same blob is never referenced by multiple content rows. There is however no mechanism in place to enforce this assumption. This task was created due to a need noticed while implementing T198341, patch https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/DeletePagesForGood/+/506573/
    • Task
    Currently, BlobStore has no notion of deletion. This prevents code that needs to delete content (for example, the DeletePagesForGood extension) from doing so. Introduce a derived interface like BlobStoreWithDeletion, which has a deleteBlob method that takes a content address. We also need a "top" BlobStore that delegates to other blob stores based on the address prefix. Since not all "inner" blob stores may support deletion, the deleteBlob() method will be advisory. This task was created due to a need noticed while implementing T198341, patch https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/DeletePagesForGood/+/506573/
    • Task
    • ·Closed
    When I first tried to execute [[ https://en.wikipedia.org/w/index.php?title=Special:Log&logid=100452451 | this move ]], I got the following exception: `[XSOTbgpAICMAAGv6TPwAAABV] 2019-07-08 19:03:11: Fatal exception of type "MWException"`
    • Task
    MCR undo actions’ summary fields like [[https://commons.wikimedia.org/w/index.php?title=File:Backlit_keyboard.jpg&action=mcrundo&undo=353482421&undoafter=353455338|this one’s]] don’t have access key. They should have the usual access key {key B} (`accesskey-summary` MediaWiki message).
    • Task
    • ·Closed
    ``` [00:58:04] <compass> hello, I just updated our mediawiki from 1.31 to 1.32 and got 500 error with this message "Failed to access name from slot_roles using id = 1". Did some search online and found a few pastebin/gist with the same message. I think someone hit is error as well and I'm wondering if it is asked and and if it is solved? Thanks. [00:59:04] <compass> Here is the pastebin I found and I have exact the same stacktrace: https://pastebin.com/iX8Uhjnx ``` @freephile has also experienced this, but apparently `maintenance/populateContentTables.php` fixed the problem With a few reports coming in, it sounds like running it in the database updater might be slightly flaky **Affected: MW 1.32+**
    • Task
    • ·Closed
    The [[https://www.mediawiki.org/wiki/Manual:Hooks/PageContentSave|PageContentSave]] hook takes a number of parameters which are references (the content to save, the author, the flags etc), so there is a natural expectation that these can be changed by the hook handler. In reality though, summary, flags and status can be replaced, but new values assigned to the user or the content are discarded. (Replacing the WikiPage, as far as I can tell, never did anything, and I can't imagine a sane use case for doing so.) This was broken in MediaWiki 1.32 during the #multi-content-revisions rewrite by e8632ab0f6264851d2115a2e6338c2074b9a9b8c. I can't remember if this was intentional or not, and even if it was accidental we might want to leave it that way (seems like it could violate a lot of assumptions, e.g. caching based on the user), but at a minimum it should be documented and a replacement suggested.
    • Task
    • ·Closed
    For a UserIdentity constructed from a revision row loaded from the database of another wiki, the user ID (and actor ID) must be ignored and forced to be 0. To find the relevant code, search for calls to $user = User::newFromAnyId() in RevisionStore. These calls must have the user ID and actor ID suppressed if $this->wikiId is not false. This is a stop-gap solution for the problem described in {T222212}. A more thorough solution will need {T222380}.
    • Task
    • ·Closed
    RevisionStore currently constructs User objects via User::newFromAnyId(), assuming rev_user (resp ar_user) refers to a user ID on the local wiki. This is however not the case if the RevisionStore was constructed with $wikiId != false. See also: {T222380}
    • Task
    • ·Closed
    #### Error * Request ID: `XO8cRQpAIDEAAL3eYJkAAACI` ```lines=10 InvalidArgumentException: The given Title does not belong to page ID 8946238 but actually belongs to 8171110 #0 /srv/mediawiki/php-1.34.0-wmf.6/includes/Revision/RevisionStore.php(1826): MediaWiki\Revision\RevisionStoreRecord->__construct(Title, User, CommentStoreComment, stdClass, MediaWiki\Revision\RevisionSlots, boolean) #1 /srv/mediawiki/php-1.34.0-wmf.6/includes/Revision/RevisionStore.php(2167): MediaWiki\Revision\RevisionStore->newRevisionFromRow(stdClass, integer, Title) #2 /srv/mediawiki/php-1.34.0-wmf.6/includes/Revision/RevisionStore.php(1535): MediaWiki\Revision\RevisionStore->loadRevisionFromConds(Wikimedia\Rdbms\DBConnRef, array, integer, Title) #3 /srv/mediawiki/php-1.34.0-wmf.6/includes/Revision.php(138): MediaWiki\Revision\RevisionStore->getRevisionByTitle(Title, integer, integer) #4 /srv/mediawiki/php-1.34.0-wmf.6/extensions/PageImages/includes/LinksUpdateHookHandler.php(50): Revision::newFromTitle(Title) #5 /srv/mediawiki/php-1.34.0-wmf.6/extensions/PageImages/includes/LinksUpdateHookHandler.php(74): PageImages\Hooks\LinksUpdateHookHandler->getPageImageCandidates(LinksDeletionUpdate) #6 /srv/mediawiki/php-1.34.0-wmf.6/extensions/PageImages/includes/LinksUpdateHookHandler.php(33): PageImages\Hooks\LinksUpdateHookHandler->doLinksUpdate(LinksDeletionUpdate) #7 /srv/mediawiki/php-1.34.0-wmf.6/includes/Hooks.php(174): PageImages\Hooks\LinksUpdateHookHandler::onLinksUpdate(LinksDeletionUpdate) #8 /srv/mediawiki/php-1.34.0-wmf.6/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL) #9 /srv/mediawiki/php-1.34.0-wmf.6/includes/deferred/LinksUpdate.php(188): Hooks::run(string, array) #10 /srv/mediawiki/php-1.34.0-wmf.6/includes/deferred/DeferredUpdates.php(274): LinksUpdate->doUpdate() #11 /srv/mediawiki/php-1.34.0-wmf.6/includes/deferred/DeferredUpdates.php(219): DeferredUpdates::runUpdate(LinksDeletionUpdate, Wikimedia\Rdbms\LBFactoryMulti, string, integer) #12 /srv/mediawiki/php-1.34.0-wmf.6/includes/deferred/DeferredUpdates.php(143): DeferredUpdates::execute(array, string, integer) #13 /srv/mediawiki/php-1.34.0-wmf.6/includes/MediaWiki.php(907): DeferredUpdates::doUpdates(string) #14 /srv/mediawiki/php-1.34.0-wmf.6/includes/MediaWiki.php(731): MediaWiki->restInPeace(string, boolean) #15 [internal function]: Closure$MediaWiki::doPostOutputShutdown() ``` ``` [XMAmggpAICsAAEwlrXgAAABD] /w/index.php?title=Speciaal:PaginaHernoemen&action=submit InvalidArgumentException from line 100 of /srv/mediawiki/php-1.34.0-wmf.1/includes/Revision/RevisionStoreRecord.php: The given Title does not belong to page ID 1284480 but actually belongs to 1280398 [XL-6RgpAAD4AAI97q5EAAADR] /w/index.php?title=Special:MovePage&action=submit InvalidArgumentException from line 100 of /srv/mediawiki/php-1.34.0-wmf.1/includes/Revision/RevisionStoreRecord.php: The given Title does not belong to page ID 41989195 but actually belongs to 39994396 ``` ### Impact The LinksUpdate logic is failing to complete during a rename or page move sometimes. It is yet to be determined whether it affects a subset of pages or a subset of attempts (e.g. does it usually work after a retry). The impact is that data in link tables (category members, file usage, WhatLinksHere etc.) and other page updates (e.g. search index etc.) might be corrupt or out of date for pages that were moved. ### Notes After a rough search, it looks like we have about ~3,850 of errors like these in the past 10 days. Similar tasks: * T200269
    • Task
    • ·Closed
    Once we have {T174031}, we need to also be able to read/import slots other than the main slot from dumps. This means implementing support for XML schema version 0.11 in WikiImporter. To enable this, we'll probably want to turn WikiRevision into a wrapper for MutableRevisionRecord.
    • Task
    Postgres currently uses columns in specific tables (pagecontent.textvector and page.titlevector, both of type tsvector) to store search index information. Postgres also currently uses triggers/procedures to maintain these tables. It needs to be converted to use a searchindex table like MySQL. This relates to MCR Schema Migration, because it prepares for when we want SearchMySQL and so on to handle more than just the main slot. By using a searchindex table, the changes to SearchPostgres will be similar rather than entirely different. Details: - add a searchindex table, similar to the MySQL one, but adapted to Postgres data types. Basically page.titlevector becomes searchindex.si_title and pagecontent.textvector becomes searchindex.si_text. searchindex.si_page works exactly like it does in MySQL. - add related code to maintain this table. Per T164898, we don't want to keep using triggers for this. SearchPostgres::update() should do it, similar to what SearchMySQL::update() does. Same for ::updateTitle(). - add necessary documentation and install/update support for these db changes - modify searchPostgres.php to use the new db changes See T198341 for the discussion that led to this task.
    • Task
    • ·Closed
    In simplewiki, the Mediawiki:Mycontris is set to [[https://simple.wikipedia.org/wiki/MediaWiki:Mycontris|"My changes"]] and has been changed more than nine years ago but at the top of the page, it shows "My edits": {F28437368} It's not falling back to English but it's using a really old value instead so I'm confused what's going on here.
    • Task
    Recently installed MW 1.32 in parallel with 1.29. (Site has less than 50 pages and around 300 revisions total.) Ran the update script. 1.29 instance still works fine, but on 1.32 around 20% of pages crash with an error related to missing revision ids in the database. **Steps to Reproduce: ** - Install MW 1.29. - Make a half dozen edits to several pages. - Backup the database. - Install MW 1.32 in parallel. - Run `update.php`. - Navigate to edited pages. Several of them should fail to load, with an error related to their revision ids not being found in the database. **Actual Results:** Approximately 20% of pages give the following error (with `$wgShowExceptionDetails` enabled): `Original exception: [long hash] /wiki/index.php/Main_Page MediaWiki\Revision\RevisionAccessException from line 1635 of /var/www/html/wiki/includes/Revision/RevisionStore.php: Main slot of revision 296 not found in database!` **Expected Results:** Pages should load properly. **Temporary Fix:** Add to `LocalSettings.php` either: - `$wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_OLD;`, or - `$wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_OLD;` Both will work. Happy to provide database sql file for reproduction.
    • Task
    Reported at https://www.mediawiki.org/wiki/Topic:Uvk534c3g65obfzp. From @daniel : Looking at <https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Duplicator/+/master/Duplicator.page.php> it seems like Duplicator is incompatible with the MCR database schema (and will break for Actor migration and Comment migration as well). To be MCR compatible, it will (depending on the $wgMultiContentRevisionSchemaMigrationStage) also copy the relevant rows in the slots table (entries in the content table can be shared between page copies), and possibly ignore the rev_text_id field. Similarly, depending on the value of $wgCommentTableSchemaMigrationStage and $wgActorTableSchemaMigrationStage, it needs to handle rev_user_text and rev_comment differently. To remove the need for the extension to bind to the concrete database schema (not to migration stage config), it should probably create a new MutableRevisionRecord for each RevisionStoreRecord of the existing page, and use a PageUpdater to save them to the new page. This would completely hide any DB schema details, but it would also be slower. Some tweaks in core may be needed to enable sharing of content between pages, core currently only supports this between revisions on the same page at the moment.
    • Task
    • ·Closed
    As identified in T200653, the revision.rev_sha1 field must be populated before the populateContentTables.php script can successfully run. For MediaWiki 1.19 and later, revision.rev_sha1 should already exist and have data. For earlier versions of MediaWiki, or for wikis that somehow have data issues, the populateRevisionSha1.php script must run to populate revision.rev_sha1, with the $wgMultiContentRevisionSchemaMigrationStage global variable having the SCHEMA_COMPAT_READ_OLD bit set. Having this bit set ensures that the code can find the content to calculate the sha1. The populateContentTables.php script, on encountering a revision.rev_sha1 with value of empty string, should die and instruct the user to: # ensure $wgMultiContentRevisionSchemaMigrationStage is set appropriately # run populateRevisionSha1.php # restore $wgMultiContentRevisionSchemaMigrationStage (if necessary) # run populateContentTables.php again
    • Task
    • ·Closed
    As identified in T200653, missing/empty rev_sha1 and content_sha1 values can cause various problems. Ensure that, between populateRevisionSha1.php script and populateContentTables.php, these values are populated. Or else if for some reason they cannot be populated, inform the user and provide helpful instructions. populateRevisionSha1.php may be run in two situations: * initialize the rev_sha1 field for wikis being upgraded from a schema without that field, which was added in MediaWiki 1.19 * fix missing rev_sha1 data on wikis that have already been upgraded populateContentTables.php may be run in two situations: * initialize MCR content-related data for wikis being upgraded to an MCR schema * fix missing content-related data for wikis that have already been upgraded There are some interdependencies to be aware of: * populateContentTables.php requires rev_sha1 to have been initialized * populateRevisionSha1.php requires access to the content, which for certain MCR stages requires the content and slot tables to have been initialized populateRevisionSha1.php currently uses deprecated functions. These should be refactored.
    • Task
    ```[08a09c9f4968bff42dd6c232] [no req] MWContentSerializationException from line 299 of /srv/mediawiki/php-1.33.0-wmf.18/extensions/Wikibase/lib/includes/Store/EntityContentDataCodec.php: $entityId and $targetId can not be the same. ``` Reproduction case: https://www.wikidata.org/w/api.php?action=query&format=json&prop=revisions&formatversion=2&titles=Lexeme%3AL123&rvprop=content%7Cuser%7Cids&rvlimit=max&continue=%7C%7C&rvcontinue=20190401115845%7C899647120 https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-deploy-2021.06.28?id=UM85U3oB3UDnvh-QHmqq Req ID: `AWk0u32gjSm8tOlx-BX_` Stacktrace for that web request: ```lines=5 from /srv/mediawiki/php-1.37.0-wmf.11/extensions/Wikibase/lib/includes/Store/EntityContentDataCodec.php(300) #0 /srv/mediawiki/php-1.37.0-wmf.11/extensions/Wikibase/repo/includes/Content/EntityHandler.php(371): Wikibase\Lib\Store\EntityContentDataCodec->decodeRedirect(string, NULL) #1 /srv/mediawiki/php-1.37.0-wmf.11/includes/Revision/RevisionStore.php(1208): Wikibase\Repo\Content\EntityHandler->unserializeContent(string, NULL) #2 /srv/mediawiki/php-1.37.0-wmf.11/includes/Revision/RevisionStore.php(1449): MediaWiki\Revision\RevisionStore->loadSlotContent(MediaWiki\Revision\SlotRecord, NULL, NULL, NULL, integer) #3 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}(MediaWiki\Revision\SlotRecord) #4 /srv/mediawiki/php-1.37.0-wmf.11/includes/Revision/SlotRecord.php(324): call_user_func(Closure, MediaWiki\Revision\SlotRecord) #5 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiQueryRevisionsBase.php(481): MediaWiki\Revision\SlotRecord->getContent() #6 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiQueryRevisionsBase.php(390): ApiQueryRevisionsBase->extractSlotInfo(MediaWiki\Revision\SlotRecord, integer, NULL) #7 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiQueryRevisionsBase.php(314): ApiQueryRevisionsBase->extractAllSlotInfo(MediaWiki\Revision\RevisionStoreRecord, integer) #8 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiQueryRevisions.php(438): ApiQueryRevisionsBase->extractRevisionInfo(MediaWiki\Revision\RevisionStoreRecord, stdClass) #9 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiQueryRevisionsBase.php(62): ApiQueryRevisions->run() #10 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiQuery.php(333): ApiQueryRevisionsBase->execute() #11 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiMain.php(1721): ApiQuery->execute() #12 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiMain.php(702): ApiMain->executeAction() #13 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiMain.php(673): ApiMain->executeActionWithErrorHandling() #14 /srv/mediawiki/php-1.37.0-wmf.11/api.php(90): ApiMain->execute() #15 /srv/mediawiki/php-1.37.0-wmf.11/api.php(45): wfApiMain() #16 /srv/mediawiki/w/api.php(3): require(string) #17 {main} ``` Note there is also a field `exception.previous.trace`: ```lines=5 from /srv/mediawiki/php-1.37.0-wmf.11/vendor/wikibase/data-model/src/Entity/EntityRedirect.php(41) #0 /srv/mediawiki/php-1.37.0-wmf.11/extensions/Wikibase/lib/includes/Store/EntityContentDataCodec.php(297): Wikibase\DataModel\Entity\EntityRedirect->__construct(Wikibase\Lexeme\Domain\Model\LexemeId, Wikibase\Lexeme\Domain\Model\LexemeId) #1 /srv/mediawiki/php-1.37.0-wmf.11/extensions/Wikibase/repo/includes/Content/EntityHandler.php(371): Wikibase\Lib\Store\EntityContentDataCodec->decodeRedirect(string, NULL) #2 /srv/mediawiki/php-1.37.0-wmf.11/includes/Revision/RevisionStore.php(1208): Wikibase\Repo\Content\EntityHandler->unserializeContent(string, NULL) #3 /srv/mediawiki/php-1.37.0-wmf.11/includes/Revision/RevisionStore.php(1449): MediaWiki\Revision\RevisionStore->loadSlotContent(MediaWiki\Revision\SlotRecord, NULL, NULL, NULL, integer) #4 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}(MediaWiki\Revision\SlotRecord) #5 /srv/mediawiki/php-1.37.0-wmf.11/includes/Revision/SlotRecord.php(324): call_user_func(Closure, MediaWiki\Revision\SlotRecord) #6 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiQueryRevisionsBase.php(481): MediaWiki\Revision\SlotRecord->getContent() #7 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiQueryRevisionsBase.php(390): ApiQueryRevisionsBase->extractSlotInfo(MediaWiki\Revision\SlotRecord, integer, NULL) #8 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiQueryRevisionsBase.php(314): ApiQueryRevisionsBase->extractAllSlotInfo(MediaWiki\Revision\RevisionStoreRecord, integer) #9 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiQueryRevisions.php(438): ApiQueryRevisionsBase->extractRevisionInfo(MediaWiki\Revision\RevisionStoreRecord, stdClass) #10 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiQueryRevisionsBase.php(62): ApiQueryRevisions->run() #11 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiQuery.php(333): ApiQueryRevisionsBase->execute() #12 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiMain.php(1721): ApiQuery->execute() #13 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiMain.php(702): ApiMain->executeAction() #14 /srv/mediawiki/php-1.37.0-wmf.11/includes/api/ApiMain.php(673): ApiMain->executeActionWithErrorHandling() #15 /srv/mediawiki/php-1.37.0-wmf.11/api.php(90): ApiMain->execute() #16 /srv/mediawiki/php-1.37.0-wmf.11/api.php(45): wfApiMain() #17 /srv/mediawiki/w/api.php(3): require(string) #18 {main} ``` ------- And an older stacktrace from a job runner ```name=trace from jobrunner,lines=10 #0 /srv/mediawiki/php-1.33.0-wmf.21/extensions/Wikibase/repo/includes/Content/EntityHandler.php(383): Wikibase\Lib\Store\EntityContentDataCodec->decodeRedirect(string, NULL) #1 /srv/mediawiki/php-1.33.0-wmf.21/includes/Revision/RevisionStore.php(1472): Wikibase\Repo\Content\EntityHandler->unserializeContent(string, NULL) #2 /srv/mediawiki/php-1.33.0-wmf.21/includes/Revision/RevisionStore.php(1634): MediaWiki\Revision\RevisionStore->loadSlotContent(MediaWiki\Revision\SlotRecord, NULL, NULL, NULL, integer) #3 [internal function]: Closure$MediaWiki\Revision\RevisionStore::loadSlotRecords(MediaWiki\Revision\SlotRecord) #4 /srv/mediawiki/php-1.33.0-wmf.21/includes/Revision/SlotRecord.php(307): call_user_func(Closure$MediaWiki\Revision\RevisionStore::loadSlotRecords;828, MediaWiki\Revision\SlotRecord) #5 /srv/mediawiki/php-1.33.0-wmf.21/includes/Revision/RevisionRecord.php(175): MediaWiki\Revision\SlotRecord->getContent() #6 /srv/mediawiki/php-1.33.0-wmf.21/includes/Revision.php(923): MediaWiki\Revision\RevisionRecord->getContent(string, integer, NULL) #7 /srv/mediawiki/php-1.33.0-wmf.21/includes/page/WikiPage.php(809): Revision->getContent(integer, NULL) #8 /srv/mediawiki/php-1.33.0-wmf.21/extensions/CirrusSearch/includes/Sanity/Checker.php(192): WikiPage->getContent() #9 /srv/mediawiki/php-1.33.0-wmf.21/extensions/CirrusSearch/includes/Sanity/Checker.php(167): CirrusSearch\Sanity\Checker->checkIfRedirect(WikiPage) #10 /srv/mediawiki/php-1.33.0-wmf.21/extensions/CirrusSearch/includes/Sanity/Checker.php(133): CirrusSearch\Sanity\Checker->checkExisitingPage(string, integer, WikiPage, array) #11 /srv/mediawiki/php-1.33.0-wmf.21/extensions/CirrusSearch/includes/Job/CheckerJob.php(214): CirrusSearch\Sanity\Checker->check(array) #12 /srv/mediawiki/php-1.33.0-wmf.21/extensions/CirrusSearch/includes/Job/Job.php(100): CirrusSearch\Job\CheckerJob->doJob() #13 /srv/mediawiki/php-1.33.0-wmf.21/extensions/EventBus/includes/JobExecutor.php(65): CirrusSearch\Job\Job->run() #14 /srv/mediawiki/rpc/RunSingleJob.php(77): JobExecutor->execute(array) #15 {main} ``` ### Impact * Some pages cannot be viewed * Some API requests fail * Some jobs are are aborted mid-way, including `CirrusSearch\Job\CheckerJob`.
    • Task
    • ·Closed
    By the next release (1.34), MediaWiki should no longer support writing to //only// the MCR-unaware legacy revision storage schema. RevisionStore already has several checks for $mcrMigrationStage in the constructor. This means that it should now fail if SCHEMA_COMPAT_WRITE_NEW is not set. See also {T231673}.
    • Task
    See Example: https://commons.wikimedia.org/w/index.php?title=File:Image_is_needed_male.svg&diff=335612920&oldid=272656470&uselang=qqx The text "mediainfo" should be localized
    • Task
    After upgrading to mediawiki 1.32.0, running updateSearchIndex.php results in: ``` Updating searchindex between 20190116040016 and 20190117171125 --- Waiting for lock --- <MyPageName>...[664e1ee17e4f2336e1e73f58] [no req] Wikimedia\Rdbms\DBQueryError from line 1496 of /opt/mediawiki/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT slot_revision_id,slot_content_id,slot_origin,slot_role_id,content_size,content_sha1,content_address,content_model FROM `slots` INNER JOIN `content` ON ((slot_content_id = content_id)) WHERE slot_revision_id = '46171' Function: MediaWiki\Revision\RevisionStore::loadSlotRecords Error: 1100 Table 'slots' was not locked with LOCK TABLES (MyDBServerHostname) ``` Fix is to add 'slots' and 'content' to Maintenance.php lockSearchindex()
    • Task
    ___ Dear Daniel, how can I send the backups of my databases to you (3 DBs, Wiki-Family). The update-Skript did not mention any special number of slot, only "main slot revision not found in database", happens when upgrading from 1.31 to 1.35, but not when upgrading via 1.32 to 1.33. > **`IF YOU GET THIS ERROR WHILE UPDATING A WIKI AND YOU HAVE A DATABASE BACKUP FROM BEFORE THE UPGRADE, PLEASE SEND THE BACKUP TO `**@daniel. ___ Noticed in [[ https://logstash.wikimedia.org/app/kibana#/dashboard/mediawiki-errors | mediawiki-errors ]] for both wmf.8 an wmf.9 ``` [XBuw4QpAICMAALTXkHkAAABG] /w/index.php?title=Speci%C3%A1lis:Lap_%C3%A1tnevez%C3%A9se&action=submit MediaWiki\Revision\RevisionAccessException from line 1643 of /srv/mediawiki/php-1.33.0-wmf.8/includes/Revision/RevisionStore.php: Main slot of revision 20798212 not found in database! ``` ``` [XBuxngpAIDgAAJFITF8AAADO] /w/api.php?rvprop=userid%7Cuser%7Cids%7Ccontent%7Csize%7Ctimestamp%7Ccontentmodel%7Ccomment&revids=815943409&prop=revisions&format=json&rvslots=main&action=query MediaWiki\Revision\RevisionAccessException from line 1643 of /srv/mediawiki/php-1.33.0-wmf.9/includes/Revision/RevisionStore.php: Main slot of revision 815943409 not found in database! ``` ### Impact Through the API, querying information about some pages results in an `internal_api_error` response.
    • Task
    • ·Closed
    https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-hhvm-docker/27382/console ``` There was 1 failure: 1) JADE\Tests\Hooks\MoveHooksTest::testOnMovePageIsValidMove with data set #2 ('judgment-existing', 'main-new', array('content-not-allowed-here', 'JadeJudgment', 'main-new')) Failed asserting that exception message '"JadeJudgment" content is not allowed on page [[:New page1653947107]] in slot "main"' contains '"JadeJudgment" content is not allowed on page [[:New page1653947107]] in slot "$3"'. /workspace/src/tests/phpunit/MediaWikiTestCase.php:424 /workspace/src/maintenance/doMaintenance.php:94 ```
    • Task
    • ·Closed
    Purge's forcelinkupdate option appears in several contexts to have become non-functional (as installed on ENWIKI), *probably* more than one and less than three weeks ago. The earliest entries in https://en.wikipedia.org/wiki/Category:AfC_pending_submissions_by_age/0_days_ago will usually demonstrate the problem. Note that by reading the page, the articles appear categorized as much older than "0 days ago." A null edit will (as expected) correct this, a purge by itself (as expected) will not correct this. Until recently, purge with the forcelinkupdate option did (as expected) correct this, now it does not. I believe I have observed similar changes in the behavior of my PERL-based bot, the Pywikibot touch.py bot, and the direct URL API. Background: Multiple tools make use of the forcelinkupdate option on ENWIKI to update pages, including but not limited to Pywikibot and Joe's Null Bot. Generally these tools are used to deal with the fact that category inclusion for an article is not constantly reevaluated, so, a template, say, conditionally includes a category if the time has passed a certain timestamp will not be included in the appropriate category until or unless a full null edit or a purge/forcelinkupdate is performed. The latter is strongly preferred for many use cases to avoid polluting the article history. See also: https://en.wikipedia.org/wiki/User_talk:Joe_Decker#CAT:AFC
    • Task
    For some kinds of pages, a great many kinds of slots may be allowed, and only one or two may be required, but a handful should be offered to the use when editing or creating a page. Example: Not all template pages need to have template documentation, but it would nice if the UI would offer an easy way to create that. A generic mechanism by which a SlotRoleHandler that a certain slot should be offered when editing a given page. Proposal: Define SlotRoleHandler::getDesiredRoles( LinkTarget ), which returns the slot roles that should be offered when editing. Note that this does not always mean that they can be edited atomically with the rest of the content, or that they can be edited using the standard EditPage at all. It just means that editing them should be offered to the user //somehow//.
    • Task
    The "page type" mechanism is intended to provide a compact way for extensions to control the behavior (display, editing, move, delete, etc) of certain wiki pages. The concept of page types is already present in MediaWiki, but not explicitly modeled or specified. Rather, the behavior is hard coded into special cases. Examples of existing "page types" in MediaWiki core: * article (the default) * talk page (talk namespaces) * category page (the Category namespace) * file description page (the File namespace) * script page (Js or CSS, user or global, active content to be interpreted by the browser) (.js and .css suffix in the MediaWiki and the User namespace) * system message (MediaWiki namespace) * conversion table (MediaWiki namespace with Conversiontable/ prefix) * ... All of these trigger special behavior during display, editing, purging, moving, etc. PageTypeHandler would model this concept, allowing extensions to easily define their own page types. It should control at least: * layout for the view action. The PageTypeHandler may be aware of certain content slots, and may show their content as appropriate. It may or may not show additional slots using a generic layout mechanism. * editing mechanism. The PageTypeHandler may be aware of certain slots, and may provide an integrated editing experience for their content. It should provide a some way to access editing interfaces for any additional slots. * which slots are allowed, required, and desired on pages of this type. * Generic action overrides (to replace ContentHandler::getActionOverrides) * behavior to be triggered upon creation, modification, and deletion, as currently encoded in WikiPage::doEditUpdates and WikiPage::doDeletionUpdates * Constraints on page moves. Since page moves change the title, the may change the page type. In such a case, the old and the new page type handler have to both agree that the move is possible. This replaces ContentHandler::canBeUsedOn. Ideally, a page's "type" is determined solely by it's title, regardless of database state. It would typically be based by the namespace, but in some cases, a title suffix or prefix may also trigger a certain page type. However, several extensions exist that cause special behavior to be triggered based on the content model (of the main slot). it may be necessary to retain this behavior, at least for a transition period. Whether it may be unavoidable in principle or even desirable remains under discussion as of this writing.
    • Task
    • ·Closed
    Fatal error: Cannot use MediaWiki\Revision\SlotRecord as SlotRecord because the name is already in use in includes\Storage\PageUpdater.php on line 42
    • Task
    • ·Closed
    Most AbuseFilter variables operate based on a string representation of revision content. Non-textual content is converted to text by calling Content::getTextForSearchIndex. That is, AbuseFilter already has to assume that the string it operates on is plain text, and cannot be parsed using any particular syntax. Because this is the case, it should be safe to simply concatenate the string representation of the Content of all slots of a given revision, as returned by AbuseFilter::contentToString.
    • Task
    • ·Closed
    I was attempting to move Bill Johnson (American football) to Bill Johnson (punter) without leaving a redirect and with moving the talk page. The move happened successfully but I was faced with the following error: Internal error Jump to navigationJump to search [W@YyNgpAICAAAKivfAEAAAAN] 2018-11-10 01:19:51: Fatal exception of type "MWException" Reporting here in case it is of some value.
    • Task
    Currently, RevisionStore directly uses a BlobStore to store slot content, calling Content::serialize() to turn a Content object into a blob. There is no reason to hard code this, however. Some kinds of Content may better be stored in a different way, e.g. using a dedicated SQL schema, or in a column store. To allow this, RevisionStore should not use a BlobStore directly, but rather use a ContentStore, which may or may not be implemented based on a BlobStore. The ContentStore interface would be very similar to the BlobStore interface, but would take Content objects instead of raw data blobs: ```lang=php public function getContent( $contentAddress, $queryFlags = 0 ): Content; public function storeContent( Content $content, $hints = [] ): string; ``` The default implementation would be based on BlobStore, Content::serialize, and ContentHandler::unserializeContent. To allow other storage mechanisms to be applied, a wrapper could be used that delegates to the correct ContentStore based on the content model (when writing) and address prefix (when reading).
    • Task
    • ·Closed
    === Error === Request ID: `W@JHKwpAMEQAACQYxLgAAABL` ```name=message MediaWiki\Revision\RevisionAccessException: Could not determine title for page ID # and revision ID # from line 391 of /srv/mediawiki/php-1.32.0-wmf.26/includes/Revision/RevisionStore.php ``` ```name=trace,lines=10 #0 /srv/mediawiki/php-1.33.0-wmf.1/includes/Revision/RevisionStore.php(379): MediaWiki\Revision\RevisionStore->getTitle(integer, integer, integer) #1 /srv/mediawiki/php-1.33.0-wmf.1/includes/Revision/RevisionStore.php(2531): MediaWiki\Revision\RevisionStore->getTitle(integer, integer) #2 /srv/mediawiki/php-1.33.0-wmf.1/includes/api/ApiComparePages.php(68): MediaWiki\Revision\RevisionStore->getPreviousRevision(MediaWiki\Revision\RevisionArchiveRecord) #3 /srv/mediawiki/php-1.33.0-wmf.1/includes/api/ApiMain.php(1570): ApiComparePages->execute() #4 /srv/mediawiki/php-1.33.0-wmf.1/includes/api/ApiMain.php(531): ApiMain->executeAction() #5 /srv/mediawiki/php-1.33.0-wmf.1/includes/api/ApiMain.php(502): ApiMain->executeActionWithErrorHandling() #6 /srv/mediawiki/php-1.33.0-wmf.1/api.php(87): ApiMain->execute() #7 /srv/mediawiki/w/api.php(3): include(string) ``` === Impact === It seems that for certain revisions, users are unable to obtain comparison information from the API. Specifically, archived revisions (possibly limited to those that are oversighted). === Notes === Reported in WMF Logstash 204 times in recent weeks (since 1.32.wmf-24, possibly earlier). It is seen from multiple different wikis for a wide range of different page IDs and revisions. The referer for many of them are like `https://en.wikipedia.org/wiki/Special:Log/suppress` which suggests it might be triggered by a gadget attempting to provide information from the API about revisions in the log. I don't know if comparing oversighted/archived revisions is currently supported in the API, but at least it shouldn't fatal.
    • Task
    • ·Closed
    AbuseFilter should be able to filter by the content of all slots. At present, filter variables that are backed by the ParserOutput will match all slots, since the ParserOutput objects exposed to AbuseFilter is the combiend output of all slots. In contrast, filter variables backed by the raw content (wikitext) apply only to the main slot. As a baseline, AbuseFilter could simply concatenate the raw content as returned by Content::getTextForSearchIndex before initializing the variables. Ideally, AbuseFilter would allow filters to specify which slot the should apply to.
    • Task
    • ·Closed
    For a request like this: https://test.wikipedia.org/w/api.php?action=query&format=json&prop=info&titles=Main%20Page&generator=linkshere&formatversion=2 A page response is like this: ``` lang=json { "pageid": 139, "ns": 4, "title": "Wikipedia:Requests", "contentmodel": "wikitext", "pagelanguage": "en", "pagelanguagehtmlcode": "en", "pagelanguagedir": "ltr", "touched": "2018-10-24T19:37:12Z", "lastrevid": 311104, "length": 227 } ``` Will the `contentmodel` property be changing for #multi-content-revisions? or will it use the `main` slot?
    • Task
    **Problem** When you attempt to edit a page with #mobilefrontend, it makes a request to the API and this warning is returned: > Because "rvslots" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used. **Solution** Update the request, as well as the code, to use the slots.
    • Task
    • ·Closed
    === Error === Request ID: `W8S@4QpAICEAAEQQ4SwAAABC` ```name=message MediaWiki\Storage\IncompleteRevisionException: Uninitialized field: content_address ``` ```name=trace,lines=14 #0 /srv/mediawiki/php-1.32.0-wmf.24/includes/Storage/SlotRecord.php(361): MediaWiki\Storage\SlotRecord->getField(string) #1 /srv/mediawiki/php-1.32.0-wmf.24/includes/Storage/SlotRecord.php(501): MediaWiki\Storage\SlotRecord->getStringField(string) #2 /srv/mediawiki/php-1.32.0-wmf.24/includes/Storage/RevisionStore.php(1435): MediaWiki\Storage\SlotRecord->getAddress() #3 /srv/mediawiki/php-1.32.0-wmf.24/includes/Storage/RevisionStore.php(1354): MediaWiki\Storage\RevisionStore->loadSlotContent(MediaWiki\Storage\SlotRecord, NULL, NULL, NULL, integer) #4 [internal function]: Closure$MediaWiki\Storage\RevisionStore::emulateMainSlot_1_29#2(MediaWiki\Storage\SlotRecord) #5 /srv/mediawiki/php-1.32.0-wmf.24/includes/Storage/SlotRecord.php(308): call_user_func(Closure$MediaWiki\Storage\RevisionStore::emulateMainSlot_1_29#2;523, MediaWiki\Storage\SlotRecord) #6 /srv/mediawiki/php-1.32.0-wmf.24/includes/Storage/RevisionRecord.php(174): MediaWiki\Storage\SlotRecord->getContent() #7 /srv/mediawiki/php-1.32.0-wmf.24/includes/Revision/RenderedRevision.php(206): MediaWiki\Storage\RevisionRecord->getContent(string, integer, NULL) #8 /srv/mediawiki/php-1.32.0-wmf.24/includes/Revision/RevisionRenderer.php(170): MediaWiki\Revision\RenderedRevision->getSlotParserOutput(string) #9 /srv/mediawiki/php-1.32.0-wmf.24/includes/Revision/RevisionRenderer.php(123): MediaWiki\Revision\RevisionRenderer->combineSlotOutput(MediaWiki\Revision\RenderedRevision, array) #10 [internal function]: Closure$MediaWiki\Revision\RevisionRenderer::getRenderedRevision#2(MediaWiki\Revision\RenderedRevision, array) #11 /srv/mediawiki/php-1.32.0-wmf.24/includes/Revision/RenderedRevision.php(177): call_user_func(Closure$MediaWiki\Revision\RevisionRenderer::getRenderedRevision#2;791, MediaWiki\Revision\RenderedRevision, array) #12 /srv/mediawiki/php-1.32.0-wmf.24/includes/poolcounter/PoolWorkArticleView.php(194): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput() #13 /srv/mediawiki/php-1.32.0-wmf.24/includes/poolcounter/PoolCounterWork.php(123): PoolWorkArticleView->doWork() #14 /srv/mediawiki/php-1.32.0-wmf.24/includes/page/Article.php(774): PoolCounterWork->execute() #15 /srv/mediawiki/php-1.32.0-wmf.24/includes/page/CategoryPage.php(69): Article->view() #16 /srv/mediawiki/php-1.32.0-wmf.24/includes/actions/ViewAction.php(68): CategoryPage->view() #17 /srv/mediawiki/php-1.32.0-wmf.24/includes/MediaWiki.php(501): ViewAction->show() #18 /srv/mediawiki/php-1.32.0-wmf.24/includes/MediaWiki.php(294): MediaWiki->performAction(CategoryTreeCategoryPage, Title) #19 /srv/mediawiki/php-1.32.0-wmf.24/includes/MediaWiki.php(868): MediaWiki->performRequest() #20 /srv/mediawiki/php-1.32.0-wmf.24/includes/MediaWiki.php(525): MediaWiki->main() #21 /srv/mediawiki/php-1.32.0-wmf.24/index.php(42): MediaWiki->run() ``` === Impact === Some users are unable to view some pages on Commons. === Notes === 924 exceptions recorded so far. Started less than 4 hours ago. No instances of this error in the 30 days prior. {F26610186}
    • Task
    • ·Closed
    Found the followign message in the log of it.wikisource.org: `[{exception_id}] {exception_url} Exception from line 1243 of /srv/mediawiki/php-1.32.0-wmf.24/includes/diff/DifferenceEngine.php: ProofreadPage\Page\PageDifferenceEngine: could not maintain backwards compatibility. Please use a SlotDiffRenderer.` This occurred only two times over the last 24 hours, but it non the less indicates a problem with the code of ProofreadPage.
    • Task
    • ·Closed
    Observed on https://m.mediawiki.org/wiki/Special:MobileDiff/2382486 Not sure if fix is needed in Flow or MobileFrontend. This does not appear to be accessible via the mobile or desktop interface but if you pass a revision ID to Special:MobileDiff an exception is thrown. ``` #0 /srv/mediawiki/php-1.32.0-wmf.24/extensions/MobileFrontend/includes/diff/InlineDifferenceEngine.php(162): Wikimedia\Assert\Assert::parameterType(string, Flow\Content\BoardContent, string) #1 /srv/mediawiki/php-1.32.0-wmf.24/includes/diff/DifferenceEngineSlotDiffRenderer.php(58): InlineDifferenceEngine->generateContentDiffBody(Flow\Content\BoardContent, Flow\Content\BoardContent) #2 /srv/mediawiki/php-1.32.0-wmf.24/includes/diff/DifferenceEngine.php(1056): DifferenceEngineSlotDiffRenderer->getDiff(Flow\Content\BoardContent, Flow\Content\BoardContent) #3 /srv/mediawiki/php-1.32.0-wmf.24/extensions/MobileFrontend/includes/diff/InlineDifferenceEngine.php(64): DifferenceEngine->getDiffBody() #4 /srv/mediawiki/php-1.32.0-wmf.24/extensions/MobileFrontend/includes/specials/SpecialMobileDiff.php(160): InlineDifferenceEngine->showDiffPage() #5 /srv/mediawiki/php-1.32.0-wmf.24/extensions/MobileFrontend/includes/specials/SpecialMobileDiff.php(132): SpecialMobileDiff->displayDiffPage() #6 /srv/mediawiki/php-1.32.0-wmf.24/extensions/MobileFrontend/includes/specials/MobileSpecialPage.php(58): SpecialMobileDiff->executeWhenAvailable(string) #7 /srv/mediawiki/php-1.32.0-wmf.24/includes/specialpage/SpecialPage.php(569): MobileSpecialPage->execute(string) #8 /srv/mediawiki/php-1.32.0-wmf.24/includes/specialpage/SpecialPageFactory.php(568): SpecialPage->run(string) #9 /srv/mediawiki/php-1.32.0-wmf.24/includes/MediaWiki.php(288): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext) #10 /srv/mediawiki/php-1.32.0-wmf.24/includes/MediaWiki.php(868): MediaWiki->performRequest() #11 /srv/mediawiki/php-1.32.0-wmf.24/includes/MediaWiki.php(525): MediaWiki->main() #12 /srv/mediawiki/php-1.32.0-wmf.24/index.php(42): MediaWiki->run() #13 /srv/mediawiki/w/index.php(3): include(string) #14 {main} ```
    • Task
    • ·Closed
    Extension:Moderation relies on PageContentSave hook to (1) remember the new text, (2) return false from this hook, preventing the edit from being saved. With MCR feature, PageContentSave hook only gets the main content (see PageUpdater::saveRevision), so it's not possible to remember the additional slots (they will be lost on edit). New hook (e.g. MultiContentSave) should be provided, and all slots should be available from it.
    • Task
    • ·Closed
    Examples at which this is consistently reproducible: * `https://os.wikipedia.org/wiki/1888` * `https://de.wikipedia.org/w/index.php?oldid=5780804` === Error === Request ID: `W7KoHArAIEAAALCQVJQAAABU ` ```name=message Failed to load data blob from tt:106822: Failed to load blob from address tt:106822 ``` ```name=exception,lines=10 MediaWiki\Storage\RevisionAccessException: Failed to load data blob from tt:106822 #0 /srv/mediawiki/php-1.32.0-wmf.23/includes/Storage/RevisionStore.php(1350): MediaWiki\Storage\RevisionStore->loadSlotContent(MediaWiki\Storage\SlotRecord, NULL, NULL, NULL, integer) #1 [internal function]: Closure$MediaWiki\Storage\RevisionStore::emulateMainSlot_1_29#2(MediaWiki\Storage\SlotRecord) #2 /srv/mediawiki/php-1.32.0-wmf.23/includes/Storage/SlotRecord.php(306): call_user_func(Closure$MediaWiki\Storage\RevisionStore::emulateMainSlot_1_29#2;519, MediaWiki\Storage\SlotRecord) #3 /srv/mediawiki/php-1.32.0-wmf.23/includes/Storage/RevisionRecord.php(174): MediaWiki\Storage\SlotRecord->getContent() #4 /srv/mediawiki/php-1.32.0-wmf.23/includes/Revision/RenderedRevision.php(205): MediaWiki\Storage\RevisionRecord->getContent(string, integer, NULL) #5 /srv/mediawiki/php-1.32.0-wmf.23/includes/Revision/RevisionRenderer.php(169): MediaWiki\Revision\RenderedRevision->getSlotParserOutput(string) #6 /srv/mediawiki/php-1.32.0-wmf.23/includes/Revision/RevisionRenderer.php(122): MediaWiki\Revision\RevisionRenderer->combineSlotOutput(MediaWiki\Revision\RenderedRevision, array) #7 [internal function]: Closure$MediaWiki\Revision\RevisionRenderer::getRenderedRevision#2(MediaWiki\Revision\RenderedRevision, array) #8 /srv/mediawiki/php-1.32.0-wmf.23/includes/Revision/RenderedRevision.php(176): call_user_func(Closure$MediaWiki\Revision\RevisionRenderer::getRenderedRevision#2;723, MediaWiki\Revision\RenderedRevision, array) #9 /srv/mediawiki/php-1.32.0-wmf.23/includes/poolcounter/PoolWorkArticleView.php(188): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput() #10 /srv/mediawiki/php-1.32.0-wmf.23/includes/poolcounter/PoolCounterWork.php(123): PoolWorkArticleView->doWork() #11 /srv/mediawiki/php-1.32.0-wmf.23/includes/page/Article.php(771): PoolCounterWork->execute() #12 /srv/mediawiki/php-1.32.0-wmf.23/includes/actions/ViewAction.php(68): Article->view() #13 /srv/mediawiki/php-1.32.0-wmf.23/includes/MediaWiki.php(501): ViewAction->show() #14 /srv/mediawiki/php-1.32.0-wmf.23/includes/MediaWiki.php(294): MediaWiki->performAction(Article, Title) #15 /srv/mediawiki/php-1.32.0-wmf.23/includes/MediaWiki.php(868): MediaWiki->performRequest() #16 /srv/mediawiki/php-1.32.0-wmf.23/includes/MediaWiki.php(525): MediaWiki->main() #17 /srv/mediawiki/php-1.32.0-wmf.23/index.php(42): MediaWiki->run() ``` ```previous.exception MediaWiki\Storage\BlobAccessException: Failed to load blob from address tt:106822 #0 /srv/mediawiki/php-1.32.0-wmf.23/includes/Storage/RevisionStore.php(1433): MediaWiki\Storage\SqlBlobStore->getBlob(string, integer) #1 /srv/mediawiki/php-1.32.0-wmf.23/includes/Storage/RevisionStore.php(1350): MediaWiki\Storage\RevisionStore->loadSlotContent(MediaWiki\Storage\SlotRecord, NULL, NULL, NULL, integer) #2 [internal function]: Closure$MediaWiki\Storage\RevisionStore::emulateMainSlot_1_29#2(MediaWiki\Storage\SlotRecord) #3 /srv/mediawiki/php-1.32.0-wmf.23/includes/Storage/SlotRecord.php(306): call_user_func(Closure$MediaWiki\Storage\RevisionStore::emulateMainSlot_1_29#2;519, MediaWiki\Storage\SlotRecord) #4 /srv/mediawiki/php-1.32.0-wmf.23/includes/Storage/RevisionRecord.php(174): MediaWiki\Storage\SlotRecord->getContent() #5 /srv/mediawiki/php-1.32.0-wmf.23/includes/Revision/RenderedRevision.php(205): MediaWiki\Storage\RevisionRecord->getContent(string, integer, NULL) #6 /srv/mediawiki/php-1.32.0-wmf.23/includes/Revision/RevisionRenderer.php(169): MediaWiki\Revision\RenderedRevision->getSlotParserOutput(string) #7 /srv/mediawiki/php-1.32.0-wmf.23/includes/Revision/RevisionRenderer.php(122): MediaWiki\Revision\RevisionRenderer->combineSlotOutput(MediaWiki\Revision\RenderedRevision, array) #8 [internal function]: Closure$MediaWiki\Revision\RevisionRenderer::getRenderedRevision#2(MediaWiki\Revision\RenderedRevision, array) #9 /srv/mediawiki/php-1.32.0-wmf.23/includes/Revision/RenderedRevision.php(176): call_user_func(Closure$MediaWiki\Revision\RevisionRenderer::getRenderedRevision#2;723, MediaWiki\Revision\RenderedRevision, array) #10 /srv/mediawiki/php-1.32.0-wmf.23/includes/poolcounter/PoolWorkArticleView.php(188): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput() #11 /srv/mediawiki/php-1.32.0-wmf.23/includes/poolcounter/PoolCounterWork.php(123): PoolWorkArticleView->doWork() #12 /srv/mediawiki/php-1.32.0-wmf.23/includes/page/Article.php(771): PoolCounterWork->execute() #13 /srv/mediawiki/php-1.32.0-wmf.23/includes/actions/ViewAction.php(68): Article->view() #14 /srv/mediawiki/php-1.32.0-wmf.23/includes/MediaWiki.php(501): ViewAction->show() #15 /srv/mediawiki/php-1.32.0-wmf.23/includes/MediaWiki.php(294): MediaWiki->performAction(Article, Title) #16 /srv/mediawiki/php-1.32.0-wmf.23/includes/MediaWiki.php(868): MediaWiki->performRequest() #17 /srv/mediawiki/php-1.32.0-wmf.23/includes/MediaWiki.php(525): MediaWiki->main() #18 /srv/mediawiki/php-1.32.0-wmf.23/index.php(42): MediaWiki->run() ``` == Notes === The fatal RevisionAccessException exception happens during the building of a page view in MediaWiki for both unregistered users and logged-in users. Triaging as at least High priority given it exposes a fatal error on a public GET url, which is a risk for false alarms and increased load. The error seems to be nested behind a related problem that is handled, but then re-throws. The above `previous.exception` happens first, and then re-throws as RevisionAccessException, which is is currently unhandled by any UI layer and results in the top-level error handling reporting is as an application problem. {F26270506} Seems to be a regression that started with 1.32.0-wmf.19. (I didn't find matches among messages from previous versions). Although it is much more frequent on wmf.22 than on wmf.20 and wmf.19. Just speculating as to why it is growing, but: * It might mean that the same pages are receiving more traffic than before, or; * It could be that the same problem is slowly affecting a growing number of pages, or; * It could be that another bug was introduced last week that made it affect more pages. {F26270546} Consistently reproducible at `https://os.wikipedia.org/wiki/1888`. See also: * {T184693} * {T184690} * {T198869} * {T203075}
    • Task
    • ·Closed
    Since {T198341} and {T198342} have been pushed back and we support direct usage of rev_text_id and the text table even in MCR read-new mode, we have to ensure that Revision::getRevisionText keeps functioning in that mode. To ensure this, we should make Revision::getRevisionText fall back to loading content via the RevisionStore if the fields from the text table are not present.
    • Task
    • ·Closed
    === Error === Request ID: `W61juwrAMGkAAHdPhScAAACK ` ```name=message PHP Fatal Error: Argument 1 passed to MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision() must be an instance of MediaWiki\Storage\RevisionRecord, null given ``` ```name=stacktrace,lines=10 #0 /srv/mediawiki/php-1.32.0-wmf.23/includes/Storage/MutableRevisionRecord.php(64): MWExceptionHandler::handleError(integer, string, string, integer, array, array) #1 /srv/mediawiki/php-1.32.0-wmf.23/includes/Storage/RevisionStore.php(1082): MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision(NULL) #2 /srv/mediawiki/php-1.32.0-wmf.23/includes/Revision.php(1180): MediaWiki\Storage\RevisionStore->newNullRevision(Wikimedia\Rdbms\DatabaseMysqli, Title, CommentStoreComment, boolean, User) #3 /srv/mediawiki/php-1.32.0-wmf.23/includes/MovePage.php(537): Revision::newNullRevision(Wikimedia\Rdbms\DatabaseMysqli, integer, string, boolean, User) #4 /srv/mediawiki/php-1.32.0-wmf.23/includes/MovePage.php(271): MovePage->moveToInternal(User, Title, string, boolean, array) #5 /srv/mediawiki/php-1.32.0-wmf.23/includes/api/ApiMove.php(189): MovePage->move(User, string, boolean, array) #6 /srv/mediawiki/php-1.32.0-wmf.23/includes/api/ApiMove.php(87): ApiMove->movePage(Title, Title, string, boolean, array) #7 /srv/mediawiki/php-1.32.0-wmf.23/includes/api/ApiMain.php(1587): ApiMove->execute() #8 /srv/mediawiki/php-1.32.0-wmf.23/includes/api/ApiMain.php(531): ApiMain->executeAction() #9 /srv/mediawiki/php-1.32.0-wmf.23/includes/api/ApiMain.php(502): ApiMain->executeActionWithErrorHandling() #10 /srv/mediawiki/php-1.32.0-wmf.23/api.php(87): ApiMain->execute() ``` Also seen from Special:Move: ```name=trace,lines=10 reqId: W6px6ArAADwAAJ@r1lgAAACM PHP Error: Argument 1 passed to MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision() must be an instance of MediaWiki\Storage\RevisionRecord, null given #1 /srv/mediawiki/php-1.32.0-wmf.22/includes/Storage/RevisionStore.php(1082): MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision(NULL) #2 /srv/mediawiki/php-1.32.0-wmf.22/includes/Revision.php(1180): MediaWiki\Storage\RevisionStore->newNullRevision(Wikimedia\Rdbms\DatabaseMysqli, Title, CommentStoreComment, boolean, User) #3 /srv/mediawiki/php-1.32.0-wmf.22/includes/MovePage.php(537): Revision::newNullRevision(Wikimedia\Rdbms\DatabaseMysqli, integer, string, boolean, User) #4 /srv/mediawiki/php-1.32.0-wmf.22/includes/MovePage.php(271): MovePage->moveToInternal(User, Title, string, boolean, array) #5 /srv/mediawiki/php-1.32.0-wmf.22/includes/specials/SpecialMovepage.php(595): MovePage->move(User, string, boolean) #6 /srv/mediawiki/php-1.32.0-wmf.22/includes/specials/SpecialMovepage.php(128): MovePageForm->doSubmit() #7 /srv/mediawiki/php-1.32.0-wmf.22/includes/specialpage/SpecialPage.php(569): MovePageForm->execute(NULL) #8 /srv/mediawiki/php-1.32.0-wmf.22/includes/specialpage/SpecialPageFactory.php(581): SpecialPage->run(NULL) #9 /srv/mediawiki/php-1.32.0-wmf.22/includes/MediaWiki.php(288): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext) #10 /srv/mediawiki/php-1.32.0-wmf.22/includes/MediaWiki.php(868): MediaWiki->performRequest() #11 /srv/mediawiki/php-1.32.0-wmf.22/includes/MediaWiki.php(525): MediaWiki->main() #12 /srv/mediawiki/php-1.32.0-wmf.22/index.php(42): MediaWiki->run() ``` == Notes === Seen over 352 times in the last few weeks. Seems to be affecting commons.wikimedia.org and ar.wikipedia.org more than other wikis, but could be a coincidence.
    • Task
    • ·Closed
    See https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Revision_deleted_history_of_article PermaLink: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=861409505#Revision_deleted_history_of_article {4835a75} caused PoolWorkArticleView to start checking revdel where it was not checked previously, leading to the article not being displayed as it should be when an admin clicks the "view" link. Possible fixes include setting `$audience = RevisionRecord::RAW` at [[https://gerrit.wikimedia.org/r/c/mediawiki/core/+/452708/34/includes/poolcounter/PoolWorkArticleView.php#158|line 158]] (to match the previous behavior where a `$content` was passed) or having the caller pass a constructor parameter to explicitly bypass the audience check.
    • Task
    • ·Closed
    Seen again recently on Travis CI: <https://travis-ci.org/wikimedia/mediawiki/jobs/433020634> ``` 1) MediaWiki\Tests\Storage\DerivedPageDataUpdaterTest::testGetPreparedEditAfterPrepareUpdate Failed asserting that two strings are identical. --- Expected +++ Actual @@ @@ -'20180925161827' +'20180925161826' /home/travis/build/wikimedia/mediawiki/tests/phpunit/includes/Storage/DerivedPageDataUpdaterTest.php:487 ``` Looks like there's some non-explicit assumption in this test based on a variable timestamp. Recent changes: * 7960d5385f1146459671148e2e34d3ba50e17aeb T194038 * e8632ab0f6264851d2115a2e6338c2074b9a9b8c T174038
    • Task
    SlotRoleHandlers should provide a way to show a placeholder when a certain slot is desired on a given page, but missing. This could be done in the following ways # provide HTML (or a ParserOutput object) to represent the missing slot # provide a dummy Content object to be show (and maybe even saved with the next revision) # provide a message key that identifies a message to be shown when the slot is missing but desired. The placeholder would be shown for all roles returned by getDesiredRoles() for a given title. However, the baseline implementation of getDesiredRoles() just returns [ 'main' ]. SlotRoleHandler could get an isDesiredOn( $title ) method, but this would require all slot handlers to be instantiated before getDesiredRoles() can return a value. Using some kind of PageTypeHandler to define which roles are desired on a given page seems to make more sense.
    • Task
    The following code is from ParserOutput::getText() ``` // Hydrate slot section header placeholders generated by RevisionRenderer. $text = preg_replace_callback( '#<mw:slotheader>(.*?)</mw:slotheader>#', function ( $m ) { $role = htmlspecialchars_decode( $m[1] ); // TODO: map to message, using the interface language. Set lang="xyz" accordingly. $headerText = $role; return $headerText; }, $text ); ``` The TODO needs to be implemented so that a slot can have a meaningful header on a page (rather than just the name of the slot role). For the purposes of SDoC a plain text msg (without params) is adequate
    • Task
    • ·Closed
    ## Frontend Save Timing | Median (coal) |-- | {F26194342}| | Median (statsd) |-- | {F26194344} | p75 (statsd) |-- | {F26194345} Median: * June 2018 and earlier: ~850ms * around 5 July 2018: Increased to ~900ms and remained raised. * around 8 August 2018: Increased again, to ~950ms and remained raised. * around 21 August 2018: Increased again, to ~1,000ms and remained raised. * around 5 September 2018: Increased again, to ~1,400ms and is still raised. ## Backend Save Timing {F26194376} p75; * 27 June and earlier: ~530ms. * around 5 July 2018: Increased to ~630ms. * around 16 July 2018: //Decreased back to ~400ms for a few days (?)// * around 8 August 2018: Increasing to ~650ms. * around 5 September 2018: Increasing over 3 days upto ~850ms.
    • Task
    • ·Closed
    Apparently `DifferenceEngine::renderNewRevision()` never really worked right, it only functions when diffing //saved// revisions. When the code was written it generated a preview of the latest revision of the page, rather than showing the result of the undo, and this wasn't noticed during coding or review. After 4835a75e it doesn't generate any preview at all.
    • Task
    • ·Closed
    Wikibase has been updated to work with MCR, however one piece of integration is missing. The ContentModelCanBeUsedOn hook in core is not currently MCR ready and does not pass in the slot being checked at all. As a result when a wikibase entity is defined as being contained within a secondary slot in a namespace and the hook is run the namespace is detected and the content model of the entity type is matched, instead of the content model of the main slot (probably wikitext). The code in Wikibase needs to be able to do a lookup based on both the title / namespace and the slot name. The ContentModelCanBeUsedOn hook in core probably needs to provide this.
    • Task
    • ·Closed
    ``` A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT rev_page AS page_id,user_id,user_name,user_real_name,user_registration,user_editcount,ipb_id,COALESCE( actor_rev_user.actor_name, rev_user_text ) AS `rev_user_text` FROM `revision` LEFT JOIN `user` ON ((COALESCE( actor_rev_user.actor_user, rev_user ) = user_id)) LEFT JOIN `ipblocks` ON ((COALESCE( actor_rev_user.actor_user, rev_user ) = ipb_user) AND (COALESCE( actor_rev_user.actor_name, rev_user_text ) = ipb_address) AND (ipb_expiry > '20180918201335')) LEFT JOIN `revision_actor_temp` `temp_rev_user` ON ((temp_rev_user.revactor_rev = rev_id)) LEFT JOIN `actor` `actor_rev_user` ON ((actor_rev_user.actor_id = temp_rev_user.revactor_actor)) WHERE rev_id = '362490' Function: MediaWiki\Extension\PageTriage\ArticleCompile\ArticleCompileUserData::compile Error: 1054 Unknown column 'actor_rev_user.actor_user' in 'on clause' (10.192.32.7) #0 /srv/mediawiki/php-1.32.0-wmf.22/includes/libs/rdbms/database/Database.php(1428): Wikimedia\Rdbms\Database->makeQueryException(string, integer, string, string) #1 /srv/mediawiki/php-1.32.0-wmf.22/includes/libs/rdbms/database/Database.php(1198): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean) #2 /srv/mediawiki/php-1.32.0-wmf.22/includes/libs/rdbms/database/Database.php(1655): Wikimedia\Rdbms\Database->query(string, string) #3 /srv/mediawiki/php-1.32.0-wmf.22/extensions/PageTriage/includes/ArticleCompile/ArticleCompileUserData.php(61): Wikimedia\Rdbms\Database->select(array, array, array, string, array, array) #4 /srv/mediawiki/php-1.32.0-wmf.22/extensions/PageTriage/includes/ArticleCompile/ArticleCompileProcessor.php(235): MediaWiki\Extension\PageTriage\ArticleCompile\ArticleCompileUserData->compile() #5 /srv/mediawiki/php-1.32.0-wmf.22/extensions/PageTriage/includes/ArticleCompile/ArticleCompileProcessor.php(166): MediaWiki\Extension\PageTriage\ArticleCompile\ArticleCompileProcessor->process() #6 /srv/mediawiki/php-1.32.0-wmf.22/extensions/PageTriage/includes/ArticleMetadata.php(211): MediaWiki\Extension\PageTriage\ArticleCompile\ArticleCompileProcessor->compileMetadata(integer) #7 /srv/mediawiki/php-1.32.0-wmf.22/extensions/PageTriage/includes/Api/ApiPageTriageList.php(86): MediaWiki\Extension\PageTriage\ArticleMetadata->getMetadata() #8 /srv/mediawiki/php-1.32.0-wmf.22/includes/api/ApiMain.php(1587): MediaWiki\Extension\PageTriage\Api\ApiPageTriageList->execute() #9 /srv/mediawiki/php-1.32.0-wmf.22/includes/api/ApiMain.php(531): ApiMain->executeAction() #10 /srv/mediawiki/php-1.32.0-wmf.22/includes/api/ApiMain.php(502): ApiMain->executeActionWithErrorHandling() #11 /srv/mediawiki/php-1.32.0-wmf.22/api.php(87): ApiMain->execute() #12 /srv/mediawiki/w/api.php(3): include(string) #13 {main} ``` URL: https://test.wikipedia.org/w/api.php?action=pagetriagelist&format=json&namespace=118&afc_state=all&showunreviewed=1&showreviewed=1&dir=newestfirst&limit=20
    • Task
    • ·Closed
    Currently, old revisions can be restored by loading them into the EditPage using the action=edit&oldid=12345. However, this will presently only restore the main slot, and will not work for content models that do not support direct editing. Until {T174033} is implemented, we need an alternative way to restore old revisions. This could be done in the same way that undo is currently implemented for MCR, per {T189808}. Note that the same mechanism should also be used in case the main slot does not support direct editing, regardless of whether there are additional slots. This case is particularly relevant for Wikibase instances with entities in the main slot, like Wikidata.
    • Task
    • ·Closed
    We've added a number of classes for MCR, and there are more that still need adding. I think we could use a review of the namespaces being used for these classes. The current structure is: * MediaWiki\Storage ** ---- blob access ** BlobAccessException ** BlobStoreFactory ** BlobStore ** SqlBlobStore ** ---- name table access ** NameTableAccessException ** NameTableStoreFactory ** NameTableStore ** ---- revision storage ** RevisionFactory ** RevisionLookup ** RevisionStoreFactory ** RevisionStore ** ---- revision records ** RevisionRecord ** MutableRevisionRecord ** RevisionArchiveRecord ** RevisionStoreRecord ** RevisionSlots ** MutableRevisionSlots ** SlotRecord ** ---- revision exceptions ** IncompleteRevisionException ** RevisionAccessException ** SuppressedDataException ** ---- page editing ** DerivedPageDataUpdater ** PageUpdater ** PageUpdateException ** RevisionSlotsUpdate * MediaWiki\Revision ** ---- revision rendering ** RevisionRenderer ** RenderedRevision That's a lot of stuff in MediaWiki\Storage, most of which is only tenuously related to "storage". Following the precedent, there's a lot more in the future that would be able to go into MediaWiki\Storage too: PageStore and all its value classes, UserStore and whatever value classes it might have, probably even EditController and so on.
    • Task
    EditPage should allow editing of the content of any slot, not just the main slot. Which slot is being edited can be controlled with a URL parameter. See also {T174033} NOTE: This mechanism would also allow a new slot to be added. This should not be done without some mechanism in place that governs what slots can exist on what page, to avoid proliferation or arbitrary slots. NOTE: This ticket does not require any UI for picking the slot to edit. That would be useful, but should be tracked separately.
    • Task
    • ·Closed
    MediaWikiTestCase was recently changed to reset the MediaWIkiServices service locator between all tests. The same should be done for parser test, to isolate parser tests against other test cases. When parser tests are run via PHPUnit, ParserTestTopLevelSuite would be responsible for that. Stand-alone runs via parserTests.php would use ParserTestRunner::runTestsFromFiles