-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Launchpad: Update tasks to redirect into site-editor edit mode #72339
Conversation
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: Sections (~10 bytes added 📈 [gzipped])
Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to. Legend What is parsed and gzip size?Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Generated by performance advisor bot at iscalypsofastyet.com. |
cc: @roundhill & @jgcaruso - I added a minor change related to the videopress flow. Can you review these changes? |
@@ -811,6 +812,7 @@ const mapStateToProps = ( | |||
...pressThisData, | |||
answer_prompt: getQueryArg( window.location.href, 'answer_prompt' ), | |||
completedFlow, | |||
...( canvasEditMode && { canvas: canvasEditMode } ), |
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 think we should simply assign this at all times. We don't want to be sending people into the template selection mode at all, ever.
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 seems sensible to me. But one concern is that changes goes well beyond our current use case and seems to change the calypso site editor handling/display for all cases. That seems like a big change, and I I wonder if that warrants wider discussion beyond our team?
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 in agreement with Matt here. We don't want to surface this to our users by default in any entry the way it is right now. But we may be able to in the future after core has iterated on its development.
With that it's important to leave a clear comment that we are doing this.
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 seems sensible to me. But one concern is that changes goes well beyond our current use case and seems to change the calypso site editor handling/display for all cases. That seems like a big change, and I I wonder if that warrants wider discussion beyond our team?
To me the big change was in Gutenberg that started exposing this to our users by default. It is still being iterated on, but is currently not in a place that is good for us to expose by default to our users on dotcom.
We relayed some of this feedback to core in this p2: p9Jlb4-6ad-p2#comment-6657, expressed desire to be able to bypass this, and were soon after notified that a change had been implemented that would allow us to do so.
We also reached out to team-calypso in slack to make them aware of this change, and present them the option to handle it on their end since they generally handle things around the gutenberg upgrade cycles. They responded that they would be happy for us to handle this, which we are happy to do 😁 p1673663392570019/1673546040.780839-slack-C7YPUHBB2
This tests well for me.
Code changes also look good and straightforward. |
Correct, the site editor link is just a fallback for an extreme case where the Home page id can't be found. Not actually testable without modifying the code to force it into the fallback condition... which I did to test this and the new query param whether there or not seems fine to me. |
@jgcaruso - I reverted the changes since we will just default to edit mode when navigating to the site editor. Thanks for testing. |
This tests well for me: |
* Pass site-editor canvas mode query param to iframe * Update launchpad site-editor navigation * Default to site editor "edit-mode" * Revert site editor route changes
Estimated Time to Test / Review:
Test -> Short
Review -> Short
Proposed Changes
The latest Gutenburg site editor changes will open the sidebar by default when users navigate to
/site-editor/{siteSlug}
. This may be confusing for users as we try to direct them towards the template/content editing view.Testing Instructions
/setup/free/
or/setup/link-in-bio/
) or use existing siteEdit site design
task. Confirm it navigates directly into site-editor edit mode.Add links
task. Confirm it navigates directly into site-editor edit mode./setup/videopress
) and click theUpload your first video
task. Confirm that it navigates into site-editor edit mode.Pre-merge Checklist
Related to #72019