Base ng Kaalaman

Paggawa sa isang site na ibinahagi sa iyo ng isang tao

Maaaring ibigay ng may-ari ng site ang isang site sa isang developer sa pamamagitan ng email — hindi ang kanilang account, hindi ang kanilang pagsingil, hindi ang kanilang iba pang mga site. Parehong bahagi: ang pagbabahagi at pagbawi nito mula sa dashboard, at ang pag-alis ng site gamit ang zinnector login, clone at dev, kasama ang database — pati na rin ang kaya at hindi kaya ng bawat tungkulin.

Ang may-ari ng site ay maaaring magbigay sa iyo ng access sa isa sa kanilang mga site — hindi ang kanilang account, hindi ang kanilang billing, hindi ang kanilang iba pang mga site — at nagtatrabaho ka dito gamit ang iyong sariling Zinn Digital® login at ang libreng Zinnector® CLI. Ang gabay na ito ay parehong kalahati nito: kung ano ang ginagawa ng may-ari, at kung ano ang ginagawa mo.

Kung hindi mo pa nagamit ang Zinnector® noon, ini-install ito ng Getting started with Zinnector® sa loob ng humigit-kumulang dalawang minuto. Walang anuman dito ang nangangailangan sa iyong bumili ng hosting.

Para sa may-ari ng site — pagbabahagi ng isang site

  1. Buksan ang site sa iyong dashboard at pumunta sa Security.
  2. Sa Who else can reach this site, piliin ang Share this site.
  3. I-type ang email address ng developer. Hindi pa nila kailangan ng account — kung hindi pa sila kailanman nag-sign in, makakatanggap sila ng imbitasyon at magsisimula ang access sa sandaling tanggapin nila ito.
  4. Pumili ng role:
  • Viewer — makakatingin, at walang mababago.
  • Editor — ang role na karaniwang kailangan ng isang developer. Maaari nilang baguhin ang mga file ng site, gamitin ang wp-admin, at mag-download ng archive ng site para magtrabaho nang lokal. Ang archive na iyon ay naglalaman ng database.
  • Manager — lahat ng magagawa ng editor, pati na rin ang pag-restore ng backup.
  1. Magbigay ng reason at, kung ang gawain ay may petsa ng pagtatapos, isang expiry. Ang grant ay hihinto lamang sa pagbilang sa petsang iyon; hindi mo na kailangang alalahaning alisin ito.
  2. I-save.

Anuman ang piliin mo, ang isang collaborator ay kailanman ay hindi maaaring mag-delete ng site, makita ang iyong billing, o maabot ang anuman sa iyong iba pang mga site.

Ang kahulugan ng "ang archive ay naglalaman ng database"

Ang isang editor o manager ay maaaring kumuha ng kopya ng site para pagtrabahuhan, at ang kopya ng isang site ay ang mga file nito at ang database nito. Ang isang WordPress database ay naglalaman ng anuman na ibinigay ng iyong mga bisita sa site — mga pangalan ng nagkomento at mga email address, mga account ng customer, mga order sa WooCommerce at mga address sa paghahatid, mga isinumite sa form.

Karaniwan na eksakto iyon ang kailangan ng developer: kung wala iyon, tinitingnan nila ang iyong theme laban sa isang blangkong site. Sulit itong malaman, dahil ito ay totoong personal na data at ang mga taong nagmamay-ari nito ay iyong mga customer, hindi sa amin.

Dalawang bagay ang sumusunod, at ginagawa ng platform ang pareho para sa iyo:

  • Ang bawat export ay nasa iyong audit log. Buksan ang Audit log at hanapin ang site.backup.exported. Ang bawat row ay nagbibigay ng pangalan kung sino ang kumuha nito, kailan, at kung ang archive na iyon ay nagdala ng database. Hindi mo kailangang magtanong.
  • Maaari mo itong tapusin sa anumang sandali. Agad ang pag-revoke — tingnan sa ibaba.

Kung mas gusto mong magtrabaho sila nang walang database, sabihin sa kanila na magdagdag ng --no-database kapag nag-pull sila; ito ay isang flag at ang natitira ay gumagana nang pareho.

Para sa developer — pagkuha ng site sa iyong makina

1. I-install ang Zinnector®

npm install -g zinnector
zinnector --version

Kailangan mo ng Node 24 o mas bago. Ang node --version ay dapat mag-print ng v24 o mas mataas.

2. Mag-sign in bilang iyong sarili

zinnector login

Binubuksan nito ang iyong browser at ini-sign in ka gamit ang iyong sariling Zinn Digital® account — ang pinadalhan ng imbitasyon. Hindi mo kailanman kailangan ang password ng may-ari, at hindi nila kailanman kailangang bigyan ka nito.

Suriin kung ano ang ibinigay sa iyo:

zinnector sites

Makikita mo nang eksakto ang mga site na ibinahagi sa iyo, at wala nang iba pa. Kung blangko ang listahan, ang imbitasyon ay hindi pa tinatanggap, o ang grant ay nai-revoke na o nag-expire na.

3. Hilahin pababa ang site

zinnector clone client-domain.com
cd client-domain.com

Ang clone ay gumagawa ng lokal na proyekto mula sa naka-host na site. Kumukuha ito ng:

  • wp-content — ang mga theme, plugin, mu-plugin, wika at media na sariling gawain ng site;
  • ang database, na isinulat sa database.sql sa proyekto.

Sadyang iniiwan nito ang WordPress core (nagbibigay ang iyong lokal na runtime ng tamang bersyon), wp-config.php (naglalaman ito ng password sa database ng live site), at anumang media na na-offload sa object storage.

Ang bawat run ay nag-print nang eksakto kung ano ang kinuha nito at kung ano ang iniwan nito, na may mga bilang. Kung gusto mo ang mga file lamang, magdagdag ng --no-database.

Mayroon na bang proyekto at gusto mo lang ang pinakabago? Patakbuhin ang zinnector pull sa loob nito.

4. Patakbuhin ito nang lokal, kasama ang totoong nilalaman

zinnector dev --runtime docker

Sa Docker runtime, ini-import nito ang database.sql, nire-rewrite ang URL ng site patungo sa iyong lokal na address, at binubuksan ang site na kasama ang totoong nilalaman ng customer dito. Mag-sign in gamit ang sariling mga WordPress account ng site.

Ang default runtime — ang WordPress Playground, na hindi nangangailangan ng Docker — ay mas mabilis simulan at hindi nag-i-import ng database; sasabihin ito sa iyo sa halip na tahimik na magsimulang blangko. Gamitin ito kapag nagtatrabaho ka sa code at hindi mo kailangan ang nilalaman.

5. Alagaan ang kopyang ibinigay sa iyo

Ang database.sql ay database ng isang live site. Idinaragdag ito ng Zinnector® sa .gitignore ng iyong proyekto sa sandaling isulat ito, kaya ang isang nakakalimutang git add -A ay hindi makapaglathala ng mga customer ng ibang tao sa isang repository. Hayaang mag-isa ang linyang iyon, at i-delete ang file kapag tapos na ang trabaho.

Kung ano ang magagawa at hindi magagawa ng isang collaborator

| | Viewer | Editor | Manager | |---|---|---|---| | Makita ang site at ang mga setting nito | ✔ | ✔ | ✔ | | Baguhin ang mga file, gumamit ng wp-admin, mag-deploy | | ✔ | ✔ | | Hilahin ang site, kasama ang database | | ✔ | ✔ | | I-restore ang backup sa ibabaw ng live site | | | ✔ | | I-delete ang site | | | | | Makita ang billing o mga invoice | | | | | Abutin ang iba pang mga site ng may-ari | | | |

Ang huling tatlong row ay blangko para sa bawat role. Hindi sila setting.

Pagtatapos ng access

Binubuksan ng may-ari ang seksyong Security ng site at pinipili ang Revoke sa tabi ng pangalan ng tao. Magkakabisa ito kaagad: ang susunod na Zinnector® command na tatakbuhin ng developer na iyon ay hindi makikita ang site, at gayundin ang anuman pang hawak nila.

Ginagawa ng expiry ang parehong bagay sa isang petsa, nang walang sinumang kailangang umalala. Kung nagtakda ka ng isa nang ibinahagi mo ang site, tapos ka na.

Kapag may isang bagay na hindi gumagana

  • Ang zinnector sites ay walang ipinapakita. Ang imbitasyon ay hindi pa tinatanggap, o ang grant ay nai-revoke o nag-expire. Hilinging tingnan ng may-ari ang seksyong Security ng site — nakatala doon ang isang nakabinbing imbitasyon.
  • Sinasabi ng zinnector pull na walang kamakailang backup ang site. Ang pull ay kukuha ng bago kung pinapayagan ito ng plano, at magatanong muna. Kung ang plano ay walang kasamang mga on-demand na backup, itaas ang --max-age para tanggapin ang mas lumang isa.
  • Nagsisimula ang zinnector dev ng blangkong WordPress. Ikaw ay nasa Playground runtime, na hindi nag-i-import ng database. Patakbuhin ang zinnector dev --runtime docker.
  • Ang lokal na site ay patuloy na nire-redirect patungo sa live domain. Nire-rewrite ng pag-import ang URL ng site; kung nabigo ang hakbang na iyon, sinasabi ito ng command at ipinrint ang linya ng wp search-replace na tatakbuhin.

Higit pang mga error at ang mga pag-ayos sa mga ito: Zinnector® troubleshooting.

Lahat ng mga dokumento ng developer

Pinakabago mula sa blog

Ang aming isinulat tungkol sa hosting, SEO at pagpapatakbo ng mga site sa malaking saklaw.

SEO at Pagbuo ng Link mula sa Hosting Layer: Pananaw ng Operator para sa 2026

Kung paano hinuhubog ng hosting ang indexing at link equity sa 2026: pagpapanatiling naka-index sa mga pahina, pagsusuri sa mga lumang domain bago ka magtayo sa mga ito, pagbuo ng link nang walang bakas, at tapat na pagsusuri sa kung ano ang kaya at hindi kaya ng imprastraktura para sa SEO.

Basahin ang post

Pagpapanatiling Mabilis at Ligtas ang WordPress: Isang Checklist para sa Pagganap at Plugin

Isang praktikal na checklist para sa mabilis at ligtas na WordPress: server-level caching, per-site object cache, ilang piling plugins na sulit patakbuhin, pagpapanatiling napapanahon sa stack, at ang mga pahina ng WooCommerce na hindi mo dapat i-cache kailanman.

Basahin ang post

Paano Pumili ng Managed Web Hosting sa 2026: Gabay ng Mamimili

Ano ba talaga ang nagpisa sa mahusay na managed hosting mula sa murang box na may control panel — mga migration, backup, isolation, tunay na caching at tapat na scaling — at kung paano ito husgahan bago ka pumirma.

Basahin ang post

Basahin ang blog

Na-stuck pa rin?

Kasama ang suporta sa bawat plan, bukas ang desk 24 oras bawat araw, at maaari kang sumulat sa amin sa alinman sa aming 58 na mga wika — sasagutin ka namin sa iyong wika.

Makipag-ugnayan sa suporta Lahat ng artikulo