Changelog for 2015-09-26

Changes

• Added section to WoTManager translation guide about Import functionality.
• Removed ability for clans to manually reload members. Clan member changes are automatically loaded each hour, and whenever a clan member signs into the site, their clan data is automatically updated. There's no need to have this, and it can lead to race conditions (for join/leave events).
• Added a minimum combination check to Code Types, to prevent a random choices and random length combination that gives a very low number of combinations (because this can cause code creation to fail due to not enough combinations).
• Added Note of when automatic code creation occurs to the Code Settings tab.
• Added Delete link on Codes lists.
• Added slight fade to Code Action links on Attendance and Valid Public Codes pages.
• When creating a new Match Type, One Battle per Match now defaults to true as this setting produces more logical results, especially when paired with setting (or having it auto-determined via a replay) the Result for a Match.
• Added better error page for timeouts.
• Added better error page for Security Violations typically caused by having more than one tab open editing an item.
• Added better error page for File Not Found (for replay downloading).

Fixes

• Added check to hopefully prevent issues with duplicate join events and a single (invalid) leave event because created, seemingly due to short-term mismatches in data returned by different WG API methods.
• Fixed Twitter widget not loading due to CSP conflicts with changes to the way Twitter loads the widget.
• View code checking show (details) instead of edit permission for codes listing. Note this was purely an error in the client side display code and had no impact on security.
• Fixed attempting to use a lowercase Prefix that has already been taken causing an internal server error.
• Moved Features/Help images to Clan Tools (instead of using Imgur).

Backend Changes

• Removed unused libraries.
• Updated various libraries.
• Increased maximum concurrent request handlers.

Also, Friday morning I finished setting up the second server. However, there was a small but noticeable increase in latency (the actual delay appears to vary based on the size of the data returned). This is the expected result, due to the database connection now being remote which adds network latency, plus the (temporal) cost of encryption for that connection.

As such, given that the current server--once I fixed the backend scheduler clobbering it--appears to be more than capable of supporting the current load, I see no reason to degrade performance just because.