In the special pages containing changes list, adding the following
CSS classes to revision rows:
- mw-changeslist-date
- mw-changeslist-title
- mw-changeslist-separator (matching the dots, ". .")
This enhancement has been implemented to the following special pages:
- [[Special:Contributions]]
- [[Special:DeletedContributions]]
- [[Special:RecentChanges]]
- [[Special:Watchlist]]
It's also implemented on pages history.
Change-Id: I2385ef21d9aed4bdbe4971bfcfa28efaf058e7dd
Also replaced two $this->getUser() calls with $user since that variable is
already in that method.
Change-Id: Iccda9f44a9cf6d3187895a8b6111bc62dca1e811
This allows both methods to not always rely on global object, but also to use the local context when possible.
Change-Id: Id10f55ed9b18c889afd8d9937d9f35acb376cce4
Each line on the watchlist and on the history pages should have a
specific class to indicate the "updated since my last visit" status,
to allow for more comprehensive styling than is possible with individual
elements embedded within the line.
Also some cleanup: turn the $classes variable in the enhanced watchlist
code path into an array, and change the bolding of titles in the
watchlist from <strong> tags to styling via CSS.
Change-Id: I90bc95db061274d4de782578a4e91f954481adfd
The history feed for a non-existing page fetched revisions for
rev_page=0. Even though there should be none in the database,
there obviously are, which means such feeds are full of spurious
entries.
Added an existence check, fetchRevisions now returns an empty result
for non-existent pages, which is (and has always been) handled
gracefully in feed() by emitting feedEmpty().
Change-Id: Iae892d900239030bc249c829faecb1bcb3672db2
The portion of the history line after the character difference is now
added immediately before running PageHistoryLineEnding hooks, allowing
the omission of the ' . . ' separator if it would not actually separate
anything but rather remain at the line's end.
Patchset2: Added corresponding release note.
Change-Id: If6458bedb7492b15ece14f5eebbb697b93905a44
Regression in 1.19 found and fixed by Umherirrender
With MediaWiki 1.19 the history page was changed from showing the
size to showing the diff and giving the size in the tooltip.
But now the first item in the history has no information about it size.
* Follows-up r108341, r108370
* Doesn't remove it, server will still handle them properly (as provided by r57415) when JavaScript is off. This commit adds a progressive enhancement when possible so that submit will go to either of these:
* title= & diff= & oldid=
* action=revisiondelete & ids[..]=
instead of one of these
* action=historysubmit & title= & diff= & oldid= & ids[..]=
* action=historysubmit & revisiondelete=1 & ids[..]= diff= & oldid=
(removing redundant parameters and parameters from the other submission-type that don't belong in that url)
* Also re-adding support for action= revisiondelete in the query, as it was originally. Due to this hack it appears that support for the original action name (which is still returned as "revisiondelete" from MediaWiki::getAction() ) was removed or never existed in that place of the code at all. Fixed now.
* Don't build $s as well as $this->buttons for re-use later in getEndBody(), simply use it in both cases.
* Adding a css class for compareselectedversions button just like there is for the revisiondelete button
This construction never looked cool, but looks like this fix is not the right way, so reverting it.
This form is used for two purposes:
-- Submitting diff/oldid to (implied) action=view
-- Submitting ids-array to action=revisiondelete
That makes it complicated. Also for IE6/IE7 compatibility, there is no way to do this from the HTML itself (i.e. using <input type="submit" name="action" value="revisiondelete"> would work but leaves no option to have a custom i18n label. and <button type="submit" name="action" value="revisiondelete">I18N LABEL</button> works but IE7 submits "I18N LABEL" as value for "action" instead of "revision delete".
Will re-fix bug 33587 in a few minutes with a "progressive-enhancement" solution from the front-end instead.
* Not needed, and not used. Is internally converted to "view" as much as possible.
* Fixes bug 33587
* See also https://bugzilla.wikimedia.org/show_bug.cgi?id=25800#c6
* Other diff links from MediaWiki don't do this either
* PermissionsError now calls OutputPage::showPermissionsErrorPage() to display the error (this is needed to make the item above work correctly)
* Removed the override of the HTML title in OutputPage::showPermissionsErrorPage() so that it shows "Permission errors - Sitename" instead of simply "Permission errors" for consistency with the other things
* Pass the error array returned by Title::getUserPermissionsErrors() to PermissionsError where available
* Converted direct calls to OutputPage::showPermissionsErrorPage() to throw an PermissionsError error instead
* Added 'action-rollback' message that will be displayed when accessing action=rollback without sufficient rights
* Changed getRestriction() in subclasses of Action to return null when they previously returned 'read' so that user rights can be check with Title::getUserPermissionsErrors()
* Reordered checks to do first user rights, then block (if needed) and finally read only (also if needed) so that users don't think the error is temporary when they both don't have right and the database is locked
* Use local context instead of global variables
* Removed obsolete aliases PageHistory and PageHistoryPager; no longer used
* Made Action::getContext() and related methods public for the call in HistoryPager's constructor and also for consistency with other classes
* Removed obsolete aliases PageHistory and PageHistoryPager; unused
* Maintained backward compatibility with HistoryPage; extensions using it will still work
* Use local context instead of global variables
* Removed calls to OutputPage::setPageTitleActionText() and OutputPage::setSyndicated(), the first one does nothing and the second one is overriden by the setFeedAppendQuery() call just below
* Call Linker methods statically
* Fixed bug where feedEmpty() was not called on empty history since casting a ResultWrapper object to boolean always returns true even when there's no row
