Core: Add "About This Forum" page with statistics, description, admins/mods, etc.

[tobyzerner]

In the left side of the footer, like in esoTalk: show the number of discussions, posts, users, online users.

Need to track this information somewhere (a new "statistics" table?) — counting the tables is flawed, because (1) I believe it requires a full table scan for InnoDB and (2) it would include invisible/private/deketed discussions/posts.

[franzliedke]

Maybe store it in the cache? We'd have to ensure it's transaction-safe, though...

[franzliedke]

Should this be an extension?

[tobyzerner]

Hmm yes you're right I think it should be a default extension.

Cache should work. The way I'm thinking of implementing it is similar to FlarumTags\HandlersTagMetadataUpdater: on certain events, +1 or -1 the numbers (rather than recalculating them completely). Storing in cache would allow them to be recalculated by clearing the cache in case they got out of sync.

[tobyzerner]

We want to add an "About This Forum" page, probably linked to from the discussion list sidebar, that contains:

• The forum description
• Statistics: total posts, discussions, users
• A list of admins and users in other select groups

What needs to be done:

• Design this page.
• Add a setting to groups to determine whether or not a group and its members will be displayed on this page.
• Add relevant information to the /forum API endpoint. Statistics should be cached somehow.
• Build the page.

[dcsjapan]

The proposed option to hide specific groups (#845) may impact this part:

A list of admins and users in other select groups

Perhaps it would be possible to combine the two into one "Display options" dropdown, the options being:

• Hide group badge
• Show group badge
• Include members on "About this forum" page

It's possible that an admin might want to hide the group badge but include the group on the "About this forum" page ... but probably rather unlikely.

[BartVB]

I only did a cursory look but it seems like the cache in Flarum can be local. I.e. specific to a webserver (for example the APC usercache) as opposed to distributed (like Redis/Memcache).

If that's the case then storing this in the cache is not going to work properly.
Another problem is that calculating this can become quite problematic on a cache clear if you have a large database. A simple select count(*) from posts takes 40 seconds on my DB with 100MM posts on a pretty beefy server.

Imagine what happens when you have 1000 users online and the cache is cleared 😱

[dav-is]

@BartVB The caching system in Flarum is minimal right now. They need to improve that before this issue is implemented.

[franzliedke]

@tobscure Do you plan to integrate this into https://github.com/flarum/flarum-ext-statistics?

[tobyzerner]

No, flarum-ext-statistics is purely for admins.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum.
In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!

[BartVB]

An 'About' page in some form still seems to be a good idea.

[luceos]

I disagree, I think this is a responsibility of 3rd parties. Keeping core and the amount of core extensions minimal will be beneficial to us, piling yet another core extension onto our to do -- and users waiting for it to be developed -- will only bite us in the long run.

Vote for close @flarum/core please review/comment.

[franzliedke]

Can't disagree. :wink: It's easy to revive if we ever find the time or the request comes up very often.