Open ivan-ottinger opened 1 year ago
ivan-ottinger
commented
1 year ago We decided to not disable the Newsletter settings fields. Instead we could just display a copy on top guiding the user how they can enable the Subscriptions module in settings/discussion/:
Related discussion: p1673451658701569/1673449151.540879-slack-C02TCEHP3HA
mashikag
commented
1 year ago Instead we could just display a copy on top guiding the user how they can enable the Subscriptions module
Should the copy tell the user how they can enable the Subscriptions module, or rather tell them that the Newsletter settings may not apply to their site because they have their Subscription module off, and give a sort of "Learn more" or "How to enable it" link?
Never-the-less the task is 🔴 Blocked until we have the exact copy and a design on how to display it. @saygunnyc is this something you could help us with?
saygunnyc
commented
1 year ago Yes, let's unblock! 😄
Re-looking at this, I think this could be a way to notify users that they currently are not letting visitors subscribe.
Some notes:
Let me know your thoughts! cc @michaelpick
Used this existing notice pattern from Performance Settings
ivan-ottinger
commented
1 year ago I just noticed that with the Subscriptions module disabled, the text areas are currently empty - as the default values are not available in that case:
This is something we may want to address as well. → I have added this information to the issue description for now.
saygunnyc
commented
1 year ago I just noticed that with the Subscriptions module disabled, the text areas are currently empty - as the default values are not available in that case:
Could you let me know if this is about an engineering effort required to pull those values in? Or does that mean it's not possible to pull those values in this case?
ivan-ottinger
commented
1 year ago Could you let me know if this is about an engineering effort required to pull those values in? Or does that mean it's not possible to pull those values in this case?
We will look at this closer - to see what it takes to get out those default values even with the module disabled.
ivan-ottinger
commented
1 year ago Could you let me know if this is about an engineering effort required to pull those values in? Or does that mean it's not possible to pull those values in this case?
I have looked into the issue with empty fields today.
What I think is worth mentioning upfront is that the issue is present only in the case when the subscriptions module is disabled AND the fields haven't been updated by the user yet.
If the user changed the fields and then disabled the module, the fields will hold the saved values and won't be empty.
The subscriptions module is active by default on Atomic sites and inactive for Jetpack sites (at least that is the case with fresh Jurassic Ninja site I tested).
Currently, the default values for both fields are set via default_option_subscription_options filter inside projects/plugins/jetpack/modules/subscriptions/views.php (introduced in this PR).
The simplest solution coming to my mind would be to move the filter outside of the subscriptions module and hence make it available even if the subscriptions module is disabled.
→ For instance, by moving the filter to projects/plugins/jetpack/functions.global.php, it executes even with the subscriptions module disabled and both fields get populated with the default values. With that said, it doesn't feel right to me to "pollute" functions-global.php with this filter, so if we decide to go this route, I would say we should find a better location for the filter - that is still executed with the subscriptions module disabled. Maybe Jeremy would have an opinion here? @jeherve 🙂
Alternative solution could be to set the default values directly where the endpoint (that Calypso calls) is defined (in projects/plugins/jetpack/json-endpoints/class.wpcom-json-api-site-settings-endpoint.php), but I would rather avoid this approach - since it would add one more place where the default values would be set. And we are trying to accomplish the opposite - to have only one place where the subscription_options default values are set (https://github.com/Automattic/wp-calypso/issues/72013).
In case we decide to keep the default_option_subscription_options filter where it is, I think we could still add the nudge as you shared earlier:
while being OK with the fact that when the subscriptions module is disabled and the user hasn't updated the fields, these fields will be empty.
When speaking about the nudge, it could lead to https://jetpack.com/support/subscriptions/ for Jetpack sites and https://wordpress.com/support/subscriptions-and-newsletters/ for Atomic sites (although this documentation page doesn't mention how the module can be activated - so that would need to be adjusted).
For completeness, the old Reading settings page in WP Admin removes the whole "Follower settings" section completely when the subscriptions module is disabled.
subscriptions module enabled |
subscriptions module disabled |
|---|---|
 |
 |
jeherve
commented
1 year ago For completeness, the old Reading settings page in WP Admin removes the whole "Follower settings" section completely when the subscriptions module is disabled.
This to me seems like the most logical approach. Couldn't we do the same in Calypso?
Could we not show settings that are not useful to site owners until the feature becomes active, and the fields start actually making sense to them?
I believe we already follow similar patterns for other Jetpack modules. For example for Sharing buttons (Tools > Marketing > Sharing buttons), we grey out / do not display some of the options when the module is disabled:
ivan-ottinger
commented
1 year ago Thanks for your input, Jeremy!
This to me seems like the most logical approach. Couldn't we do the same in Calypso?
Could we not show settings that are not useful to site owners until the feature becomes active, and the fields start actually making sense to them?
I was thinking about hiding the settings originally (related draft PR), but then there was some discussion on keeping the settings in - from the design perspective. I think @saygunnyc would be probably better to share the details he had in mind.
saygunnyc
commented
1 year ago Thank you for chiming in, @jeherve, and thanks for the ping, @ivan-ottinger.
Let me elaborate, and we can re-discuss the best option. With the information shared above, it may not make sense to spend too much effort figuring out patches to display the email values, so we could re-consider hiding the email content input fields. (However, seeing them, editing them, and saving them would still be useful.)
I believe letting visitors subscribe to posts and comments is enabled by default for all sites. (Lemme know if this is not true!)
As a user, who is not fond of the default email message sent to subscribers, I may want to disable the setting and enable it once I work on the messages.
As another user, these settings (below) would still apply to me because Jetpack settings only disable new subscribers. As a user, I can still technically add subscribers, or/and the existing subscribers will keep receiving emails. –except for welcome emails
We have about %40 - $50 bloggers in our user base. And Emails/Newsletters apply to all. –Not just Newsletter customers. Making these settings visible at all times shouldn't hurt; it could be beneficial. – As a user, I know what I can customize when it comes to emails sent from my site.
That's my thinking, let me know your thoughts!
jeherve
commented
1 year ago I believe letting visitors subscribe to posts and comments is enabled by default for all sites. (Lemme know if this is not true!)
That's not the case for self-hosted sites.
As a user, who is not fond of the default email message sent to subscribers, I may want to disable the setting and enable it once I work on the messages.
That's very true, and would definitely be very useful. Behind the scenes, since the Subscriptions code doesn't run when the feature is disabled, that's definitely something tricky to achieve.
On the other hand, and unless one uses scheduled posts, they'll either be customizing or publishing posts; they won't be doing the 2 things at the same time. That means they could stop publishing, customize the messages, and hit publish, without having to disable the Subscriptions feature at any time.
As another user, these settings (below) would still apply to me because Jetpack settings only disable new subscribers. As a user, I can still technically add subscribers, or/and the existing subscribers will keep receiving emails. –except for welcome emails
I'm not sure I understand this. Yes, you can use the Calypso UI add subscribers, but I don't think any emails should be sent when the subscription feature is disabled, regardless of when the subscribers were added.
saygunnyc
commented
1 year ago That's not the case for self-hosted sites.
I didn't know. Is there a reason to do so?
but I don't think any emails should be sent when the subscription feature is disabled, regardless of when the subscribers were added.
Do you mean previously subscribed users will stop receiving new posts and comment emails? If yes, this setting doesn't mention so.
jeherve
commented
1 year ago Is there a reason to do so?
This was part of a larger discussion a few years back, when we decided to avoid auto-activating some features when Jetpack was first connected to WordPress.com on sites. Here is the P2 post about it: p1HpG7-6qm-p2
Do you mean previously subscribed users will stop receiving new posts and comment emails?
Yes, exactly. When you deactivate the feature, no emails are being sent.
We could certainly update the wording to make that clearer!
saygunnyc
commented
1 year ago Here is the P2 post about it:
Thank you for sharing. Interesting. I am unsure if I'm missing more context, but with the latest efforts^1, I feel like we might want to enable subscriptions by default.
Yes, exactly. When you deactivate the feature, no emails are sent.
Oh wow, I am surprised. Those two would likely be better as two different settings, IMO, as pausing/stopping new subscribers is a very distinct action than stopping to send emails to existing subscribers.
jeherve
commented
1 year ago I feel like we might want to enable subscriptions by default.
Yes, that's definitely something we could consider again.
There have been discussions about discoverability lately:
I'll see if I can restart those discussions by suggesting a few changes in the next few days.
When the Subscriptions module in Jetpack is inactive, we could consider adding short text to the Newsletter settings on the new Reading settings page guiding the user where they can enable the module.
The original idea was to also disable the related form fields.
This applies to Jetpack and Atomic sites.
With the Subscriptions module disabled, the text areas are currently empty - as the default values are not available:
This is something we may want to address as well.