[KUBE](../README.md)  /  Transfer sites # Transfer sites > [!NOTE] > In progress... - [Transfer via console](#transfer-via-console) - [Transfer via plugin Wordpress](#transfer-via-plugin-worpress) - [Workflow 1. Cloning a website via the WordPress plugin](#workflow-1-cloning-a-website-via-the-wordpress-plugin) - [Workflow 2. Cloning websites to SODEW servers via the WordPress plugin](#workflow-2-cloning-websites-to-sodew-servers-via-the-wordpress-plugin) - [Workflow 3. Detailed description of the process](#workflow-3-detailed-description-of-the-process) ## Transfer via console: ```bash sudo kube.sh --worker task [domain] ``` ### Configuration analysis. Example: ```ini action=test files_url=https://wp.krumax.cz/transfer_36b91e68-53d3-49ac-922a-0031e664125b/2b3d170e-9f50-435c-b189-b8c3a45cbb8a.zip database_url=https://wp.krumax.cz/transfer_36b91e68-53d3-49ac-922a-0031e664125b/2b3d170e-9f50-435c-b189-b8c3a45cbb8a.sql.zip domain=new.domain.com status=new ``` Where: * `action` — the main operation (`copy`/`test`/`migrate`/...) * `files_url` — link to the files archive * `database_url` — link to the DB archive * `status` — execution status: * `new` - new task * `execution` - in progress * `success` - task completed successfully * `failed` - task failed * `domain` - new domain (optional field) > [!NOTE] > Working only action `test` (18.11.2025). > [!NOTE] > If a domain is specified in the command call, the domain from the configuration file is ignored. > [!NOTE] > If the domain is not specified in the command and not specified in the configuration file, it will be assigned automatically from the available ones (`domainsList`). If none are available, the task fails. ### Work **Stage 1**. Configuration analysis. **Stage 2**. Availability check and archive download. The download is performed into the folder `//`: * `//.zip` — files archive * `//.sql.zip` — DB archive **Stage 3**. Depending on the task: * `test` - A site is created based on the downloaded backup. * `copy` - in progress... * `migrate` - in progress... **Stage 4**. The status is changed in the configuration file * `success` - upon successful completion of the task * `failed` - upon errors at any stage ## Transfer via plugin Wordpress When using the plugin "SODEW Backup & Transfer" ([https://gitlab.wedos.org/mk250/transfer-plugin](https://gitlab.wedos.org/mk250/transfer-plugin)), it is possible to copy a site to SODEW hosting. ### Preparation **Stage 1**. Create a full site backup in the plugin. **Stage 2**. Create a task "Launch a copy of the website on SODEW hosting". ### Work **Stage 1**. Sending a request to create a copy of the site for testing to `api.sodew.ai`. Request parameters: * `action` – selected action * `transfer_id` – plugin identifier * `backup_id` – backup identifier * `base_url` – site URL (WordPress) * `base_path` – base path Example: ```json [ "action":"test", "transfer_id":"22222222-53d3-49ac-922a-0031e664125b", "backup_id":"33333333-c976-43c2-bdee-d7d6ec21900a", "base_url":"https://wp.us1.com", "base_path":"/usr/www/wp.us1.com", ] ``` **Stage 2**. Processing the request on the `api.sodew.ai` side. 1. Parameter validation 2. Preparation and validation of URLs to the backup: ```ini /transfer_/.zip /transfer_/.sql.zip ``` 3. Creating a task for Workers **Stage 3**. Request from the Worker (agent) to `api.sodew.ai` to obtain a new task and receiving it. The task is assigned to the Worker. **Stage 4**. Processing of the `api.sodew.ai` response by the Worker (agent) and creating a task for the `kube.sh` script. A task file `.task` is created in the `workerTasksPath` folder with the following content: * `action` – action * `files_url` – URL to the files archive * `database_url` – URL to the database archive * `domain` – domain (optional) * `status` – new (task status: new) **Stage 5**. Launching the `kube.sh` task handler via CRON, searching for new tasks and starting execution of the found new task. **Stage 6**. Validation of the task parameters. Checking the availability of backup files. Downloading the backup files. Creating the site. (Detailed: [Transfer](#transfer)) **Stage 7**. Monitoring of the task execution status by the Worker (agent) and sending reports to `api.sodew.ai`. **Stage 8**. Receiving task execution reports from the Worker (agent). **Stage 9**. Updating the task execution status on `api.sodew.ai` by the plugin. ## Workflow 1. Cloning a website via the WordPress plugin. ```mermaid flowchart TB; subgraph SW[Server-worker] WO(Worker-observer
CRON) WA(Worker-agent) TP[[workerTasksPath/task_id.task
action
files_url
database_url
status=new]] CS[Сopy of user's website] end subgraph API[api.sodew.ai] AT(task_id
files_url
database_url) end subgraph US[User site] WP(Plugin WP
action
transfer_id
backup_id
base_url) end WP -->|1. create task
check status| AT WA -->|2. get new task
send statuses| AT WA -->|3. save new task| TP WO -->|4. executing tasks| TP WO -->|5. load files| US WO -->|6. create site| CS ``` ## Workflow 2. Cloning websites to SODEW servers via the WordPress plugin. ```mermaid flowchart LR; US[[User sites...]] SW[[Server-workers...]] API(api.sodew.ai) US -->|tasks...| API -->|tasks...| SW ``` ## Workflow 3. Detailed description of the process. ```mermaid sequenceDiagram alt task Wordpress plugin ->> api.sodew.ai: new task loop every 30sec Wordpress plugin ->> api.sodew.ai: how status task? activate api.sodew.ai api.sodew.ai ->> Wordpress plugin: status task is ... deactivate api.sodew.ai end end loop every 30sec Worker-Agent ->> api.sodew.ai: receiving new tasks activate api.sodew.ai api.sodew.ai ->> Worker-Agent: deactivate api.sodew.ai activate Worker-Agent Worker-Agent ->> workerTasksPath: saving a new task deactivate Worker-Agent end loop every 15sec Worker-Agent ->> workerTasksPath: reading task statuses activate Worker-Agent Worker-Agent ->> api.sodew.ai: sending task statuses deactivate Worker-Agent end loop every 1min Worker-Observer ->> workerTasksPath: get new task Note over Worker-Observer: Execute task... end ```