Use wikiId in data instead of wfWikiId()

wfWikiId() always refers to the current wiki while the data
may be from other wiki.

Change-Id: Ic060eb7386adadac23d7a7fa533e351471df6f22
Localisation updates from https://translatewiki.net.

Change-Id: Iac0db6df2327413741bc9a2d6a979e126cefb112
Stop populating rc_cur_time

Per the bug report this column is due to be dropped in 1.24 and
is not used in queries in 1.23.

Change-Id: I87c970df5dbc4e3e239854381d29a5a05340ac16
Related: I48989aceec31019f0b6c98aaeafaf60e975244df
Bug: 40667
Merge "Stop populating rc_cur_time"
insert() should not alter the row value

This is a bug in current master

It converts alpha to binary, which is then saved to cache.  Only
alpha number should be saved in cache, test case:

1. purge cache.
2. post some new posts.
3. purge cache.
4. post some new posts.
5. the topic_list cache contains both alpha and binary values

Change-Id: Icfa4279c3e93b65eba6dc408a49247a566c7a7e7
Incorrect offset key position

The postion should start from 0, test case:

1. make a page with 3 topics.
2. change to load 2 topics per load
3. error will appear

See also gerrit 131911 for the cache bug in current master

Bug: 64938
Change-Id: Ic5da533279c6e58db9a9fa93ff491b4316cbd7f0
Merge "Incorrect offset key position"
Localisation updates from https://translatewiki.net.

Change-Id: Ie0a6c10ebae203752dd0eacef3bff8634605d68d
Add additional check before potentially array_merging non-array values

This was/is breaking https://integration.wikimedia.org/ci/job/mwext-Thanks-testextensions-master/129/consoleFull

Change-Id: If82521da4a16779aa36f5237952593fd8cdd81f6
Add Sorting to topic list based on last updated timestamp

The solution is based on what we discussed in the estimation meeting.
This is probably not the most optimal solution since the ordering list
is in one table while the ordering field is in another table

To test the result, use the following in findMulti() option:

array(
  'pager-dir' => 'rev',
  'sort' => 'workflow_last_update_timestamp',
  'order' => 'desc',
  'limit' => 100
)

Change-Id: I2cb045d199e3364e4da38fd196a42e06ed721735
Merge "Add Sorting to topic list based on last updated timestamp"
Drop table: flow_header_revision

Remove maintenance update to flow_header_revision as well. Since jenkins
creates flow table for unittest from scratch, it would cause error when
updating a non-existing table

Change-Id: I1af9d1bf5014f84a529de9ad017f14a813b79896
Merge "Use wikiId in data instead of wfWikiId()"
Localisation updates from https://translatewiki.net.

Change-Id: Iddd9ffd0b342c166220afaf1e368c12a68a3d3b8
Fix inability to reply

replyTo input field is read by JS to submit which post we're replying to

Change-Id: I7fed8c142f9618c5fd4e77b85a17162c18c56c99
Merge "Fix inability to reply"
Add FailCommitException to autoloader

Change-Id: I1a0c722203daaac27a18e8625388999b92090604
Merge "Add FailCommitException to autoloader"
Fix not being able to submit new topics

flow_definition contains a serialized UUID for discussion's definition_options.
If you've set up Flow a long time ago, that UUID will have been 128-bit.
Depending on when exactly you ran this, propery $hexValue may also be stored
(with an old 128-bit UUID hex representation)

When we merged to 88-bit UUIDs, we've added some B/C code to convert 128-bit
binary values to 88-bit binaries. The hex property was left untouched.

We've recently optimized UUID to not always convert from/to binary anymore,
unless when only needed. This caused $hexValue to be used to convert to
alphanumeric, instead of binary.
Binary was the only format with B/C code for 128-bit to 88-bit, not hex.
This resulted in a 128-bit alphanumeric value being returned.

When, in turn, using that value to find topic definitions (definition_id) in
order to submit a new topic, we failed :)

Change-Id: I65e8e51c5d854e40556c7376291762c98836c200
Merge "Fix not being able to submit new topics"