Problems with email and Stripe

Memberships & subscriptions
1

Ghost 3.9

I am experiencing the following problems:

  • If an unregistered user tries to log in from the form signin, and the “Allow free member signup” option is disabled, the green “check your e-mail” notification should not appear as the e-mail will never arrive. An “email address is not registered” message should come out.

  • If I try to register, with the “Allow free member signup” option activated, I get an email like this: "https://domain.it/%7B%7B@site.url%7D%7D/signup/?action=checkout"
    The url is broken, the variable shouldn’t be there.

  • Why if I am not registered, can I register both using the login and registration forms? Can’t unify them?

  • I installed ghost locally with the ghost install local command (and imported production db)
    In the configuration file, the url is "http://localhost:2368/"
    In the “Members” screen, the parameter “email settings” is noreply@localhost
    The email that arrives to me has the domain name in the link "https://domain.it/?token=...", where does the domain name come from?

2

I’ve tried answering your queries below:

  • If the “Allow free member signup” option is disabled then you should wrap the form in the @member helper as an if statement so only existing members can use it, as shown here: https://ghost.org/docs/members/content-visibility/#member
  • I think you might have your domain entered incorrectly. The string you have there has @site.url in it, which is the template variable for the site url
  • Member forms have a fallback system which you can read up more about here: https://ghost.org/docs/members/signup-signin-forms/#extending-forms
  • Again, I think you have your domain setup not quite right. If you’re working locally you don’t actually need to setup a domain, localhost:2368 is your working local site domain
3

I have to start from the third point to be clearer. Based on this documentation, forms do the same thing. Both send either the registration or login email based on whether I’m already a registered user or a new user. Theoretically, I can use only one form for any action. So it seems useless to use them both, I think.

Considering the previous point, it is right that the green notification is displayed, because the email arrives both if I am registered and if I am not. Of course if I am already connected, I use the @member helper to hide the forms.

Could you tell me where to look for the value to be changed? I searched throughout the project including the core for the domain name, but nothing was found. I think it’s some database level setting.

I installed Ghost locally again, without importing the backup json, and the url is generated correctly. If I import the json, I get the error.

Same answer as above. I have not set any url by installing ghost locally with the recommended command. I think it’s a problem with imported json.

4

Maybe it’s worth checking the json before you import it, and try to locate the @site.url?

5

You’re right, I’m not home now. In the evening I check and update you.

1 Like
6

About forms and notifications:

  • Both forms send the email if they are registered or if they are not registered. But I can’t hide both forms with the helper member, otherwise even someone who is a member but not logged in would not see the form.
    So a form will always be visible. Now if you disable “Allow free member signup” and a user does not exist in the database try to log in, the notification of success will appear, but the email will never reach him.
    The same problem you can see on Rediverge, I tried to log in with a new email gmail, the success notification comes out but the email does not reach me, as it has disabled “Allow free member signup” i thknk.

I hope I explained myself on this point.

About @site.url:

  • Not a database problem, I made a clean new installation and I have no problems, I imported the database and I have no problems, I imported my theme (with accounts.hbs signup.hbs and signin.hbs by default) and I get the problem. I think at this point it’s a router problem:
routes:
  /signup/: members\signup
  /signin/: members\signin
  /account/: members\account
  /:
    data: page.home
    template: home

collections:
  /:
    permalink: /{slug}/
    template: index

taxonomies:
  tag: /tag/{slug}/
  author: /author/{slug}/
7

This is expected behaviour. Please note that the Members feature is still in beta, so areas like this are still in development. The use case for disabling free sign up is if you have your Ghost site connected to something like Patreon or Mailchimp. Themes like Lyra are designed for free sign ups, and would require additional work to work with a more specific use case.

One possible reason that your routes file is causing issues is that you’re defining two pieces of data for the index page, in both the routes definition and collections definition. You might want to remove the one in routes and use a get helper instead

8

Ok, I understand that Member feature is still under development, if I can’t solve it myself I will also start using the free subscription.

About the router, can you suggest how to solve it? I didn’t make any big changes, I just created a new homepage and inserted this rule into the router.

To solve the reported problem, how do I proceed?

Thank you

9

Try removing these 3 lines from the routes file and testing your emails again:

10

After a sickening number of attempts and changes I understood what the problem is, it is not the router.
The problem is the site.url variable in these lines of code, in the default.hbs file:

	if (action == 'signup') {
		window.location = '{{@site.url}}/signup/?action=checkout';
	}

At least for 1 year I have always had the footer scripts, including the new ones from the members section, in a footer_scripts.js file, which I called in a footer_scripts.hbs file like this:

<script src="{{asset "js/footer_scripts.js"}}"></script>

and in the default.hbs file:

  {{> "notifications"}}

  {{> "footer_scripts"}}

  {{{block "scripts"}}}

  {{ghost_foot}}

I’m sure the order is correct, it always worked, now no longer, I directly inculcated the footer scripts of the default.hbs file.
It made me lose my mind, I would like to understand why these happen now.

11

I solved the above problem, although I did not understand why it happens.

Finally I also found the wrong domain problem in the checkout link. The problem is in the link of the stripe webhooks.

How and when is this webhook generated? is it automatic? wrong domain name is set

Cattura
Cattura1125×397 23.2 KB

12

Looks like the issue is that you’re trying to use Handlebars templating inside a .js file. You can only use templating, e.g. {{@site.url}} inside .hbs files. Best solution would be to inline that piece of JavaScript in your footer_scripts.hbs file, Or place a function call in there with the {{@site.url}} as a variable. This will probably fix your Stripe issue too.

13

Is the stripe weebook created automatically by Ghost when you enter the stripe APIs?

14

I’m not sure what you’re asking here? All of Ghost’s webhook events are listed here:

There is member signup, edited and deleted. For Stripe related events you’ll want to check the Stripe webhook events:

15

I mean this, it was automatically generated by Ghost & Stripe, right?
I did not manually enter this link and these actions in the Stripe dashboard

I ask you why, even if we solved the problem, I wanted to get to understand all the steps.