Jeg registrerte to WordPress-applikasjoner i Cloudways Site Manager for denne gjennomgangen, én via onboarding-skjermen som ligger gjemt i sidefeltet til en applikasjon, én via bulkflyten som finnes på kontonivå.

Derfra kjørte jeg en ekte Safe Update på fire plugins, bygde en delt automatisk oppdateringsplan som omfattet begge nettstedene, slo på aktivitetslogging og tilbrakte nok tid i kontonivå-dashbordet til å forstå hvor den samme informasjonen vises på mer enn ett sted, og hvorfor det betyr mer enn det høres ut som.

Cloudways

Manage Cloudways-hosted WordPress applications with centralized updates, Safe Updates, activity logs, and portfolio-wide scheduling.

Besøk Cloudways

Hva er Cloudways Site Manager?

Site Manager erstattet et eldre Cloudways-tilleggsprodukt kalt SafeUpdates. Å forstå hva SafeUpdates ikke kunne gjøre forklarer nesten alle designbeslutningene i det nåværende produktet.

SafeUpdates kjørte alt over SSH, noe som skapte et spesifikt sett med problemer for alle som administrerer mer enn et par nettsteder:

• Ingen dashbord, så ingen måte å se hvilke nettsteder som trengte oppmerksomhet uten å sjekke hvert enkelt
• Oppdateringer låst til en fast ukentlig plan, uansett om en kunde trengte daglige oppdateringer eller månedlig vedlikehold
• Visuell regresjonstesting begrenset til tre skrivebordssider per nettsted, svak dekning for alt utover et brosjyrenettsted
• Ingen revisjonsspor som viste hva som endret seg, når eller hvem som gjorde endringen

Byråer som administrerer tjue eller flere WordPress-installasjoner fortalte Cloudways, i praksis, at verktøyet fungerte helt til det ikke skalerte, og skalering var hele grunnen til at de var på Cloudways i utgangspunktet.

Site Manager er det direkte svaret på den tilbakemeldingen. Den konteksten er viktig for å lese resten av denne gjennomgangen, fordi den forklarer hvorfor noen deler av produktet føles uvanlig modne for noe som fortsatt er i Public Preview, og hvorfor andre deler, som onboarding-trinnet du møter første dag, fortsatt viser sømmene.

Hva kan Cloudways Site Manager gjøre?

Med den bakgrunnen på plass, er det neste spørsmålet omfang: hva kan dette verktøyet faktisk nå. Før vi går inn på onboarding, oppdateringer og planlegging, er det verdt å være presis om hva Site Manager dekker og hva det ikke gjør, fordi det ærlige svaret er mer nyansert enn et rent ja eller nei.

Det innebygde dashbordet er Cloudways-only

Hver applikasjon som var tilgjengelig for registrering i Site Manager på kontonivå, enten via skjermen per app eller bulkveiviseren under Integrations, kom fra en server som allerede lå i Cloudways-kontoen min.

Det fantes ikke noe felt for å lime inn legitimasjon for en ekstern installasjon, og ingen kobling for et nettsted som kjørte på en helt annen host.

Hele funksjonssettet som dekkes i denne gjennomgangen, Safe Update sin staging-klone, visuell regresjonstesting, aktivitetslogger, bulkplanlegging, alt dette ligger inne i dette innebygde, Cloudways-hostede laget.

Et eget plugin utvider lettere overvåking til alle nettsteder

Cloudways publiserer også et gratis WordPress-plugin, også kalt Cloudways Site Manager, utviklet sammen med WP Remote.

I motsetning til det innebygde dashbordet installeres dette pluginet direkte på et WordPress-nettsted uansett hvor det er hostet, noe som betyr at det kan bringe et eksternt, ikke-Cloudways nettsted inn i en versjon av den samme sentraliserte visningen.

Det er imidlertid et genuint annet produkt enn det innebygde dashbordet, og gapet mellom de to betyr noe:

Pluginet deaktiverer også WordPress’ egne automatiske oppdateringer mens det er aktivt, et bevisst valg fra Cloudways for å unngå konflikter under fjernadministrasjon.

Cloudways er tydelige på at plugin-sporet er et mellomsteg snarere enn målpunktet: hvis du vil ha hele pakken, automatiske sikkerhetskopier, ettklikks staging, Cloudflare-integrasjon og administrert caching, er den uttalte beste praksisen å migrere det eksterne nettstedet til Cloudways heller enn å administrere det eksternt på lang sikt.

For et byrå med en fullt Cloudways-hostet portefølje spiller ingen av dette noen rolle. For alle som fortsatt driver noen få nettsteder andre steder, og de fleste byråer jeg har snakket med gjennom årene har minst noen få, er pluginet et reelt alternativ for grunnleggende overvåking og oppdateringer, bare ikke en erstatning for det det innebygde dashbordet gjør.

Cloudways

Manage Cloudways-hosted WordPress applications with centralized updates, Safe Updates, activity logs, and portfolio-wide scheduling.

Besøk Cloudways

Kom i gang: To måter å onboarde nettsteder på

Med omfangsspørsmålet avklart, starter den praktiske delen her: faktisk å registrere en WordPress-applikasjon. Cloudways gir deg to måter inn i det innebygde Site Manager, og de er ikke like godt egnet for oppgaven.

Vei 1: via sidefeltet til en applikasjon

Her er nøyaktig hvordan jeg kom dit første gang. Fra Cloudways-hoveddashbordet klikket jeg inn på serveren min, deretter på WordPress-applikasjonen som lå på den, noe som tar deg til den appens Access Details-side.

Sidefeltet til venstre der lister Access Details, Staging Management, Monitoring, Application Security, Domain Management, og deretter Site Manager, merket med en “New”-tag. Å klikke på den tok meg rett til en skjerm med tittelen “Simplify App Management with Site Manager,” avgrenset helt til den ene applikasjonen, med to plan-kort side om side, Basic og Pro.

Jeg klikket Get Pro. Da begynte det å gå galt.

Skjermen skiftet til “Subscribing to the Site Manager Plan…” med en melding som forklarte at Cloudways installerte pluginet og synkroniserte dataene til nettstedet mitt, og at dette kunne ta noen minutter avhengig av størrelsen på applikasjonen.

Det kjørte i omtrent to minutter og feilet deretter, og kom tilbake med en rød feilmelding: “Please delete existing plugin and install again.” Jeg hadde ingen tidligere installasjon å slette, så selve meldingen fortalte meg ikke hva som faktisk hadde gått galt.

Jeg klikket Get Pro en gang til, på samme plan-skjerm, uten å endre noe. Det forsøket fungerte. Det kjørte i omtrent tre minutter og avsluttet med en grønn suksessmelding som bekreftet at jeg hadde abonnert på Site Manager-planen, og landet meg på appens Site Manager Overview-side, med pluginantall, temanummer, en ytelsesscore og en Manage Updates-tabell alle utfylt og klare.

Vei 2: via kontonivå-dashbordet

Dette er veien som er verdt å bruke så snart du har mer enn ett nettsted å administrere, og her er nøyaktig hvordan jeg fant og brukte den.

Fra Cloudways-hoveddashbordet har venstre navigasjon en rad med ikoner: Home, Flexible, Autonomous, Integrations og Agency Partners. Jeg klikket Integrations. Det åpnet et panel med kort, blant annet Site Manager (merket “New”), Application Migration, DNS Made Easy, CookieYes og Equalize Digital Accessibility Checker.

Å klikke på Site Manager-kortet tok meg til en helt annen skjerm enn Vei 1, en som ligger under brødsmulen Integrations → Add-Ons → Site Manager, med sin egen fanerad: Overview, Manage Updates, Auto Updates, History.

Denne Overview-siden er det egentlige kontrollsenteret. Den viser kontobaserte statistikker, Total Apps on Site Manager, Apps on Free Plan, Apps on Pro Plan, Apps with Auto Updates, og under dette en Manage Applications-tabell som lister hver app som allerede er registrert.

For å legge til flere klikket jeg Add Apps to Site Manager øverst til høyre i den tabellen. Det åpnet en veiviser i to trinn:

1. Select Application(s): en avkrysningsliste over alle WordPress-appene i kontoen min som ennå ikke var registrert, med et Select All-alternativ og et søkefelt.

En merknad over listen forklarte at den ekskluderer staging-apper, apper på stoppede servere og alle apper som allerede kjører det eldre SafeUpdates-tillegget. Jeg krysset av appen jeg ville ha og klikket Select Plan.

2. Select your Plan: Basic og Pro vist side om side igjen, denne gangen som bekreftet hvor mange applikasjoner jeg hadde valgt og den totale månedlige kostnaden for den batchen. Jeg valgte Pro og klikket Enable Site Manager.

Hele flyten tok under ett minutt når jeg først var på veiviserskjermen, og den gjaldt for hver app jeg hadde krysset av i steg én på en gang, uten å gjenta planvalget per nettsted.

Gapet ingen advarer deg om

Etter å nå ha registrert apper gjennom begge veiene, er dette funnet som endret hvordan jeg tenker om den daglige driften av dette produktet. Jeg la til en andre WordPress-applikasjon på en server som allerede hadde Site Manager som aktivt administrerte en annen app på samme server.

Jeg forventet at den nye appen skulle dukke opp automatisk, siden den sto rett ved siden av en app Site Manager allerede kjente til. Det gjorde den ikke. Kontonivå-dashbordets “Total Apps on Site Manager”-tall sto helt stille til jeg manuelt gikk gjennom onboarding for den nye appen.

Dette er et designvalg, men et designvalg med en operasjonell kostnad:

• For en frilanser med tre eller fire nettsteder er det trivielt å huske å onboarde et nytt.
• For et byrå som setter opp et nytt klientnettsted hver uke eller to, blir dette en tilbakevendende oppgave på noens sjekkliste, permanent.
• Går du glipp av det én gang, ligger det nettstedet utenfor overvåkingen, bulkoppdateringene og aktivitetsloggene, usynlig for dashbordet som skal være din eneste sannhetskilde.

Cloudways

Manage Cloudways-hosted WordPress applications with centralized updates, Safe Updates, activity logs, and portfolio-wide scheduling.

Besøk Cloudways

Hva du faktisk betaler for

Site Manager er delt inn i et virkelig brukbart gratisnivå og et Pro-nivå som låser opp funksjonene et byrå faktisk ville bygge en arbeidsflyt rundt.

Basic vs. Pro, funksjon for funksjon

Basic er ikke en nedstrippet prøveversjon. Det inkluderer en reell nettstedoversikt, muligheten til å administrere brukere, temaer og plugins uten å røre wp-admin, ettklikks WordPress single sign-on og Quick Updates, og, viktig nok, det sentraliserte dashbordet selv.

Cloudways la ikke den grunnleggende “se alle nettstedene dine på ett sted”-opplevelsen bak en betalingsmur. Det som er låst, er alt som gjør det dashbordet pålitelig nok til å bruke uten å overvåke det hele tiden.

Pro er for øyeblikket gratis å bruke under Public Preview uansett oppgitt pris, som er $3 per app per month, og faller til $2 per app når du passerer fem applikasjoner.

Hva Pro faktisk koster etter hvert som porteføljen din vokser

Den rabattterskelen er verdt å regne på før du antar at Pro skalerer billig:

Ingen av disse tallene er urimelige sammenlignet med hva én ødelagt, ubeskyttet oppdatering kan koste i kundetillit, men prising per app betyr at regningen vokser i en rett linje med porteføljen din, ikke i trappetrinns-rabatter som noen konkurrerende verktøy tilbyr på høyere nivåer.

Tre steder å utløse samme oppdatering

Med registrering og prising ute av veien, dekker resten av denne gjennomgangen hvordan daglig bruk faktisk ser ut, og vi begynner med et arkitekturpoeng som er verdt å forstå.

Dette er delen av Site Manager-designen som tok lengst tid å faktisk forstå, og den er ikke forklart noe sted i selve grensesnittet.

• En applikasjons egen Overview-side viser fortsatt sin egen Manage Updates-tabell, med de samme ventende plugin-oppdateringene du ville sett fra kontonivå-dashbordet.
• Kontonivå-dashbordets row-level Actions-meny tilbyr sin egen Manage Updates-handling, og henter fra de samme underliggende dataene.
• Auto Updates-fanen lar deg planlegge at akkurat samme type oppdatering skal kjøre automatisk, på én app eller på alle registrerte apper samtidig.

Dette er tre dører inn i det samme rommet. Visningen per app er for noen som allerede jobber inne i det spesifikke nettstedet og tilfeldigvis oppdager en ventende oppdatering. Row-level-handlingen på kontonivå er for noen som skanner hele porteføljen og bestemmer seg for å handle på ett nettsted akkurat nå.

Planleggingsfanen er for å fjerne mennesket fra løkken helt.

Quick Update versus Safe Update

Av de tre dørene som nettopp er beskrevet, dekker denne delen de to første, visningen per app og row-level-handlingen på kontonivå, siden begge åpner den samme oppdateringsmekanismen.

Alle planenivåer tilbyr Quick Update. Å bruke den tar sekunder: oppdateringen installeres direkte i produksjon uten kompatibilitetssjekk og uten at det tas en sikkerhetskopi først.

Cloudways’ egen grensesnitttekst er ærlig om avveiningen og advarer om at den “may carry risks if updates aren’t compatible.”

Jeg kjørte ikke en Quick Update i denne testen, så jeg kan ikke beskrive førstehånds hvordan en mislykket en faktisk ser ut på skjermen. Det er et reelt hull i denne gjennomgangen, og jeg ville behandlet enhver påstand om Quick Updates feilhåndtering, fra meg eller noen andre som ikke har utløst en, med passende skepsis.

Safe Update er der Pro forsvarer prisen sin, og det er verdt å gå gjennom i detalj fordi prosessen er mer involvert enn “backup, then update.”

Hvordan en Safe Update-kjøring faktisk ser ut

Her er nøyaktig hvordan jeg utløste den. Fra kontonivå-Overview-tabellen under Integrations → Site Manager fant jeg raden for appen med ventende oppdateringer og klikket på menyen med tre prikker Actions ytterst i den raden. Den åpnet fire alternativer: WP-Admin, App Overview, Manage Updates og Manage Plan. Jeg klikket Manage Updates.

Det åpnet en modal som listet alle plugins med en ventende oppdatering, fire i mitt tilfelle, Breeze, Elementor, Object Cache Pro og WP ULike, hver vist som et avkrysset element med sin nåværende versjon og versjonen den ville oppdatere til.

Under listen lå to radiovalg: Quick Update og Safe Update, hver med en énlinjes beskrivelse av avveiningen. Jeg valgte Safe Update og klikket Proceed.

I stedet for en enkel fremdriftssnurr viser modalen som åpner seg neste gang en trinnvis sjekkliste som oppdateres i sanntid.

Staging environment:

• Pre Snapshot
• Fetch Update Packages
• Update each plugin individually
• Post Snapshot
• Purge Cache
• Visual Regression

Produksjon:

• Den identiske sekvensen gjentas når staging er godkjent, og avsluttes med én siste cache-tømming

Jeg startet kjøringen kl. 6:21 pm og den ble ferdig kl. 6:27 pm. Seks minutter, for fire plugins, gjennom en komplett staging-til-produksjon-syklus. Selve modalen setter forventningen om at dette “usually takes less than a minute,” noe min kjøring overskred med god margin.

Den avstanden mellom anslaget og faktisk tid er verdt å planlegge rundt i stedet for å bli overrasket av hvis du kjører Safe Update på en pakke med plugins i et vedlikeholdsvindu, sett av minutter, ikke sekunder, særlig etter hvert som antallet plugins vokser.

En suksessvarsling bekreftet resultatet, og idet det var ferdig, logget kontonivåets History-fane det som “On-Demand Successful: Plugins (4)” med en lenke videre til fullstendige detaljer.

At loopen blir lukket på denne måten, å se en handling skje og deretter umiddelbart kunne peke på en permanent registrering av den, er akkurat den typen kundevendt bevis et byrå trenger, og SafeUpdates ga dem aldri det.

De to innstillingene som avgjør hvor tilgivende oppdateringer er

Begge disse ligger inne i planleggingsflyten heller enn i skjermen for oppdatering på forespørsel, noe som gjør dem lette å overse:

• Visual Regression Sensitivity styrer hvor mye visuell forskjell mellom staging-testen og produksjon som tolereres før en oppdatering avbrytes for å beskytte layouten din. Den er satt til den strengeste tilgjengelige innstillingen som standard, “Critical, 0% difference.”
• Smart Skip for Plugin/Theme Update Failures, aktivert som standard, betyr at én enkelt plugin som mislykkes i å oppdatere ikke stopper hele batchen. Systemet legger akkurat det ene elementet til side, oppdaterer alt annet, kjører visuell regresjonssjekk på det som lyktes, og publiserer disse endringene automatisk.

Sammen avgjør disse to standardinnstillingene om en uovervåket oppdateringsrunde over natten vekker deg med én flagget plugin i køen, eller med et helt nettsted som står midt i en oppdatering fordi ett inkompatibelt tema stoppet hele prosessen. Verdt å sjekke begge før du stoler på at en plan skal kjøre uten tilsyn.

Cloudways

Manage Cloudways-hosted WordPress applications with centralized updates, Safe Updates, activity logs, and portfolio-wide scheduling.

Besøk Cloudways

Planlegging av oppdateringer på tvers av hele porteføljen samtidig

Det dekker de to første dørene. Denne delen dekker den tredje: å fjerne mennesket fra løkken helt. Auto Updates-fanen, som nås fra samme Site Manager-side på kontonivå, er stedet der “manage many sites like they’re one”-løftet enten leverer eller faller fra hverandre. I mitt tilfelle leverte det.

Her er nøyaktig hvordan jeg satte det opp. Fra Integrations → Site Manager klikket jeg på fanen Auto Updates i toppraden.

Med ingenting planlagt ennå, viste siden en tom tilstand, “No Auto Updates Schedule,” med én knapp: Set Auto Update Schedule.

Å klikke på den åpnet en veiviser, “Set Auto Update Schedule,” som gikk gjennom følgende i ett strekk:

1. Day of Week and Schedule Time: to nedtrekksmenyer, pluss en tidssonevelger ved siden av tidsfeltet. Jeg satte Friday, mellom midnatt og 5:59am UTC.
2. Select Application: en avkrysningsliste over alle appene som allerede var registrert i Site Manager, med et Select All-alternativ, og en merknad om at enhver eksisterende plan allerede satt på en valgt app ville bli erstattet av denne nye. Jeg valgte begge appene mine og klikket Choose Preferences.

Deretter åpnet en andre skjerm, “Create Auto Update Schedule,” som dekket:

3. Configure Update List: tre utvidbare seksjoner, WordPress Core, Plugins og Themes, hver med sin egen avkrysningsliste og en løpende telling av hvor mange som var valgt. På tvers av mine to apper var ti plugins og fire temaer tilgjengelige for å inkludere, og hver enkelt plugin og hvert tema viste nøyaktig hvor mange av applikasjonene mine som faktisk brukte det, en liten detalj som betyr enormt mye når du administrerer dusinvis av nettsteder og prøver å se hvilke oppdateringer som er verdt å teste bredt versus hvilke som bare berører ett nettsted.

4. Update Type: en nedtrekksmeny som tilbyr Quick Update eller Safe Update, hver med samme beskrivelse som i oppdateringsmodalen på forespørsel. Å velge Safe Update avdekket to ekstra kontroller som bare vises for den modusen, Visual Regression Sensitivity og Smart Skip for Plugin/Theme Update Failures.

5. Critical Updates: en bryter, av som standard, reservert spesifikt for å sende en sikkerhetsdrevet oppdatering utenfor den normale planen i det øyeblikket en sårbarhet blir flagget.

Å klikke Set AutoUpdate Schedule nederst lagret det, anvendt på hver app jeg hadde valgt i steg to, uten behov for å gjenta konfigurasjonen én gang per nettsted.

Aktivitetslogger: Den delen som egentlig handler om kundetillit

De tre dørene og oppdateringsmekanikkene bak dem dekker hvordan. Denne siste funksjonen dekker beviset: en permanent registrering av hva som skjedde, separat fra selve oppdateringsprosessen.

Her er nøyaktig hvordan jeg slo det på.

Fra appens egen Site Manager Overview-side, den samme som du lander på etter å ha abonnert via Vei 1, ligger det et kort merket “Activity Logs are Disabled” ved siden av ytelsesringen, med en kort beskrivelse og én knapp: Enable Activity Logs.

Jeg klikket på den, og kortet oppdaterte seg umiddelbart, ingen bekreftelsesmodal, ingen ekstra steg. Da jeg sjekket kontonivåets Manage Applications-tabell umiddelbart etterpå, under Integrations → Site Manager, hadde Activity Logs-kolonnen for den appen allerede skiftet fra Disabled til Enabled, uten at jeg måtte oppdatere siden.

Denne funksjonen ligger bak Pro, og den finnes for å svare på et spørsmål hvert byrå til slutt får fra en kunde: hvem endret hva, og når?

Uten den lever svaret vanligvis i et WordPress-logging-plugin som skriver til nettstedets egen database, noe som bygger seg opp over tid og ikke gir noen beskyttelse mot manipulering. Å ha den loggen live utenfor WordPress-installasjonen, inne i hostingslaget, er et meningsfullt annet tillitsnivå for alt som er kundevendt.

Cloudways

Manage Cloudways-hosted WordPress applications with centralized updates, Safe Updates, activity logs, and portfolio-wide scheduling.

Besøk Cloudways

Fordeler og ulemper

Hvem dette faktisk er for

Med hele funksjonssettet, kostnadene og kantene lagt på bordet, er det siste spørsmålet ganske enkelt om det passer din spesifikke portefølje.

Den klareste matchen er et byrå eller en frilansutvikler som driver flere, helst mange, WordPress-nettsteder som allerede ligger helt og holdent i Cloudways, der en ødelagt oppdatering har en reell kostnad i kundetillit heller enn bare personlig irritasjon.

Safe Update-arbeidsflyten og bulkplanleggingen eksisterer spesifikt for å løse problemet som dukker opp når du er forbi punktet der det fortsatt er rimelig å sjekke hvert nettsted individuelt.

Det er en delvis match for alle med en blandet portefølje. Det gratis Site Manager-pluginet kan bringe inn eksterne nettsteder for grunnleggende overvåking og oppdateringer, men funksjonene som gjør det innebygde dashbordet verdt å betale for, staging-basert Safe Update, visuell regresjon, aktivitetslogger, forblir utenfor rekkevidde til disse nettstedene faktisk flyttes til Cloudways.

Det er rett og slett unødvendig for en eier av ett nettsted. Gratisnivået ville teknisk sett fungere, men hele produktet eksisterer for å løse et porteføljeproblem som ett enkelt nettsted aldri skaper.

Konklusjon: Verdt det, men bare innenfor Cloudways

Ja, site manager er verdt å ta i bruk, på én betingelse: nettstedene dine må allerede ligge på Cloudways. Innenfor den grensen leverer Site Manager det den lover, et ekte dashbord på tvers av nettsteder, en Safe Update-vei som tar sikkerhetskopi før den rører produksjon, og bulkplanlegging som behandler oppdateringer som en flåtehandling i stedet for en per-innlogging-oppgave.

Utenfor den grensen er det et lettere verktøy med en tydelig migreringsdytt knyttet til seg. Den beste matchen er et byrå som samler kundesider på Cloudways og trenger ett sted å bevise hva som endret seg og når.

Cloudways

4.6

537 brukeromtaler

Nkr 102 /mo

Startpris

Besøk Cloudways

Rating based on expert review

• Brukervennlig
  4.5
• Support
  4.6
• Funksjoner
  4.8
• Pålitelighet
  4.8
• Prising
  4.3