-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable site creation for WP users with no sites #22415
Conversation
Generated by 🚫 Danger |
📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.
|
📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two acceptance criteria mentioned in the issue #22368 that are not met.
- Features removal modal should be shown right after site creation.
- Plan sales should be disabled on the WordPress app.
Features removal modal should be shown right after site creation.
Reproduction steps:
- Fresh install the app
- Sign up
- Choose to create a new site
- Notice that a fullscreen modal is shown, after dismissing it, the site creation flow is shown. The fullscreen modal should be shown after site creation is complete not before.
Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-01-19.at.02.20.42.mp4
Plan sales should be disabled on the WordPress app.
Plans and domains are being promoted inside the WordPress app.
Domains | Plans |
---|---|
WordPress/Classes/ViewRelated/Site Creation/Final Assembly/SiteAssemblyWizardContent.swift
Outdated
Show resolved
Hide resolved
WordPress/Classes/ViewRelated/Blog/Blog List/BlogListViewController+SiteCreation.swift
Outdated
Show resolved
Hide resolved
RELEASE-NOTES.txt
Outdated
@@ -11,6 +11,7 @@ | |||
* [**] Block Editor: Media uploads that failed due to lack of internet connectivity automatically retry once a connection is re-established [https://github.com/wordpress-mobile/WordPress-iOS/pull/22238] | |||
* [**] Block Editor: Manually retrying a single failed media upload will retry all failed media uploads in a post [https://github.com/wordpress-mobile/WordPress-iOS/pull/22240] | |||
* [*] [internal] Drop iOS 14 Support: Remove deprecated UIDocumentPickerViewController API [#22286] | |||
* [**] Site creation is re-enabled for WordPress users with no sites. [#22415] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this should be marked internal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am really not sure. If you think that makes more sense I'll do that.
@alpavanoglu FYI, looks like the tests are failing to build |
I'm going to bump this to the next release because we'll be code freezing 24.1 today and this hasn't been approved yet. If these changes cannot wait two weeks and it's important that it makes it into this release, let me know and we'll organize a new beta once ready. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Notice that a fullscreen modal is shown, after dismissing it, the site creation flow is shown. The fullscreen modal should be shown after site creation is complete not before.
@alpavanoglu I am still seeing the modal before the site creation flow starts. I also see the compliance popover. After the site creation flow is done, I see another feature removal modal.
Plans and domains are being promoted inside the WordPress app.
Domains are still being promoted inside the app. If I choose a paid domain, the step passes normally, but I end up with a free domain.
Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-01-22.at.03.40.42.mp4
) | ||
let overlayViewController = JetpackFullscreenOverlayViewController(with: viewModel) | ||
let navigationViewController = UINavigationController(rootViewController: overlayViewController) | ||
JetpackFeaturesRemovalCoordinator.presentOverlay( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there's a need to manually trigger an overlay.
Correctly configuring MySiteViewController.willDisplayPostSignupFlow
before triggering the site creation flow should stop the overlay from being presented at the wrong time and should then automatically be displayed after the site is created.
@@ -7,7 +7,7 @@ final class SiteCreationWizardLauncher { | |||
}() | |||
|
|||
let steps: [SiteCreationStep] = { | |||
if RemoteFeatureFlag.plansInSiteCreation.enabled() { | |||
if RemoteFeatureFlag.plansInSiteCreation.enabled() && !AppConfiguration.isWordPress { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Nit] I think this is more readable:
if RemoteFeatureFlag.plansInSiteCreation.enabled() && !AppConfiguration.isWordPress { | |
if RemoteFeatureFlag.plansInSiteCreation.enabled() && AppConfiguration.isJetpack { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've left some comments and suggestions.
I've also applied one of the suggestions and a change related to the compliance popover and pushed it to this branch: suggestion/alp-site-creation-pr
I haven't done proper testing on that branch, but here's the happy scenario:
Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-01-31.at.02.17.03.mp4
@@ -255,6 +255,10 @@ final class SiteAssemblyWizardContent: UIViewController { | |||
|
|||
self.errorStateViewController = errorStateViewController | |||
} | |||
|
|||
private func shouldPresentJetpackFeaturesRemovalOverlay() -> Bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this should be removed?
@@ -281,7 +281,7 @@ final class DomainSelectionViewController: CollapsableHeaderViewController { | |||
let type: DomainsServiceRemote.DomainSuggestionType | |||
switch domainSelectionType { | |||
case .siteCreation: | |||
type = RemoteFeatureFlag.plansInSiteCreation.enabled() ? .freeAndPaid : .wordPressDotComAndDotBlogSubdomains | |||
type = (RemoteFeatureFlag.plansInSiteCreation.enabled() && AppConfiguration.isJetpack) ? .freeAndPaid : .wordPressDotComAndDotBlogSubdomains |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line feels clunky. What do you think about splitting into two lines? Or extracting the isEnabled logic to a computed variable?
dismissTapped(viaDone: true) { [blog, weak self] in | ||
RootViewCoordinator.shared.isSiteCreationActive = false | ||
RootViewCoordinator.sharedPresenter.showBlogDetails(for: blog) | ||
RootViewCoordinator.shared.reloadUIIfNeeded(blog: blog) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving the reload trigger outside the completion fixes the glitch of showing an invalid state for a split second before reloading.
dismissTapped(viaDone: true) { [blog, weak self] in | |
RootViewCoordinator.shared.isSiteCreationActive = false | |
RootViewCoordinator.sharedPresenter.showBlogDetails(for: blog) | |
RootViewCoordinator.shared.reloadUIIfNeeded(blog: blog) | |
RootViewCoordinator.shared.isSiteCreationActive = false | |
RootViewCoordinator.shared.reloadUIIfNeeded(blog: blog) | |
dismissTapped(viaDone: true) { [blog, weak self] in | |
RootViewCoordinator.sharedPresenter.showBlogDetails(for: blog) |
launchSiteCreation: { [weak self] in self?.launchSiteCreationFromNoSites() }, | ||
launchSiteCreation: { | ||
[weak self] in self?.launchSiteCreationFromNoSites() | ||
RootViewCoordinator.shared.isSiteCreationActive = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm worried we're not setting for all possible flows of starting site creation. Can you double check? 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added the call to all the places that present SiteCreationWizardLauncher.ui
.
complianceCoordinator = CompliancePopoverCoordinator() | ||
complianceCoordinator?.presentIfNeeded() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it makes sense to show this popover during sign-up. Can we maintain the current behavior of showing it from My Site, and avoid showing it at the wrong time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've created a branch with an alternate solution for the compliance popover issue.
Check suggestion/alp-site-creation-pr
…o task/reenable-site-creation-wp # Conflicts: # WordPress/Classes/ViewRelated/Blog/My Site/MySiteViewController.swift
@@ -268,6 +268,7 @@ private extension SiteAssemblyWizardContent { | |||
|
|||
func dismissTapped(viaDone: Bool = false, completion: (() -> Void)? = nil) { | |||
// TODO : using viaDone, capture analytics event via #10335 | |||
RootViewCoordinator.shared.isSiteCreationActive = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this as a safety measure. I left the one below in place regardless as we need to set the state before reloading the UI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks on working on the fixes @alpavanoglu!
The happy scenario works as expected 🚀
I did however notice the following:
- Install the WP app
- Sign up
- Tap on "Create a new site"
- Cancel the flow
- We land on My Site, but the features removal overlay is never shown and the UI is never reloaded even though it should.
The following flow works as expected:
- Install the WP app
- Sign up
- Tap on "Not right now"
- The overlay is shown and the UI is reloaded.
I would expect both flows to behave the same.
Generated by 🚫 dangerJS |
To resolve the issue Hassaan raised above, I added a force-reload on Site creation cancellation only for WordPress app with an account with 0 blogs to o minimize regression possibilities. I tested the following cases again:
At the end of each of these cases, Jetpack Migration Overlay appears as expected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works as expected 🚀
Left one comment on the code.
@@ -110,6 +110,7 @@ class SiteIntentViewController: CollapsableHeaderViewController { | |||
@objc | |||
private func closeButtonTapped(_ sender: Any) { | |||
SiteCreationAnalyticsHelper.trackSiteIntentCanceled() | |||
RootViewCoordinator.shared.reloadPostSiteCreationCancellationIfNeeded() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now we always reload the UI if some conditions are met, even if the UI shouldn't be reloaded.
I think we can just do this:
RootViewCoordinator.shared.reloadPostSiteCreationCancellationIfNeeded() | |
RootViewCoordinator.shared.isSiteCreationActive = false | |
RootViewCoordinator.shared.reloadUIIfNeeded(blog: blog) |
We can either pass a nil value for the blog or fetch the current blog for consistency. There shouldn't be a need for the isWordPress or blog count condition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried this but reloadUIIfNeeded
does not reload still. iirc guard newUIType != oldUIType
was falling into else. That's why I force the reload. However we don't reload in any case. The new function checks if the user has blogs and is on WordPress app. Since this function is only invoked from SiteIntentViewController
, and that can only happen if the user has specifically 0 blogs and taps "close" on the first site creation screen, it will run on this very specific case and nothing else. Not on Jetpack app, not if the user has already a site.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alpavanoglu I tried it locally and it works as expected:
Screen.Recording.2.mov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested it and it does work indeed. Perhaps I mistakenly tried the same account and the overlay was already shown once. I pushed the changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
...ess/Classes/ViewRelated/Jetpack/Branding/Coordinator/JetpackFeaturesRemovalCoordinator.swift
Outdated
Show resolved
Hide resolved
Maybe I'm missing something but the features removal overlay didnt appear the site was created. Other than that, the rest of the steps worked as described in the Test Instructions. trim.EE0DEAB7-D38F-4057-99A8-7D1864099F46.MOV |
@salimbraksa was it a fresh install? |
@hassaanelgarem No, it wasn't, but I tried signing out and login again, assuming that may reset the catch. I clean installed the app and everything worked as expected. cc @alpavanoglu |
Fixes: #22368
Refs: pcdRpT-5mv-p2
Testing Steps
Main Functionality
Regression for Jetpack
Regression Notes
Potential unintended areas of impact
Quick start may appear and highlight features that aren't available on WordPress app.
What I did to test those areas of impact (or what existing automated tests I relied on)
Manually tested.
What automated tests I added (or what prevented me from doing so)
PR submission checklist:
RELEASE-NOTES.txt
if necessary.UI Changes testing checklist: