Skip to content
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

Default to Gutenberg upon opening a block based post #12066

merged 4 commits into from Jul 8, 2019


Copy link

commented Jul 4, 2019

Fixes wordpress-mobile/gutenberg-mobile#1186

This PR flips the "default for new posts" switch to true the first time the block editor is launched, if the switch is off.

The alert text was changed to match wordpress-mobile/gutenberg-mobile#1186 (comment)

The logic is:

  • The alert will be shown if:
    • The Gutenberg default switch is off
    • The post has gutenberg blocks
    • Is first time opening a gutenberg post

When the alert is shown, we automatically flip the switch located in App Settings.

This will trigger the tracks event AppSettingsGutenbergEnabled but I'd say that it is still desirable, unless we want a new tracks event for this particular case?

I'm unsure if we should add this to the release notes.

To test:

  • Set UserDefaults.standard.setValue(false, forKey: "Gutenberg.InformativeDialog") to be triggered on app lunch. (on applicationWillEnterForeground is helpful to easily reset it)
  • Make sure the gutenberg switch is off on App Settings
  • Open a new post
    • It should open Aztec
  • Open a post without gutenberg blocks
    • It should open Aztec
  • Open a post with gutenberg blocks
    • It should open gutenberg and show the alert
  • Open again the same post
    • It should open gutenberg without showing the alert
  • Open a new post
    • It should open gutenberg
  • Check the switch on AppSettings
    • It should be ON
  • Flip the AppSettings switch to OFF
  • Open a gutenberg post
    • It should open gutenberg
    • It should NOT show the alert
    • it should NOT flip the switch back to ON

Update release notes:

  • If there are user facing changes, I have added an item to RELEASE-NOTES.txt.

@etoledom etoledom added this to the 12.9 milestone Jul 4, 2019

@etoledom etoledom requested a review from koke Jul 4, 2019

@etoledom etoledom self-assigned this Jul 4, 2019

@@ -7,6 +7,7 @@ import Foundation
/// list objects.
protocol KeyValueDatabase {
func object(forKey defaultName: String) -> Any?
func bool(forKey: String) -> Bool

This comment has been minimized.

Copy link

koke Jul 4, 2019


This should be in a protocol extension since it’s just a wrapper that will be the same for all cases

This comment has been minimized.

Copy link

etoledom Jul 4, 2019

Author Contributor

Nice catch! Updated 👍


koke approved these changes Jul 4, 2019

Copy link

left a comment

It works! There is a case that this didn't account for but I think we can live with that. The logic checks if the dialog has been shown, not if the setting has been changed, so the following is possible:

  1. Install the app
  2. Go to settings and enable gutenberg
  3. Try gutenberg for a few things
  4. Decide you don't want it anymore and disable the app setting
  5. Open a gutenberg post, the alert shows and gutenberg is enabled again for new posts

Since it seems like an odd case, and it would only happen once, I think it's fine?

etoledom added some commits Jul 4, 2019

Update Gutenberg InfoDialog message.
To describe automatic switch flip to make gutenberg the default editor.

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2019

Since it seems like an odd case, and it would only happen once, I think it's fine?

As agreed, we will merge this as a short lived feature, so we won't worry about these edge cases.
Thank you!

@etoledom etoledom merged commit 72f4e7c into develop Jul 8, 2019

3 checks passed

Hound No violations found. Woof!
Peril All green. Well done.
ci/circleci: build_and_test Your tests passed on CircleCI!

@etoledom etoledom deleted the issue/gutenberg-1186-default-after-first-open branch Jul 8, 2019

@etoledom etoledom referenced this pull request Jul 15, 2019
1 of 1 task complete
@etoledom etoledom referenced this pull request Aug 8, 2019
1 of 3 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.