* dry getAllTemplates util
* Improve goToSiteEditor e2e util
It will now properly wait for page to load
and critical parts to be available before
handing control over to the next steps
* adapt site editing tests to new goToSiteEditor API
* try to stabilize the saveTemplate
to early navigation was causing the dreaded
"Expected an Error, but "" was thrown"
* try stabilizing saveTemplate
* contextually group/sort params
* improve clarity of the goToSiteEditor E2E util
- adds goToSiteEditor private helper that hides the temporary need
for handling theme.php and site-editor.php paths
- adds two exported utils goToTemplatesList and goToTemplateEdit
that hide UX details of waiting ofr page to be ready on load including special
case for waitingFor templates list actions to be loaded
* put back page where it belongs ⚡️
* Add handling of editor context via GUTENBERG_EDITOR_CONTEXT env var
* Fix flaky tests around editing templates
* Wait for save template response to complete
The internal ID has been kept after a comment by @tjcafferkey. This causes a
bit of inconsistency in the internal code, but it was deemed that it would have
been better as users who have customized templates using this
blocks ID will have saved this in their database, and it would result
in a corrupt block when loaded, and we didn't want to support both IDs at the
moment.
Otherwise, most other references to the legacy template, are now using the word
“classic”.
Co-authored-by: Alba Rincón <alba@albasauatticmbp.home>
* Change atomic blocks to not use custom webpack build paths
we want to always load lazy loaded components from their default paths
to avoid having to handle importing components in different ways for
regular and atomic component packages
* Add footer parts to test themes
The Site Editor is expecting the footer parts to be there or it will try to
load them anyways and throw a 404. It's not breaking, but it's polluting
the console.
* Use REST API to tear down the templates
Previously, we used a util called `trashAllPosts` which navigated to the post UI
and deleted all the posts to tear down any side-effects of template editing tests.
However, with a [recent change](14e20f72b5),
WP Core removed the UI for those and that made our tests meet a 500 error.
Using the REST API should also make everything faster.
* Remove deprecated pupeteer waitFor usage
was still present in attribute-filter.test.js
* Update package-lock.json
* pin package versions
* Unify all atomic blocks to register on php side
* Remove Atomic Blcoks chunk_translation handling from AllBlocks
Before it was responsible for enabling translations for all the atomic blocks
* Add per atomic block chunk_translation registration
* update @wordpress/e2e-test-utils to 6.0.2
* add optional puppeteer
* pin workflows node version to 16.13.2
* upgrade package-lock
* upgrade package-lock
* set react and react-dom as peerDeps
* remove atomic block registration
Co-authored-by: Lucio Giannotta <lucio.giannotta@a8c.com>
Co-authored-by: Luigi <gigitux@gmail.com>
This PR adds a block-enabled theme with templates for WooCommerce
which is intended to be used when testing the more complex scenarios
such as template fallbacks.
Additionally, since theme-dependent logic seems to be becoming more
and more useful (see woocommerce/woocommerce-blocks#5913), this PR also adds a utility function used to
explicitly declare theme dependencies of a test (`useTheme`).
Said function will activate the theme before running a given suite and then
reactivate the previous theme, as to make sure to not have any side-effects
(such as the ones described in woocommerce/woocommerce-blocks#5913 above).
Closeswoocommerce/woocommerce-blocks#5660
Also:
* Refactors the function to add a custom paragraph
* Add front-end test for archive template
* Use WordPress data to guarantee block presence
* Use WordPress data instead of selectors to match blocks
Luigi Teschio
Tomasz Tunik
Alba Rincón
Lucio Giannotta