Ghost: New {{@stats}} helper

[ErisDS]

Problem:

Members sites want to be able to upsell visitors and incentivise them to upgrade. Right now there's no easy way to do that other than writing some hardcoded copy.

Appetite: 1 day

Solution

Add a new data helper called {{@stats}} and add the following properties:

@stats.total_members
@stats.total_posts
@stats.total_members_posts
@stats.total_paid_members_posts
@stats.total_tags
@stats.total_authors

This allows people to write dynamic upsells like "Subscribe now and get access to our archive of {{@stats.total_members_posts}} posts written by {{@stats.total_authors}} across {{@stats.total_tags}} categories."

Bonus: There's also a desire to be able to write something like "over the last x years" e.g.

@stats.site_age timestamp of oldest post published date (can be formatted with date helper)
@stats.site_age_years years since oldest post published date

[stromfeldt]

For differentiation purposes and usage with a public-facing Chartmogul graphic (similar to the one on ghost.org/about), would it be possible to also add the properties @stats.total_free_members and @stats.total_paid_members, to go along with what might then be @stats.total_all_members?

[naz]

@peterzimon would be good to get your opinion on proposal above above. It makes sense for me product wise, but having to calculate these stats would need more research into performance implications, specially for sites with large audiences.

[naz]

@peterzimon another question around the "bonus" field @stats.site_age. In case there are no posts, this situation can happen when admin removes all posts and is most likely temporary, what value should we take as a blog's start date? There are few ideas outlined in this comment. Personally think it's ok to take "current date" as the start date as it represents - fresh blog with no posts and is pretty easy to solve technically. Not sure we need a sophisticated mechanism to determine a true start date for an edge case like this :thinking:

[matthanley]

@naz agreed that we should include free/paid members in the implementation for this.

having to calculate these stats would need more research into performance implications

Stats on members will be much easier once we have a status flag on the member model (@allouis has been working on the implementation for this), so suggest we defer implementation of this element until that work has been completed.

Personally think it's ok to take "current date" as the start date

Agreed 👍

[kevinansfield]

In terms of cache-clearing, do we output cache clear headers on member signups and subscription changes? If not then the member stats could end up being static between content/settings changes.