Fri, Sep 21
Tue, Sep 18
Mon, Sep 17
Thu, Sep 13
@Gilles Apologies for the delay... Is it ok with you if this goes on next week's deployment train? (Also replied to your e-mail... Apologies again!!!)
Wed, Sep 12
Hi! Some notes here:
- As far as I can tell, by requesting that CentralNotice administrators refrain from creating or editing banners with translatable messages, we're preventing any affectation of cluster performance due to the specific problem described in this bug (incredibly slow save times for banners with translatable messages).
- Nonetheless, we do need a careful review of CentralNotice-Translate interaction, to improve performance and code sanity in general, which includes this specific bug.
- The option suggested by @Nikerabbit is the immediate action we're pursuing, though that should also not be deployed until we're clear about its impact on all bits and pieces of this complex system.
- @Krenair, indeed we wouldn't disable CN-Translate integration without looking carefully at the impact, and, also, that doesn't look like the right option at this point :)
Tue, Sep 11
@jcrespo @Nikerabbit Thanks!!! I think we could potentially look at disabling CentralNotice-Translate integration as a measure of last resort. (Note that we have asked CentralNotice administrators to not use translatable messages in banners for now, also.)
Mon, Sep 10
Just to note, though the general slow-to-save banner issue is important, that problem, as far as I can tell, has a different cause from very-very-slow-to-save problem with banners containing translatable messages...
Hi! Looked at this quickly:
- This does not seem to be affecting banner displays, as far as I can see.
- There are a lot of Database warnings related to translatable messages.
Thu, Sep 6
Tested the update script locally--works so far!
Wed, Sep 5
So, the SQL to create the testing database should just be whatever's in sql/create_tables.sql in FRUEC.
Hi! Thanks much for finding this cruft!!!
Tue, Sep 4
Updated SQL to create the testing database, as per
Mon, Sep 3
Sun, Sep 2
Sat, Sep 1
Fri, Aug 31
Thu, Aug 30
Wed, Aug 29
Tue, Aug 28
@matmarex @Tgr Interesting! Well, if permission changes are pretty easy and not a risk to CentralNotice infrastructure ahead of the year-end fundraising campaigns, I'm ok with it!!! Moving CN pages out of the Mediawiki namespace is probably eventually a good idea (for previous discussions, see T33595 and this RFC). And, in general, the CentralNotice backend and administration interface need quite a lot of reworking--it has to be carefully planned and executed, though.
Mon, Aug 27
Hi! Just a few notes here:
- Inline JS is used quite a lot in CentralNotice banners, for both community and Fundraising campaigns. However, many campaigns don't really need it.
- The reason Meta Admins can edit CentralNotice banners is that banners are stored as Mediawiki namespace pages. So, anyone with the ability to edit interface messages (i.e. Admins) can edit banners.
It looks like there is tracking of all navigation to external sites with this. For example, when I clicked on "Donate Now", the following request was sent:
Fri, Aug 24
There's now (in review) some basic test data for both CentralNotice and LandingPage events. However, at least the CN data should be need to be more varied. Also, for CN, the filenames should be changed to match those currently used on the cluster. Thanks!!!
Aug 24 2018
Aug 22 2018
Aug 21 2018
Aug 20 2018
I think perhaps this is all done? (As per comment on merged-in task, the log files are getting written as needed, thx much!!!)
@Jgreen yeah looks great! Apologies for the delay in checking this out :) Thx much!!!!!
A first glance at the error logs shows a spike in "Banner message key" warnings during the first week in August. This would likely point to a problem with i18n caching. There's still a lot more digging to do, though... :)
Aug 17 2018
Aug 13 2018
Location of the log files to be consumed into the database in the new system: alnitak:/srv/banner_logs/2018/. (There's a lot in that directory... To find some, try: ls /srv/banner_logs/2018/ | grep -v beacon | tail -n 10
Fantastic, thanks @Pcoombe!!!
Aug 10 2018
Aug 9 2018
Aug 2 2018
@Pcoombe ok thanks that's an important detail!
Aug 1 2018
Jul 30 2018
Jul 26 2018
A few notes from discussions on IRC...
Part of this should be to update or remove and archive oudated documentation about DjangoBannerStats and other bits of the pipeline that have changed. Here are a few bits that I found (though there may well be more):