Is it possible to determine a member’s tier in the handlebars helpers?
E.g. on a pricing page like …
… I’d like to be able to display a ‘Your current tier’ kind of message, to encourage upgrading (and enable downgrading, too, I guess).
Is it possible to determine a member’s tier in the handlebars helpers?
E.g. on a pricing page like …
… I’d like to be able to display a ‘Your current tier’ kind of message, to encourage upgrading (and enable downgrading, too, I guess).
This part of tiers is still WIP! It would actually be super useful if you could write out and share the theme code you’d expect/want to work
I’d be looking for something along the lines of
{{#if @member}}
{{#has tier="basic"}}
{{else tier="pro"}}
{{else tier="gold"}}
{{/has}}
{{/if}}
Yep, that’s exactly the kind of thing that’d be the most helpful, I think — based on the tier slug … but that means we would probably need to see (and edit, too, most likely) the tier slug somewhere, somehow.
As a small side-note, I’ve always wanted to be able to make a more dynamic check with a ‘has’, i.e. comparing two dynamic strings, something along the lines of:
{{#has @member.tier.slug=product.slug}}
… do some stuff here
{{/has}}
… so, e.g., I can check things in a {{#foreach @product}}
loop, but that’d mean a new helper, right. And I’ve never managed to work out if/how to do that on a Ghost Pro install.
Saying this, partly, coz I can see the product_id in a {{log @member}}
at @member.subscriptions.0.price.product.product_id
… but can’t really use that without being able to do a dynamic string comparison, I think.
I’m currently accomplishing this via some very hacky handlebars-assisted javascript and CSS, but having this built into the helpers would be tremendously useful.
Both @ForestCityBuild and @joesb suggestions would be nice, but just being able to get the member’s actual tier slug or nickname using {{plan.slug}}
and/or {{plan.nickname}}
would be good. Currently nickname
still only returns monthly
or yearly
as near as I can determine. I’m currently having to use {{plan.amount}} (and some hard-coded javascript) to determine which tier they’re in.
Ooh, I’m wondering if the new {{match}}
helper released in 4.19.0 is able to do some of this string comparison stuff I’m eager to be able to do.
The commit notes look super-interesting:
- The match helper allows for basic equals and not equals comparisons,
Example:
{{match title "=" "Getting Started"}}
{{match slug "!=" "welcome"}}
- There's a lot more functionality we want to add here, so that it ends up being a replacement for {{#has}}
- However, this first iteration is already useful, especially in the context of custom theme settings
- Therefore we are adding it early, and will document it along with custom theme settings when that goes GA very soon
Will be trying that out today!
Lord have mercy! It works as I’d hoped!
Fantastic!
The current long route round to get the member’s tier is something like @member.subscriptions.0.price.product.product_id
, so then …
{{#foreach @products as |product|}}
{{#match @member.subscriptions.0.price.product.product_id "=" product.id}}
{{log product.slug}}
{{/match}}
{{/foreach}}
… and that dumps the right product slug (i.e. the product slug for the product that matches the tier to which the user is subscribed) to the log — yay!
Brilliant.
Since @member.subscriptions
is an array and I guess members could be subscribed to multiple tiers, you could easily loop over the subscription array to match to the product.
Where that log is supposed to log? Console or logfile didn’t show anything.
I’m trying to manage the subscription without showing all the plans in order to guide the tribe step by step because our categories needs some time to engage to the next one.
We are learning and teaching.
Looking for the same - is there any chance to get the tier of the current logged in user?
@histhff, I /think/ the code posted above still works. Did you try it? Note that handlebars works in the theme, but not in code injection.
(Very belated to matenauta’s question: if you start Ghost with ghost run -D
, that causes very spammy debugging logs to write to the terminal window. It doesn’t cause any logging in the browser.)