r81554 MediaWiki - Code Review archive

Repository:MediaWiki
Revision:r81553‎ | r81554 | r81555 >
Date:02:16, 5 February 2011
Author:bawolff
Status:ok (Comments)
Tags:
Comment:
(follow up r79706 to address CR comments) Simplify some of the logic in LinksUpdate.php

Make it so that by default, the parser consdiers categories to have a sortkey of "" unless
specified otherwise. Before, the parser said the sortkey was the page name, and then in LinksUpdate
we reset the sortkey (prefix) to "" if it was the same as the page name.

This way, the parser uniformly outputs the sortkey prefix, instead of a mix between prefix or pagename.

It should be noted, this changes the output of api.php?action=parse for categories that do not have
a sortkey.
Modified paths:
  • /trunk/phase3/includes/LinksUpdate.php (modified) (history)
  • /trunk/phase3/includes/parser/Parser.php (modified) (history)

Diff [purge]

Index: trunk/phase3/includes/parser/Parser.php
@@ -5072,15 +5072,19 @@
50735073
50745074 /**
50755075 * Accessor for $mDefaultSort
5076 - * Will use the title/prefixed title if none is set
 5076+ * Will use the empty string if none is set.
50775077 *
 5078+ * This value is treated as a prefix, so the
 5079+ * empty string is equivalent to sorting by
 5080+ * page name.
 5081+ *
50785082 * @return string
50795083 */
50805084 public function getDefaultSort() {
50815085 if ( $this->mDefaultSort !== false ) {
50825086 return $this->mDefaultSort;
50835087 } else {
5084 - return $this->mTitle->getCategorySortkey();
 5088+ return '';
50855089 }
50865090 }
50875091
Index: trunk/phase3/includes/LinksUpdate.php
@@ -72,7 +72,10 @@
7373 # it truncated by DB, and then doesn't get
7474 # matched when comparing existing vs current
7575 # categories, causing bug 25254.
76 - $sortkey = substr( $sortkey, 0, 255 );
 76+ # Also. substr behaves weird when given "".
 77+ if ( $sortkey !== '' ) {
 78+ $sortkey = substr( $sortkey, 0, 255 );
 79+ }
7780 }
7881
7982 $this->mRecursive = $recursive;
@@ -435,7 +438,7 @@
436439 global $wgContLang, $wgCategoryCollation;
437440 $diffs = array_diff_assoc( $this->mCategories, $existing );
438441 $arr = array();
439 - foreach ( $diffs as $name => $sortkey ) {
 442+ foreach ( $diffs as $name => $prefix ) {
440443 $nt = Title::makeTitleSafe( NS_CATEGORY, $name );
441444 $wgContLang->findVariantLink( $name, $nt, true );
442445
@@ -447,23 +450,12 @@
448451 $type = 'page';
449452 }
450453
451 - # TODO: This is kind of wrong, because someone might set a sort
452 - # key prefix that's the same as the default sortkey for the
453 - # title. This should be fixed by refactoring code to replace
454 - # $sortkey in this array by a prefix, but it's basically harmless
455 - # (Title::moveTo() has had the same issue for a long time).
456 - if ( $this->mTitle->getCategorySortkey() == $sortkey ) {
457 - $prefix = '';
458 - $sortkey = Collation::singleton()->getSortKey( $sortkey );
459 - } else {
460 - # Treat custom sortkeys as a prefix, so that if multiple
461 - # things are forced to sort as '*' or something, they'll
462 - # sort properly in the category rather than in page_id
463 - # order or such.
464 - $prefix = $sortkey;
465 - $sortkey = Collation::singleton()->getSortKey(
466 - $this->mTitle->getCategorySortkey( $prefix ) );
467 - }
 454+ # Treat custom sortkeys as a prefix, so that if multiple
 455+ # things are forced to sort as '*' or something, they'll
 456+ # sort properly in the category rather than in page_id
 457+ # order or such.
 458+ $sortkey = Collation::singleton()->getSortKey(
 459+ $this->mTitle->getCategorySortkey( $prefix ) );
468460
469461 $arr[] = array(
470462 'cl_from' => $this->mId,
@@ -699,11 +691,7 @@
700692 array( 'cl_from' => $this->mId ), __METHOD__, $this->mOptions );
701693 $arr = array();
702694 foreach ( $res as $row ) {
703 - if ( $row->cl_sortkey_prefix !== '' ) {
704 - $arr[$row->cl_to] = $row->cl_sortkey_prefix;
705 - } else {
706 - $arr[$row->cl_to] = $this->mTitle->getCategorySortkey();
707 - }
 695+ $arr[$row->cl_to] = $row->cl_sortkey_prefix;
708696 }
709697 return $arr;
710698 }

Follow-up revisions

RevisionCommit summaryAuthorDate
r816541.17: MFT r78372, r79324, r80841, r81430, r81488, r81496, r81554, r81561, r81...catrope22:28, 7 February 2011
r81671Back out the changes which depend on the categorylinks schema change, so that...tstarling00:57, 8 February 2011

Past revisions this follows-up on

RevisionCommit summaryAuthorDate
r79706(Bug 25254) cl_timestamp gets updated on null edit where it shouldn't....bawolff02:42, 6 January 2011

Comments

#Comment by Bawolff (talk | contribs)   02:19, 5 February 2011

Tagging as 1.17 since its a follow-up to the other one. But its really only a cosmetic change, so it doesn't matter if its in 1.17

Status & tagging log