Wp-calypso: [PBD interim fix] Update Upgrade&Launch prompt screen

[adamziel]

Related to PBD interim fix epic https://github.com/Automattic/wp-calypso/issues/38110

Goal

Make /plugins/upload and /themes/upload pages look like the screenshot below for users who are not eligible for an upgrade:

• Only mention the business plan if they are on lower plan
• Only mention site launch if their site is private
• Replicate the calypso_banner_cta_click event that's currently fired by the upgrade banner

Obviously ignore the arrows from Figma :-)

Links

• Figma file 233b7-pb
• paObgF-I3-p2

[adamziel]

cc @jancavan - did I get the description right?

[adamziel]

@jancavan one problem here is that we need to account for the other failure conditions, e.g. email verification:

The exhaustive list is available here: https://github.com/Automattic/wp-calypso/blob/2f66b6346cbb997c0c108a23453fbc1c312499b2/client/blocks/eligibility-warnings/hold-list.jsx

[jancavan]

Only mention the business plan if they are on lower plan

Correct.

Only mention site launch if their site is private

Correct. They should only see the upgrade nudge (not the prequisites screen) if their sites have already been launched. Please see Figma.

Re this: https://github.com/Automattic/wp-calypso/blob/2f66b6346cbb997c0c108a23453fbc1c312499b2/client/blocks/eligibility-warnings/hold-list.jsx

I think we should not make the feature available in cases where they will only be told it isn't possible:

NO_JETPACK_SITES
NO_VIP_SITES
NON_ADMIN_USER

For BLOCKED_ATOMIC_TRANSFER, if they contact support, is this issue fixable?

For TRANSFER_ALREADY_EXISTS, it's not clear to me what this means. Is the site being transferred to wpcom?

@adamziel

[p-jackson]

I don't know for sure but I assume that BLOCKED_ATOMIC_TRANSFER is a catch-all and that it's going to need manual digging to figure out what's going wrong, and that TRANSFER_ALREADY_EXISTS means it's in progress.

My plan was to leave the existing <EligibilityWarnings> component to handle all the different edge cases, but to create a new <EligibilityWarningsSimplified> for the special case where it's private or a low-tier plan i.e. we know they're in the flow we're trying to streamline.

I think we should not make the feature available in cases where they will only be told it isn't possible

We could hide the install plugin button in these cases but I think the user would miss having the explanation there. Especially for holds like NOT_RESOLVING_TO_WPCOM and NON_ADMIN_USER. They'll be hunting for the install plugin button knowing it should be somewhere, but rather than ever fixing the problem they'll just assume they haven't found the button yet.

Even with the button hidden the API will still return these holds (e.g. user stops being an admin in the time between when they view /plugins/{siteid} and /plugins/upload/{siteid}) so they'll need to be handled somewhere.

@jancavan

[p-jackson]

I also see that <EligibilityWarnings> is used on the /hosting-config page, which I think is something @Automattic/serenity is working on. I haven't been able to navigate to that page in calypso but I'm guessing that it's something atomic related and we should roll our changes out there too?

[gwwar]

The three transfer points are Themes, Hosting (/hosting-config) and Plugins, I'd prefer if we had consistent UIs for these flows.

Thanks for looking into this further, I did notice that there wasn't a clear call to action when a site is Private and folks would like to transfer.

[gwwar]

cc @olaolusoga do you mind helping with design on a consolidated Automated Transfer flow?

Also cc @aidvu for recent work in https://github.com/Automattic/wp-calypso/pull/37983

[jancavan]

and that TRANSFER_ALREADY_EXISTS means it's in progress.

Right, but just wanted to know what exactly is happening here so we can come up with more helpful error messages.

The current one says:

Installation in progress
Just a minute! Please wait until the installation is finished, then try again.

But I'm not sure what's currently being installed?

NOT_RESOLVING_TO_WPCOM - Does this currently prevent users from upgrading and launching? I just don't think it's directly related to the task of uploading a theme/plugin, so it could be handled after or elsewhere.

Which of the eligibility warnings prevent users from upgrading and launching?

@p-jackson @adamziel

[jancavan]

What is EXCESSIVE_DISK_SPACE? Is this if they have no more space left in the accounts?

Why does the error message say "they aren't eligible..." vs just telling them to delete some files from their Media Library (assuming my interpretation of it is correct)?

@p-jackson @adamziel

[gwwar]

What is EXCESSIVE_DISK_SPACE?

I'm not sure all these cases still apply today @jmdodd @aidvu ? I believe that one was around potentially long transfer times.

[jancavan]

@gwwar Right, and in this particular flow of asking the user to upgrade to upload a theme/plugin, if the cap reflects that of a lower-tier plan, then why would that matter in this scenario? The only thing that matters is for them to upgrade (and launch). By the time they're on a Business plan, then space should no longer be an issue.

[jancavan]

I believe that one was around potentially long transfer times.

Interesting. The error message isn't helpful in this case.

[p-jackson]

Does this currently prevent users from upgrading and launching? I just don't think it's directly related to the task of uploading a theme/plugin

These all block the the task at hand (uploading a theme/plugin) because they all stop the user going atomic. So I guess they're _indirectly_ related 😄

I've been thinking of the holds in terms of three categories:

• Something's in progress, the user doesn't need to do anything
  
  
  
  • NO_SSL_CERTIFICATE
  
  
  • TRANSFER_ALREADY_EXISTS
  
  
• The user needs to do something
  
  
  
  • BLOCKED_ATOMIC_TRANSFER
  
  
  • NO_BUSINESS_PLAN
  
  
  • SITE_PRIVATE
  
  
  • SITE_GRAYLISTED
  
  
  • NON_ADMIN_USER
  
  
  • NOT_RESOLVING_TO_WPCOM
  
  
  • EMAIL_UNVERIFIED
  
  
  • EXCESSIVE_DISK_SPACE
  
  
• No on can do anything
  
  
  
  • NO_JETPACK_SITES
  
  
  • NO_VIP_SITES
  
  

Maybe the solution depends on what category the hold is?

Then there's the fact that the backend can return an arbitrary warning. Could be that they're going to lose their current *.wordpress.com domain, or it could be that some widget will stop working after going atomic. So there's lots of edge cases which is why I thought simplifying the flow if it's a simple case might be easier

---

Some notes about different holds:

BLOCKED_ATOMIC_TRANSFER actually means the site has a blog sticker that I just learnt about. If happiness have applied the blocked-from-atomic-transfer sticker to the site then they'll get this hold.

EXCESSIVE_DISK_SPACE means the site is over 150GB in size. That's unfortunate because that's lower than the business plan supports according to the plans page. Not sure why, maybe a limitation of the atomic platform? But they may be directed to support because it's going to be more sensitive.

TRANSFER_ALREADY_EXISTS just doesn't have a good message at the moment. The hold means that the transfer is either complete or in progress. I originally thought the message was for a case where the user starts uploading a plugin then refreshes the page, so the "upload in progress" would refer to the one the user just started. But when I tried this myself I got a combination of no error and "no jetpack allowed"

[jancavan]

This is really helpful, thank you @p-jackson!

Then there's the fact that the backend can return an arbitrary warning. Could be that they're going to lose their current *.wordpress.com domain

Yeah, we have eliminated this since it isn't actionable, and something the user doesn't really need to know about. The site is also still unlaunched, so I don't think they would have already been sharing the URL publicly.

I'd broken them up again based on how I understood each:

(1) A hard block, it's like a "dead end" until they get this resolved:

• BLOCKED_ATOMIC_TRANSFER _(Contact support to fix)_
• TRANSFER_ALREADY_EXISTS _(Wait for process to complete)_
• NO_SSL_CERTIFICATE _(Wait for process to complete)_
• SITE_GRAYLISTED _(Contact support to fix)_

I don't think the items in (1) can be combined with other eligibility warnings? I was thinking that we ask the user to solve these first before asking them to upgrade/launch.

(2) A "soft" block, ie: user can resolve it themselves:

• NO_BUSINESS_PLAN _(Upgrade to fix)_
• SITE_PRIVATE _(Launch to fix)_
• NOT_RESOLVING_TO_WPCOM _(Fix domain setup)_
• EMAIL_UNVERIFIED _(Verify email to fix)_
• EXCESSIVE_DISK_SPACE _(Clear up disk space to fix)_

(3) The user can't do anything (I think we can remove the feature for these use cases since it isn't actionable):

• NO_JETPACK_SITES
• NO_VIP_SITES

Questions:

NON_ADMIN_USER

• I tried giving a user different access rights to a site, but I don't see a way for them to even be able to access /themes or /plugins; these menu items aren't available in the sidebar for them. So I'm guessing this isn't relevant to this particular flow?

NOT_RESOLVING_TO_WPCOM

• Why would this stop the user from going Atomic? They can still upload a Theme/Plugin and upgrade without fixing this, right? I just feel like we can bug them about this somewhere else.

Yeah, they would launch their sites and the domain would not be pointed correctly, but it's not like they wanted to launch it anyway in the first place.

EXCESSIVE_DISK_SPACE

• Why is the cap at 150GB?
• I would like to make this actionable, but you're right about it being an odd request when they haven't technically reached their 200GB limit yet. On the other hand, I actually don't see this library capacity progress bar in the Media Library of Business/eCommerce plans:

So it might be ok to tell them to delete some files, albeit kinda unscrupulous.

[adamziel]

Just flagging there are also problems like this one here when there's no error message at all: p9F6qB-4n9-p2 although it seems out of scope for this issue

[adamziel]

(1) A hard block, it's like a "dead end" until they get this resolved:
I don't think the items in (1) can be combined with other eligibility warnings? I was thinking that we ask the user to solve these first before asking them to upgrade/launch.

This is accurate

(2) A "soft" block, ie: user can resolve it themselves:

👍

(3) The user can't do anything (I think we can remove the feature for these use cases since it isn't actionable)

👍

NON_ADMIN_USER
I tried giving a user different access rights to a site, but I don't see a way for them to even be able to access /themes or /plugins; these menu items aren't available in the sidebar for them. So I'm guessing this isn't relevant to this particular flow?

Calypso already does a good job of not allowing these users on that page so it's not relevant for that flow.

NOT_RESOLVING_TO_WPCOM
Why would this stop the user from going Atomic? They can still upload a Theme/Plugin and upgrade without fixing this, right? I just feel like we can bug them about this somewhere else.

I think that's a technical limitation of Atomic platform, but I asked here just to be sure p1575455657261000-slack-C7YPW6K40

EXCESSIVE_DISK_SPACE

I think just tasking users to delete some files would be fine. I'm not sure why cap is at 150GB - do you think we should get to the bottom of that?

[p-jackson]

I'm not sure why cap is at 150GB - do you think we should get to the bottom of that?

Asked here: p9o2xV-EH-p2

SITE_PRIVATE _(Launch to fix)_

I'm thinking about adding a new SITE_UNLAUNCHED hold so we can distinguish between unlaunched and private. In both cases we'll be able to solve it for them without going to the settings page, but we can have better copy if it's easy to distinguish between the two cases.

[jancavan]

Asked here: p9o2xV-EH-p2

Thank you @p-jackson! That was really helpful and now makes much more sense.