[Gutenberg] Set consistent editor colours in both the WordPress and Jetpack apps #19113

SiobhyB · 2022-07-25T18:20:35Z

Fixes the iOS side of wordpress-mobile/gutenberg-mobile#5047, Android PR is here

Description

In the Jetpack app, some UI elements like the cursor, text selection, and caret are using a green colour. However, the rest of the editor’s elements are using blue.

To be consistent with colours across the editor, this PR seeks to update them for consistency across both the WordPress and Jetpack apps. The PR specifically achieves the following for the Jetpack app:

Updates the colour of UI elements within the main editor (e.g. cursor, highlight) from green to blue.
Updates the accent of sub screens within Post Settings from green to blue.

There's still some known inconsistencies that need to be addressed in separate PRs, however:

The media picker (available from media blocks and the Post Settings screen) still has some green.
There is still green visible in other screens 'connected' to the editor, such as Preview, History, Help & Support, etc.

These remaining inconsistencies have been captured in the issue at wordpress-mobile/gutenberg-mobile#4889 for the future.

Screenshots

A before/after screenshot taken from the Jetpack app to show the editor's green → blue colour changes:

Before	After

A before/after taken from the WordPress app (dark mode) to confirm there are no unexpected changes:

Before	After

Testing

Download this PR's installable build for both the WordPress and Jetpack apps.
In each app, navigate to the editor.
Verify the colours used throughout the editor appear consistent for both app. The cursor, text selection, and caret should all now be blue for Jetpack (this is in contrast to the green that's used outside of the app's editor). There should be no change in the WordPress app, with the colours remaining blue.

Special considerations to keep in mind while testing include:

This PR aims to bring colour consistency to the Post Settings screen as well as the editor.
Testing of any popovers, modals, or less visible UI elements within the editor would be beneficial.
As this is a UI change, dark/light mode should be a consideration.
These changes should be noticeable in both the post and the page editor.

Code Changes

The colours we're aiming to change are using the default .tintColor, which is set to .primary via the following line of code:

WordPress-iOS/WordPress/Classes/Extensions/Colors and Styles/WPStyleGuide+ApplicationStyles.swift

Lines 20 to 22 in 3eabde7

    
           class func configureDefaultTint() { 
        
               UIWindow.appearance().tintColor = .primary 
        
           }

.primary is set as .jetpackGreen here for the Jetpack app and .blue here for the WordPress app.

As a number of UI elements needed to be updated as part of this PR, a new .editorPrimary variable was created, following the same patterns found for other colours in the UIColor+MurielColors.swift file, such as .primary and .success.

Root React Native View

The tintColor for the editor's main view (i.e. the root React Native view) has been set here:

WordPress-iOS/WordPress/Classes/ViewRelated/Gutenberg/GutenbergViewController.swift

Line 568 in 43b9994

view.tintColor = .editorPrimary

React Native Modals

configureDefaultTint() is setting the tint colour for the entire window of each screen via UIWindow. As React Native's modals exist outside of the root view, it's necessary to override the default tintColor once again to ensure consistency in BottomSheets and other parts of the app that may be using modals.

This was achieved on the native side via override func present:

WordPress-iOS/WordPress/Classes/ViewRelated/Gutenberg/GutenbergViewController.swift

Lines 415 to 420 in 43b9994

    
           override func present(_ viewControllerToPresent: UIViewController, animated flag: Bool, completion: (() -> Void)? = nil) { 
        
               super.present(viewControllerToPresent, animated: flag, completion: completion) 
        
               let presentedView = presentedViewController?.view 
        
               presentedView?.tintColor = .editorPrimary 
        
           }

React Native Action Sheets and Switches

The default .tintColor for switches/toggles within the editor's modals needed to be overridden, which was done via the following line of code:

WordPress-iOS/WordPress/Classes/ViewRelated/Gutenberg/GutenbergViewController.swift

Line 576 in 43b9994

    
           UISwitch.appearance(whenContainedInInstancesOf: [RCTModalHostViewController.self]).onTintColor = .editorPrimary

Note, the above was set within GutenbergViewController.swift rather than WordPressAppDelegate.swift as RCTModalHostViewController resulted in an out-of-scope error in the latter's file.

In addition, the .tintColor for action sheets has been set directly in React Native via wordpress-mobile/gutenberg-mobile#5074.

Post Settings Screen

It was possible to set the tintColor for multiple UI elements in the Post Settings screen.

Some hacky code has been used for the parent category screen (found within Post Settings). This was necessary because the screen is used elsewhere in the app (via Site Settings → Category) and there wasn't any other views in the hierarchy that could be used to only target the Post Settings UI:

WordPress-iOS/WordPress/Classes/System/WordPressAppDelegate.swift

Lines 889 to 893 in 56dab96

    
           /// Sets the `tintColor` for parent category selection within the Post Settings screen 
        
           UIView.appearance(whenContainedInInstancesOf: [PostCategoriesViewController.self]).tintColor = .editorPrimary 
        
           /// It's necessary to target `PostCategoriesViewController` a second time to "reset" the UI element's `tintColor` for use in the app's Site Settings screen. 
        
           UIView.appearance(whenContainedInInstancesOf: [PostCategoriesViewController.self, WPSplitViewController.self]).tintColor = .primary

Regression Notes

Potential unintended areas of impact

There's the potential for this PR to unexpectedly change colours in either the WordPress or Jetpack app beyond what's desired. For example, the cursor colour may unexpectedly change within the WordPress app.

What I did to test those areas of impact (or what existing automated tests I relied on)

I manually tested both apps, making sure to experiment with various blocks and writing flows.

What automated tests I added (or what prevented me from doing so)

No automated tests.

PR submission checklist:

I have completed the Regression Notes.
I have considered adding unit tests for my changes.
I have considered adding accessibility improvements for my changes.
I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

The editor's "tintColor" is explicitly set to be "wordPressBlue" with this commit. The most notable colour that will change following this is the editor's cursor and "highlight" colour when text is selected.

wpmobilebot · 2022-07-25T21:46:07Z

You can test the changes in Jetpack from this Pull Request by:

Clicking here or scanning the QR code below to access App Center
Then installing the build number pr19113-56dab96 on your iPhone

If you need access to App Center, please ask a maintainer to add you.

wpmobilebot · 2022-07-25T21:47:43Z

You can test the changes in WordPress from this Pull Request by:

Clicking here or scanning the QR code below to access App Center
Then installing the build number pr19113-56dab96 on your iPhone

If you need access to App Center, please ask a maintainer to add you.

dcalhoun

Thank you for investigating this. This change makes sense to me, however, I noticed several UI instances where this change does not control.

The Editor UI references below are bit unexpected IMO. If it is easily addressable, then I think it makes sense to avoid the Jetpack brand green for these places in service of wordpress-mobile/gutenberg-mobile#5047.

Editor UI

Location	Image
Inserter Search
Link Picker
Text Area
Text Input
Range Input
Toggle

The Post Settings UI references below are bit of a "gray area" IMO, I think there is an argument to make that this UI is not within the editor and should mirror the general Jetpack app color scheme. We can likely leave the Post Settings UI as-is.

Post Settings UI

Location	Image
Post Slug
Post Excerpt

I could be convinced this PR is worth merging as-is to address the blatant issue of rich text fields utilizing the unexpected Jetpack brand green, with a follow up for the Editor UI references. WDYT about these references?

WordPress/Classes/ViewRelated/Gutenberg/GutenbergViewController.swift

SiobhyB · 2022-07-26T16:23:12Z

Thanks so much for spotting those UI pieces that the original PR missed, @dcalhoun!

I found that this is caused by configureDefaultTint() setting the tint colour for the entire window of each screen via UIWindow. So, setting the tint colour specifically for the editor view isn't enough, it needed to be set for the window. I went ahead to implement that in 38aac84.

In my testing, this addresses all the views from your screenshots, including the Post Editor settings. However, I see it also changes the tint colour for other areas of the app after exiting the editor. 🤔

I'll work on this further tomorrow and update you when it's ready for review again. 🙇‍♀️

dcalhoun · 2022-07-26T20:48:33Z

I found that this is caused by configureDefaultTint() setting the tint colour for the entire window of each screen via UIWindow.

Given that all the references I called out are rendered within a modal, I wonder if that explains why modifying the Gutenberg root view does not impact them. My understanding is that React Native Modal is rendered outside of the default root view. I wonder if there is a way to modify the tintColor for the React Native Modal. 🤔

However, I see it also changes the tint colour for other areas of the app after exiting the editor. 🤔

I do not find this surprising. The current code mutates the top-level window tintColor when Gutenberg's view is created, but never resets it. We would likely need to reset the tintView when Gutenberg is dismissed. However, this approach concerns me a bit. I would want to seek input from a more experience iOS developer on this approach.

Setting the tintColor to the entire window caused colours to be set elsewhere in the app. As such, this commit, reverts that change and limits the tintColor to the editor's root view.

In the previous commit, I accidentally committed the reference to "editorPrimaryLight", but hadn't intended to. This commit removes that reference and adds back the "editorPrimary" function that was accidentally deleted.

Previously, the tintColor for the menu items in Post Settings was being targetted via the 'UIView' element. This had the undesired side effect of also changing the tintColor for other UI elements in the editor. With this commit, 'UIView' has been changed to 'UITableView' in order to more specifically target the UI elements that should be changed.

This change was committed accidentally, and won't be a part of this PR's changes.

SiobhyB · 2022-08-02T16:16:53Z

@dcalhoun, thank you again for your diligent testing and help.

I've been able to set the colours for the main editor and Post Settings, but some of the approaches I settled on feel very hacky. I suspect my lack of iOS experience is a part of that.

In addition, I wasn't able to find a way to customise the preview and help sections that didn't also impact their use in other areas of the app.

What do you think about reducing the scope of this PR to include only the main editor and Post Settings screens? The other areas could then be addressed in separate PRs, depending on feedback. I'd also definitely be interested to hear thoughts on possible different, cleaner alternatives to the approaches I've taken.

dcalhoun

Great work! I was unable to identify any unexpected outcomes while testing the latest changes. 🎉 👏🏻

What do you think about reducing the scope of this PR to include only the main editor and Post Settings screens?

This makes sense to me. I believe the changes proposed here provide an improved brand experience in the editor. There is less inconsistency in color. The remaining color inconsistency is buried within adjacent configuration screens.

I left a few comments to spark discussion. I think it may be appropriate to request additional review from a more experienced iOS developer as well. That person may have ideas on alternative approaches.

WordPress/Classes/System/WordPressAppDelegate.swift

WordPress/Classes/ViewRelated/Gutenberg/GutenbergViewController.swift

dcalhoun · 2022-08-02T16:50:30Z

WordPress/Classes/ViewRelated/Gutenberg/GutenbergViewController.swift

+        // Resets the action sheet's tintColor to `.primary` to prevent `.editorPrimary` being set as the tintColor for UI elements outside of the editor.
+        UIView.appearance(whenContainedInInstancesOf: [UIAlertController.self]).tintColor = .primary


The need to mutate and reset this change is unfortunate and obscure. I am curious if more experience iOS developers have idea for an alternative approach.

I wonder if we can avoid this by targeting AztecNavigationController. [more context]

@twstokes, thank you for taking a look at this!

I tried UIView.appearance(whenContainedInInstancesOf: [UIAlertController.self, AztecNavigationController.self]).tintColor = .primary, but it doesn't work locally for me.

I checked the hierarchy and I believe that AztecNavigationController is a 'sibling' view to UIAlertController, rather than a parent view:

Is there perhaps another way to target the UIAlertController that I'm missing?

I checked the hierarchy and I believe that AztecNavigationController is a 'sibling' view to UIAlertController, rather than a parent view

Good catch! When I did my smoke test this code was still active so I thought the appearance proxy umbrella covered it. 👍

Is there perhaps another way to target the UIAlertController that I'm missing?

I'll look into this.

👋 @SiobhyB - This doesn't solve all the UIAlertController cases, but what do you think about adding alert.view.tintColor = .editorPrimary here to explicitly set the "More Sheet" tint color?

WordPress-iOS/WordPress/Classes/ViewRelated/Gutenberg/GutenbergViewController+MoreActions.swift

Lines 16 to 18 in 9f4c72a

let alert = UIAlertController(title: nil, message: nil, preferredStyle: .actionSheet)

if mode == .richText, let contentInfo = contentInfo {

For UIAlertControllers created on the RN side (e.g. Image block -> Add Image -> Choose image), is there a reason why we're not trying to enforce the tint from there (if that's possible)? Or perhaps RN has no concept of the branding colors?

If this can't be controlled / set from the RN side, I currently can't think of a better solution than what you have @SiobhyB. It's fascinating to me that the bottom sheet being presented by the editor isn't a descendant.

For UIAlertControllers created on the RN side (e.g. Image block -> Add Image -> Choose image), is there a reason why we're not trying to enforce the tint from there (if that's possible)? Or perhaps RN has no concept of the branding colors?

Woah, yes, I just tested this quickly and it seems possible! It seems such an obvious solution, not sure why I went down such a complicated road with it now. 🤦‍♀️ Thanks so much @twstokes, I'll work on a Gutenberg PR.

I've gone ahead to create that PR at WordPress/gutenberg#42996 and have removed the (now redundant) calls within iOS in a67b94b.

Co-authored-by: David Calhoun <[email protected]>

SiobhyB · 2022-08-03T10:37:30Z

Thanks so much for your review so far @dcalhoun!

I think it may be appropriate to request additional review from a more experienced iOS developer as well. That person may have ideas on alternative approaches.

+1, some of the approaches I've taken feel very hacky and I suspect I arrived at them due to lack of iOS knowledge rather than a lack of cleaner alternatives. @twstokes, 👋 , would you perhaps have availability to review this PR? Thanks in advance!

Co-authored-by: David Calhoun <[email protected]>

With this commit, a redundant call to the PostSettingsViewController's 'UITableView' is removed. This call is 'covered' already by targeting AztecNavigationController's 'UITableView'. In addition, instead of targetting PostSettingsViewController's UISwitch, this commit updates the target to AztecNavigationController. AztecNavigationController is higher up in the view hierarchy, so will capture more UI elements.

peril-wordpress-mobile · 2022-08-04T10:34:36Z

	Warnings
⚠️	PR is not assigned to a milestone.

Generated by 🚫 dangerJS

twstokes · 2022-08-04T21:20:15Z

One thing I noticed @SiobhyB was that Jetpack green was still coming through when selecting multiple items from the WordPress Media Library (Image Gallery block -> Add Media -> WordPress Media Library). This is partially affected by the call here to set the tint color of the cells.

The footer also had green views, so they may be explicitly set as well.

These calls are going to be replaced with direct calls in Gutenberg: WordPress/gutenberg#42996

SiobhyB · 2022-08-05T09:19:48Z

@twstokes, @dcalhoun, thank you both for all your help with this. 🙇‍♀️

I've gone ahead to update the PR and, as it stands, it achieves the following for the Jetpack app:

Updates the colour of UI elements within the main editor (e.g. cursor, highlight) from green to blue.
Updates the accent of sub screens within Post Settings from green to blue.

The reset hack for the parent category screen has been left here, in order to avoid a single random screen with green remaining under Post Settings:

WordPress-iOS/WordPress/Classes/System/WordPressAppDelegate.swift

Lines 889 to 893 in 56dab96

    
           /// Sets the `tintColor` for parent category selection within the Post Settings screen 
        
           UIView.appearance(whenContainedInInstancesOf: [PostCategoriesViewController.self]).tintColor = .editorPrimary 
        
           /// It's necessary to target `PostCategoriesViewController` a second time to "reset" the UI element's `tintColor` for use in the app's Site Settings screen. 
        
           UIView.appearance(whenContainedInInstancesOf: [PostCategoriesViewController.self, WPSplitViewController.self]).tintColor = .primary

Let me know if there's a better approach for handling that.

I removed the reset option for the featured media selection, as that modal feels a bit more separate to the Post Settings screen to me and not as jarring. There's also still pending work to be done on the media selection within blocks and on the Android side, so I think it seems logical to group work together in future PRs for that..

I've summed up where we're at in a comment on the original issue here and the remaining inconsistencies are as follows:

The media picker (available from media blocks and the Post Settings screen) still has some green.
There is still green visible in other screens 'connected' to the editor, such as Preview, History, Help & Support, etc.

Do you think it'd make sense to ship this PR's improvements and handle the remaining issues separately? Looking forward to hearing your thoughts.

twstokes · 2022-08-05T12:18:40Z

@twstokes, @dcalhoun, thank you both for all your help with this. 🙇‍♀️

I've gone ahead to update the PR and, as it stands, it achieves the following for the Jetpack app:

Updates the colour of UI elements within the main editor (e.g. cursor, highlight) from green to blue.

Updates the accent of sub screens within Post Settings from green to blue.

The reset hack for the parent category screen has been left here, in order to avoid a single random screen with green remaining under Post Settings:

WordPress-iOS/WordPress/Classes/System/WordPressAppDelegate.swift

Lines 889 to 893 in 56dab96

/// Sets the `tintColor` for parent category selection within the Post Settings screen

UIView.appearance(whenContainedInInstancesOf: [PostCategoriesViewController.self]).tintColor = .editorPrimary

/// It's necessary to target `PostCategoriesViewController` a second time to "reset" the UI element's `tintColor` for use in the app's Site Settings screen.

UIView.appearance(whenContainedInInstancesOf: [PostCategoriesViewController.self, WPSplitViewController.self]).tintColor = .primary

Let me know if there's a better approach for handling that.

That makes sense to me @SiobhyB!

Do you think it'd make sense to ship this PR's improvements and handle the remaining issues separately? Looking forward to hearing your thoughts.

I think that's fair. Thanks for all your hard work and attention to detail!

Update editor's tint colour to always be WP Blue

d22a59e

The editor's "tintColor" is explicitly set to be "wordPressBlue" with this commit. The most notable colour that will change following this is the editor's cursor and "highlight" colour when text is selected.

SiobhyB added the Gutenberg Editing and display of Gutenberg blocks. label Jul 25, 2022

SiobhyB self-assigned this Jul 25, 2022

SiobhyB added Jetpack [Status] DO NOT MERGE labels Jul 25, 2022

SiobhyB added this to the 20.5 milestone Jul 25, 2022

SiobhyB added 3 commits July 25, 2022 22:22

Update tintColor to match correct shade of blue

0948e1e

Merge branch 'trunk' into gutenberg/incorporate-consistent-tint-color

b68465a

Update RELEASE-NOTES

5ee8d0c

SiobhyB changed the title ~~[Gutenberg] Set consistent cursor/highlight colours in both the WordPress and Jetpack apps~~ [Gutenberg] Set consistent editor colours in both the WordPress and Jetpack apps Jul 25, 2022

SiobhyB removed the [Status] DO NOT MERGE label Jul 26, 2022

SiobhyB marked this pull request as ready for review July 26, 2022 10:07

SiobhyB requested a review from dcalhoun July 26, 2022 10:07

dcalhoun reviewed Jul 26, 2022

View reviewed changes

WordPress/Classes/ViewRelated/Gutenberg/GutenbergViewController.swift Outdated Show resolved Hide resolved

SiobhyB added 4 commits July 26, 2022 16:27

Set tintColor for *entire* editor window

38aac84

Clarify purpose of code in comment

feb03ea

Tidy up code for clarity and conciseness

c85beaf

Merge branch 'trunk' into gutenberg/incorporate-consistent-tint-color

b4efa6a

SiobhyB added 8 commits July 27, 2022 20:44

Revert previous changes

256a4d2

Setting the tintColor to the entire window caused colours to be set elsewhere in the app. As such, this commit, reverts that change and limits the tintColor to the editor's root view.

Set tintColor for modals

9e64f2b

Merge branch 'trunk' into gutenberg/incorporate-consistent-tint-color

77e8e32

Set tintColor to Post Settings screen

4fa4d0c

Set tintColor for last Post Setting UI elements

a1cce52

Add editorPrimary var for clarity and reusability

324fe7b

Address mistake in previous commit

f4eb426

In the previous commit, I accidentally committed the reference to "editorPrimaryLight", but hadn't intended to. This commit removes that reference and adds back the "editorPrimary" function that was accidentally deleted.

Set tintColor on Post Settings' date picker

b6b76c5

SiobhyB added 8 commits August 2, 2022 15:26

Update tintColor used in Post Settings media pick

0e3821d

Add clarifying comments

233825f

Apply tintColor to Post Settings tag selection

fe50487

Add clarifying comments to code

10ed59f

Merge branch 'trunk' into gutenberg/incorporate-consistent-tint-color

43b9994

Revert accidental commit to previewController

1d5ba16

This change was committed accidentally, and won't be a part of this PR's changes.

Tweaks to comment spacing/wording for clarity

e034bc6

SiobhyB requested a review from dcalhoun August 2, 2022 16:16

dcalhoun reviewed Aug 2, 2022

View reviewed changes

Add clarifying comment

1eeb3ef

Co-authored-by: David Calhoun <[email protected]>

SiobhyB requested a review from twstokes August 3, 2022 10:34

SiobhyB and others added 2 commits August 3, 2022 11:46

Add clarifying comment

6b2d0d9

Co-authored-by: David Calhoun <[email protected]>

Merge branch 'trunk' into gutenberg/incorporate-consistent-tint-color

9f4c72a

SiobhyB added 2 commits August 4, 2022 23:01

Remove calls to change editor action sheets

a67b94b

These calls are going to be replaced with direct calls in Gutenberg: WordPress/gutenberg#42996

[Code quality] Refine calls to UI elements

56dab96

SiobhyB mentioned this pull request Aug 5, 2022

Make colors of editor’s UI to be consistent in the Jetpack app wordpress-mobile/gutenberg-mobile#5047

Open

SiobhyB removed this from the 20.5 milestone Aug 5, 2022

twstokes approved these changes Aug 5, 2022

View reviewed changes

SiobhyB added this to the 20.5 milestone Aug 5, 2022

SiobhyB merged commit aa12198 into trunk Aug 5, 2022

SiobhyB deleted the gutenberg/incorporate-consistent-tint-color branch August 5, 2022 18:30

SiobhyB mentioned this pull request Jan 11, 2023

Jetpack app: Update tint color in editor's navigation bar #19887

Merged

4 tasks

	class func configureDefaultTint() {
	UIWindow.appearance().tintColor = .primary
	}

	override func present(_ viewControllerToPresent: UIViewController, animated flag: Bool, completion: (() -> Void)? = nil) {
	super.present(viewControllerToPresent, animated: flag, completion: completion)

	let presentedView = presentedViewController?.view
	presentedView?.tintColor = .editorPrimary
	}

	/// Sets the `tintColor` for parent category selection within the Post Settings screen
	UIView.appearance(whenContainedInInstancesOf: [PostCategoriesViewController.self]).tintColor = .editorPrimary

	/// It's necessary to target `PostCategoriesViewController` a second time to "reset" the UI element's `tintColor` for use in the app's Site Settings screen.
	UIView.appearance(whenContainedInInstancesOf: [PostCategoriesViewController.self, WPSplitViewController.self]).tintColor = .primary

		// Resets the action sheet's tintColor to `.primary` to prevent `.editorPrimary` being set as the tintColor for UI elements outside of the editor.
		UIView.appearance(whenContainedInInstancesOf: [UIAlertController.self]).tintColor = .primary

	let alert = UIAlertController(title: nil, message: nil, preferredStyle: .actionSheet)

	if mode == .richText, let contentInfo = contentInfo {

[Gutenberg] Set consistent editor colours in both the WordPress and Jetpack apps #19113

[Gutenberg] Set consistent editor colours in both the WordPress and Jetpack apps #19113

Uh oh!

Conversation

SiobhyB commented Jul 25, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Screenshots

Testing

Code Changes

Root React Native View

React Native Modals

React Native Action Sheets and Switches

Post Settings Screen

Regression Notes

Uh oh!

wpmobilebot commented Jul 25, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wpmobilebot commented Jul 25, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dcalhoun left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

SiobhyB commented Jul 26, 2022

Uh oh!

dcalhoun commented Jul 26, 2022

Uh oh!

SiobhyB commented Aug 2, 2022

Uh oh!

dcalhoun left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SiobhyB commented Aug 3, 2022

Uh oh!

peril-wordpress-mobile bot commented Aug 4, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

twstokes commented Aug 4, 2022

Uh oh!

SiobhyB commented Aug 5, 2022

Uh oh!

twstokes commented Aug 5, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

SiobhyB commented Jul 25, 2022 •

edited

Loading

wpmobilebot commented Jul 25, 2022 •

edited

Loading

wpmobilebot commented Jul 25, 2022 •

edited

Loading

peril-wordpress-mobile bot commented Aug 4, 2022 •

edited

Loading

twstokes commented Aug 5, 2022 •

edited

Loading