How to Disable Members Function?

I’m reverting back to 3.x This update has been a nightmare


I am not a lawyer, I am just concerned, but this is actually the point. I mentioned GDPR because it’s a topic I just don’t want to get involved with, because its quite confusing and I don’t want to do anything wrong.
When it comes to the member feature of Ghost, I don’t see a feature to handle a user requests which want their data to be handed out to them. So, before I am not feeling confident about my knowledge about GDPR, saving user data, doing (potentially) money transactions and not having a possibility to hand over those data to the user, I will not use a feature like this. And tbh, I simply do not have trust in the stability of the feature, but that’s another topic. Currently testing other CMS, which do not have any of that member stuff. There is just to much other stuff that bugs me with 4.0.


Depending on your interpretation of GDPR you’re not allowed to transfer personal data to third parties. But including an external script, you’re actually doing this. You somehow make the user access this resource and with that make him transmit his IP address (which is a personal date in GDPR) without giving him a chance to deny this. You cannot heal this by just stating this fact in your data protection policy, that’s too late, because the user’s personal data is already transmitted.

So, most importantly the script must be hosted locally.

And it would be nice to be able to disable the membership feature to not give the users a way to give you their data, because even if you don’t want their data, if you have it, you must comply with GDPR with all the strings attached.


Looks like the only way to disable autoloading of that portal script is to remove {{ghost_head}} from the default.hbs. But that will also disable all SEO functionality among other things. If this bug (and I consider force injecting an unneeded script on my site a bug) won’t be fixed, I will most likely just replace {{ghost_head}} in my theme with a custom header. I already tried it, and it sort of works, but Ghost throws a soft error at start up:

The usage of {{meta_description}} in the HTML head tag is no longer required because Ghost outputs this for you automatically in {{ghost_head}}.

…which is ironic :slight_smile:


I’m no GDPR expert but it’s not because a script is loaded from elsewhere that you necessarily needs to ask for consent and/or offer a way to disable it:

  • Are we sure personal, identifiable information are transmitted to the hosting service? If the answer is no, then it’s GDPR compliant, and you don’t need to ask for consent. See for an example doing precisely that.
  • You don’t need to offer an option to disable everything. You can argue that loading this script is necessary for your website to work – which is the case, even if you don’t use memberships, as it’s built in in Ghost and you don’t have control over it.

Also: GDPR covers a use case when you send users data to a third party for technical purposes, which is arguably what’s going here - if the js hosting service indeed collect personal data. In this case, and for what I understand, you don’t need to offer an option to disable it – asking for consent is enough.

So deep down, the only question that matters is what kind of personal, identifiable data the js hosting service collects. If the answer is “none”, then there’s no GDPR issue here!


asking for consent is enough …

When do you ask for consent? After the fact has already happened or before? How do you do this? And as I mentioned: Your IP address in combination with the time and date is considered personal information by German authorities, because it can be traced back to a person.

It needs to be informed consent and not consent and then inform. And how do you know that the CDN provider is not collecting data, even if it states that. How does the CDN provider pay for its bills? Probably not by letting the opportunity slip to sell your data.

You ask for consent the same way everybody does: with a banner/a modal.

IP address is considered a personal information not just in Germany, but by the GDPR in general. If no (full) IP adresses are collected, then it’s fine. I may also be the case that if the IP address is collected for technical purpose by a data vendor (aka a subcontractor), you only need to inform, not to ask for consent.

And regarding the CDN hosting service, if it says it doesn’t collect personal information but it actually does it, it’s a matter of breaking the law. It’s a criminal behavior and it goes far beyond GDPR compliance.

The technical reason so to say is: I use this software, it does the thing and I cannot change it? I would argue: then don’t use it.

Furthermore if you state: “[…] even if you don’t use memberships”, there is no technical reason from my point of view.

Or you could just block nginx to send calls to and still use the product.

More generally, there are plenty of GDPR guides over there to make sure wether loading this script is compliant or not, instead of relying on interpretations. And I don’t even mention checking data policy – because if it doesn’t collect any personal information, there is literally no reason to have this conversation anymore as the problem is solved.

Have a good day

1 Like

Can you please NOT post the same question all over the place in topics not related with the question you’re asking? Thanks.

According to the pinned topic, spam is forbidden: Welcome to the Ghost Community


Sorry @simardcasanova

Then where should I go for the solution?

It is very difficult for me to solve this and there is no solution on the internet related to this topic.

I understand that you need a solution. Just wait for people to answer the topic you created specifically with your issue.

If I may, can I suggest you delete the multiple messages you posted?

sure, I am deleting.

1 Like

I don’t want to use a CDN. I don’t care if they collect data or not. I want either to disable this script or to host it inside my Ghost installation. I would prefer the first one, but the second option is also fine. To use the CDN for any resource is not an option for me.

P.S. unpkg doesn’t state how they handle personal data at all. But they are hosted by Google and we know their business model :see_no_evil:


Further to this, I was able to disable the inclusion of the portal script from unpkg by manually commenting out the following line of code (181) in my installation:

Doesn’t seem to have caused major adverse effects so far (I have only done a cursory smoke test) - of course this is only a manual workaround and not ideal because I can’t automatically update my deployment without this patch.

But it might help those who want to temporarily disable this until the feature flag idea is reviewed by the team and possibly taken into consideration.


this is so weird, I can’t believe it’s just turned on by defautl AND you can’t turn it off!?

1 Like

This worked for me too.

There is an easier way to do this without modifying the ghost blog code. Hopefully the developers will leave this method open. I feel very trongly that the ability to disable the members function should be an option, and truly hope that they will reconsider their stance on the matter.

Anyway, you can disable the member helper by running this query in the ghost database:

update settings set `value` = 'none' where `key` = 'members_signup_access';

After doing this, restart ghost. The /#/portal url no longer functions and the javascript from unpkg is no longer included.

The method you use to access your database depend on if you are using mysql or sqlite3. After briefly reviewing the code, I do not think that there are any side effects of doing this if you do not intend to use the members function.

I do not understand the rationale behind the decision to force this upon users. Yes, I know that I’m free to fork the project and add this feature and perhaps it may come to that. Not everybody’s goal is to build subscriber lists and send out newsletters. It may be hard to comprehend if that’s where you make your living, but many people do this sort of thing for fun, or use it as a showcase of their accomplishments. These people have no need for this function.

I am personally asking the developers to reconsider their decision.

1 Like

update settings set value= 'none' wherekey = 'members_signup_access';

This will only work in Ghost 4.3 onwards. The UI for this option is currently behind a developer experiments flag and will be made generally available in a future release.

As this is currently in development be aware this setting value may change.


Thanks Kevin, I’ve appreciated the help you’ve given us with this memership feature.

I’ve now applied @mdeneen’s setting to a couple of installs, but I’ll keep an eye out for future changes.