`mw-datatable` has already been in use and should be the main class
for styling TablePager tables.
`mw-datatable` also includes the equivalent padding of former
`.TablePager th` & `td`, therefore removing it.
Bug: T214218
Change-Id: I2025b2ede87035e15f0280a6fe5efddec174bcca
Some are needed to make better results with phan in extensions
For example:
File CentralNoticeCampaignLogPager.php line 12:
Assigning array{0:20,1:50,2:100} to property but
\CentralNoticeCampaignLogPager->mLimitsShown is
array{0:20,1:50,2:100,3:250,4:500}
[PhanTypeMismatchProperty]
With "@var int[]" the type is correct
Change-Id: Ic68910bf17344852ad11fcc000a47891e4bf0179
Rename $descending variable in doQuery() to $order, along with the
$descending argument to reallyDoQuery() and buildQueryInfo(). Use
new IndexPager::QUERY_* constants for checking and inverting such
values. Fix the comments so that they do not imply the opposite of
what is true anymore.
For compatibility, the constants are boolean values such that any
subclass defining reallyDoQuery()/buildQueryInfo() can use that
argument the same way as before.
Change-Id: I912d3678c755c25463a2fadbec6888f3a87d4215
Reducing buttons to `frameless` buttons and reposition icons of
next and last page button to be symmetrically harmonious.
Bug: T214128
Change-Id: I1c0a621d7699b5fadc2559abdf6003a0db0aabae
I'm intentionally only touching these protected properties and nothing
else, because I believe these are uncontroversial. They should be protected
according to modern SOLID standards, and actually are declared as
protected in the base class. What this patch effectively does is documenting
this fact, but it does not change anything.
Change-Id: I625307b58bd419c4a72e9842b2b46c08ed9b4f8e
This affects at least Special:Log and Special:Contributions.
The setTimezone() call does not actually change the offset used for
database lookup, because getTimestamp() returns a Unix timestamp,
which by definition does not include timezone information.
We don't actually want to do anything with timezones here. Whether
we like it or not, these date selectors have always used UTC dates.
Follow-up to I8c2cd398d7c7ac68a8f46ee94cb9e7c6beed5694.
Change-Id: Ia034017af5b37da3aa4889d5b7680c8be423126e
(This change is best tested with Special:Log before changes from
38756eae4, since it seems the $mDay/$mMonth/$mYear values are not
directly used anywhere in core after that.)
The setTimezone() call did not actually change the offset used for
database lookup, because getTimestamp() returns a Unix timestamp,
which by definition does not include timezone information.
It did change the offset used for year/month/day fields in the
interface, but it changed it in the wrong direction: instead of
assuming the date is in local timezone and converting to UTC, it
assumed the date is in UTC and converted it to local timezone.
We don't actually want to do anything with timezones here. For better
or worse, the date selectors for pagers have always used UTC dates.
The timezone code was only introduced relatively recently in 53fa809a.
What we really want for the interface is to display the previous
date, relative to the database offset. The interface asks the user
to select the month/date up to which to display things (such as
"May 2018 (and earlier)"), but the database queries use strict
comparison (such as `log_timestamp < '20180601000000'`), so the
database offset is calculated to the next date after selected one.
The incorrect timezone calculation accidentally did so, but only if
the wiki timezone had a negative offset relative to the UTC. If the
wiki was using UTC or a timezone with positive offset, the correction
was not applied, causing the selected date in the interface to move
one day forward from the date that was set.
Bug: T171110
Change-Id: I8c2cd398d7c7ac68a8f46ee94cb9e7c6beed5694
Directly use the UTF-8 encoding of the 'NO-BREAK SPACE' (U+00A0) instead of
the HTML/XML entities   or   or .
With the UTF-8 character the generated HTML is shorter and better to read.
Also change the special value for the label in HTMLForm from   to
U+00A0 but also support   for backward compability.
Bug: T154300
Change-Id: I882599ac1120789bb4e524c4394870680caca4f4
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
It's deprecated in PHP 7.2, may as well replace it now.
I note that, contrary to claims at
https://wiki.php.net/rfc/deprecations_php_7_2#each, none of our uses
were trivially replaceable with foreach.
* wfArrayDiff2_cmp() is processing two arrays by value in parallel.
* MagicWordArray::parseMatch() is doing something funky with the data
structure returned by preg_match().
* HashRing was using it like "nextKey()", replaced with calls to key()
and next().
* FormatMetadata and IndexPager were both using it as a shorter way to
get both key() and current() for the first element in the array. I
suppose a foreach(){ break; } would do the same, but that's confusing.
Bug: T174354
Change-Id: I36169a04c764fdf1bfd6603395111c6fe0aae5eb
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
It has the effect of breaking pagination entirely when a date range
is set. Special:Contributions doesn't break this way because it has
its own code clearing start/end when offset is set, but Special:Newfiles
does break.
Change-Id: Ie9b26a4b54ebc608035c942b5bdc6ee26b82bc1e
New abstract class RangeChronologicalPager to provide shared date range
filtering capability (with unit tests)
I18n msgs to use as common labels for date range inputs
Expose some ReverseChronologicalParser::getDateCond logic so we can
convert year/month date filters to datestamp date filters
Bug: T120733
Change-Id: I65fdc00368f406f5fa2492600e95e07ce442c165
Use HTTPS instead of HTTP where the HTTP link is a redirect to the HTTPS link.
Also update some defect links.
Change-Id: Ic3a5eac910d098ed5c2a21e9f47c9b6ee06b2643
Database::timestamp() intentionally lets errors bubble up, so catch
invalid user-provided timestamps in
ReverseChronologicalPage::getDateCond(), and avoid using an offset in
that case.
Bug: T149257
Change-Id: Ida85eb44b66e8a0166e7f68a101ff094e04b1c8e
Apparently some calls to getDateCond() expect it to not set an offset.
Also, removing some of the new tests that no longer work since they
don't pass all the required parameters. (Before I8e684f06, the year
and month were both required parameters.)
Bug: T145597
Change-Id: I3a90b3da48e49ec9723b7100a7d92146154f74e3
* ReverseChronologicalPager::getDateCond now accepts a day parameter
* Make year parameter of getDateCond optional (current year used)
* Make month parameter of getDateCond optional (end of year used)
* Tests for ReverseChronologicalPager::getDateCond
Depends-On: I587f1f4402ba2964ff23c0d4b06e41accbe05c10
Bug: T120733
Change-Id: I8e684f067d792b07137341d63cd2e54a18c51a7d
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
When searching for a year/month with the year/month selector on
Special:Contributions or action=history the given time should be treated
as wiki time and therefore needs adjust to UTC before search in the
Database.
This has no effect on wikis with UTC like enwiki, but for example on
dewiki with an offset from 1hour/2hour.
Change-Id: Iccd41d19a360827b9c80b66582ca0daa7ed7576c
- Added newline at end of file
- Removed double spaces/newlines
- Added space after if/function and parentheses/brackets
- Removed space before comma/cast
- Fixed indent of some lines
Change-Id: I29867ffdffdfb7d2b56997e9393497c7dc12f7d3
I've spent several hours looking at related code and I still can't
remember which direction is 'true' and which is 'false'.
Change-Id: I58694f7a0892c986e7215f59b56b014cece8d40d
Redrawn the images with SVG versions.
Intentionally did not preserve the value of the 'alt' attribute of the old
images, it doesn't seem very useful to me. Instead, added 'title'
attributes on the sort links that describe their action. This should be
more useful than the old version for both visual and aural mediums.
Bug: 69277
Change-Id: Ibaec75e81d3eb8338d911ac84d91570047f475f5
These values for the "rel" attribute (aliases for 'begin' and 'end',
respectively) have only appeared as proposals for the HTML4
specification, but were then explicitly dropped.
The story of them and more links are available on
<http://microformats.org/wiki/existing-rel-values> (search for
'first', 'last', 'begin', 'end'). The gist is that they were
intentionally dropped and therefore should not be used.
Change-Id: I33afd1364bf9ccf79c11a2a050ad0c4ff52c447a
