The migration module is used to initiate the migration process by installing the required plugins for migration.

• It installs the instawp-connect plugin and connects the website with it.
• It triggers the events based on update option hook when instawp updates the instawp_last_migration_details value in database.

• Migration process is initiated when user hits the endpoint ( /newfold-migration/v1/migrate/connect ).
• It triggers the migration initiation process when nfd_migrate_site key gets updated in the database.

• When user hits the endpoint or updates the value in db, it installs the plugin and connects the plugin with the website and returns a url.
• Once you're redirected to the url, you'll be taken to instawp screen where it'll ask you for source website that you wanted to migrate and migration starts here and completes in the instawp screens only.
• As soon as the migration gets completed, the current BH plugin which is present in destination site is being replaced with the latest BH plugin from hiive url. Instawp is updating the db value instawp_last_migration_details with the respective status, which we're using to trigger the events ( migration_completed, migration_failed ) based on update hook of that value and doing the post migration logic here updating the db value to show migration steps in brand plugin dashboard.

composer config repositories.newfold composer https://newfold-labs.github.io/satis

composer require newfold-labs/wp-module-migration

If you're doing something that will not break anything or not adding any new dependency. But, only doing basic stuff like bug fixes, copy changes etc. Change which doesn't really impact the plugin in bigger way you can put them under the last number of versions.

If you're doing something, like adding a new library, or changing something in the way the plugin can use our module then it's better to upgrade the minor version which is the 2nd digit of version.

In rare scenarios, like UI redesign where the change is bigger or a major refactor, we update the 1st digit of version.

1. Merge approved PRs into trunk branch

2. Do version update to new one in package.json and update the version in bootstrap.php

3. Run npm install (this will auto update version in package-lock.json)

4. Commit above change in separate commit (commit message: Bump to new version value)

5. Go to GitHub Releases

6. Click on Draft a new release button.

7. By default, you'll always create a release from target: trunk branch.

8. Give V version that you want to release and click on create a new tag.

9. Click Generate release notes button. It will basically collect all the pull requests that came in from the previous release to now and then just create a summary. (It won't track any direct comments to the trunk. It will just only track pull requests.)

10. Keep Set as the latest release checkbox checked as it is by default.

11. Click Publish a release button.

12. Go to Satis. Satis is a PHP registry for our packages.

13. On above URL in package filter, you can search for migration.

14. We have set up an integration within our workflow itself so once the workflow completes, we trigger an alert to Satis that a newer version of the migration module is released and rebuild Satis so that it can show the newer version in packages (Repo: Satis Actions)

15. The newer version will appear in 5 to 10 minutes of rebuilding.

16. You can check the status of Satis build & Publish workflow here.

17. On successful completion, you can see the latest package here.

1. In composer.json file, update the version of newfold-labs/wp-module-migration.

2. In package.json file, update newfold-labs/wp-module-migration to the new version number.

3. Run command:

   npm i --legacy-peer-deps

4. package-lock.json should auto update.

5. Once Satis starts showing the updated version, run the below command for composer update:

composer update newfold-labs/wp-module-migration -W

6. Create a branch (naming convention: update/wp-module-migration-version_number).

7. Currently, we don't have the permission to publish directly to the BlueHost plugin. So, we need to create a fork of the repo, push it to that fork, and then create a pull request against the develop branch.

8. The new release process is thus completed. More on NewFold WordPress Modules