This is a feature of Gerrit. From what I remember yellow/blue is when you rebase a change sometimes the file was changed in another change. So that’s what these colours show.

I *think* this may be fixed from gerrit 3.6. In gerrit 3.6 we redesigned how we did syntax highlighting. Still using highlight.js but syntax highlighting should be more reliable.

https://gerrit-review.googlesource.com/c/gerrit/+/313982/7 Was merged on 3.4 and I’ve backported https://gerrit-review.googlesource.com/c/gerrit/+/336094 to 3.4

Fixed with https://gerrit-review.googlesource.com/c/gerrit/+/313983 and https://gerrit-review.googlesource.com/c/gerrit/+/313982/7.

we don't have git:// enabled for gerrit, we have had ECDSA and Ed25519 for years now and we can disable the ssh algorithms we don't want using the gerrit config.

You can have super submodules configured see https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/+/3487cb2fe882b42d4e181c3c6ed013691fe80e4f/project.config#13

In T296898#7542718, @Reedy wrote:

BadMethodCallException: Sessions are disabled for this entry point

Which entry point would that be?

I’m not sure, that’s what I saw in the log (didn’t specify which end point though)

In T40010#7353052, @AntiCompositeNumber wrote:

In T40010#7352995, @Paladox wrote:

librsvg repo haas been disabled and doesn't support node v12+ (https://github.com/2gis/node-rsvg/tree/0.7.0). I see we could switch to puppeteer. E.g. https://github.com/etienne-martin/svg-to-img as a replacement?

(Debian bullseye uses nodejs 12.22.5).

Even the repo it says to use hasn't received an update since 2019...

We don't use that. Thumbor is written in Python (2, we know), but we shell out to rsvg-convert anyway. Librsvg is written mostly in Rust now, but the version currently in production is still C. Upstream is https://gitlab.gnome.org/GNOME/librsvg, packaged as https://packages.debian.org/stretch/librsvg2-bin.

librsvg repo haas been disabled and doesn't support node v12+ (https://github.com/2gis/node-rsvg/tree/0.7.0). I see we could switch to puppeteer. E.g. https://github.com/etienne-martin/svg-to-img as a replacement?

In T288792#7340317, @Majavah wrote:

In T288792#7340314, @Paladox wrote:

I think it just checks each wikis edit table (which isn't future realistic). What if you had 20,000 wikis or a million? Very expensive to run.

Core already caches edit counts in the user table. CentralAuth reads it from there, but it takes a while as it needs to read it from every individual wiki.

In T288792#7340274, @Majavah wrote:

In T288792#7340009, @Paladox wrote:

Could also improve the performance for Special:CentralAuth. Some ideas are creating a job to do the edit stat updates rather then doing it all on page load.

Which stat counters? I'd rather not duplicate practically all displayed per-wiki user data to the CA database.

I presume the reason why logins are slow is the same reason that page is slow?

Probably different reasons.

Could also improve the performance for Special:CentralAuth. Some ideas are creating a job to do the edit stat updates rather then doing it all on page load.

Upstream fix merged and I've backported it to https://gerrit-review.googlesource.com/c/plugins/codemirror-editor/+/314364 which has been merged.

In T288035#7265744, @Paladox wrote:

Change is merged. Backported to 3.3 here https://gerrit-review.googlesource.com/c/gerrit/+/314022

Change is merged. Backported to 3.3 here https://gerrit-review.googlesource.com/c/gerrit/+/314022

Made this fix: https://gerrit-review.googlesource.com/c/gerrit/+/313982/4

Gerrit 3.3 uses highlight.js 10.7. Looks like the newer HEREdoc support was added here https://github.com/highlightjs/highlight.js/commit/2a65144dfe92bc2eca0af913b29be56a97e66eae#diff-b056c5a26741799f5d40c82d9bfff3d9975a8b63bdb5955cf5e30b3059042bdd (included from 10.2)

@hashar back ported the fix here https://gerrit-review.googlesource.com/c/gerrit/+/313689

Seems this works now? At least I don't get the error.

Resolved in the gerrit 3.3 update done by @hashar

Missing several of the default plugins too that is listed on https://github.com/GerritCodeReview/gerrit/tree/master/plugins

https://gerrit.wikimedia.org/r/admin/plugins doesn't look like the download plugin is installed? Neither is codemirror-editor. CC @hashar

Fixed.

Upstream rejected back porting that change. We will have to wait for gerrit 3.5 for the fix.

Change merged, back ported here https://gerrit-review.googlesource.com/c/gerrit/+/311045

Change merged, back ported it to https://gerrit-review.googlesource.com/c/gerrit/+/311043

Fixed with https://gerrit-review.googlesource.com/c/gerrit/+/310664

Seems this is now fixed https://issues.apache.org/jira/browse/SSHD-1141?focusedCommentId=17317087&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17317087

Backported the change here: https://gerrit-review.googlesource.com/c/gerrit/+/310683

Ok, I know how it was fixed upstream though I'm not sure if that change can be back ported.

Fixed with https://gerrit-review.googlesource.com/c/gerrit/+/310663

This seems fixed at least on gerrit master... I'm not sure what change fixed it tho.

It works and has for a while. Closing as resolved.

https://gerrit.wikimedia.org/r/admin/repos/mediawiki/extensions/MsUpload,access Shows it has push rules. Should be as simple as removing that rule to revoke direct pushing.

I think that we use java 11 now?

Oh! That's because of wgLinkTitlesFirstOnly.

In T222413#6931966, @edwardspec wrote:

Slots can still be accessed via RenderedRevision object:

public static function onMultiContentSave( $renderedRevision, $user, $summary, $flags, $hookStatus ) {
    $slots = $renderedRevision->getRevision()->getSlots();

In T222413#5695446, @edwardspec wrote:

See also T205982. If/when MultiContentSave hook is merged (https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/467308/), it will be possible to use the following:

public static function onMultiContentSave( $title, $user, $slots, $summary, $flags, $status ) {
    $slots->setContent( 'main', ContentHandler::makeContent( "Another text", $title ) );

@Dzahn I've fixed the api with https://github.com/miraheze/WikiDiscover/commit/d69574d21636a9fe29fa69ea693460940f5f992a

I sent them a follow up email and they replied with:

Found it... I was looking at the wrong database.

some how manually running it worked.

Yeh, I checked the db and the schema it shows is:

"Web host or proxy. Contact cvt{{@}}miraheze.org if affected.: (Likely web host with a company name like Triple T Internet Company Limited, a Pakkret, Nonthaburi, Thailand-based concern.) Used by nefarious crosswiki spambot accounts for crosswiki spamming (200+ in past two months)" the full thing it tried to insert.

In T270923#6714071, @Reedy wrote:

Pretty sure you've not deployed a schema change - T231170: Alter globalblocking tables to allow longer comments brought it up to 767 chars

URL: "https://test2.miraheze.org/w/rest.php/test2.miraheze.org/v3/transform/wikitext/to/html/Topic%3AVz5uwxnb5dt80i8u"

Seems to affect Flow only, works with VE.

though I guess its disabled for a reason, so I think restarting gerrit is the only way.

Need to enable https://github.com/GerritCodeReview/gerrit/blob/774100cf7e3b28af0087f77baf83b0da9c715977/java/com/google/gerrit/server/plugins/PluginLoader.java#L119 apparently

@Dzahn Actually you could see if reloading the plugin works (which doesn't require downtime).

Gerrit needs a restart I think for that to take effect.

Fix is available at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/649910/12