Jag registrerade två WordPress-applikationer i Cloudways Site Manager för den här recensionen, en via introduktionsskärmen som finns i en applikations egen sidomeny, en via bulkflödet som finns på kontonivå.

Därifrån körde jag en riktig Safe Update på fyra plugins, byggde ett gemensamt schema för automatiska uppdateringar som omfattade båda webbplatserna, slog på aktivitetsloggning och tillbringade tillräckligt mycket tid i instrumentpanelen på kontonivå för att förstå var samma information visas på mer än ett ställe, och varför det betyder mer än det låter.

Cloudways

Hantera WordPress-applikationer som hostas hos Cloudways med centraliserade uppdateringar, Safe Updates, aktivitetsloggar och portföljomfattande schemaläggning.

Besök Cloudways

Vad är Cloudways Site Manager?

Site Manager ersatte ett äldre Cloudways-tillägg som hette SafeUpdates. Att förstå vad SafeUpdates inte kunde göra förklarar nästan alla designval i den nuvarande produkten.

SafeUpdates körde allt via SSH, vilket skapade en specifik uppsättning problem för alla som hanterar fler än ett par webbplatser:

• Ingen instrumentpanel, så inget sätt att se vilka webbplatser som behövde uppmärksamhet utan att kontrollera varje enskilt enskilt
• Uppdateringar låsta till ett fast veckoschema, oavsett om en kund behövde daglig patchning eller månatligt underhåll
• Visuell regressionsprovning begränsad till tre skrivbordsidor per webbplats, tunn täckning för allt annat än en broschyrsajt
• Ingen revisionslogg som visade vad som ändrades, när eller vem som gjorde ändringen

Byråer som hanterar tjugo eller fler WordPress-installationer berättade i praktiken för Cloudways att verktyget fungerade tills det inte skalerade längre, och skalning var hela anledningen till att de använde Cloudways från början.

Site Manager är det direkta svaret på den feedbacken. Det sammanhanget är viktigt för att läsa resten av den här recensionen, eftersom det förklarar varför vissa delar av produkten känns ovanligt mogna för något som fortfarande är i Public Preview, och varför andra delar, som introduktionssteget du stöter på dag ett, fortfarande visar skarvarna.

Vad kan Cloudways Site Manager göra?

Med den bakgrunden på plats är nästa fråga omfång: vad kan det här verktyget faktiskt nå. Innan vi går in på introduktion, uppdateringar och schemaläggning är det värt att vara exakt med vad Site Manager täcker och vad det inte gör, eftersom det ärliga svaret är mer nyanserat än ett rakt ja eller nej.

Den inbyggda instrumentpanelen är endast för Cloudways

Varje applikation som gick att registrera i Site Manager på kontonivå, oavsett om det skedde via skärmen för enskild app eller bulkguiden under Integrations, kom från en server som redan låg i mitt Cloudways-konto.

Det fanns inget fält för att klistra in inloggningsuppgifter för en externt hostad installation, och ingen anslutning för en webbplats som kördes på en helt annan host.

Hela funktionsuppsättningen som täcks i den här recensionen, Safe Update:s staging-klon, visuell regressionsprovning, aktivitetsloggar, bulkplanering, allt detta finns i detta inbyggda, Cloudways-hostade lager.

En separat plugin utökar lättare övervakning till alla webbplatser

Cloudways publicerar också ett gratis WordPress-plugin, också kallat Cloudways Site Manager, samutvecklat med WP Remote.

Till skillnad från den inbyggda instrumentpanelen installeras detta plugin direkt på en WordPress-webbplats oavsett var den är hostad, vilket innebär att det kan ta in en extern, icke-Cloudways-webbplats i en version av samma centraliserade vy.

Det är dock en faktiskt annan produkt än den inbyggda instrumentpanelen, och gapet mellan de två spelar roll:

Pluginet inaktiverar också WordPress egna automatiska uppdateringar medan det är aktivt, ett medvetet val från Cloudways sida för att undvika konflikter vid fjärrhantering.

Cloudways är tydliga med att plugin-spåret är ett steg på vägen snarare än slutdestinationen: om du vill ha hela paketet, automatiska säkerhetskopior, staging med ett klick, Cloudflare-integration, hanterad cache, så är den uttalade bästa praxis att migrera den externa webbplatsen till Cloudways i stället för att hantera den på distans på lång sikt.

För en byrå med en helt Cloudways-hostad portfölj spelar inget av detta någon roll. För alla som fortfarande kör några webbplatser någon annanstans, och de flesta byråer jag har pratat med genom åren har åtminstone några, är pluginet ett verkligt alternativ för grundläggande övervakning och uppdateringar, bara inte en ersättning för vad den inbyggda instrumentpanelen gör.

Cloudways

Hantera WordPress-applikationer som hostas hos Cloudways med centraliserade uppdateringar, Safe Updates, aktivitetsloggar och portföljomfattande schemaläggning.

Besök Cloudways

Komma igång: Två sätt att registrera webbplatser

Med omfattningsfrågan löst börjar det praktiska här: att faktiskt få en WordPress-applikation registrerad. Cloudways ger dig två vägar in i den inbyggda Site Manager, och de är inte lika lämpade för uppgiften.

Väg 1: via en applikations egen sidomeny

Så här kom jag dit första gången. Från Cloudways-startpanelen klickade jag in på min server, sedan på WordPress-applikationen som låg på den, vilket tog mig till den appens sida för åtkomstuppgifter.

Den vänstra sidomenyn där listar Access Details, Staging Management, Monitoring, Application Security, Domain Management, och sedan Site Manager, markerad med en “New”-etikett. Att klicka på den tog mig direkt till en skärm med titeln “Simplify App Management with Site Manager,” helt avgränsad till just den applikationen, med två plan-kort sida vid sida, Basic och Pro.

Jag klickade på Get Pro. Det var då det gick snett.

Skärmen ändrades till “Subscribing to the Site Manager Plan…” med ett meddelande som förklarade att Cloudways installerade pluginet och synkade min webbplats data, och att detta kunde ta några minuter beroende på applikationens storlek.

Det körde i ungefär två minuter och misslyckades sedan, och återvände med en röd felnotis: “Please delete existing plugin and install again.” Jag hade ingen tidigare installation att ta bort, så meddelandet i sig berättade inte vad som faktiskt hade gått fel.

Jag klickade på Get Pro en andra gång, på samma planskärm, utan att ändra något. Det försöket fungerade. Det körde i ungefär tre minuter och avslutades med en grön framgångsnotis som bekräftade att jag hade prenumererat på Site Manager-planen, och landade mig på appens Site Manager Overview-sida, med pluginantal, temanantal, ett prestandapoäng och en Manage Updates-tabell ifyllda och klara.

Väg 2: via instrumentpanelen på kontonivå

Det här är vägen värd att använda så fort du har mer än en webbplats att hantera, och här är exakt hur jag hittade och använde den.

Från Cloudways-startpanelen har den vänstra navigeringen en rad ikoner: Home, Flexible, Autonomous, Integrations och Agency Partners. Jag klickade på Integrations. Det öppnade en panel med kort, Site Manager (markerad med “New”), Application Migration, DNS Made Easy, CookieYes och Equalize Digital Accessibility Checker bland dem.

Att klicka på Site Manager kortet tog mig till en helt annan skärm än Väg 1, en som ligger under brödsmulan Integrations → Add-Ons → Site Manager, med sin egen flikrad: Overview, Manage Updates, Auto Updates, History.

Den här Overview-sidan är det verkliga kommandocentret. Den visar statistik på kontonivå, Total Apps on Site Manager, Apps on Free Plan, Apps on Pro Plan, Apps with Auto Updates, och under det en Manage Applications-tabell som listar varje app som redan är registrerad.

För att ta in fler klickade jag på Add Apps to Site Manager uppe till höger i den tabellen. Det öppnade en guide i två steg:

1. Select Application(s): en checklista över varje WordPress-app i mitt konto som ännu inte var registrerad, med ett Select All-alternativ och ett sökfält.

En notis ovanför listan förklarade att den exkluderar staging-appar, appar på stoppade servrar och alla appar som redan kör den äldre SafeUpdates-tillägget. Jag markerade appen jag ville ha och klickade på Select Plan.

2. Select your Plan: Basic och Pro visade sida vid sida igen, den här gången med bekräftelse på hur många applikationer jag hade valt och den totala månadskostnaden för den batchen. Jag valde Pro och klickade på Enable Site Manager.

Hela flödet tog under en minut när jag väl var på guide-skärmen, och det tillämpades på alla appar jag hade kryssat i i steg ett på en gång, utan att upprepa planvalet per webbplats.

Glappet ingen varnar dig för

Nu när jag har registrerat appar via båda vägarna är här upptäckten som ändrade hur jag tänker om produktens dagliga underhåll. Jag lade till en andra WordPress-applikation på en server som redan hade Site Manager som aktivt hanterade en annan app på samma server.

Jag förväntade mig att den nya appen skulle dyka upp automatiskt, eftersom den stod precis bredvid en app som Site Manager redan kände till. Det gjorde den inte. Instrumentpanelen på kontonivås “Total Apps on Site Manager”-räkning stod exakt där den var tills jag manuellt körde den nya appen genom introduktionen.

Det här är ett designval, men det är ett designval med en operativ kostnad:

• För en frilansare med tre eller fyra webbplatser är det trivialt att komma ihåg att registrera en ny.
• För en byrå som startar en ny kundwebbplats varje vecka eller varannan vecka blir detta en återkommande punkt på någons checklista, permanent.
• Missar du det en gång ligger den webbplatsen utanför din övervakning, dina bulkuppdateringar och dina aktivitetsloggar, osynlig för instrumentpanelen som ska vara din enda sanna källa.

Cloudways

Hantera WordPress-applikationer som hostas hos Cloudways med centraliserade uppdateringar, Safe Updates, aktivitetsloggar och portföljomfattande schemaläggning.

Besök Cloudways

Vad du faktiskt betalar för

Site Manager delas upp i en verkligt användbar gratisnivå och en Pro-nivå som låser upp de funktioner en byrå faktiskt skulle bygga ett arbetsflöde kring.

Basic vs. Pro, funktion för funktion

Basic är inte en nedbantad testversion. Den innehåller en verklig webbplatsöversikt, möjligheten att hantera användare, teman och plugins utan att röra wp-admin, WordPress Single Sign-On med ett klick och Snabba uppdateringar, och, vilket är viktigt, själva centraliserade instrumentpanelen.

Cloudways låste inte den grundläggande “se alla dina webbplatser på ett ställe”-upplevelsen bakom en betalvägg. Det som är låst är allt som gör den instrumentpanelen tillräckligt pålitlig för att agera på utan att vaka över den.

Pro är för närvarande gratis att använda under Public Preview oavsett dess listade pris, vilket är $3 per app per månad, sjunkande till $2 per app när du passerar fem applikationer.

Vad Pro faktiskt kostar när portföljen växer

Den där rabattgränsen är värd att räkna på innan man antar att Pro skalar billigt:

Inga av de siffrorna är orimliga jämfört med vad en enda trasig, osäkrad uppdatering kan kosta i kundförtroende, men pris per app betyder att fakturan växer i en rak linje med din portfölj, inte i stegvisa rabatter som vissa konkurrerande verktyg erbjuder på högre nivåer.

Tre platser för att utlösa samma uppdatering

Med registrering och prissättning avklarade täcker resten av den här recensionen hur det faktiskt ser ut i vardagsbruk, med början i en bit arkitektur som är värd att förstå.

Det här är delen av Site Manager:s design som tog längst tid att faktiskt reda ut, och det förklaras inte någonstans i själva gränssnittet.

• En applikations egen Overview-sida visar fortfarande sin egen Manage Updates-tabell, som listar samma väntande pluginuppdateringar som du skulle se från instrumentpanelen på kontonivå.
• Instrumentpanelen på kontonivås radvisa Actions-meny erbjuder sin egen Manage Updates-åtgärd, som hämtar från samma underliggande data.
• Fliken Auto Updates låter dig schemalägga samma typ av uppdatering att köras automatiskt, för en app eller för varje registrerad app på en gång.

Dessa är tre dörrar till samma rum. Vy per app är för någon som redan arbetar inne i just den webbplatsen och råkar märka en väntande uppdatering. Åtgärden på kontonivå är för någon som skannar hela portföljen och bestämmer sig för att agera på en webbplats just nu.

Fliken för schemaläggning är för att ta bort människan ur loopen helt och hållet.

Snabb uppdatering versus Safe Update

Av de tre dörrarna som just beskrevs täcker det här avsnittet de två första, vy per app och åtgärden på kontonivå, eftersom båda öppnar samma uppdateringsmekanism.

Varje plan-nivå erbjuder Quick Update. Att tillämpa den tar sekunder: uppdateringen installeras direkt till produktion utan någon kompatibilitetskontroll och utan att någon säkerhetskopia tas först.

Cloudways egen gränssnittstext är ärlig om avvägningen och varnar för att den “may carry risks if updates aren’t compatible.”

Jag körde inte någon Quick Update i det här testet, så jag kan inte beskriva hur en misslyckad sådan faktiskt ser ut på skärmen. Det är en verklig lucka i den här recensionen, och jag skulle behandla alla påståenden om Quick Update:s felbeteende, från mig eller någon annan som inte har utlösts en sådan, med lämplig skepsis.

Safe Update är där Pro tjänar sitt pris, och det är värt att gå igenom i sin helhet eftersom processen är mer omfattande än “säkerhetskopia, sedan uppdatera.”

Hur en Safe Update-körning faktiskt ser ut

Så här utlöste jag den exakt. Från tabellen Overview på kontonivå under Integrations → Site Manager hittade jag raden för appen med väntande uppdateringar och klickade på trepunktsmenyn Actions i slutet av den raden. Den öppnade fyra alternativ: WP-Admin, App Overview, Manage Updates och Manage Plan. Jag klickade på Manage Updates.

Det öppnade en modal som listar varje plugin med en väntande uppdatering, fyra i mitt fall, Breeze, Elementor, Object Cache Pro och WP ULike, vart och ett visat som ett markerat objekt med sin nuvarande version och den version det skulle uppdateras till.

Under listan fanns två radioval: Quick Update och Safe Update, vart och ett med en kort beskrivning av avvägningen. Jag valde Safe Update och klickade på Proceed.

I stället för en enda förloppsindikator visar modalen som öppnas därefter en stegvis checklista som uppdateras i realtid.

Staging-miljö:

• Pre Snapshot
• Fetch Update Packages
• Uppdatera varje plugin individuellt
• Post Snapshot
• Purge Cache
• Visual Regression

Produktion:

• Samma sekvens upprepas när staging har passerat, och avslutas med en sista cache-rensning

Jag startade körningen klockan 6:21 pm och den avslutades klockan 6:27 pm. Sex minuter, för fyra plugins, över en fullständig staging-och-produktion-cykel. Modalen i sig sätter förväntningen att detta “usually takes less than a minute,” vilket min körning översteg med god marginal.

Det glappet mellan den angivna uppskattningen och den faktiska tiden är värt att planera för i stället för att bli överraskad av om du kör Safe Update på ett paket av plugins under ett underhållsfönster, räkna med minuter, inte sekunder, särskilt när antalet plugins ökar.

En lyckad notis bekräftade resultatet, och i samma ögonblick som det var klart loggade fliken History på kontonivå det som “On-Demand Successful: Plugins (4)” med en länk vidare till fullständig detalj.

Det där att sluta cirkeln, att se en åtgärd ske och sedan omedelbart kunna peka på en permanent registrering av den, är precis den typ av kundvittnesbevis en byrå behöver, och SafeUpdates gav dem aldrig det.

De två inställningarna som avgör hur förlåtande uppdateringar är

Båda dessa finns inne i schemaläggningsflödet snarare än i skärmen för uppdatering på begäran, vilket gör dem lätta att missa:

• Visual Regression Sensitivity styr hur stor visuell skillnad mellan staging-testet och produktion som tolereras innan en uppdatering avbryts för att skydda din layout. Den är som standard inställd på den strängaste tillgängliga nivån, “Critical, 0% difference.”
• Smart Skip for Plugin/Theme Update Failures, aktiverad som standard, betyder att ett enda plugin som misslyckas med att uppdateras inte stoppar hela batchen. Systemet lägger det ena objektet åt sidan, uppdaterar allt annat, kör den visuella regressionstestet på det som lyckades och skjuter dessa ändringar live automatiskt.

Tillsammans avgör dessa två standardinställningar om en obevakad nattlig uppdateringskörning väcker dig till ett flaggat plugin som ligger kvar i en kö, eller till en hel webbplats som har fastnat mitt i uppdateringen eftersom ett inkompatibelt tema tog ner hela processen. Värt att kontrollera båda innan du litar på att ett schema ska köra utan övervakning.

Cloudways

Hantera WordPress-applikationer som hostas hos Cloudways med centraliserade uppdateringar, Safe Updates, aktivitetsloggar och portföljomfattande schemaläggning.

Besök Cloudways

Schemalägg uppdateringar över hela portföljen på en gång

Det där täcker de två första dörrarna. Det här avsnittet täcker den tredje: att ta bort människan ur loopen helt och hållet. Fliken Auto Updates, nådd från samma Site Manager-sida på kontonivå, är platsen där löftet om att “hantera många webbplatser som om de vore en” antingen levererar eller faller platt. I mitt fall levererade det.

Så här ställde jag in det exakt. Från Integrations → Site Manager klickade jag på fliken Auto Updates i den övre raden.

Med inget schemalagt ännu visade sidan ett tomt tillstånd, “No Auto Updates Schedule,” med en enda knapp: Set Auto Update Schedule.

Att klicka på den öppnade en guide, “Set Auto Update Schedule,” som gick igenom följande i ett enda svep:

1. Day of Week and Schedule Time: två rullistor, plus en tidszonsväljare bredvid tidsfältet. Jag satte fredag, mellan midnatt och 5:59am UTC.
2. Select Application: en checklista över varje app som redan var registrerad i Site Manager, med ett Select All-alternativ, och en notis om att alla befintliga scheman som redan var satta på en vald app skulle ersättas av detta nya. Jag valde båda mina appar och klickade på Choose Preferences.

En andra skärm öppnades sedan, “Create Auto Update Schedule,” som täckte:

3. Configure Update List: tre utfällbara sektioner, WordPress Core, Plugins och Themes, var och en med sin egen checklista och en löpande räknare över hur många som var valda. Över mina två appar fanns tio plugins och fyra teman tillgängliga att inkludera, och varje enskilt plugin och tema visade exakt hur många av mina applikationer som faktiskt använde det, en liten detalj som betyder enormt mycket när du hanterar dussintals webbplatser och försöker avgöra vilka uppdateringar som är värda att testa brett versus vilka som bara påverkar en webbplats.

4. Update Type: en rullista som erbjuder Quick Update eller Safe Update, vardera med samma beskrivning som visades i den on-demand-modalen. Att välja Safe Update avslöjade två ytterligare kontroller som bara visas för det läget, Visual Regression Sensitivity och Smart Skip for Plugin/Theme Update Failures.

5. Critical Updates: en växel, avstängd som standard, reserverad specifikt för att trycka ut en säkerhetsdriven patch utanför det normala schemat i samma ögonblick som en sårbarhet flaggas.

Att klicka på Set AutoUpdate Schedule i botten sparade det, tillämpat på alla appar jag hade valt i steg två, utan behov av att upprepa konfigurationen en gång per webbplats.

Aktivitetsloggar: Delen som faktiskt handlar om kundförtroende

De tre dörrarna och uppdateringsmekaniken bakom dem täcker hur. Den här sista funktionen täcker beviset: en permanent registrering av vad som hände, separat från själva uppdateringsprocessen.

Så här slog jag på den exakt.

Från appens egen Site Manager Overview-sida, samma sida som du landar på efter att ha prenumererat via Väg 1, finns ett kort märkt “Activity Logs are Disabled” bredvid prestandaringen, med en kort beskrivning och en enda knapp: Enable Activity Logs.

Jag klickade på det, och kortet uppdaterades omedelbart, ingen bekräftelsedialog, inga ytterligare steg. När jag kontrollerade tabellen Manage Applications på kontonivå direkt efteråt, under Integrations → Site Manager, hade Activity Logs-kolumnen för den appen redan växlat från Disabled till Enabled, utan att sidan behövde uppdateras.

Den här funktionen ligger bakom Pro och finns för att besvara en fråga som varje byrå så småningom får från en kund: vem ändrade vad, och när?

Utan den lever svaret vanligtvis i ett WordPress-loggningsplugin som skriver till webbplatsens egen databas, vilket växer över tid och inte ger något skydd mot manipulering. Att ha den registreringen live utanför WordPress-installationen, i själva hostlagret, är en betydligt annorlunda nivå av förtroende för allt som är kundrelaterat.

Cloudways

Hantera WordPress-applikationer som hostas hos Cloudways med centraliserade uppdateringar, Safe Updates, aktivitetsloggar och portföljomfattande schemaläggning.

Besök Cloudways

För- och nackdelar

Vem det här faktiskt är för

Med hela funktionsuppsättningen, dess kostnader och dess svaga punkter på bordet är den sista frågan helt enkelt om den passar din specifika portfölj.

Den tydligaste passformen är en byrå eller frilansutvecklare som driver flera, helst många, WordPress-webbplatser som redan helt och hållet finns hos Cloudways, där en trasig uppdatering innebär en verklig kostnad i kundförtroende snarare än bara personlig irritation.

Safe Update-flödet och bulkplaneringen finns specifikt för att lösa problemet som uppstår när du har passerat den punkt där det fortfarande är rimligt att kontrollera varje webbplats individuellt.

Det är en delvis passform för alla med en blandad portfölj. Det gratis Site Manager-pluginet kan ta in externa webbplatser för grundläggande övervakning och uppdateringar, men de funktioner som gör den inbyggda instrumentpanelen värd att betala för, staging-baserad Safe Update, visuell regression, aktivitetsloggar, förblir utom räckhåll tills de webbplatserna faktiskt flyttas till Cloudways.

Det är helt enkelt onödigt för en ensam webbplatsägare. Gratisnivån skulle tekniskt sett fungera, men hela produkten finns för att lösa ett portföljproblem som en enda webbplats aldrig skapar.

Slutsats: Värt det, men bara inom Cloudways

Ja, site manager är värt att använda, på ett villkor: dina webbplatser måste redan ligga på Cloudways. Inom den gränsen levererar Site Manager det den lovar, en verklig instrumentpanel över flera appar, en Safe Update-väg som säkerhetskopierar innan den rör produktionen, och bulkplanering som behandlar uppdateringar som en åtgärd för hela flottan i stället för en per-inloggning-syssla.

Utanför den gränsen är det ett lättare verktyg med en tydlig migreringsknuff bifogad. Den bästa passformen är en byrå som konsoliderar kundwebbplatser på Cloudways och behöver ett ställe att bevisa vad som ändrades och när.

Cloudways

4.6

537 user reviews

106 kr /mo

Utgångspris

Besök Cloudways

Rating based on expert review

• Användarvänligt
  4.5
• Support
  4.6
• Funktioner
  4.8
• Pålitlighet
  4.8
• Priser
  4.3