Hi,
I’m using Headline theme.
I have enabled commenting for all members but I have setup the blog to be accessible by everyone, even for non-members. So when a non-member visits the blog and clicks to read an article, the comment section is locked with some CTA asking the person to login/signup.
The problem here is that upon clicking the button, it appends the signin page url behind the current page i.e. https://blog.ghost.io/ghost/#/article-name → https://blog.ghost.io/ghost/#/article-name/signin instead of https://blog.ghost.io/ghost/#/signin.
How can I configure it such that it redirects non-members to signin page instead?
Those URLs don’t look right.
It should be appending /#/portal/signin to the article, so you’d expect to go from /<yourarticleslug>/ to /<yourarticleslug>/#/portal/signin
If that’s what’s happening and you just got the URLs wrong, then that’s the expected behavior. The portal pops up as an overlay on any existing page. There’s not a configuration option for comments to have it open a separate signin page. (Since headline doesn’t have a separate signin page anyway, I feel like I’m missing something here…)
1 Like
Right, I think some of the updated settings were only updated just a moment ago. Now I’m seeing the behaviour as you’ve described.
One more question - when I try to sign in, it tells me that there’s no account registered under the email that I keyed in in the form input. I’ve tried both emails that we’re already using for admin & contributor roles. Is there something else that I need to update?
Thank you!
That’s a Ghost ‘quirk’! Staff users (admin, contributor, author, editor) log in at /ghost to access the dashboard. Members (website visitors who’ve signed up on your site) log in to the main (non-admin/non-dashboard) site using the Portal button (usually) to get a magic link. Staff users don’t automatically have member accounts. From /ghost, if you click the members link, you can add a member account for yourself, then either visit the homepage and log in using the button like any other user, or if you don’t want to fuss with email, click the gear icon on your own member page and choose the impersonation link.
got it!
that kind of makes it tricky for my use case. we’re trying to create a blog where we invite some users to join as contributors to write on our blog & let signed-in members interact with the post. if my understanding is correct, this means that if a user wishes to post an article & also be able to comment on other writers’ posts/reply comments, they would have to be added as members. also, members would then have to sign up again as contributor, right?
Right. Staff users and website members are separate accounts.
There’s no method for anyone to sign up as a contributor, whether or not they’re a website member. You add them to Ghost from the dashboard (/ghost > settings (gear icon) > staff), and then they receive an email inviting them to join the site as a contributor.
So just to confirm - currently if a user wants to both post & comment, they have to be invited as contributor & also need to create their own member account themselves. There’s no automated way or a workaround where they can be a member while being a contributor?
There’s not a webhook for adding a user (contributor), so that’s going to make automation in that direction tough. You could use a webhook from adding a member (or perhaps a change like the member gets a new label?) to trigger adding a contributor. And then they could upload It might be possible in Zapier or Make or another automation platform.
Security concerns: I’m not crazy about this idea, and you should be aware that if you allow people to sign up as members, a little fussing with the signup form would allow them to get any label they wanted. So now you’ve got unvetted contributors. While contributors can’t publish, they can make mischief, like filling your drafts with garbage (want to delete 10k new drafts?), filling your dropdown tags list with obscenities, uploading images (rude or huge), etc.
It isn’t something built into Ghost.
If this is something you really need, you could stand up a form that takes an email address, password (for the contributor account), and name, and some automation on form submission that creates the accounts, since there are endpoints for both member and staff user creation. But this strikes me as a lot of fuss to avoid a small amount of work. 