Indeed, that solved the immediate issue entirely: the bot's run went from 195m down to its expected 5m or so.

That said, I'd love to know why the plan switches too; there's an obvious inefficiency there even if it doesn't explain the odd discrepancy when the proxy is involved.

Ah, I had suspected it did not use an index, rather than just different ordering. But the most interesting question in my mind is: why is this happening only when going through the proxy and not when doing the queries directly on the DB behind it?

(Forgot to mention that those queries are being run on the frwikisource database)

I'm a bit surprised nobody searched Phab on the topic first given that T66115 is specifically about whether to include those properties.

I'll be working on changesets for the points above shortly.

In T483#2293454, @GWicke wrote:

All modern browsers support <link rel="stylesheet"> in the body

In T483#2289895, @GWicke wrote:

Adding the parsing team, as this would introduce page-global state, and also needs to work in Parsoid and VE.

@kaldari I've also been taking a look at how valuable the various search results are in practice, and with Google I am able to coalesce some of the searches together using operators; reducing the query count by 50% at the cost of a slight increase in false negative results* - if budget is the sole remaining issue that would lighten that load quite a bit.

@csteipp, template description updated - I think that's most/all of what you need? I don't expect the work involved to be extreme, the extension is pretty well self-contained and has few interactions with core.

@Jdforrester-WMF: What is next for this? Anything I can do to help things along?

In T483#2232623, @brion wrote:

If volunteers are +2'ing config updates and deploying them, I'm impressed. :)

In T125459#2221746, @Legoktm wrote:

Share or set up another proxy/IP...?

We don't run afoul of 2.7.11 (we provide the links themselves), but 2.7.7 kills us since we explicitly do filter.

I think the extension is at a point where that review makes sense.

In T483#2232314, @brion wrote:

Note that people do like to use templates outside the template NS, for user or project pages for instance. Not sure if we want to support that explicitly/implicitly/not at all, etc. :)

With the latest rounds of merges, the TemplateStyles extension appears to be in a reasonable state and implements the major substantive part of this RfC as discussed in Jerusalem.

What's left to do?

In T17075#2231789, @He7d3r wrote:

Only if you are going to require that for each book we make edits to add the same template to each page of the book

In T48580#2228508, @jayvdb wrote:

Is it safe to assume this feature will not suddenly become active and in use in production once code from this task is merged?

In T483#2223326, @Edokter wrote:

I think scoping to #mw-content-text should be enough. Any tempate appearing outside actual content is usually protected anyway.

In T48580#2214028, @Ankry wrote:

We are still waitng for Page namespace support which is the main editing namespace for most wikisources. Moreover, many new wikisourcians edit only in the Page namespace. The general trend is to have articles in main namespace automatically or semi-automatically generated basing on data from Index and Page namespaces. So having VE support in main namespace may be a nice feature, but mostly useless.

In T483#2218236, @Edokter wrote:

Actually, plenty of templates can appear outside 'content' space, such as edit notices. Those should be able to be styled. The risk of clashing CSS classes is pretty low anyway.

Adapting CSBot now.

In T483#2211010, @TheDJ wrote:

Right, found a quite important point... We are now scoping using:
mw-body-content it seems. But that is a skin specific class, amongst others not used by the mobile minerva skin.

We have #mw-content-text that contains all generated output for wikitext pages, but more importantly the classes mw-content-ltr and mw-content-rtl.

In T483#2210556, @Legoktm wrote:

In T483#2209954, @TheDJ wrote:

Tried using wikimarkup inside the style block, but that doesn't seem to work (and scary if it would..)

What if you used {{#tag:templatestyles}} so the wikitext is processed? I'm not sure how the extension is storing the actual styles though.

In T483#2209954, @TheDJ wrote:

Tried using wikimarkup inside the style block, but that doesn't seem to work (and scary if it would..)

In T483#2209954, @TheDJ wrote:

Some first practical experiences:
1: i quickly found a situation, where in lieu of inline styles, i'll have to use a unique (per parserrun) class or ID. we have no good options for this right now. For now, i'll keep using inline styles for those situations. (width specific to the image being transcluded)

Done. I added ParserFunctions and Scribunto, and reimported Template:Wide image recursively to make sure it worked.

In T483#2209633, @TheDJ wrote:

Coren, can you add parserfunctions extension to your experimental wiki ?
i'd like to test a few actual en.wiki templates, and almost all of those need parserfunctions and/or scribunto

The current WIP can be played with on an experimental wiki. The main page is an example of a transclusion of a style template.

@Krenair I believe it was, yes.

In T989#2188527, @Jdforrester-WMF wrote:

Note that, at least in the prototype for T483: RfC: Allow styling in templates in https://gerrit.wikimedia.org/r/#/c/282155/4/CSSParser.php, @coren wrote a manual RegEx instead of using a library validator/processor.

In T48580#2173976, @Jdforrester-WMF wrote:

Clarification: This will be for all Wikisources, not just frws. :-)

After some architecture discussion with @Brion and @Jdlrobson, we came up with a fairly good plan for which I'm going to do a first prototypical implementation.

In T123156#1957447, @Nemo_bis wrote:

I guess core could add another class that be the same on all subpages, like .page-Foo-subpage.

I have an opportunity to work on this while at the Hackathon; with luck I may be able to submit a changeset today.

Current status: we now have a proper design for Page namespace that is in progress but - as a first step - we now have usable mainspace editing with Visual Editor (including the transclusion tag). This is currently working on a test server, and is scheduled for the deployment train Tueseday, Apr 5 (and deployed on group 1 that inlcludes the Wikisources on Apr 6).

I'm not sure why you never received a reply, but it's very clear-cut. Indeed, there was at least one user whose access to labs was suspended because of that very reason.

I will be in Jerusalem, and will concentrate on coordinating work on this task while there (as well as hack on it myself).

I've created a variation on common's link trickery with JS for wikimania2017wiki (see related T122994) and it works pretty well; so having the links constructed in that way properly would help a great deal.

This occurs repeatedly on wikimania2017wiki, which uses language features heavily including translatable templates.

FWIW, excepting commons (for obvious reasons), most wikis where this feature would be desirable/necessary seem to me to be the smaller wikis and it's not immediately clear that the performance impact would be all that catastrophic if the caches did vary on a language selection cookie for them.

In T122675#1910377, @Krenair wrote:

Also, not an ops thing. This is about MediaWiki setup, so is expected to be handled by people in the deployer or restricted groups

In T122638#1909877, @valhallasw wrote:

which actually shows another interesting tidbit: thre's 20 seconds between restarts, but between 547749 and 9999897 there's a two minute gap.

In T122638#1909769, @valhallasw wrote:

What is unclear to me at this point is what commands were issued when and by whom. Was this a cronjob gone wrong? The tool owners haven't logged in to any tools-bastion recently.

In T122638#1909554, @yuvipanda wrote:

I'm also wondering if more up-to-date backups of the job db would help.

FWIW, from the DB transaction logs, the master seems to have valiantly struggled for about 90 minutes before it finally went down (and I expect the survival was made harder by the simultaneous LDAP and NFS issues). It might be worthwhile to add something to monitor really unusual growth of the BDB and alert.

VE is desired, but as the wiki is very young and the number of non "powerusers" is going to be very low, there is no emergency to deploy outside the normal cycle. Most of what is going to be added to that wiki in the short term is going to be imports, stylesheets, and templates.

The only way around this that I can think of is for the post-exit script to first check that the kv that is actually there really /is/ the one it expects to delete before going ahead and deleting it.

We just missed a window, and tomorrow is a "Friday", I think. How does Dec 28 sound to you?

@Krenair: That's what I asked @demon to okay; we want to be able to do press releases in January so the more time to set the wiki up the better. :-)

In T122062#1896571, @Dzahn wrote:

do you want this -> T96564 for 2017 wiki as well or no?

Logo exists there: https://upload.wikimedia.org/wikipedia/commons/4/4a/Wikimania_Montreal_logo.png
Announcement allowing the switch being thrown pending only on James (F). :-)

I can tell you what the Labs side of things is: run maintain-replicas after the database exists to create the views. AFAIK, the prod side involves adding the database to the list that should be replicated, something which I think only Jaime currently knows the secret sauce for.

@Krenair: I hereby notify myself. :-) More seriously, that doc should probably be amended as I should no longer be a point of contact starting Jan 1.

May or may not be significant, but tools-proxy-01 has (partially) live userland at least insofar as nginx continues accepting connection and proxying.