Issue: Forum integration questions

Oh and add to that, the big L for the avatar under species when the user has an avatar?

Fixed the missing sub-areas in the next release. Integrations were only showing sub-areas for the first integration on the page. This was due to reusing the same ID pool for sub-area integrations.

Also fixed the inconsistent avatar type in forum-list integrations. It appeared to be random, but was possibly related to whether the user was already listed elsewhere on the page.

With the counters, it does not appear to be a math bug since the numbers appear to also be wrong in your database. It is important to know that the counters are not counted on demand. They are incremented with +1/-1 as books, etc are added or deleted. If there is a bug, it involves a +1/-1 that should have happened, but did not happen, or possible +/- that were double-counted. Since the numbers are so far off, it would need to be a massive event (such as deleting 300 books at once, or moving 300 books to another area, which you would probably remember), or occurred gradually over time (a long period of time if the number is that far off). For a gradual counting problem, it could be that the bug was fixed but we didn't recount all the content at that time. So the question is whether the counter is correctly changing now. If you create a new book, does it +1; if you delete, does it -1?

After spending a bit looking at the code, I've confirmed that in a lot of cases, an extra +1 is added whenever a book/etc is edited.

This is now fixed in the next release. The upgrade script will perform a recount, and afterwards book edits will no longer be counted towards the total book count.

Ah, just tested myself and the counter was behaving for create and delete.

However when you delete the most recent article, the wiki integration node still shows a blank entry "created" as the most recently modified article which just links to the area front page

Fixed in the next release. This should only ever happen if you delete the 10 most recent updates in a node before that node can receive a new update. However, since 4.0.21, a node's update buffer size was incorrectly being kept much lower than 10, usually 1-2.

For content that is already showing the node's creation time as the last update, the buffer should refill gradually as new updates are made. Also, beginning in the next release, if the buffer is empty, we will use some shortcuts to try to guess a recent update (which might still fail or might not be the actual last update).