So I think the only outstanding question is about revision_id, and whether we get the information we want when

Good point; I've not forgotten about those.

This should be solved by the move to Miraheze.

The outcomes of this investigation have been added to the other tickets.

Okay, it's now restoring to the staging DB (daily). We'll get emailed any stderr output.

Merged and staging site updated. Ready for QA.

Done. PR: https://github.com/wikimedia/grantmetrics/pull/120

PR merged, and the staging site updated. I'm sure there's still room for discussion! :) And anyway, maybe we're going to move the participants editing into the event editing page (in T204009)? So this panel would be redone.

Merged date-formatting patch, and updated staging site. See what you think (note that you can change to 'US English' to get the old date format back).

Another point about the revision ID: we can only know the current revision ID (and then only for existing pages). We can't even know that it'll be the parent of the revision created upon save, can we? If there was another intervening but non-conflicting edit, then our edit would be a child of that one wouldn't it? Does that make using this for analysis harder? e.g. finding out if it was reverted.

Other schemas (e.g. CitationUsage) record revision ID, so I think it's fine (as long as we only keep it for 90 days; is that right?).

One thing we can do is increase the parameter-finding to avoid {{{#, because that's never the start of a valid parameter name.

The former logged warning is Intuition's fault; I've made this to fix it: https://github.com/Krinkle/intuition/pull/91

There are a few reoccurring errors in the logs, e.g.:

The backup report email will now be sent every day, listing the existing backups and their sizes.

Yeah, we've got masses of space to the left side. This is what it looks like without wrapping (with a machine translated Dutch label, because that's a long one):

After we finish the move to Miraheze, we can use MediaWiki-extensions-Cargo for making an event calendar.

Okay, it now keeps 30 days of dumps and doesn't use logrotate. I've updated the docs. Still to do:

• give developers an easy way to pull the latest backup into their local DB.
• mail the ~/backup.err file (which is the stderr output of the script) to maintainers (at the moment, all we'll get is "job submitted successfully").

I was hoping that using logrotate like this would work, because it handles keeping a set number of copies of the dump and deletes old ones when they drop off the end. However:

With JS we can have an embedded SVG that's modified on the fly as the user changes the labels.

In T203699#4564956, @Mooeypoo wrote:

I don't think that this feature is a must, but ULS is easy to integrate and exists with Wikimedia standards on it.

The first part of this (dumping the database daily to disk) is done. Documented here: https://wikitech.wikimedia.org/wiki/Tool:Grant_Metrics#Backups

Sometimes, the label might then be a bit long:

I think we could, as a fairly simple first step, append the locale name to the language list. Then it would still be sorted alphabetically, but it'd be more obvious how it's sorted (i.e. not many people are familiar with collation between alphabets) and would mean it'd put the same languages next to each other (e.g. gom-deva गोंयची कोंकणी and gom-latn Gõychi Konknni would be next to each other in the list.

The datepicker will be done as a separate patch (see my comments on the above PR for why).

Merged.

One final PR for this: https://github.com/wikimedia/grantmetrics/pull/113

Yeah, if multiple templates were inserted.

The description feature is working now.

PR ready for review: https://github.com/wikimedia/grantmetrics/pull/105

Merged.

I've updated the PR to make that whole lower area of the panel scrollable with a max hight of 400px.

Good point. I've left it in and added a slight hack to avoid pulling in an extra dependency on AliceDataFixtures (at least I think so... I might have been doing things wrong).

In T202768#4547007, @kaldari wrote:

I don't think there's much point in trying to make sure it works without JavaScript. The live SVG preview interface (which I would favor) will require JavaScript to manipulate the SVG (otherwise we have to do a round-trip for every edit and have the client reload the whole image).

One example of something that doesn't quite work as might initially be expected is setting the value of an OOUI date field.

In T202768#4546988, @aezell wrote:

I was thinking about this earlier today and it dawned on me that we already have all the work done for the OAuth bit in a Symfony stack. That's a nice plus in the Symfony column.

Another upgrade increment (to change the docroot): https://github.com/wikimedia/grantmetrics/pull/107

I think that the only reason we're using Alice is to make writing fixture data easier, i.e. it lives in Yaml files instead of us creating PHP code to construct the fixtures. Is that right @MusikAnimal? This perhaps is from when we had to have masses of Wikimedia data before we were running the tests against the live replica databases.

PR merged, and deployed to staging. Huzza for no Node on the server. :)

I've had a crack at a draft of a Wikimedia URL embedding plugin: https://wordpress.org/plugins/embed-wikimedia/

Yes, I played with putting the scroll on the panel body; it works well I think. I'm not sure how to fix the textarea and button though (and still have them scroll with the outer page).

Merged, and staging site updated.

I think the answer to the other part of this is that it's too hard to try to take into account edit conflicts, and that the log event emitted on save will just have to be taken with a pinch of salt.

PR: https://github.com/wikimedia/grantmetrics/pull/102

Production is back on 5.6.

@Legoktm yup, looks great! Thanks!

The vertical scrollbar takes up a bit of space at the side, so the 'remove' buttons have to come in a bit. Should this extra space still be shown when there's no need for the scrollbar? e.g.:

Is the Redis extension able to be enabled now that T200666 is resolved? Or is there more to it? (I'm happy to help, if someone points me in the right direction.)

This is passing now. I'm not sure if we want to introduce better selectors for some buttons etc. (I did for trash for instance, because it has no text); maybe for now it's okay?

@Yaron_Koren I'm still trying to track this down. Do you have any ideas of how to get confirmation-free purging to work?

I've updated production to PHP 7.2. A small issue with the cache not clearing properly (did it manually and all is okay now).

Production updated.

This one? https://tools.wmflabs.org/grantmetrics-test/programs/%EF%BF%BD%E2%9D%A4%EF%B8%8F_heartless

Did you input three of the same characters?

My PhpStorm doesn't seem to have an inspection for that. What's it called?

I know we didn't estimate this, but it had to be looked at as part of the Symfony 4 upgrade, so I carried on with it this morning and it's pretty much done.

So Assetic is not available for Symfony 4 (I thought it was, but was just discouraged), so we have to switch to Webpack first.

The above PR is ready for review.