It is a boolean parameter that is confusing for three reasons:
* It's a boolean parameter, given parameters are unnamed in PHP,
these are always poor UX for call sites.
* It's negated ("noudp"). save(true) means no feeds events,
save(false) [default] means sending events to feeds.
* To overcome this problem, typical use was to pass a free-form
string that self-documents the intended behaviour,
e.g. `save('pleasenoudp')`, any string casts to true.
Fix this by moving the booleans to constants and use those
instead. For compatiblity, keep the negation internally,
although it's hidden from regular usage. Also document
the string hack, deprecate it, and update callers.
Change-Id: Ia57c86b38bf50cb4ec580f42a6b1ca798fcf781a
These actions mark edits as patrolled automatically, so the
correct rc_patrolled value to use is PRC_AUTOPATROLLED rather than
PRC_PATROLLED. The code for log entries checks the autopatrol right, and
the code for category entries has a comment that says "just like log
entries".
Bug: T190408
Bug: T184791
Change-Id: Id994af8cd3833a862a09389431256aba35c2e6d9
Per the RFC, it will now become the default and only behaviour
to not log autpatrol actions. The information is already
recorded via the rc_patrolled field.
Bug: T184485
Change-Id: I98ae895a2b4cde4bb945f1df23be4a070b0bf9c4
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
This allows CommentStore to be added to MediaWikiServices
without the need of an aditional Factory.
This change includes a compatability layer to allow the behaviour
from 1.30 to continue to be used while deprecated.
CommentStore::newKey has been deprecated.
Keys are now passed into the public methods of CommentStore
where needed.
The following CommentStore methods have had their signatures changed
to introduced a $key parameter, but when used in conjunction with
CommentStore::newKey behaviour will remain unchanged:
* CommentStore::getFields
* CommentStore::getJoin
* CommentStore::getComment
* CommentStore::getCommentLegacy
* CommentStore::insert
* CommentStore::insertWithTemplate
Change-Id: I3abb62a5cfb0dcd456da9f4eb35583476ae41cfb
Redundant given this is the project-wide license already,
especially in file headers that already include the GPL license
header.
This and other minor fixups based on feedback from Ie0cea0ef5027c7e5.
* Add @file where missing.
* Move @ingroup and @deprecated from file to class doc where needed.
Change-Id: I7067abb7abee1f0c238cb2536e16192e946d8daa
These comments do not add anything. I argue they are worse than having
no comments, because I have to read them first to understand they
actually don't explain anything. Removing them makes room for actual
improvements in the future (if needed).
Change-Id: Iee70aad681b3385e9af282d5581c10addbb91ac4
Several classes have a "selectFields()" static method to tell callers
which fields to select from the database. With the recent comment table
change and the upcoming actor table change, this pattern has become too
simplistic as a SELECT will need to join several tables to be able to
retrieve all the needed fields.
Thus, we deprecate the selectFields() methods in favor of getQueryInfo()
methods that return tables and join conditions in addition to the
fields.
Change-Id: Idcfd15568489d9f03a7ba4460e96610d33bc4089
Get rid of isPerGroupRequestParameter and define a consistent
interface that all filter groups can implement.
Change-Id: Ib904bcdc697c65722a0041ac611d1e00c577389f
Followup to I3e48a9f2d9b70f0b9f6d7c6329db9c8e8001ee49
Reported in T174725#3590145
Comparing current value and active value with
different representation ("1" !== true) leads to
not applying filters that are ON by default.
Bug: T174725
Change-Id: If083610c0294756589adfc32a59388cc7422ad5d
CategoryMembershipChange is great, but it doesn't have a
machine-readable way to see if the category has been added or removed
from the page. We could parse the comments, but that would rely on
reading the comments and matching the message against the translated
strings.
This patch adds a couple of parameters and notes whether the change
was an addition or removal in rc_params.
Also, puts the evaluation of the AbortEmailNotification hook before
the check of rc_type in the hopes that the extension CatWatch can send
out emails at the right time.
Bug: T175052
Change-Id: I3e2ac0cc148b9d618e2f8b7853b14bff827ee443
Since the caller doesn't (and shouldn't) know whether CommentStore is
using the old or the new schema, it should leave truncation of comments
to CommentStore.
Change-Id: I92954c922514271d774518d6a6c28a01f33c88c2
* Respect different default values for 'limit' and 'day'
in RC and WL.
* Make 'latestrevision' respect 'watchlistextended'
Introducing 2 properties to ChangesListBooleanFilter
* activeValue: The value that defines when a filter is active.
Most filters are active when they are set to 'true' but
'extended' has no effect when it is 'true' and applies
filtering when it is set to false.
* isVisible: Whether this filter is visible anywhere.
'extended' is not visible in the legacy form but
it is activated from preference or URL. When
understanding form submission, it should not be assume
to be 'false' when not present in the request.
Bug: T171134
Change-Id: I3e48a9f2d9b70f0b9f6d7c6329db9c8e8001ee49
When the 'watchlistunwatchlinks' preference option is enabled, this
adds a '×' link to each entry of the watchlist that unwatches the page
of that entry. When clicked, it changes into a '+' which can be used to
re-watch the page (effectively undoing the earlier unwatch).
When a page is unwatched, its entries and the entries of its associated
talk page (or vice versa) become translucent and are struck through.
Without JS, '×'/'+' link to action=(un)watch for the relevant page.
In addition, ChangesList classes have been modified to allow a prefixer
that adds a prefix to each line (used in this case to put the unwatch
link) and to add HTML data attributes to reliably determine the target
page of each entry. Unit tests have been updated accordingly.
Bug: T2424
Change-Id: I450b2901413d7e75c11de2a446829fdbb22d31e1
- mostly auto fixes
- some too long lines fixed
- ignore amp space in one case passing by reference
Change-Id: I6472f83bc3cbf4bd629d83050cc3319b19ec465c
Reenable MediaWiki.WhiteSpace.SpaceBeforeClassBrace.NoSpaceBeforeBrace,
because the mentioned bug is fixed
Bug: T172933
Change-Id: I1593bdba2295ebed401b921f2beabed69dba7638
For both "Live Update" and "View newest changes", add a marker
between old and new groups when changes are grouped by page.
Bug: T163426
Change-Id: I00947d05e9b6022604a2a6b94eec94f6ed747c96
When "live update" is off and new changes are detected,
show a link to load and prepend the changes to the list.
Also adding a line between old and new changes
when grouping by pages is off.
Bug: T163426
Change-Id: I6a111d23956bdc04caa4c71e9deede056779aafa
And auto-fix all errors.
The `<exclude-pattern>` stanzas are now included in the default ruleset
and don't need to be repeated.
Change-Id: I928af549dc88ac2c6cb82058f64c7c7f3111598a
Having such comments is worse than not having them. They add zero
information. But you must read the text to understand there is
nothing you don't already know from the class and the method name.
This is similar to I994d11e. Even more trivial, because this here is
about comments that don't say anything but "constructor".
Change-Id: I474dcdb5997bea3aafd11c0760ee072dfaff124c
EnhancedChangesList renders an <h4> for every day, but it
does so before it starts rendering the changes for that day.
If all of the changes for a different day fail to render
(due to permissions issues, extension hooks, or whatever)
this would result in an empty heading.
Instead, render the heading after formatting is complete,
so that if all changes for a given day are dropped,
the heading is also dropped.
Bug: T171078
Change-Id: I8a0c6cbd679976d18d2c2e6e9ac972fb7b294a42
ChangesListStringOptionsGroup::modifyQuery checks for ALL and
behaves accordingly, but isSelected() didn't. This broke conflict
detection when an entire non-full-coverage group was selected.
Bug: T162630
Change-Id: Ie241744201380ca5450d5edbb3eba971194f3df4
The used phpcs has a bug, so the version 0.9.0 could not be enforced at the moment.
Will be fixed in next version, see T167168
Changed:
- Remove duplicate newline at end of file
- Add space between function and ( for closures
- and -> &&, or -> ||
Change-Id: I4172fb08861729bccd55aecbd07e029e2638d311
We push 'class' in the attribute array so the hook
can manipulate it, so it needs to be added to the attribute
whitelist as well.
Broken in I6dd006d0b1b0fd35c0020f0f9eea9113eca30b35.
Bug: T167922
Bug: T167535
Change-Id: Ic24400382a9dcbb990e12dfddae4ab7db14553cc
Enhanced RCFilters: Add the ability to filter by namespaces to RCFilters.
🎉🎁🎊
- Add the ability to separate groups of filters by 'views'
- Add the first views as 'default' (for predefined filters)
and 'namespace' as the list of namespaces.
- Add 'nsinvert' to namespace group
- Allow highlighting namespaces
- Allow searching on either view, depending on prefix
- Add a way to switch views by typing prefix, clicking the
'Namespaces' button or clicking a tag (either namespace
or filter tag, changes the view accordingly, and adds
or removes the prefix from the input to stay consistent)
- Add an optional wrapper text for tags, so we can represent
them with their respective prefixes and (if needed) with
a special message for inverted state.
- Add unit tests and make pass
- Bonus: Fix issue with URL not updating (and not being updated)
the inverted and highlight enabled states.
Bug: T159942
Bug: T163521
Bug: T164130
Change-Id: I7e83f0800cbeb289dfd3461c1c5a197c053147ca
We have several types of change lists (old RC/watchlist/related
changes, enhanced RC/watchlist, history) with slightly different
HTML, each with their own idiosyncracies. JavaScript code trying
to identify lines by log ID / revision ID has to jump through all
kinds of hoops to work with that.
To simplify the lives of frontend / gadget maintainers and provide
something approaching an API for these pages, we now expose the basic
attributes of each change line (revision ID for edits, log type/action
and ID for log events) as data attributes.
The OldChangesListRecentChangesLine, EnhancedChangesListModifyLineData,
EnhancedChangesListModifyBlockLineData, PageHistoryLine,
ContributionsLineEnding and DeletedContributionsLineEnding hooks
are updated accordingly. New hooks (LogEventsListLineEnding and
NewPagesLineEnding) are added for the change list pages which did
not yet have them.
Change-Id: I6dd006d0b1b0fd35c0020f0f9eea9113eca30b35
When all grouped changes were categorization, the formatted character
difference was an empty string. This resulted in doubled separator.
In this case, we need to change it to false (like the code already
did with log entries).
Change-Id: Ic5cd82426985285809858ed67967bb2529bc31cb
If a page is deleted, rc_cur_id is missing, but it takes
a while before job queue deletes RC entries. If we encounter
something like that, just skip it since its bound for
deletion anyways.
Bug: T164059
Change-Id: I286109a9707e54939c0da31656ef54fd29acf481
TemplateParser has an instance cache to avoid reading from APC
repeatedly for the same template, but that only works if the code uses
the same TemplateParser object.
Noticed while investigating T163154.
Change-Id: I645895a0965f7150e9a5aebc5a7788f27aa5a26d
All the lists and sub-lists now render correctly,
and missing parameters have been added.
Bug: T163069
Change-Id: I7a8c95efaff7c844e32e4375dfe6af8c2e91923f
Filters are in conflict when their combination is guaranteed
to return no results. For instance: minor and log entries
is a conflict because major/minor does not apply to
log entries and the field is set to major by default.
Letting conflicts go through result in some very slow
database queries.
Bug: T160220
Change-Id: Ia6b0125c675c4a3cc4e4be4f83d1bd10d23059ba
Some legacy filters are replaced in structured UI by new filters.
It's important that their default value doesn't cause them
to filter the results when they are not even visible to the
user.
Bug: T162158
Change-Id: I3ff09164bbc0d14283302aa37bdee2c7ef9f5eb3
This is pretty fragile; it's easy to accidentally miss one of the
checks (as has already happened in e.g. parseParameters).
Although I don't yet know of any bugs as a result of this, it's
cleaner to do it at registration time.
There are no extensions using this feature.
Change-Id: I8547ea6432cae73e1bc272dbe959f2415b8a6d21
Explicitly block two filters in the same group from having the same
name.
Before, it would be left to registerFilter, which would just cause
the second one to win.
Also, avoid a getFilter warning when the filter does not exist.
Do the same for getFilterGroup on ChangesListSpecialPage
Finally, a minor related doc fix.
Change-Id: I6b3880a5c7cc381c169bbd969cd4814559b49c91
This is reserved for the client-side which joins 'someGroup'
and 'somefilter' to make 'someGroup__somefilter' as an internal
ID.
Change-Id: I1b6ca9f337dd48e10705c46ef5027c3156254e01
Generate old RC, Related changes (it was already displayed and working
on 'Related changes' before this change), and Watchlist/etc. and data
for new UI from back-end.
This moves everything used for defining the old (unstructured) and new
(structured) filters into unified objects, ChangesListFilter and
ChangesListFilterGroup (and sub-classes).
This includes the query logic (see below) and logic for adding
CSS attribution classes.
This is a breaking change (for subclasses of ChangesListSpecialpage)
due to the signature (and name) change of buildMainQueryConds and
doMainQuery. An alternative that I don't think is a breaking change
would be to put the filter->DB logic in runMainQueryHook, but then it's
doing more than just running a hook.
This is because it used to only build $conds here, but it's clear from
filterOnUserExperienceLevel filters need more than this. I added all
the DB parameters from the hook, but this could be debated.
I have an checked and fixed the WMF-deployed extensions affected by
this.
Other than that, there should be full back-compat (including legacy
filters not using the new system).
* add hidepatrolled/hideunpatrolled to new UI.
* Move userExpLevel from RC to ChangesListSpecialPage. Although for
now the structured UI only displays on RC anyway, when it displays on
watchlist, it seems we'll want userExpLevel there.
Change this to make 'all' exclude unregistered users.
* Don't have front-end convert none-selected to 'all' on string_options.
* Needs the hideanons/hideliu special redirect to be done before this
is merged (T151873)
Bug: T152754
Bug: T152797
Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
CSS classes mw-changeslist-diff and mw-changeslist-history should be
added to diff and history links in recent changes. There is already a
patch for the old recent changes page, this one adds the same classes
onto the enhanced recent changes page (class EnhancedChangesList). As
enhanced RC has a lot more links, this patch introduces two new css
classes for some links, one named #mw-changeslist-diff-cur which is for
the diff that links to a current version within nested changes and the
other named #mw-changeslist-groupdiff which is for the 'summary diff'
that appears for a group of nested changes.
Follow-up: I2d5ef8c180ae4ff6e7f5d0ab443dc7084f8c4c77
Bug: T157178
Change-Id: Ib51639a92b5925f2bad0aebd4f7068b178f65017
Let there be highlight! and there were highlights
And RCFilters separated the highlight from the darkness
And it defined highlights as five colors
The lights are called yellow and green, and the darks red and blue
And there were colors and there were circles; one highlight.
This is the commit that adds highlight support for filters both in the backend
and the UI. The backend tags results based on which filter they fit and the
front end paints those results according to the color chosen by the user.
Highlights can be toggled off and on.
Also added circle indicators to the capsule items and each line of results
to indicate whether the line has more than one color affecting it.
Bug: T149467
Bug: T156164
Change-Id: I341c3f7c224271a18d455b9e5f5457ec43de802d
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
Follows-up 39a6e3dc4d. Class-based feeds are always given their parameters
by RCFeed::factory. However because the old getEngine() method insists
on creating its own object, the constructor parameters were not given.
Add it as optional parameter and pass it through there.
This is backwards-compatible still because before the 39a6e3dc4d refactor,
an RCFeedEngine also was not given information about any formatter and it
was the callers responsibility to format the line before calling send().
CentralAuth still uses it this way and that works fine. The core-caller
that expected the construction parameters since 39a6e3dc4d is hereby fixed.
The test couldn't catch this because it constructed the class instance there,
since PHPUnit does not support a mock class that is instantiated by foreign
code, and the parameter is passed there.
Bug: T156996
Bug: T157106
Change-Id: I83433cf57b6e040cdb69f3ad8807a999c4f931a5
Previously:
* Engines had to be registered in $wgRCEngines.
* The RCFeedEngine classes took no constructor arguments and
were expected to send whatever text is previously formatted
without any information about it. This generic design was
flexible in allowing one to use any formatter with any engine
with minimal configuration and no need for additional classes.
* Each feed configured their destination by setting a 'uri'
option that encodes the name of the engine in PHP as the uri
scheme. Other uri components had to be used for any other
parameters to the engine (host, port, path). While fairly
limited, it was sufficient for the default engines in core.
Changes:
* Allow feed classes to be directly associated with a feed in $wgRCFeeds
via a new 'class' option - without the indirection of 'uri' and
$wgRCEngines. All options are passed to the given class constructor.
This matches the design used elsewhere in MediaWiki. (ObjectCache,
FileRepo, FileBackend, JobQueue, LBFactory, etc.)
This means we no longer enforce a 1:1 mapping of internet protocols
to a specific feed engine, and it allows settings to be passed
without being encoded as a URI neccecarily.
Main use case for this refactor is EventBus (see I7edc4d57fa),
Interestingly, this matches the (then incorrect) documentation
written for $wgRCFeeds in 2961884b43 (which mentions an 'engine'
property that would do the same thing).
* Move the default 'omit' filters and unrestricted 'formatter' handling
to a new FormattedRCFeed class, which remains the default.
* Deprecate RecentChange::getEngine() in favour of RCFeed::factory().
* Document wgRCEngines as "@since 1.22". Follows 2961884b43, ffc71cb6af.
Change-Id: I8be497c623c5d928762e3d3406a388f4d91add9a
Use of &$this doesn't work in PHP 7.1. For callbacks to methods like
array_map() it's completely unnecessary, while for hooks we still need
to pass a reference and so we need to copy $this into a local variable.
Bug: T153505
Change-Id: I8bbb26e248cd6f213fd0e7460d6d6935a3f9e468
The old code was similar to Message::params(), but Message::params()
was unable to handle "special" parameters and received an overhaul
in 7f2663f, yet wfMessage remained broken. To avoid duplication,
wfMessage shall call Message::params() to correctly handle these
parameters.
CategoryMembershipChange::getChangeMessageText and its caller has
been updated so as not to take advantage of this bug.
Bug: T153747
Change-Id: I6667acf7e71c9db07fefc9fbb741c160e15823ff
Since T106119, moves that overwrite a redirect produce a deletion log
entry. It should be possibleto identify such deletions within other ones.
Note that this patch only applies for actions in the future because there
is no way to easily identify these cases for the software (until now).
Bug: T145991
Change-Id: I3c006bca57351d82031c4fdce0c53f65d630b0d9
This creates a hook triggered when updating change tags, so that
extensions can take actions when tags are updated.
When tagging accompanies the action, the recent change is passed
while when tagging is subsequent to the action, the user who
performs the tagging is passed.
Bug: T118698
Change-Id: Ifb0cdc43252c4185e4f216d23b8a21fb31595a37
Most planned callers of RecentChange::addTags() only want to add a
single tag, so forcing them to create an array seems unfriendly. Plus
this lets us avoid a array_merge call.
Change-Id: If001ba9ff01a33be158e7edd5c5e4de9825fa180
Currently, extensions that add tags within the recentchanges_save
hook directly call ChangeTags::addTags. This often results in
consecutive writes to the changetags table.
This provides a addTags method to RecentChange so extensions
can simply use it when they want a tag added. And all the actual
tagging is done once at the end.
Change-Id: I8df2fd983c12632337e8d2922fa357808482338c
Simplify DB callers by just having one code path.
All but some very old code paths bothered with these.
Change-Id: Iaf7a2f83146a0ed15995f9cfc74edcf16ae5a448
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
These were added to Special:RecentChanges in 2004, but it doesn't
match what we do in any of the other lists. For accessibility
purposes, in flow indexing is preferred these days, or alternatively
a JS controlled roving tabindex, but this was neither.
Bug: T116127
Change-Id: Id455fafe4bdea40fb5988bdec14eed672844c8e3
In getLineData, if the EnhancedChangesListModifyLineData hook returns false,
then $line is an empty array and recentChangesFlagsRaw is not set.
If $line is empty then presumably we don't want to render it and
can skip the line here.
Bug: T133296
Change-Id: I92fded07274a06a0dd2929b97815bfe56f1847ea
If a hidden category has a member added or removed
this will only be shown to users that have the user
preference "display hidden categories".
Also added method to WikiCategoryPage to check
for hidden status.
Added unit tests for both.
Bug: T127944
Change-Id: Ic53d51391fa29d5e18fef4c42b8a275816c7ba4a
Per the docs of unserialize:
In case the passed string is not unserializeable, false is returned.
Also as we can not guarentee an array was serialized in
rc_params we cant say it will always be an array...
Quite often this is just an empty string which will
result in: "s:0:"";" (not an array)....
Change-Id: Ib22f9f7468a23ce3d4f145d47f8514d08be6c957
Providing the perfectly correct number of pages
that have acctually been added to or removed from a
category is extermly hard.
Rather than providing data that is most likely wrong
and a bit useless ONLY provide a link to Special:WhatLinksHere.
This touches on the following bugs and may mean that
some of them don't need to be thought about any further.
Bug: T126855
Bug: T126407
Bug: T126139
Change-Id: Ida06d822d1955091595c17c9c6c2968a40a93bcd
Flags can be either 'any' or 'all' type, and both core and extension flags will be
rolled up into the top-level line of grouped changes.
See Ic49a355a2
Bug: T120921
Bug: T112856
Change-Id: If9fd6af3ac7ac2fbee9aa5536fe94d7574699966
This patch addes the summarized number of category changes
for grouped category changes on the EnhancedChangesList.
Bug: T126849
Change-Id: I3c8ccb2ad6310dac19a724b2ce923c1e67e588be
This adds new methods to ManualLogEntry that allow to specify that
a log entry is patrollable. RecentChange::newLogEntry then checks
this in order to allow or not unpatrolled status instead of checking
if there is an associated rev id. This allows to associate a revision
to a log entry without possibly making the recent change unpatrolled,
and extensions can implement patrol of actions not dependent on an
associated revision id.
Bug: T127848
Change-Id: I98298047142819b69639e6ca9d77c5ba982a380c
This way the messages are generated in the correct language instead
of relying on the user language from global context.
This should ideally become a non-static method at some point,
but currently there currently many out-of-class callers.
Change-Id: Ifb1756c1a3bddc717387ed66a58dedd4c1a7dab9
Was calling escaped() directly on a Message object which resulted
in a $wgLang lookup, thus ignoring the context language given to the
class constructor.
Change-Id: Ia8ce739178924299ca559088fc40a2b048d7ed72
- Add 'tags' parameters to appropriate API modules
- Add tag-adding logic to appropriate functions that carry out
relevant functions
- ManualLogEntry::{set,get}Tags to handle adding tags to log
entries in a cleaner fashion
- Use ManualLogEntry::setTags in LocalFile::recordUpload2
Bug: T97720
Change-Id: I98c52da7985623bfdafda2dc2dae937b39b72419
This will mean that EnhancedChangesList does not
do odd things.
Log changes also have this set to null
This also adds a tiny bit of cleanup for the past which
could be removed in a month or 2.
This will fix all current RC entries as well as new ones.
Once no old RC entires for CategoryMembership changes exist
we can kill the type check.
Bug: T126428
Change-Id: Ib19819373af70e10b0c750ffdb06156764b7fa3d
This should mean that where possible the timestamp for
the category membership change will be equal to that of
the time of the revision that caused the change.
The IDs still may have space between them.
Bug: T126048
Change-Id: Ia270451ccb02f2fca979ccb1fcefa5bdb4a96722
When non-existent categories appear in the changelist
they wont get marked reddue to the use of
Linker::linkKnown.
Bug: T126854
Change-Id: I3dc9746c0fe55e81ffd2df1c04ade6950efcc020
$unpatrolled is unused in the method, so make it optional,
and then uses of it can be removed.
I realize it would do no harm to remove it completely, even
if a few (2 that I know of) extensions still pass the variable
to the method, but think this is nicer way.
Change-Id: Idbe6f00e9eb40db6a28de76fca0aea7c17b75656
Change tags to apply to an edit can now be passed directly to the
WikiPage::doEditContent function. They are then passed to the
RecentChange::notifyNew/Edit functions where tagging is made
after the recent change is saved. This ensures that other callers
of doEditContent will not run into the same issue as T100248.
ApiRollback is fixed in this way.
In addition, we'll have to pass tags in this way for core tagging
of edits (I2e48bd458fc8d7c289f04dc276f9287516e0b987), and this makes
it possible to merge the arrays of tags and call ChangeTags::addTags
only once.
Change-Id: I829960c7a33b70464065839d7504d7529dfd0b72
Using IContextSource avoids the use of $wgLang and wfMessage which make
use of global $wgTtle.
Add IContextSource as parameter to ChangeTags::formatSummaryRow to avoid
globals. Define an IContextSource instance in all functions which
reference ChangeTags::formatSummaryRow and pass it in ChangeTags::formatSummaryRow
function call.
Also make the default value of IContextSource $context as null in
parameter, to avoid breaking changes for old callers in extensions.
Document default null value of IContextSource and add a @note to prefer
IContextSource over null value.
Remove trailing whitespace, and make code order according to parameter
order.
Bug: T105648
Change-Id: Ib54a6a96b73f6cd8fcdf8e520db2448a1e811cfa
This allows to patrol file uploads, both new files and new file
versions, from the description page, provided $wgUseFilePatrol
is set to true. Special:NewFiles can be filtered to hide patrolled
files.
Bug: T11501
Change-Id: If71af58719a4461f12d125455b7bef07164525ca
Deprecated since 1.22 and not used in any extension
hosted in Wikimedia git (and afaik elsewhere).
Change-Id: I0974ba80b7ab21b056d7f16e936b5c564b562e6d
Rewrite a chunky HTML string concatenation party as Mustache template
rendering. This decouples the view from the controller.
Bug: T120921
Change-Id: I3217b80168f89e7b91dbc33a7053865ad3408615
This provides a mechanism to associate a revision id to an action.
For example in core, it makes sense for moves and uploads, which both
generate null revisions (also protections, but it isn't interesting if one
has patrolling in mind).
Crucially, in that case an unpatrolled status is allowed for the RC item.
So if the performer of the action is not autopatrolled, it will be displayed
as unpatrolled, and if the performer is autopatrolled, it will record an
autopatrol action.
When one associates a rev id to a type of action, one should also implement
a mechanism to patrol said action, since getting the diff for the associated
revision is not user friendly and works only if RC patrol is enabled.
This is done for uploads in If71af58719a4461f12d125455b7bef07164525ca (with
a new file patrol) and for moves in Ie0fa417feaf930c096b69521fc54d57aecd6cd51
(within RC patrol).
Extensions might possess other such actions that could benefit from patrolling.
Bug: T122089
Change-Id: I694424eca32b69e277f89d4c15183870983d0993
Move ad-hoc variables under an array, in preparation for merging with
RC flags implemented by extensions.
Bug: T120921
Change-Id: I5dd91ba5e5ed36785d9fbf01673defcd227c8b01
* Recursive link updates no longer mention an category changes.
It's hard to avoid either duplicate mentioning of changes or
confusing explicit and automatic category changes.
* LinksUpdate no longer handles this logic, but rather WikiPage
decides to spawn this update when needed in doEditUpdates().
* Fix race conditions with calculating category deltas. Do not
rely on the link tables for the read used to determine these
writes, as they may be out-of-date due to slave lag. Using the
master would still not be good enough since that would assume
FIFO and serialized job execution, which is not garaunteed.
Use the parser output of the relevant revisions to determine
the RC rows. If 3 users quickly edit a page's categories, the
old way could misattribute who actually changed what.
* Make sure RC rows are inserted in an order that matches that
of the corresponding revisions.
* Better avoid mentioning time-based (parser functions) category
changes so they don't get attributed to the next editor.
* Also wait for slaves between RC row insertions if there where
many category changes (it theory it could well over 10K rows).
* Using a separate job better separates concerns as LinksUpdate
should not have to care about recent changes updates.
* Added more docs to $wgRCWatchCategoryMembership.
Bug: T95501
Change-Id: I5863e7d7483a4fd1fa633597af66a0088ace4c68
This makes the delete() calls work properly for all DCs.
Also, using the message cache was fairly bizzare.
Change-Id: Idec7fa47811e982ba89bb8fbbd9565a26585e77f
This is part of a chain that reverts:
e412ff5ecc.
NOTE:
- The feature is disabled by default
- User settings default to hiding changes
- T109707 Touching a file on wikisource adds and
removes it from a category... Even when page
has no changes.... WTF? See linked issue,
marked as stalled with a possible way forward
for this patch.
@see https://gerrit.wikimedia.org/r/#/c/235467/
Changes since version 1:
- T109604 - Page names in comment are no longer
url encoded / have _'s
- T109638 & T110338 - Reserved username now used
when we can't determine a username for the change
(we could perhaps set the user and id to be blank
in the RC table, but who knows what this might do)
- T109688 - History links are now disabled in RC....
(could be fine for the introduction and worked
on more in the future)
- Categorization changes are now always patrolled
- Touching on T109672 in this change emails will never
be sent regarding categorization changes. (this
can of course be changed in a followup)
- Added $wgRCWatchCategoryMembership defaulting to true
for enabling / disabling the feature
- T109700 - for cases when no revision was retrieved
for a category change set the bot flag to true.
This means all changes caused by parser functions
& Lua will be marked as bot, as will changes that
cant find their revision due to slave lag..
Bug: T9148
Bug: T109604
Bug: T109638
Bug: T109688
Bug: T109700
Bug: T110338
Bug: T110340
Change-Id: I51c2c1254de862f24a26ef9dbbf027c6c83e9063
This method is implemented in all sub classes.
Not having this method here looks odd as
ChangesList::newFromContext returns a ChangesList
and parts of the code base then call recentChangesLine
on that object which may not exist..
In the future we might even have some interface here?
Change-Id: Iad00a956862c078a2bcaf3ef0602abcf3fedb7d2
Using the following command line, I have found doc comments (and
a wfDeprecated() call) mentioning "1.26" when they should mention
"1.27" instead, which I have fixed manually:
git diff -M REL1_26 | grep --color=always -C 10 -iP \
'^\+.*\D1\.26(\D|$)' | aha > oldver.html
Follows-up these commits:
* 047b60b96d
* 169b7b98b5
* 25a44aa3e4
* 2fb2a3f14b
* 3f1e9fa268 [1]
* 8c84af70b6
* c0cb80beac
* d04a92a551
* d3b85592ea
[1] Release notes moved in I195dd1cf.
Because a release note stating that the UserRights hook is deprecated
was added in 37062a0c0d (before the branch cut), this commit does not
change the Hooks::run call that had been changed in 21206c8fbe.
Change-Id: I5a427f003e7e3b4559fe377bcdfdca466a570708
This adds optional flags to Revision::getRecentChange
And uses them in CategoryMembershipChange
Bug: T109700
Change-Id: I197ebccf1f62cdcb03ce4daa2527b973e495236c
Not only doesn't it make sense to render this, getLogText has
some assumptions about this array, and an empty array just didn't
work.
Bug: T112738
Change-Id: Ibdc0c4ed15449883a91a3292bfa174ff84116be0
It was possible to abort the rendering of all block lines, but
the block would still be rendered (with nothing inside). It
would also render a "x changes" link, even though that "x" is
no longer correct.
This had been reverted in adba11dfe3,
but has now been fixed up.
Change-Id: Ic5d15e56bc2f46fa6aa8c9375f3cafeb13e1ea9c
Caused errors when there were two new topics created on the
same Flow board on the same day.
BadMethodCallException from line 496 of
/srv/mediawiki/php-1.26wmf23/includes/changes/EnhancedChangesList.php:
Call to a member function getTitle() on a non-object (NULL)
{"exception_id":"58b04b8c"}
This reverts commit b30417048b.
Bug: T112738
Change-Id: Ib404d78eaf1aa9ac7ea34516183bcc9956efc515
$this->recentChangesFlags() was being called on the data twice, so the
second time it was processing the string, causing the flags go missing.
Follows-up 94f153db6a.
Bug: T105237
Change-Id: I04465d0317eecc1c12e47bc9a74f11986eba99a4
It was possible to abort the rendering of all block lines, but
the block would still be rendered (with nothing inside). It
would also render a "x changes" link, even though that "x" is
no longer correct.
Change-Id: I94ae68e80461dcfbf328683522ea6cb58c6c5753
Introduce a new hook to allow (single) block-level entries.
Very similar to EnhancedChangesListModifyLineData.
Bug: T104399
Change-Id: I6b4715277d44e5f09d7a230b33e956676aeab1c2
Gives extensions a chance to modify the data used to
build each enhanced recent change 'inner' lines
(as opposed to the header lines).
Bug: T102021
Change-Id: Ia8a796fb9621db14d6574e66a4572e1fdf3bad03
wfSuppressWarnings() and wfRestoreWarnings() were split out into a
separate library. All usages in core were replaced with the new
functions, and the wf* global functions are marked as deprecated.
Additionally, some uses of @ were replaced due to composer's autoloader
being loaded even earlier.
Ie1234f8c12693408de9b94bf6f84480a90bd4f8e adds the library to
mediawiki/vendor.
Bug: T100923
Change-Id: I5c35079a0a656180852be0ae6b1262d40f6534c4
* Make MachineReadableRCFeedFormatter use it
* Some unit tests
* Also fixed some line-too-long warnings in RecentChange.php
Change-Id: I443d14f5d4cdac0945cb9c03608d55745bbb865b
* These updates add to editing time and can be done
after sending the HTTP response for performance
* Also improved the active users job insertion logic
Change-Id: I5b25217c4f08db7fa9a05eac046283f02d45865e
Enhanced RC generates these "(3 changes | history)" links for
every block of grouped recentchanges. That changes-link links
to a diff page.
For Flow, that is all wrong: we have different ids (not integers),
on a different page (&curid=&oldid=&diff= means nothing). Even
the concept of a "diff" page seems wrong here for us - a new post
is not part of some document that can be diffed.
In short: we'll want to generate a different link, and we'll need
a hook to let us change them.
Meanwhile also split the code that generates those links into a
separate method.
Bug: T72513
Change-Id: Ib32fb9552b80f9581d89b3b47da6e5d32e3d84a3
The current formatting does not display these
external changes very well (e.g. doesn't distinguish
between local and foreign wiki user or whatnot).
Unless there is better handling or integration of these,
also with the option of hiding or showing, it is best
to simply exclude these from the feed.
This brings the ChangesFeed inline with default
behavior of Special:RecentChanges and Watchlist.
Bug: T88254
Change-Id: I956a3c392e9f163478b9f6994bde4c0be8932163
* Also added a selectFieldValues helper method to the DB classes
since this use case keeps coming up.
Change-Id: I62cdbb497dc2c8fe4758e756d13688b85165e869
Seems stupid omission. Title has one. Why do I need to think how
to determine how to users objects point to the same user. Allows
more expressive code.
Also fixes a bug in multiple places where users "0" and "00" were
considered equal.
Change-Id: I682392e564b332b77ab489f2ad394fa2d28098a5
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
The former is by far the most common.
Skipped:
* resources/lib/jquery.ui/jquery.ui.datepicker.js
* resources/src/mediawiki.special/mediawiki.special.upload.js
Change-Id: I73c93797e745128ba703e4865080c36784caa474
Not used in core, the only usage outside removed in Ieb5bb6f9.
Also removed two now-unused files from skins/common/.
Bug: 69675
Change-Id: Ia0e9fc2af25af903db085f2a05c04dcd9aff213e
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I7b65fe04db431342cc58b469dc48f41a50c4e891
- Removed spaces after not operator (!)
- Removed spaces inside array index
- use tab as indent instead of spaces
- Add newline at end of file
- Removed spaces after casts
Change-Id: I9ba17c4385fcb43d38998d45f89cf42952bc791b
RC_MOVE and RC_MOVE_OVER_REDIRECT are obsolete, since at least 2006.
So it is considered safe to remove.
Bug: 63755
Change-Id: I0f17c4d164585a48fb9f0d40b90a7d3b975c7ab8
Like we do in ApiQueryRecentChanges as well, expose the named
rc.type property, not the internal integer constants.
Change-Id: I89a948eee999032bb2e42cc23345affa879afb42
The user can now specify which feeds to send to in
RecentChange::notifyFeeds if they don't want to use
$wgRCFeeds.
Additionally, the 'formatter' in $wgRCFeeds can now be an object
rather than just a class name.
Change-Id: Ibfdffc17a934e35223887c123331795563102752
Prior parseRCType was an private method in includes/api/ApiQueryRecentChanges and also
duplicated in includes/api/ApiQueryWatchList. This method has been made static and moved
to includes/changes/RecentChange.php.
Bug: 65071
Change-Id: Ic911fbcf9411c782685c4f956f8522051f2517f0
This change adds redirect=no in the URL of redirect entries in the RecentChanges or in the Watchlist.
Entries which are not redirects will not be affected.
Some typos in documentation were also fixed.
Bug: 890
Change-Id: I79593811d92b2f57abd742c8ba9e66769d8bc9b7
Variants included 'in <version>', 'as of <version>' and just the
version number.
Some @deprecated annotations do not have the version number at all,
I want to hunt them down separately.
Change-Id: I8208c6097098f4735d4f51bc42254675f1f27f6d
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: I8c9f30128b46086064326708a4878228ba459447
Changed RecentChange::notifyRCFeeds() to allow more
filter options than just omit_bots. In order to mirror
the on-wiki Special:RecentChanges UI, the options
omit_anon, omit_user, omit_minor, omit_patrolled were added,
which omits anonymous, registered, minor, and patrolled
edits, respectively.
Bug: 60941
Change-Id: I716c741f1f7d42b6506a97e9a5733beac23ac16c
An extension hooking into recent changes may need to load additional
data that did not fit into the recentchanges table. This hook gives
extensions an opportunity to see the full result prior to rendering
and batch load where approprite rather than loading piecemeal during
the render process.
This is implemented as an optional method called by the ChangesList
consumer, since the ChangesList never sees the full result set. Hook
implementers must be able to work regardless of the hook being called,
they just have the oportunity to be more efficient when it is called.
Change-Id: If74ae600ffba949364dd381dd3d466cbbaa27286
This reverts commit 01798c3813.
The patch set changed a RecentChanges interface used in at least the
extension CleanChanges so that it was generating a lot of warnings.
Additional parameters to existing methods that are used elsewhere
should have defaults to not break backward compatibility.
Change-Id: I1851e23e186ba7aaeb001ba212e56888657a3ae0
An extension hooking into recent changes may need to load additional
data that did not fit into the recentchanges table. This hook gives
revisions an opportunity to see the full result prior to rendering
and batch load where approprite rather than loading piecemeal during
the render process.
Change-Id: I28d4e41437e485e518f2a23b6da00cdc430a8c23
There are differences, like grouping, between watchlist and
normal rendering that hook recipients need to know about.
This exposes if the setWatchlistDivs method has been called
which currently happens immediatly after instantiation in
SpecialWatchlist
Change-Id: Ibc06c6d9b878cad3f5da92cfbe3f650ad3f63efa
This is akin to $wgSkipSkin/$wgSkipSkins. It is quite plausible for a wiki
to have more than one self prefix (e.g. enwiki has w: en: wikipedia: and
maybe others).
Some recent changes code seems to use $wgLocalInterwiki for quite unclear
purposes:
- I removed the line using $wgLocalInterwiki from the RecentChange
class, as the 'lang' field of $mExtra is not used anywhere in core code.
Extensions may use it, but it would seem more appropriate for them to
use something like $wgDBname (or indeed to consult $wgLocalInterwikis
directly) if they need to identify a particular wiki.
- In the IRC formatter, the first prefix in the array is used (if set).
Appropriate documentation is added to DefaultSettings.php.
Related to bug 954 comment 3.
Bug: 954
Bug: 955
Change-Id: I9dbb566385b464402c5e78510b95dd2ffb4d9489
This makes it more feasible for Wikibase, Flow, etc. to support
enhanced changes format, and allow better support for the rc_source
column in the future.
Change-Id: I873f6b86007000a94337f0c963df4bf8fec5b715
The OldChangesListRecentChangesLine hook can skip rendering of
a particular rc line. If that line was the one that would have
added a new date header then no date header is output. The
pushes checking for a new date header until after we know a
line will be output so none of the headers get lost.
Change-Id: I64ddd99c6af0b562802504b803563cf77fc2eb28
The legend is not part of the ChangesList itself, but a part of the
ChangesListSpecialPage; move around modules and calls appropriately.
Followup to I02f2ced4.
Change-Id: I2c8922135404aab1960158cee06e2d8d07a1ace7
