hosting

POST /v1/sites/{siteId}/wordpress/staging/publish

Publish a site's staging WordPress over the live site.

همه نقاط پایانی hosting

احراز هویت

یک کلید API را به عنوان یک توکن حامل ارسال کنید. این کلید باید دارای مجوز sites.view باشد؛ کلیدی که فاقد آن باشد با خطای 403 رد می‌شود، نه 404.

این نقطه پایانی هیچ شناسه سازمانی را دریافت نمی‌کند. کلید شما در حال حاضر سازمان مربوطه را مشخص می‌کند و پاسخ در همان محدوده ارائه می‌شود.

امتحان کنید

هر چیزی را که داخل براکت‌های زاویه‌دار قرار دارد با مقادیر خودتان جایگزین کنید، و نگهدارنده کلید را با کلیدی از داشبورد خود جایگزین نمایید.

curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/wordpress/staging/publish \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{  }'

وارد شده‌اید؟ کنسول API در داشبورد شما شناسه سازمان واقعی و کلید خودتان را پر می‌کند و درخواست را روی API زنده اجرا می‌کند تا بتوانید پاسخ واقعی را ببینید. این نقطه پایانی را در کنسول API باز کنید

جزئیات

⛔ **The most destructive operation on the managed hosting line**: the live site's files and database are replaced by the staging clone's. Its own path, so no request aimed at any other staging operation can reach it. ⛔⛤ **The one optional field, `mode`, selects SCOPE and never DIRECTION.** This path exists separately from `createSiteWordPressStaging` precisely so that no field can flip which way the copy runs — on managed shared hosting both directions are driven from a single value, and one passthrough endpoint would let a request reading as *"refresh my staging copy"* publish a stale clone over a live shop. Every value of `mode` copies staging onto live; it says only how much travels. A field that could change the direction must never be added here. ⛔ **A scope the site's platform cannot honour is refused `422`.** Read `publish_modes` on `SiteWordPressStaging` first and offer only what it lists: the Zinn® autoscaling platform performs `files`, `db` and `both`, and managed shared hosting performs `both` only, because its staging operation takes no scope at all. That is a property of the platform, not of the customer's plan — a larger package does not add a database-only publish. Refused `422` when the site has **no staging clone** — the platform does not check, and would happily publish an empty staging environment over a live shop. The client is required to take a typed confirmation naming the site. `202` because the publish continues at the vendor after the acknowledgement. `404` for a site with no vendor hosting package. Requires `sites.view` and `sites.panel_access`.

پارامترها

نامنوعالزامیچیست
siteId (path)UuidبلهSite ID (UUIDv7).

بدنه درخواست

نامنوعالزامیچیست
modestring<files, db, both>خیر`files` copies the document root and leaves the live database alone; `db` copies the database and search-replaces the staging URL back to the live one, leaving the live files al…

پاسخ

نامنوعالزامیچیست
permittedbooleanبلهWhether this site may use WordPress staging at all — on the resold range the package type's own flag, and on our own fleet the plan's `staging` entitlement.
publish_modesstring<files, db, both>[]بلهWhich publish scopes this site's **platform** can actually perform, for `publishSiteWordPressStaging`. A client offers exactly these and no more. ⛔⛔ **This is not a permission a…
publishablebooleanبلهWhether the plan also carries **publish to live**, which is a separate permission from creating a staging copy. ⛔ Not folded into `permitted`, because the catalogue sells the tw…
reinstallablebooleanبلهWhether the plan carries **reinstalling** the platform software over the staging copy. A fifth question for the same reason as `publishable`: the catalogue sells it separately,…
operationsSiteWordPressStagingOperation[]بلهThe site's recent staging operations, newest first — the client's window onto work that runs **after** the request returns. ⛔⛔ **Creating, publishing, deleting and reinstalling…
dataSiteWordPressStagingClone[]بلهThe staging copies that exist.

خطاهایی که این نقطه پایانی می‌تواند برگرداند

401 · 403 · 404 · 409 · 422 · 429 · 503