Updated mediawiki/extensions
Project: mediawiki/extensions/ArticleFeedbackv5  0e49024de4b168a860fd518c25efdf9eabbbd173

(bug 46797) There's an inconsistency in the feedback page view and the permalink view; it looks like the feedback page view is not up-to-date

After changing data (e.g. moderating feedback to "resolved"), some caches (e.g. cache for entries in the "unreviewed" and "resolved" filters) are purged.
After being purged, the following hit would perform a new query, fetch the updated data, and cache them again.

At times, the follow-up requests seems to happen before the DB slaves catch up; in which case incorrect, outdated, data is cached for an hour.

It looks like LoadBalancer already attempts to let slaves catch up to the master (for a short timeout, that is) and if that timeout is surpassed (= slave is lagging) a flag is set: mLaggedSlaveMode.
Given that it is possible to check if we're reading from a lagging slave, I can now also tell exactly when it's allowed to cache data (= not when it's lagged)

Oh; also, in theory (it's not the case in the current code), I can pass a certaim $wiki as parameter to getLB. This then got saved in a property, but if I were to call getLB() with another $wiki argument, it would re-use that existing connection (which was for another $wiki). I also fixed this.

Bug: 46797
Change-Id: I5653fa1bbdbec474ae91e281fdf4381f00db3975
Updated mediawiki/extensions
Project: mediawiki/extensions/MobileFrontend  215a728a213906a96636c75c38cfd8de5554c2d2

Story 394: Show CTA on nearby when no photo

Default when no page image to show a camera image to
tempt people to upload photos

This completes story 394

Change-Id: I7588246bbdaa90be221d7cb531373eb5b1233bf2