Hi folks,
Sorry for cross-posting, not sure which list is the best venue for my problem.
I have an issue with regards to the translation of the word
"attribution" in "Creative Commons Attribution-Share-Alike". For
reasons (explained in [1]) which are not interesting for Wikimedia,
the CC-sanctioned Romanian translation has changed from "distribuire"
to "partajare" in the translation for version 4.0 *only*.
This becomes a problem for multilingual wikis (mw, m, c), which use
meta-templates and MediaWiki messages to translate the {{cc-by-sa-*}}
templates. What would be the easiest way to solve the problem without
affecting other languages?
Thanks,
Strainu
[1] (in Romanian)
https://www.cyberculture.ro/2020/07/20/licente-creative-commons-versiunea-4…
Hi all,
Are you interested in writing a post for the Wikimedia Technical Blog
<https://techblog.wikimedia.org/>? We're currently seeking contributions!
Writing a post is a great opportunity to reflect on and share your work
with a wide audience of people who are curious about Wikimedia technology
and the Open Source community. This venue provides a central place for
people to share stories about the technical work that they do. Posts cover a
range of topics
<https://www.mediawiki.org/wiki/Wikimedia_technical_blog_editorial_guideline…>
from how-tos, to community outreach, to deep dives into processes and
technology, and much more.
If you're interested in writing a blog post, read the editorial guidelines
<https://www.mediawiki.org/wiki/Wikimedia_technical_blog_editorial_guidelines>
to learn about what would make a good story and how to get published! We
manage the process of reviewing and publishing posts here:
https://phabricator.wikimedia.org/tag/Technical-blog-posts
Looking forward to reading your stories!
Sarah R. Rodlund
Senior Technical Writer, Developer Advocacy
<https://meta.wikimedia.org/wiki/Developer_Advocacy>
srodlund(a)wikimedia.org
*“*
Hi everybody!
As you might have noticed, the Revision class is being hard deprecated in MediaWiki core 1.35 release. The class has been replaced with RevisionRecord as a part of MCR work and has been soft-deprecated in 1.31 release. You can find out more about deprecation process in [1]
In practice, this means that extensions using Revision will keep working with MediaWiki 1.35, but would start emitting a deprecation warning, causing your tests to fail if $wgDevelopmentWarnings configuration enabled (it is in WMF CI). After 1.35 is released, Revision class and fallbacks using it will start being removed from core, breaking extensions that are still using it.
In order to help you start the update process and prepare, DannyS has written a comprehensive migration guide available under [2]. If you have any questions, Platform Engineering Team(Core Platform Team) will be answering them and providing assistance. To reach us, please use any of the following methods of communication:
#wikimedia-cpt IRC channel. The best time to find CPT is during the office hours, the next time slot it July 23 16:00-17:00 UTC - that’s when you’re guaranteed to find assistance, but if this timing is not good for you, please feel free to drop your questions at any convenient time.
Phabricator with #core-platform-team tag
Here on this email thread
Best regards.
Petr Pchelko
Senior Software Engineer, Core Platform Team
1. https://www.mediawiki.org/wiki/Stable_interface_policy#Deprecation_process <https://www.mediawiki.org/wiki/Stable_interface_policy#Deprecation_process>
2. https://www.mediawiki.org/wiki/Manual:Revision.php/Migration <https://www.mediawiki.org/wiki/Manual:Revision.php/Migration>
Hi there,
>From the Release Note for MW 1.33:
(https://www.mediawiki.org/wiki/Release_notes/1.33)
> LinksDeletionUpdate is now a subclass of LinksUpdate. As a consequence,
> the following hooks will now be triggered upon page deletion in addition
> to page
> updates: LinksUpdateConstructed, LinksUpdate, LinksUpdateComplete.
I have an extension that uses the LinksUpdate hook to re-parse the article
in order to extract meta-data that it then stores in the DB for use
elsewhere in the extension.
I use LinksUpdate, rather than ArticleSaveComplete, as I also need to
re-parse the article when any of its templates changes. This hook captures
all changes that affect the page (by my understanding) except - up until
1.33 - deletions.
I therefore also use the ArticleDeleteComplete hook to remove the article
from the extension's meta-data tables when the article is deleted.
In the light of the above change to the LinksUpdate hook, what changes do I
need to make to my extension? Shall I simply drop the ArticleDeleteComplete
hook and update LinksUpdate to check whether an article is deleted or not
(how?) to decide which action is required? Or is there more to it.
On a separate note, I also reparse the page when the ArticleUndelete hook is
called. Is this necessary, or is LinksUpdate also being called for
undeletes?
Finally, I do a similar thing in the TitleMoveComplete hook - I reparse both
the old article and the new article. Is this also redundant due to
LinksUpdate calls, or not?
Kind regards,
- Mark Clements (HappyDog)
Hello,
Today the Wikimedia Foundation would like to introduce a new community
blog. It's called "Diff" (diff.wikimedia.org) and is a blog by – and
for – the Wikimedia volunteer community to connect and share
learnings, stories, and ideas from across our movement. We'd like to
encourage you to learn more about Diff and how it can help you in
sharing and learning from your fellow Wikimedians.
Everyone is invited to contribute!
https://diff.wikimedia.org/2020/07/14/welcome-to-diff-a-community-blog-for-…
The name “Diff” is in reference to the wiki interface that displays
the difference between one version and another of a Wikipedia page. It
also reflects the “difference” our communities and movement make in
the world every day.
For some background, Diff builds on lessons and experiences from the
Wikimedia Blog, the Wikimedia Foundation News, and Wikimedia Space;
previous posts from these channels are archived on Diff. The channel
is primarily intended for community-authored posts, in which
volunteers can share their stories, learnings, and ideas with each
other.
Diff offers a simple and accessible editorial process, moderated by
Foundation communications staff and open to volunteers, to encourage
participation from all — especially emerging and under-represented
communities. Additionally, content on Diff can be written and
translated into languages to reach a wide audience. Diff also has a
code of conduct and comments can be flagged and moderated.
Still curious to learn more?
https://diff.wikimedia.org/2020/07/14/welcome-to-diff-a-community-blog-for-…
Yours,
Chris Koerner (he/him)
Community Relations Specialist
Wikimedia Foundation
Dear all,
This is a demo of how the Desktop Improvements
<https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements#What_featur…>
project might look once it's finished:
http://demian-demo.epizy.com/wiki/Desktop_Improvements_volunteer_demo
Some details are not specified yet, therefore the end result will look
somewhat different.
I've implemented this mostly in 2 months' free time, around March-April.
Early, partial previews (wmf hosted):
http://patchdemo.wmflabs.org/wikis/380ec9d400f1bd8a573e09b015352723/w/http://patchdemo.wmflabs.org/wikis/b70f4202792d685831e5f957fb5953e1/w/
About me: I'm Demian (aka. Aron), senior software architect, creator of the
most recent Wikipedia Dark Theme
<https://www.mediawiki.org/wiki/User:Aron_Manning/Skin_themes> for Vector
and Timeless skins, among other various contributions and swift bugfixes.
With this preview I'd like to demonstrate what is possible with
collaboration. These demos were kept up-to-date with the project's progress
and benefited from the WMF developers' work to iron out some details. If
that collaboration would go both ways, the project could have been at the
same stage possibly a few months ago, nearing the finish line by now.
There are surprisingly few volunteers, even less professionals contributing
at MediaWiki, despite its high visibility. The small number of GitHub stars
and forks of the replica repos is also negligible compared to the thousands
of stars and forks of similarly popular projects.
The following is my opinion.
There is a great pool of talent that could contribute to modernizing the
aging code-base and designs (both software and UI), but despite the WMF's
regular calls for participation, volunteering has a very limited
aspect, more similar to interning at a closed-source project, not
reminiscent of the contribution patterns of free software. The development
- or community - practices can't benefit from a wide range of volunteers.
This untapped potential is of great value, lost for the MediaWiki project
and the communities using it.
If the WMF wishes to manifest its vision
<https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recomme…>
of an inclusive community, innovation and improved user experience, basic
steps can be taken at the back-office in that direction by making
development more open and welcoming to volunteers. Openness and
collaboration from the developer team would invite more talent and serve as
a foundation for a bigger, thriving developer community, similar to
open-source projects that succeeded with this model. There is a great
unused potential, that's in our core values to invite to the creation of
the foundation of free knowledge.
Further resources:
https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Wikimania_S…https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Feature_seq…https://www.mediawiki.org/wiki/User:Aron_Manning/Design/Desktop_Improvement…
Demian (aka. Aron)
Hi,
for HTML version see https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-07-15
Željko
--
= 2020-07-15 =
== Callouts ==
* Release Engineering
** [All] Review guidance at [[wikitech:Deployments/Covid-19]] and Code
Deployment Office Hour at 17:00UTC in #wikimedia-office
** "scap sync" will be renamed to "scap sync-world" in the next
release. If you use "scap sync" non-interactively, please add a note
to: [[phab:T250302]] (and also, explain why you're using it)
** scap sync now has option --canary-wait-time; [[phab:T217924]]
== Product ==
=== iOS native app ===
* Updates:
** Bug fixes and 1st experiment development for 6.7 - [[phab:project/view/4661]]
** WWDC research
=== Android native app ===
* Updates:
** Continuing work on onboarding design refresh - [[phab:project/view/4819/]]
=== Web ===
* Updates:
** '''Summary''': Desktop Improvements Project (DIP) deployment prep,
continuing DIP sidebar persistence, and wrapping up DIP content
max-width, Vue.js search design spec, initial WVUI library rolling
development release, building button, input, and icon for Vue.js
search.
** [[Reading/Web/Desktop_Improvements|Desktop Improvements Project
(Vector / DIP)]]:
*** [[phab:T153043|<nowiki>Align Vector skin with WikimediaUI color
palette</nowiki>]]
*** [[phab:T257518|<nowiki>[Bug] Max-Width Layout: Sidebar overlaps
footer when its height is longer than the content height</nowiki>]]
*** [[phab:T255727|<nowiki>Make collapsible sidebar persistent for
logged-in users</nowiki>]]
*** [[phab:T247790|<nowiki>wgLogos follow up work</nowiki>]]
*** [[phab:T246427|<nowiki>[Spike 8hrs] Decide how to persist state of
collapsible sidebar across sessions for logged-in users, logged-out
users</nowiki>]]
*** [[phab:T246420|<nowiki>Limit content width, and refine alignment &
styling of relevant elements</nowiki>]]
*** [[phab:T246419|<nowiki>Build collapsible sidebar and sidebar
button </nowiki>]]
*** [[phab:T167956|<nowiki>Deprecate and remove printable version
mode</nowiki>]]
*** [[phab:T256092|<nowiki>[Modern Vector] Fix broken rendering of
`main` and `dialog` elements in IE9-11</nowiki>]]
*** [[phab:T251212|<nowiki>[Dev] Drop VectorTemplate usage in Vector</nowiki>]]
*** [[phab:T244392|Vue.js search case study]]:
**** Thank you, Anne Tomasevich, for your work on wvui-icon!
**** See [[Reading/Web/Desktop Improvements/Vue.js case study/Status
log|weekly status updates]].
** Mobile website (MinervaNeue / MobileFrontend):
*** [[phab:T254287|<nowiki>Final warning: Mobile main page special
casing will be disabled July </nowiki>]]
*** [[phab:T32405|<nowiki>[EPIC] MobileFrontend extension should stop
special-casing main page</nowiki>]]
** Standardization
*** [[phab:T257167|<nowiki>Narrator not announcing popup dialog when
help button/icon is clicked.</nowiki>]]
*** [[phab:T182050|<nowiki>Deprecate and replace mediawiki.ui
components</nowiki>]]
*** [[phab:T256520|<nowiki>Consider 'normalize' stylesheet RL module</nowiki>]]
*** [[phab:T257768|<nowiki>Change filewarning to normal warning color
and amend padding slightly</nowiki>]]
*** [[phab:T257385|<nowiki>Window: focus lost when navigating with
shift + tab key</nowiki>]]
*** [[phab:T257279|<nowiki>Standardize 'mediawiki.ui' variables to CSS
variables naming scheme in preparation for WikimediaUI Base variables
takeover</nowiki>]]
*** [[phab:T257165|<nowiki>OOUI PopupWidget : need to Notify caller
when popup widget closes</nowiki>]]
*** [[phab:T248206|<nowiki>SelectFileInputWidget: "Close" button is
not accessible through keyboard.</nowiki>]]
*** [[phab:T165650|<nowiki>Directly use the WikimediaUI values in the
WikimediaUI theme in OOUI, rather than via copy-paste</nowiki>]]
*** [[phab:T255325|<nowiki>Outline control widget wrong focus order</nowiki>]]
*** [[phab:T253399|<nowiki>Focus not visible on Button on high
contrast mode</nowiki>]]
** Portals
*** [[phab:T128546|<nowiki>[Recurring Task] Update Wikipedia and
sister projects portals statistics</nowiki>]]
** QuickSurveys
*** [[phab:T246977|<nowiki>Run baseline quicksurvey on test wikis</nowiki>]]
** Miscellaneous
*** [[phab:T257630|<nowiki>SkinMustache::getTemplateData keys should
be hyphenated and existing in a dictionary</nowiki>]]
*** [[phab:T254048|<nowiki>Render the FallbackSkin and SkinApi with a
simplistic SkinMustache class</nowiki>]]
*** [[phab:T248751|<nowiki>Adopt mustache templates in Modern and
Monobook</nowiki>]]
*** [[phab:T231615|<nowiki>Use project logo wordmarks on Wikimedia
projects in Timeless</nowiki>]]
*** [[phab:T257877|<nowiki>MediaWiki installer appears unstyled</nowiki>]]
=== Product Infrastructure ===
* Updates:
** working on adding image schema.org licence data to article pages
** mediasearch improvements - vue frontend, improved linked data
search on backend
== Technology ==
=== Fundraising Tech ===
* Updates:
** Refining and improving bulk email sync
** Better filtering for matching gift policies db
** Looking into potential bugs with flow asking one-time donors to
convert to monthly donations
=== Engineering Productivity ===
==== Quality and Test Engineering ====
* Updates:
** New blog!
*** Wow. So wikimedia. Such quality. Many testing. Very team. 🐶
[[phab:phame/blog/view/21/]]
** Blog posts (by Google Summer of Code interns):
*** [[User:Vidhi-mody|Vidhi Mody]] - GSoCpedia: The journey so far
[[phab:phame/post/view/201/gsocpedia_the_journey_so_far/]]
*** [[User:AlQaholic007|Soham Parekh]] - Fanboying Cypress
[[phab:phame/post/view/202/fanboying_cypress/]]
==== Release Engineering ====
* Updates:
** [All] Deployments/Covid-19 [[wikitech:Deployments/Covid-19]]
** Train Health
*** Last week: 1.35.0-wmf.40 - [[phab:T256668]]
*** This week: 1.35.0-wmf.41 - [[phab:T256669]]
*** Next week: 1.36.0-wmf.1 - [[phab:T257969]]
The example below works, and I see it used in some extensions, but it
has no autocompletion and not catching typos.
Services.php:
class TranslateServices implements ContainerInterface {
public function getParsingPlaceholderFactory(): ParsingPlaceholderFactory {
return $this->container->get( 'Translate:ParsingPlaceholderFactory' );
}
public function getTranslatablePageParser(): TranslatablePageParser {
return $this->container->get( 'Translate:TranslatablePageParser' );
}
}
ServiceWiring.php:
return [
'Translate:ParsingPlaceholderFactory' => function ():
ParsingPlaceholderFactory {
return new ParsingPlaceholderFactory();
},
'Translate:TranslatablePageParser' => function ( MediaWikiServices
$services )
: TranslatablePageParser
{
return new TranslatablePageParser(
$services->get( 'Translate:ParsingPlaceholderFactory' ) # <--------
);
},
];
Do you see any downsides of using code like below instead?
'Translate:TranslatablePageParser' => function (): TranslatablePageParser {
$services = TranslateServices::getInstance();
return new TranslatablePageParser(
$services->getParsingPlaceholderFactory() );
},
I looked at other extensions and I noticed a lot of small differences
among them:
* Some extensions use static methods as opposed to wrapping the core
service container
* Some extensions use constants for service identifiers
* Lots of different implementations of "To avoid name conflicts, the
service names should be prefixed with the extension's name.":
** ExtensionService
** Extension.Service
** Extension:Service
** Extension_Service
Are we yet in a stage to agree on some (additional) conventions and
document them somewhere? Maybe in
https://www.mediawiki.org/wiki/Dependency_Injection
-Niklas
Dear all:
In light of the number of extensions making use of Revision objects, I've
documented some suggestions for how to replace each method. These
suggestions are also available at
https://www.mediawiki.org/wiki/Manual:Revision.php/Migration.
tl;dr: its complicated, but doable. I'm happy to review any patches, and if
you want to do part of the migration at a time, Jenkins will fail but can
be overridden.
----
For extensions that make widespread use of Revision objects, switching to
RevisionRecord may be challenging. It may be easier to split the migration
into multiple patches that each do part of the migration. Tests will still
fail, but if you add me (DannyS712) as a reviewer I'd be happy to review
all of the patches.
== Constructors ==
To replace uses of the static constructors (Revision::newFrom*) while still
having Revision objects, as a stop-gap measure use `new Revision(
$revisionRecord )` with the RevisionRecord constructed using the
RevisionLookup service. The RevisionLookup methods either return a
RevisionRecord or null, and the corresponding Revision methods returned
either a Revision or null:
Instead of
$revision = Revision::newFromId( $id, $flags );
use
$revisionRecord =
MediaWikiServices::getInstance()->getRevisionLookup()->getRevisionById(
$ids, $flags );
$revision = $revisionRecord ? new Revision( $revisionRecord ) : null;
For the other static constructors, simply replace `getRevisionById` with
the corresponding RevisionLookup method (note that the loadFrom* methods
accept different parameters than the newFrom*):
Revision::newFromTitle -> RevisionLookup::getRevisionByTitle
Revision::newFromPageId -> RevisionLookup::getRevisionByPageId
Revision::loadFromPageId -> RevisionLookup::loadRevisionFromPageId
Revision::loadFromTitle -> RevisionLookup::loadRevisionFromTitle
Revision::loadFromTimestamp -> RevisionLookup::loadRevisionFromTimestamp
The RevisionFactory service is used to replace Revision::newFromArchiveRow
and Revision::newFromRow; use RevisionFactory::newRevisionFromArchiveRow,
::newMutableRevisionFromArray, and ::newRevisionFromRow. Note, however,
that RevisionFactory::newMutableRevisionFromArray is itself deprecated, and
uses of it will need to be replaced with construction of a
MutableRevisionRecord.
For direct uses of `new Revision`, either existing ones or those added now,
see the notes below regarding the final removal of constructing Revision
objects.
== Fetching relative revisions ==
Revision::getNext was replaced by RevisionLookup::getNextRevision, which
returns a RevisionRecord object. Likewise, Revision::getPrevious was
replaced by RevisionLookup::getPreviousRevision.
== Revision text ==
Revision::getRevisionText returns a string of the text content for a
specific revision (based on a row from the database). To replace it, get
the RevisionRecord object corresponding to the row, and then use
RevisionRecord::getContent( SlotRecord::MAIN ) to get the relevant content
object, and if there is such an object, use Content::serialize to get the
text.
Revision::compressRevisionText can be replaced with
SqlBlobStore::compressData.
Revision::decompressRevisionText can be replaced with
SqlBlobStore::decompressData.
== Other static methods ==
The following static methods are replaced by non-static methods:
Revision::getQueryInfo -> RevisionStore::getQueryInfo
Revision::getArchiveQueryInfo -> RevisionStore::getArchiveQueryInfo
Revision::getParentLengths -> RevisionStore::getRevisionSizes
Revision::getTimestampFromId -> RevisionStore::getTimestampFromId (NOTE:
the Revision method's first parameter was a Title object that was ignored,
the RevisionStore method does not accept a Title, and only needs the
relevant id and any query flags)
Revision::countByPageId -> RevisionStore::countRevisionsByPageId
Revision::countByTitle -> RevisionStore::countRevisionsByTitle
Revision::userWasLastToEdit -> RevisionStore::userWasLastToEdit (NOTE: the
Revision method's first parameter was an int or an IDatabase object, the
RevisionStore method requires an IDatabase object. ADDITIONALLY, the
RevisionStore method is itself soft deprecated)
== userCan ==
Revision::userCanBitfield can be replaced with
RevisionRecord::userCanBitfield, and Revision::userCan can be replaced with
RevisionRecord::userCanBitfield with the bitfield being the int returned
from RevisionRecord::getVisibility. NOTE that both of the Revision methods
fell back to $wgUser if no user object was passed;
RevisionRecord::userCanBitfield requires that a User be provided.
== Corresponding Revision and RevisionRecord methods ==
The following Revision methods can be replaced with idential RevisionRecord
methods (though some have different names). Once a Revision object is
available in a relevant class or function, I suggest immediately retrieving
the corresponding RevisionRecord via Revision::getRevisionRecord and slowly
making use of the RevisionRecord instead of the Revision:
Revision::getId -> RevisionRecord::getId
Revision::getParentId -> RevisionRecord::getParentId
Revision::getPage -> RevisionRecord::getPageId
Revision::isMinor -> RevisionRecord::isMinor
Revision::isDeleted -> RevisionRecord::isDeleted
Revision::getVisibility -> RevisionRecord::getVisibility
Revision::getTimestamp -> RevisionRecord::getTimestamp
Revision::isCurrent -> RevisionRecord::isCurrent
The following Revision methods can be replaced with identical
RevisionRecord methods, BUT, while the Revision methods returned null if
the value was unknown, the RevisionRecord methods throw
RevisionAccessException exceptions:
Revision::getSize -> RevisionRecord::getSize
Revision::getSha1 -> RevisionRecord::getSha1
Revision::getTitle returned the relevant Title object for the revision. Its
replacement, RevisionRecord::getPageAsLinkTarget, returns a LinkTarget
instead of a Title. If a full Title object is needed, use
Title::newFromLinkTarget.
== Audience-based information ==
The Revision class had multiple methods that accepted a specific audience
for which a value (the editing user's id and username, the edit summary
used, or the revision content) was based on whether the audience could view
the information (since it may have been revision deleted).
The constants used for specifying an audience are identical in the Revision
and RevisionRecord classes:
Revision::FOR_PUBLIC -> RevisionRecord::FOR_PUBLIC
Revision::FOR_THIS_USER -> RevisionRecord::FOR_THIS_USER
Revision::RAW -> RevisionRecord::RAW
Replacements:
Revision::getUser returned the editing user's id, or 0, and
Revision::getUserText returned the editing user's username, or an empty
string. These were replaced with RevisionRecord::getUser, which returns a
UserIdentity object if the audience specifid can view the information, or
null otherwise. To get the user's id, use UserIdentity::getId, and for the
username, use UserIdentity::getName.
Revision::getComment returned the revision's edit summary (as a string), or
null. It was replaced with RevisionRecord::getComment, HOWEVER instead of a
string, RevisionRecord::getComment returns a CommentStoreComment.
Revision::getContent returned the content of the revision's main slot, or
null. It was replaced with RevisionRecord::getContent, HOWEVER the
RevisionRecord method requires that the slot for which the content should
be retrieved be specified. Use SlotRecord::MAIN to match the behaviour of
the Revision method. FURTHERMORE, the RevisionRecord method can throw a
RevisionAccessException, which the Revision method silently converted to
null.
NOTE: When the audience specified for ::getUser, ::getUserText,
::getComment, or ::getContent was FOR_THIS_USER, and no second parameter
was passed with the user, the Revision methods fell back to using $wgUser.
The RevisionRecord methods have no such fallback, and will throw an
InvalidArgumentException if attempting to use FOR_THIS_USER without passing
a User.
== Content handling ==
As part of the migration to multi-content revisions, there is no longer a
single content model or format for a revision, but rather there are content
models and formats for each slot.
Revision::getContentModel returned a string for the content model of the
revision's main slot (SlotRecord::MAIN), either the model set or the
default model. To replace it, get the RevisionRecord's main slot, and use
SlotRecord::getModel. If the revision has no main slot, fall back to the
default model for the title. Use the SlotRoleRegistry service to get the
SlotRoleHandler for the relevant role (in this case SlotRecord::MAIN), and
then use SlotRoleHandler::getDefaultModel.
Revision::getContentFormat returned a string for the content format of the
revision's main slot, or falls back to the default format for the content
model. To replace it, get the RevisionRecord's main slot, and use
SlotRecord::getFormat. If the revision has no main slot, or if
SlotRecord::getFormat returns null, fall back to the default format for the
content model using ContentHandler::getDefaultFormat with the relevant
ContentHandler.
Revision::getContentHandler returned the relevant ContentHandler object.
Use ContentHandlerFactory::getContentHandler with the relevant content
model as a replacement.
== Setting revision information ==
Revision::setId was only supported if the Revision object corresponded to a
MutableRevisionRecord. It can be replaced with MutableRevisionRecord::setId.
Revision::setUserIdAndName was only supported if the Revision object
corresponded to a MutableRevisionRecord. It can be replaced with
MutableRevisionRecord::setUser; NOTE that the MutableRevisionRecord method
requires a UserIdentity, rather than a user id and name.
Revision::setTitle was not supported, and threw an exception if it was
called with a different title than the one already set for the revision.
== Misc ==
Revision::getTextId -> use SlotRecord::getContentAddress for retrieving an
actual content address, or RevisionRecord::hasSameContent to compare content
Revision::isUnpatrolled -> RevisionStore::getRcIdIfUnpatrolled
Revision::getRecentChange -> RevisionStore::getRecentChange
Revision::getSerializedData -> use SlotRecord::getContent for retrieving a
content object, and Content::serialize for the serialized form
Revision::insertOn -> RevisionStore::insertRevisionOn
Revision::base36Sha1 -> SlotRecord::base36Sha1
Revision::newNullRevision -> RevisionStore::newNullRevision
Revision::newKnownCurrent -> RevisionLookup::getKnownCurrentRevision
== Constructing ==
For uses of `new Revision`, there are multiple relevant replacements:
If the Revision was constructed with a RevisionRecord, just use that
RevisionRecord directly
If the Revision was constructed with an array, use
RevisionFactory::newMutableRevisionFromArray
NOTE: If neither the `user` nor `user_text` fields were set, the Revision
class fell back to using $wgUser;
RevisionFactory::newMutableRevisionFromArray includes no such fallback, and
if no user is provided the MutableRevisionRecord returned simply won't have
a user set.
If the Revision was constructed with an object, use
RevisionFactory::newRevisionFromRow
----
Sorry if the suggestions were overwhelming. Let me know if there are any
questions. Hope this helps!
--DannyS712