Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
E2E Utils: add setPreferences and editPost utils #55099
E2E Utils: add setPreferences and editPost utils #55099
Changes from 7 commits
fe70678
aecd765
ecef484
86c8f79
a3c356e
8ac5f11
148c15b
c3f20f5
ddfd869
256f5b9
34f93b3
6e5feb7
59720fe
d2aba51
9559d8e
7658a0a
36b26c2
99c2b2d
8b7ffd2
fa96ad2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
This file was deleted.
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 curious to know if we need to do this every time, seems wasteful to me. Could we just do this in
global-setup
with a network request? I know that the preference API doesn't seem stable in e2e tests though 😅,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 like the idea. The only time the welcome guide needs to be enabled is when we're actually testing it.
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.
Is there an existing util for setting prefs via a network request? 🤔
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.
Now that we have the opportunity to refactor this, I wonder if we should just combine
createNewPost
andvisitPostEditor
?WDYT?
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.
Combined in 59720fe.
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.
A few notes on this:
@wordpress
packages try to follow the same rules as WP regarding backward compatibility.createNewPost
action.@WunderBart, I guess we can make
createNewPost
a wrapper aroundvisitPostEditor
. We just need to make sure that the argument signature is the same.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.
The wrapper idea makes sense to me. cc @kevin940726 if he has any objections here!
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 actually starting to lean in this direction as well. The main issue with merging createNewPost and visitPostEditor are the props (and their typing) that can be confusing (e.g. if postId is passed, all the props for creating a new post are ignored). Personally, at this point I also feel like a more explicit approach would be better - keep the
createNewPost
and implementeditPost
instead ofvisitPostEditor
. For the Site Editor, it makes sense to be reachable byvisitSiteEditor
because there's only one URL we can visit it by: /site-editor.php.Sorry for going back and forth with it, but I just want to avoid overcomplicating stuff (which I might already be doing 😅). Please let me know if the above would make sense to you!
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.
100% - I think this fits the WP glossary around posts much better.
No worries. It's easier to anticipate what would work best when we try. Thanks for taking the time and experimenting with different approaches.
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 appreciate the discussions and I agree with the final solution we settled on too! Thank you all 🧡
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 code removal doesn't look related to the changes proposed in this PR. As discussed in #54911, there were usually good reasons for introducing similar guardrails.
Maybe we should split this into a separate PR. What do you think?
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.
Ugh, nice catch! I actually forgot to restore this part. I wasn't planning on removing it in this PR, only running a single round without it to see how it goes. Restoring it now.
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.
It's good, though, that now we know only perf tests fail without it - these tests require specific handling, so it might be good to move this safeguard there if it's not necessary here for the regular E2Es. Anyway, it's just a note for myself, I guess - let's leave that for another PR.
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.
Restored in 9559d8eSee comment belowThere 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 had to remove it as the slight timing change caused by using
setPreferences
invisitSiteEditor
revealed that the part above is actually faulty. Before, it checked the canvas iframe(s) before they were attached, so that check has always been skipped and moved instantly to wait until the loading spinner is hidden. Now, becausesetPreferences
adds a little delay by waiting until thewindow.wp.data
is available, all the editor iframes get attached in the meantime, which ends up violating the locator strict mode:ℹ️ The other iframes are previews of the patterns created in that test.