[Corvid CLI] Use local "Published" version of the site for testing

Ask the community
1

Hello,

Please see the below time-sensitive request.
We are aware Corvid CLI is in Alpha, and would appreciate any help the Corvid team can provide.

Thanks very much!

Bug description

When using the local editor npx corvid open-editor, it is not possible to see the “Published” version of the site. Wix has some limitation to this version when using some Corvid APIs, like wix-users or wix-pay, which do not allow to test their functionalities on “Preview” mode.

Therefore, when using the local editor, it is not possible for us to test such important parts of the site like the use of another User with other roles than ‘Admin’. To do that, you must Push your site, with all problems that implies in the development workflow that accounts on the local revisioning of the site.

Steps to reproduce it

  1. Clone wix site with corvid-cli npx corvid clone <siteurl>
  2. Open editor with corvid-cli npx corvid open-editor
  3. Preview site to test.
  4. Try to log in as a different user.
  5. A note pops up redirecting to the “Published” site, but we are on the Local Editor and there is no way to go to a “Published” version locally.

Expected behavior

The expected behavior would be to be able to see a local version of the “Published” site under a local server on your machine, without the necessity to Push the local changes. And therefore be able to use the functionalities of wix-users locally as well.

Screenshots

See the illustrated problem in the screenshot below:

1010×602 265 KB

Version used

  • OS: macOS Mojave 10.14.5 (18F132)
  • Version: Corvid CLI v0.1.76

Link to other bugs

https://www.wix.com/corvid/forum/community-discussion/bug-corvid-cli-unexpected-and-undesired-changes-into-the-database
https://www.wix.com/corvid/forum/community-discussion/bug-corvid-cli-problems-creating-dynamic-pages

#bug #corvid #cli #corvidcli #localeditor #local #editor #environment #dynamicpages #dynamic #create #page #dynamicdataset #dataset

2

We are also trying to use this Alpha feature to ease collaboration and release management.

The way I’m planning to sidestep the issues you describe above is to clone a release candidate version of the site.
When your local development is done and tested (except for the user related features that, as you pointed out, cannot be tested in preview), you would:

  1. create a local clone of the release candidate site.

  2. then merge your developed features (which may be from multiple developers’ local dev) into this local release candidate clone

  3. and push it to the release candidate site for online integration testing.
    This isn’t perfect because the member data will be empty so you’ll need to dummy up some members, but by and large you should be able to test the member related features.

  4. Once your release candidate is tested and good to go, you would pull it again into local and merge it with the current local version of your production site,

  5. then push that final release to production.

Hope this helps.
If anyone has a better suggestion please chime in.