Áttekintés céljából két WordPress alkalmazást regisztráltam a Cloudways Site Manager szolgáltatásba: az egyiket egy alkalmazás saját oldalsávjába rejtett onboarding képernyőn keresztül, a másikat pedig a fiókszintű tömeges folyamaton keresztül.

Innen egy valós Safe Update-et futtattam négy pluginen, létrehoztam egy megosztott automatikus frissítési ütemtervet, amely mindkét webhelyet lefedte, bekapcsoltam az aktivitásnaplózást, és elég időt töltöttem a fiókszintű vezérlőpulton ahhoz, hogy megértsem, ugyanaz az információ hol jelenik meg több helyen is, és miért fontos ez jobban, mint amilyennek hangzik.

Cloudways

A Cloudwaysen hosztolt WordPress alkalmazások kezelése központosított frissítésekkel, Safe Updates, aktivitásnaplókkal és teljes portfólióra kiterjedő ütemezéssel.

Látogatton el a(z) Cloudways weboldalára

Mi az a Cloudways Site Manager?

A Site Manager leváltotta a korábbi Cloudways kiegészítőt, a SafeUpdates-et. Ha megértjük, mire nem volt képes a SafeUpdates, szinte minden jelenlegi termékdöntés érthetővé válik.

A SafeUpdates mindent SSH-n keresztül futtatott, ami sajátos problémákat okozott mindenkinek, aki néhány webhelynél többet kezelt:

• Nincs vezérlőpult, így nem volt mód látni, mely webhelyek igényelnek figyelmet anélkül, hogy egyenként ellenőrizni kellett volna őket
• A frissítések rögzített heti ütemezéshez voltak kötve, függetlenül attól, hogy egy ügyfél napi javításokat vagy havi karbantartást igényelt-e
• A vizuális regressziós tesztelés oldalanként mindössze három asztali nézetre korlátozódott, ami igen gyenge lefedettséget jelentett minden olyan webhelyhez, amely több volt, mint egy egyszerű bemutatkozó oldal
• Nincs auditnapló, amely megmutatta volna, mi változott, mikor és ki hajtotta végre a változtatást

Az ügynökségek, amelyek húsz vagy annál több WordPress telepítést kezeltek, lényegében azt jelezték a Cloudwaysnek, hogy az eszköz addig működik, amíg nem kell skálázódnia, márpedig a skálázódás volt az egész oka annak, hogy a Cloudwaysnél voltak.

A Site Manager erre a visszajelzésre adott közvetlen válasz. Ez a kontextus fontos a továbbiak értelmezéséhez, mert megmagyarázza, miért tűnik a termék egyes része szokatlanul kiforrottnak egy olyan eszközhöz képest, amely még mindig Public Preview állapotban van, és miért látszanak más részek, például az az onboarding lépés, amellyel az első napon találkozik az ember, még mindig kissé varrottnak.

Mit tud a Cloudways Site Manager?

Ezzel a háttérrel a következő kérdés a hatókör: mire képes ez az eszköz valójában. Mielőtt belemennénk az onboardingba, a frissítésekbe és az ütemezésbe, érdemes pontosan meghatározni, mit fed le a Site Manager, és mit nem, mert az őszinte válasz árnyaltabb egy egyszerű igen vagy nem szónál.

A natív vezérlőpult csak Cloudways-es

Minden alkalmazás, amelyet a fiókszintű Site Managerben be lehetett regisztrálni, akár az alkalmazásonkénti képernyőn, akár az Integrations alatti tömeges varázslón keresztül, már eleve a Cloudways-fiókomban lévő szerveren futott.

Nem volt olyan mező, ahová egy külső hoszton futó telepítés hitelesítő adatait be lehetett volna illeszteni, és nem volt csatlakozó egy másik szolgáltatónál futó webhelyhez sem.

A jelen áttekintésben tárgyalt teljes funkciókészlet, a Safe Update staging klónja, a vizuális regressziós tesztelés, az aktivitásnaplók, a tömeges ütemezés, mindez ebben a natív, Cloudways által hosztolt rétegben található.

Egy külön plugin könnyebb monitorozást biztosít bármely webhelyhez

A Cloudways emellett kiad egy ingyenes WordPress plugint, szintén Cloudways Site Manager néven, amelyet a WP Remote-tal közösen fejlesztettek.

A natív vezérlőpulttal ellentétben ez a plugin közvetlenül telepíthető egy WordPress webhelyre, függetlenül attól, hol hosztolják, így egy változata lehetővé teszi, hogy egy külső, nem Cloudways-es webhely is bekerüljön ugyanabba a központosított nézetbe.

Ez azonban egy valóban más termék, és a kettő közötti különbség számít:

A plugin emellett letiltja a WordPress saját automatikus frissítéseit, amíg aktív, ez a Cloudways részéről tudatos döntés, hogy elkerülje az ütközéseket a távoli menedzsment során.

A Cloudways nyíltan közli, hogy a plugin-út inkább lépcsőfok, mint végállomás: ha a teljes csomagot szeretné, automatizált biztonsági mentésekkel, egykattintásos staginggel, Cloudflare-integrációval és menedzselt gyorsítótárazással, akkor a javasolt legjobb gyakorlat az, hogy a külső webhelyet inkább átköltözteti a Cloudwaysre, mintsem hosszú távon távolról kezeli.

Egy teljesen Cloudways-en hosztolt portfólióval rendelkező ügynökség számára mindez nem számít. Bárki számára viszont, aki még mindig néhány webhelyet máshol futtat, és az általam az évek során megismert ügynökségek közül soknak van legalább néhány ilyen, a plugin valódi lehetőség az alap monitorozásra és frissítésekre, csak nem helyettesíti azt, amit a natív vezérlőpult nyújt.

Cloudways

A Cloudwaysen hosztolt WordPress alkalmazások kezelése központosított frissítésekkel, Safe Updates, aktivitásnaplókkal és teljes portfólióra kiterjedő ütemezéssel.

Látogatton el a(z) Cloudways weboldalára

Első lépések: Kétféle mód webhelyek regisztrálására

A hatókör kérdésének tisztázása után a gyakorlati rész itt kezdődik: magának egy WordPress alkalmazásnak a regisztrálása. A Cloudways két utat kínál a natív Site Managerhez, és ezek egyáltalán nem egyformán alkalmasak a feladatra.

1. út: az alkalmazás saját oldalsávján keresztül

Íme pontosan, hogyan jutottam el ide először. A Cloudways főoldaláról rákattintottam a szerveremre, majd az azon futó WordPress alkalmazásra, ami az adott app Access Details oldalára vitt.

Az ottani bal oldalsávban az Access Details, Staging Management, Monitoring, Application Security, Domain Management és végül a Site Manager szerepelt, egy “New” címkével jelölve. Erre kattintva egy olyan képernyőre jutottam, amelynek címe “Simplify App Management with Site Manager,” és amely kizárólag erre az egy alkalmazásra vonatkozott, középen két tervkártyával, Basic és Pro.

Az Get Pro gombra kattintottam. Ekkor fordultak rosszra a dolgok.

A képernyő átváltott a “Subscribing to the Site Manager Plan…” nézetre, egy üzenettel, amely szerint a Cloudways telepíti a plugint és szinkronizálja a webhely adatait, és ez az alkalmazás méretétől függően néhány percet is igénybe vehet.

Körülbelül két percig futott, majd hibával leállt, és egy piros értesítést adott vissza: “Please delete existing plugin and install again.” Korábban nem volt telepítve plugin, amit törölni lehetett volna, így maga az üzenet nem árulta el, mi ment valójában rosszul.

Másodszor is megnyomtam a Get Pro gombot, ugyanazon a tervképernyőn, anélkül, hogy bármit változtattam volna. Ez a próbálkozás sikerült. Körülbelül három percig futott, majd zöld sikerértesítéssel zárult, amely megerősítette, hogy feliratkoztam a Site Manager csomagra, és az alkalmazás Site Manager Overview oldalára jutottam, ahol a pluginok száma, a témák száma, a teljesítményérték és a Manage Updates táblázat már mind ki volt töltve és használatra kész volt.

2. út: a fiókszintű vezérlőpulton keresztül

Ez az az út, amelyet akkor érdemes használni, amint egynél több webhelyet kezel. Íme pontosan, hogyan találtam meg és használtam.

A Cloudways főoldaláról a bal oldali navigációban egy ikon sor látható: Home, Flexible, Autonomous, Integrations és Agency Partners. Az Integrations lehetőségre kattintottam. Ez egy kártyákat tartalmazó panelt nyitott meg, köztük a Site Manager (egy “New” címkével), Application Migration, DNS Made Easy, CookieYes és Equalize Digital Accessibility Checker elemekkel.

A Site Manager kártyára kattintva egy teljesen más képernyőre jutottam, mint az 1. út esetében, amely az Integrations → Add-Ons → Site Manager útvonal alatt található, és saját tab-sora van: Overview, Manage Updates, Auto Updates, History.

Ez az Overview oldal az igazi központ. Megmutatja a fiókszintű statisztikákat, a Total Apps on Site Manager, Apps on Free Plan, Apps on Pro Plan, Apps with Auto Updates értékeket, és alatta egy Manage Applications táblázatot, amely felsorolja az összes már regisztrált alkalmazást.

További alkalmazások bevonásához a táblázat jobb felső sarkában az Add Apps to Site Manager gombra kattintottam. Ez egy kétlépéses varázslót nyitott meg:

1. Select Application(s): a fiókomban lévő, még nem regisztrált összes WordPress alkalmazás listája jelölőnégyzetekkel, egy Select All opcióval és egy keresőmezővel.

Fent a lista felett egy megjegyzés jelezte, hogy a staging appokat, a leállított szervereken lévő appokat, valamint a korábbi SafeUpdates kiegészítőt használó alkalmazásokat kizárja. Kijelöltem a kívánt appot, majd a Select Plan gombra kattintottam.

2. Select your Plan: a Basic és Pro egymás mellett látható ismét, ezúttal megerősítve, hány alkalmazást választottam ki, és mekkora a teljes havi költség ehhez a csomaghoz. A Pro-t választottam, majd az Enable Site Manager gombra kattintottam.

Az egész folyamat kevesebb mint egy percet vett igénybe, miután a varázsló képernyőjére értem, és egyszerre az összes kiválasztott appra alkalmazta a beállítást, anélkül, hogy minden egyes webhelyhez újra el kellett volna végezni a tervválasztást.

A rés, amire senki nem figyelmeztet

Miután mindkét úton regisztráltam alkalmazásokat, íme az a megállapítás, amely megváltoztatta, hogyan gondolok erre a termékre a mindennapi működés szempontjából. Egy második WordPress alkalmazást adtam hozzá egy olyan szerverhez, amelyen már a Site Manager aktívan kezelt egy másik appot ugyanazon a szerveren.

Azt vártam, hogy az új app automatikusan megjelenik, mivel közvetlenül egy olyan alkalmazás mellett volt, amelyet a Site Manager már ismert. Nem így történt. A fiókszintű vezérlőpult “Total Apps on Site Manager” számlálója változatlan maradt, amíg manuálisan végig nem vittem az új appot az onboardingon.

Ez egy tudatos tervezési döntés, de olyan, amelynek működési költsége van:

• Egy három-négy webhelyet kezelő freelancer számára egy új webhely regisztrálásának észben tartása triviális.
• Egy olyan ügynökségnél, ahol hetente vagy kéthetente új ügyfélwebhely indul, ez örökre visszatérő tétel lesz valakinek a teendőlistáján.
• Ha egyszer elmarad, az a webhely kimarad a monitorozásból, a tömeges frissítésekből és az aktivitásnaplókból is, és láthatatlanná válik a vezérlőpult számára, amelynek elvileg az egyetlen megbízható forrásnak kellene lennie.

Cloudways

A Cloudwaysen hosztolt WordPress alkalmazások kezelése központosított frissítésekkel, Safe Updates, aktivitásnaplókkal és teljes portfólióra kiterjedő ütemezéssel.

Látogatton el a(z) Cloudways weboldalára

Mit fizet valójában ezért?

A Site Manager egy valóban használható ingyenes szintre és egy Pro szintre oszlik, amely feloldja azokat a funkciókat, amelyekre egy ügynökség ténylegesen munkafolyamatot építene.

Basic vs. Pro, funkcióról funkcióra

A Basic nem egy megnyirbált próbaidőszak. Valódi webhelyáttekintést tartalmaz, lehetővé teszi a felhasználók, témák és pluginok kezelését anélkül, hogy a wp-adminhoz kellene nyúlni, biztosít egykattintásos WordPress single sign-on-t, Quick Updates-t, és ami fontos, magát a központosított vezérlőpultot is.

A Cloudways nem zárta fizetőfal mögé az alap “látni az összes webhelyet egy helyen” élményt. Amit fizetőssé tett, az minden olyan elem, amely elég megbízhatóvá teszi ezt a vezérlőpultot ahhoz, hogy felügyelet nélkül is lehessen rá cselekedni.

A Pro jelenleg ingyenesen használható a Public Preview alatt, függetlenül a feltüntetett ártól, amely apponként havi 3 $, és 2 $/appra csökken, ha átlépi az öt alkalmazást.

Mennyibe kerül valójában a Pro, ahogy nő a portfólió?

Az a kedvezményküszöb megéri a számolgatást, mielőtt valaki azt feltételezné, hogy a Pro olcsón skálázódik:

Ezek közül egyik szám sem irreális ahhoz képest, amennyibe egyetlen hibás, nem visszaállítható frissítés kerülhet ügyfélbizalom szempontjából, de az apponkénti árazás azt jelenti, hogy a számla egyenes vonalban nő a portfólióval, nem pedig olyan lépcsős kedvezmények mentén, mint amit néhány versenytárs eszköz kínál magasabb csomagoknál.

Három helyről is elindítható ugyanaz a frissítés

Az onboarding és az árazás után a továbbiakban az látható, milyen a napi használat, kezdve egy olyan architektúrával, amelyet érdemes megérteni.

Ez az a része a Site Manager kialakításának, amelyet a legtovább tartott ténylegesen megérteni, és ez nincs megmagyarázva magában a felületen.

• Egy alkalmazás saját Overview oldala továbbra is mutatja a saját Manage Updates táblázatát, amely ugyanazokat a függőben lévő pluginfrissítéseket listázza, mint amit a fiókszintű vezérlőpulton látnánk.
• A fiókszintű vezérlőpult soronkénti Actions menüje saját Manage Updates műveletet kínál, ugyanarra az alapul szolgáló adatra támaszkodva.
• Az Auto Updates fül lehetővé teszi ugyanennek a frissítésnek az ütemezését, egyetlen alkalmazásra vagy az összes regisztrált alkalmazásra egyszerre.

Ez a három ajtó ugyanabba a szobába vezet. Az alkalmazásonkénti nézet azoknak való, akik már az adott webhelyen dolgoznak, és észrevesznek egy függőben lévő frissítést. A fiókszintű soronkénti művelet azoknak való, akik a teljes portfóliót pásztázzák, és úgy döntenek, hogy most egyetlen webhelyen cselekednek.

Az ütemezési fül arra szolgál, hogy teljesen kivonja az embert a folyamatból.

Gyors frissítés és Safe Update

Az imént leírt három ajtó közül ez a szakasz az első kettőt, az alkalmazásonkénti nézetet és a fiókszintű soronkénti műveletet tárgyalja, mivel mindkettő ugyanazt a frissítési mechanizmust nyitja meg.

Minden csomagszint kínál Quick Update-et. Az alkalmazása másodpercekig tart: a frissítés közvetlenül a produkcióra kerül, kompatibilitási ellenőrzés nélkül és előzetes biztonsági mentés nélkül.

A Cloudways saját felületi szövege őszinte a kompromisszumról, figyelmeztetve arra, hogy az “may carry risks if updates aren’t compatible.”

A teszt során nem futtattam Quick Update-et, így első kézből nem tudom leírni, hogyan néz ki egy sikertelen futás a képernyőn. Ez valódi hiányosság ebben az áttekintésben, és minden olyan állítást, amelyet én vagy bárki más tesz a Quick Update hibakezeléséről anélkül, hogy ténylegesen elindította volna, kellő óvatossággal érdemes kezelni.

A Safe Update az a funkció, amely igazán megindokolja a Pro-ra váltást, és érdemes teljes egészében végigmenni rajta, mert a folyamat összetettebb annál, mint hogy egyszerűen „biztonsági mentés, aztán frissítés”.

Hogyan néz ki valójában egy Safe Update futás

Íme pontosan, hogyan indítottam el. Az Integrations → Site Manager alatti fiókszintű Overview táblázatból megkerestem azt az appot, amelyen függőben lévő frissítések voltak, majd rákattintottam a sor végén lévő hárompontos Actions menüre. Ez négy lehetőséget nyitott meg: WP-Admin, App Overview, Manage Updates és Manage Plan. Az Manage Updates opcióra kattintottam.

Ez egy modalt nyitott meg, amely felsorolta az összes függőben lévő pluginfrissítést, az én esetemben négyet: Breeze, Elementor, Object Cache Pro és WP Ulike, mindegyik kipipált állapotban, az aktuális verzióval és azzal a verzióval, amelyre frissülni fog.

A lista alatt két rádiógombos opció volt: Quick Update és Safe Update, mindkettő egy-egy mondatos magyarázattal a kompromisszumról. A Safe Update lehetőséget választottam, majd a Proceed gombra kattintottam.

Nem egyetlen állapotjelző pörgettyű jelent meg, hanem egy szakaszokra bontott ellenőrzőlista, amely valós időben frissül.

Staging környezet:

• Pre Snapshot
• Fetch Update Packages
• Frissítsd az egyes plugineket külön-külön
• Post Snapshot
• Cache ürítése
• Vizuális regresszió

Production:

• Ugyanez a sorrend ismétlődik, miután a staging sikeres, és egy utolsó cache ürítéssel ér véget

Hat óra 21 perckor indítottam el a futást, és hat óra 27 perckor fejeződött be. Hat perc, négy pluginra, egy teljes staging-then-production cikluson keresztül. Maga a modal azt az elvárást állítja, hogy ez “usually takes less than a minute,” ami az én futásomhoz képest jócskán alábecsülte az időt.

Érdemes ezzel a különbséggel számolni, nem pedig meglepődni rajta, ha Safe Update-et futtat több pluginra egy karbantartási ablakban: percekkel számoljon, ne másodpercekkel, különösen ahogy nő a pluginok száma.

Az eredményt sikerértesítés jelezte, és abban a pillanatban, amikor befejeződött, a fiókszintű History fülön naplózva lett mint “On-Demand Successful: Plugins (4)”, teljes részletekhez vezető hivatkozással.

Az a fajta teljes körű lezárás, amikor látja, hogy egy művelet lefut, majd azonnal rá is tud mutatni a róla szóló maradandó rekordra, pontosan az a klienstámogatási bizonyíték, amelyre egy ügynökségnek szüksége van, és amit a SafeUpdates soha nem adott meg.

A két beállítás, amely eldönti, mennyire megbocsátóak a frissítések

Mindkettő az ütemezési folyamatban található, nem az igény szerinti frissítési képernyőn, ezért könnyű átsiklani felettük:

• Visual Regression Sensitivity szabályozza, mekkora vizuális eltérés engedélyezett a staging teszt és a produkció között, mielőtt a frissítés leállna a layout védelme érdekében. Alapértelmezés szerint a legszigorúbb rendelkezésre álló szintre van állítva, “Critical, 0% difference.”
• Smart Skip for Plugin/Theme Update Failures, amely alapértelmezetten be van kapcsolva, azt jelenti, hogy ha egyetlen plugin frissítése sikertelen, az nem állítja meg az egész csomagot. A rendszer az adott elemet félreteszi, frissíti a többit, lefuttatja a vizuális regressziós ellenőrzést a sikeresen frissítetteken, majd automatikusan élesíti ezeket a változásokat.

Együtt ez a két alapbeállítás dönti el, hogy egy felügyelet nélküli éjszakai frissítési futás egyetlen megjelölt, sorban álló pluginról szóló értesítéssel ébreszt-e, vagy egy olyan webhelyről, amely egy inkompatibilis téma miatt félúton megakadt. Érdemes mindkettőt ellenőrizni, mielőtt bármilyen ütemezést felügyelet nélkül futtatna.

Cloudways

A Cloudwaysen hosztolt WordPress alkalmazások kezelése központosított frissítésekkel, Safe Updates, aktivitásnaplókkal és teljes portfólióra kiterjedő ütemezéssel.

Látogatton el a(z) Cloudways weboldalára

Frissítések ütemezése az egész portfólióra egyszerre

Ez lefedte az első két ajtót. Ez a rész a harmadikat fed le: az ember teljes kivonását a folyamatból. Az Auto Updates fül, amely ugyanarról a fiókszintű Site Manager oldalról érhető el, az a hely, ahol a “több webhely kezelése, mintha egy lenne” ígéret vagy beválik, vagy összeomlik. Az én esetemben bevált.

Íme pontosan, hogyan állítottam be. Az Integrations → Site Manager útvonalról rákattintottam az Auto Updates fülre a felső sorban.

Mivel még nem volt beállított ütemezés, az oldal üres állapotot mutatott: “No Auto Updates Schedule,” egyetlen gombbal: Set Auto Update Schedule.

Erre kattintva egy varázsló nyílt meg, “Set Auto Update Schedule,” amely egy menetben végigvezetett a következő lépéseken:

1. Day of Week and Schedule Time: két legördülő mező, valamint egy időzóna-választó az időmező mellett. Pénteket állítottam be, éjfél és 5:59am UTC közötti időpontra.
2. Select Application: minden, már Site Managerben regisztrált alkalmazás listája jelölőnégyzetekkel, egy Select All opcióval, és egy megjegyzéssel, hogy a kijelölt appokon már meglévő ütemezést ez az új felülírja. Mindkét appomat kiválasztottam, majd a Choose Preferences gombra kattintottam.

Egy második képernyő nyílt meg ekkor, “Create Auto Update Schedule,” amely a következőket fedte le:

3. Configure Update List: három lenyitható szakasz, WordPress Core, Plugins és Themes, mindegyik saját jelölőlistával és egy futó számlálóval, amely megmutatja, hány elem van kijelölve. A két alkalmazásom között tíz plugin és négy téma volt elérhető bevonásra, és minden egyes plugin, illetve téma mellett pontosan az is látszott, hogy az alkalmazásaim közül hány használja azt, ez egy apró részlet, amely rendkívül fontos, amikor már tucatnyi webhelyet kezel az ember, és el akarja dönteni, mely frissítéseket érdemes széles körben tesztelni, illetve melyek csak egyetlen webhelyet érintenek.

4. Update Type: egy legördülő menü, amely Quick Update-et vagy Safe Update-et kínált, ugyanazzal a leírással, mint az igény szerinti modalban. A Safe Update kiválasztása két további vezérlőt tett láthatóvá, amelyek csak ennél a módnál jelennek meg: Visual Regression Sensitivity és Smart Skip for Plugin/Theme Update Failures.

5. Critical Updates: egy kapcsoló, alapértelmezés szerint kikapcsolva, kifejezetten az olyan biztonsági javításokra fenntartva, amelyeket egy sebezhetőség jelzésekor azonnal, a normál ütemezéstől függetlenül kell kiküldeni.

Az alján lévő Set AutoUpdate Schedule gombra kattintva elmentettem, és ez az összes kiválasztott appra alkalmazásra került a második lépésben, anélkül hogy minden egyes webhelyhez külön-külön meg kellett volna ismételni a konfigurációt.

Aktivitásnaplók: az a rész, ami tényleg az ügyfélbizalomról szól

A három ajtó és a mögöttük álló frissítési mechanika bemutatja a hogyan-t. Ez az utolsó funkció a bizonyítékot mutatja: egy maradandó rekordot arról, mi történt, elkülönítve magától a frissítési folyamattól.

Íme pontosan, hogyan kapcsoltam be.

Az adott app saját Site Manager Overview oldalán, ugyanazon az oldalon, amelyre az 1. út során történő előfizetés után érkezik az ember, a teljesítménygyűrű mellett egy “Activity Logs are Disabled” címkéjű kártya látható, rövid leírással és egyetlen gombbal: Enable Activity Logs.

Rákattintottam, és a kártya azonnal frissült, nem jelent meg megerősítő párbeszédablak, és nem kellett további lépés. A fiókszintű Manage Applications táblázatot rögtön ezután megnézve, az Integrations → Site Manager alatt az adott app Activity Logs oszlopa már átváltott Disabled-ről Enabled-re, az oldal újratöltése nélkül.

Ez a funkció a Pro mögött van, és arra szolgál, hogy választ adjon arra a kérdésre, amelyet minden ügynökség végül megkap egy ügyféltől: ki mit változtatott meg, és mikor?

Enélkül a válasz általában egy WordPress naplózó pluginben él, amely a webhely saját adatbázisába ír, ami idővel felduzzad, és semmiféle védelmet nem nyújt a manipuláció ellen. Az, hogy ez a rekord nem magában a WordPress telepítésben, hanem a hosztolási rétegben él, érezhetően más szintű bizalmat jelent minden ügyféloldali projektnél.

Cloudways

A Cloudwaysen hosztolt WordPress alkalmazások kezelése központosított frissítésekkel, Safe Updates, aktivitásnaplókkal és teljes portfólióra kiterjedő ütemezéssel.

Látogatton el a(z) Cloudways weboldalára

Előnyök és hátrányok

Kinek való ez valójában?

Miután a teljes funkciókészlet, a költségek és a gyenge pontok is az asztalon vannak, az utolsó kérdés egyszerűen az, hogy illik-e az Ön portfóliójához.

A legnyilvánvalóbb célcsoport egy ügynökség vagy szabadúszó fejlesztő, aki több, ideális esetben sok WordPress webhelyet kezel, amelyek már teljes egészében Cloudwaysen futnak, és ahol egy hibás frissítés valós költséget jelent az ügyfélbizalomban, nem csupán személyes kellemetlenséget.

A Safe Update munkafolyamata és a tömeges ütemezés kifejezetten azt a problémát oldja meg, amely akkor jelenik meg, amikor már nem reális minden webhelyet egyenként ellenőrizni.

Ez részleges megoldás mindenkinek, akinek vegyes portfóliója van. Az ingyenes Site Manager plugin külső webhelyeket is be tud vonni az alap monitorozásba és frissítésekbe, de azok a funkciók, amelyek miatt a natív vezérlőpult megéri az árát, a staging-alapú Safe Update, a vizuális regresszió és az aktivitásnaplók, csak akkor érhetők el, ha ezek a webhelyek ténylegesen átkerülnek a Cloudwaysre.

Egyetlen webhelyet birtokló felhasználónak egyszerűen felesleges. A free tier technikailag működne, de az egész termék egy olyan portfóliószintű problémát old meg, amelyet egyetlen webhely soha nem teremt meg.

Konklúzió: Megéri, de csak a Cloudwaysen belül

Igen, a site manager megéri az alkalmazást, egy feltétellel: a webhelyei már a Cloudwaysen élnek. Ezen a határon belül a Site Manager teljesíti, amit ígér: valódi többalkalmazásos vezérlőpultot, egy olyan Safe Update utat, amely mentést készít, mielőtt az éles környezethez nyúlna, és olyan tömeges ütemezést, amely a frissítéseket flottaszintű műveletként kezeli, nem pedig egyenkénti bejelentkezési feladatként.

Ezen a határon kívül ez egy könnyebb eszköz, egyértelmű migrációs ösztönzéssel. A legjobb illeszkedés egy olyan ügynökség, amely az ügyfélwebhelyeket Cloudwaysre konszolidálja, és egy helyen szeretné bizonyítani, mi változott és mikor.

Cloudways

4.6

537 user reviews

3 440 Ft /mo

Kezdő ár

Látogatton el a(z) Cloudways weboldalára

Rating based on expert review

• Felhasználóbarát
  4.5
• Támogatás
  4.6
• Szolgáltatások
  4.8
• Megbízhatóság
  4.8
• Ár
  4.3