WordPress SDK 2.5.0-RC.1 este gata pentru testare: rezoluție clonării, îmbunătățiri UX cu feedback de dezactivare, amestecare a activelor și multe altele

Este oficial! WordPress SDK 2.5.0 RC1 este acum disponibil cu îmbunătățiri uimitoare (și relevante) care abordează ceea ce am identificat drept problemele tale cele mai comune și consumatoare de timp până în prezent.

Scopul nostru cu această versiune este să vă ajutăm să reduceți sarcina de asistență, astfel încât să puteți aloca mai mult timp pentru livrabile și alte activități mai productive.

Înainte de a ne aprofunda în funcții, avem nevoie de ajutorul tău 🙌

Apelați pentru testeri

Chiar dacă am efectuat teste amănunțite de tot felul (teste automate, manuale și de regresie), și deși ne simțim destul de încrezători în stabilitatea 2.5.0, datorită complexității și cantității de modificări de cod și cazuri de utilizare implicate în această versiune , am decis să-l împingem mai întâi ca candidat pentru lansare.

„Vreau să fiu implicat în testare – cum pot ajuta?”

Vrei să ne ajuți la testare? Este grozav și apreciat!

• Dacă rulați un program beta, pur și simplu actualizați SDK-ul la acest RC și împingeți o nouă versiune ca beta .
• Dacă nu rulați un program beta și știți că unii dintre clienții dvs. rulează medii clonate, cum ar fi punerea în scenă în producție sau folosesc pluginul/tema dvs. cu pluginuri WaaS precum WP Ultimo, atunci când vă contactează asistența din cauza problemelor SDK, le puteți trimite un versiune specială a produsului dvs. cu acest SDK, deoarece ar trebui să le rezolve problemele.

Indiferent, dacă încercați RC, indiferent dacă aveți probleme sau, dimpotrivă, dacă rezolvă problemele SDK cu care se confruntau utilizatorii dvs. înainte, vă rugăm să ne anunțați! Pur și simplu contactați-ne prin [email protected], deschideți o problemă GitHub sau utilizați orice alt canal de comunicare care este cel mai ușor pentru dvs. - vrem feedbackul dvs.

Să trecem la caracteristici.

Site-uri web duplicate și rezoluție clonă

Odată cu popularitatea tot mai mare a rețelelor WaaS (WordPress as a Service) și a companiilor de găzduire care oferă fluxuri de lucru de implementare a producției cu un singur clic, probabil că ați avut de-a face deja cu clienții care se plâng de probleme neașteptate atunci când este implicată duplicarea site-ului.

Pe scurt, o clonă este un site web (sau un subsite) care are un ID unic și o pereche de chei publice/secrete care au fost atribuite de Freemius și sunt identice cu ID-ul și cheile altui site web. Puteți afla mai multe despre clone, cum sunt create de obicei și când, în acest document.

Inspirat de interfața de utilizare a Jetpack, sunt încântat să vă spun că această versiune SDK vine cu un mecanism complet de identificare, gestionare și rezoluție a clonelor. Este o capacitate care se află în back-burner de ceva timp și vă încurajez să vă familiarizați cu problema site-urilor clonate și cu modul în care WordPress SDK o gestionează pentru a profita la maximum de îmbunătățire:

Îmbunătățiri UX pentru formularul de feedback de dezactivare

Amânare pentru instrumente de depanare

În timp ce formularul nostru de feedback pentru dezactivare oferă utilizatorilor o oportunitate unică de a oferi feedback proprietarilor de produse înainte de a abandona, de-a lungul anilor am auzit plângeri conform cărora utilizatorii chiar urăsc această funcție. După ce am analizat feedback-ul, am reușit să atribuim acest sentiment în mod specific segmentului „depanatorilor”.

Actualizările pluginurilor sunt o sarcină comună cu care întreținerii site-ului trebuie să se ocupe zilnic. Uneori, o actualizare de plugin/temă poate merge prost din cauza conflictelor, erorilor și incompatibilităților, cauzând probleme și erori neașteptate pe un site. De obicei, întreținerii nu se scufundă la nivelul codului, așa că procesul obișnuit de depanare este identificarea cauzei problemei cu dezactivările și reactivările pluginului, urmată de schimbarea temei. Adică trebuie să dezactivați pluginurile unul câte unul până când problema este rezolvată, apoi să le reactivați individual și în aceeași ordine în care au fost dezactivate. În teorie, acest lucru ar trebui să ajute la izolarea pluginului „problematic”, dar dacă nu descoperă problema, atunci următoarea încercare ar trebui să fie o „comutare a temei”.

Pe măsură ce „amprenta” temelor și pluginurilor care utilizează SDK-ul nostru WordPress crește, formularul de feedback de dezactivare adaugă un clic suplimentar la fiecare dezactivare. De acolo, reactivarea unui plugin alimentat de Freemius redirecționează automat la ecranul de înscriere sau la pagina principală de setări a pluginului (pe baza stării de înscriere), care adaugă un alt clic pentru a naviga înapoi la pagina de pluginuri.

Aceasta înseamnă că doar 5 plugin-uri care utilizează Freemius pe un site pot adăuga potențial 10 clicuri suplimentare - ceva ce este de înțeles enervant pentru cei care depanează. Și atunci când gestionați 20 de site-uri, de exemplu, toate acele clicuri se acumulează în timp, ceea ce explică de ce unor menținători chiar displace SDK-ul WordPress.

După ce am înțeles motivele din spatele „ura”, am venit cu o soluție simplă pentru a atenua „durerea” depanatorilor și, sperăm, să le recâștigăm o parte din încredere.

Formularul de feedback afișează deja o opțiune care indică o dezactivare temporară pentru depanare. Deci, în loc să trimitem doar acel feedback în felul nostru...

1. Afișăm acum o opțiune de amânare a panoului de la o oră la 30 de zile.
2. Pentru că ne dăm seama că nu adaugă nicio valoare proprietarilor de produse, alegerea de a amâna omite cu totul trimiterea feedback-ului către Freemius.
3. În cele din urmă, dacă administratorul amână formularul, redirecționarea va fi dezactivată pentru perioada de amânare.

Amânarea va afecta numai administratorul conectat curent și va funcționa pe toate pluginurile și temele bazate pe Freemius instalate pe site-ul respectiv.

Această UX îmbunătățită poate economisi tone de clicuri pentru depanatorii „grei” și suntem încântați să vedem diferența pe care o va face.

Activați dezactivarea cu Feedback „Alt” gol

Pentru a încuraja utilizatorii să trimită feedback, puteți acționa, anterior, când un utilizator a selectat opțiunea „Altul” din formularul de feedback de dezactivare, starea butonului „Trimiteți și dezactivați” a fost schimbată în dezactivată până când utilizatorul a introdus o introducere pentru a explica „ alt motiv.

Ni s-a atras atenția că acest UX a fost problematic deoarece utilizatorii citesc din stânga sus și unii aleg această opțiune pentru că pur și simplu nu doresc să ofere niciun feedback. IE, dacă aleg acea opțiune înainte de a observa că există o opțiune pentru „Skip & Deactivate”, dă impresia că este imposibil să dezactivezi produsul fără a oferi feedback.

Acum, când opțiunea „Altele” este selectată și caseta de explicații este goală, butonul este activat și etichetat ca „Dezactivare”:

Și, evident, nicio dată nu va fi trimisă până la capăt, deoarece feedback-ul gol „Alt” este inutil.

Stare casetă de selectare implicită a feedbackului anonim

Dacă un utilizator a omis înscrierea și a ales să ofere feedback utilizând formularul de feedback de dezactivare, în mod implicit, feedbackul nu a fost anonim pentru a vă permite să contactați utilizatorul dacă este necesar. Această versiune a SDK-ului introduce un nou filtru, astfel încât să puteți controla modul implicit de trimitere al formularului de feedback și să îl schimbați în feedback anonim în mod implicit, folosind următoarele:

my_fs()->add_filter( 'default_to_anonymous_feedback', '__return_true' );

Confuzie privind proprietatea activelor utilizatorilor — A dispărut!

Un procent sănătos din achizițiile de pluginuri și teme WordPress sunt făcute de „constructori”, unde în cele din urmă proiectul este predat clientului lor. Pentru a facilita relația, oferim o cantitate bună de flexibilitate pentru a permite schimbarea proprietății activelor contului de la o persoană la alta.

Fără să ne scufundăm în aspecte tehnice, cu multe milioane de site-uri care rulează SDK-ul nostru, am dat peste mai multe cazuri marginale care au amestecat în mod neașteptat activele între conturi. Deși aceste probleme au fost rare, este dureros pentru client, pentru tine și pentru noi să remediem.

Dacă a existat un concurs pentru problemele cele mai enervante și consumatoare de timp, acesta este câștigătorul incontestabil al anului 2020–2021 🏆 Este, de asemenea, un bun exemplu de a oferi prea multă flexibilitate fără a încerca să prevadă toate cazurile de utilizare (și niciodată va) poate provoca mai mult daune decât bine.

Nu numai că am adăugat câteva restricții în backend pentru a reduce cazurile de problemă, dar noua versiune WordPress SDK îmbunătățește, de asemenea, experiența de actualizare prin e-mail a contului, cu informații suplimentare din partea utilizatorului și tratează fiecare caz ușor diferit:

Remedierea HTTP 404 nu a fost găsită (AKA „Fără actualizări”)

Unii dintre voi s-ar putea să fi primit bilete de asistență în care clienții s-au plâns că SDK-ul produce erori și încetinește sistemul, de obicei cu o captură de ecran complementară a unei erori din Jurnalul de depanare (sau alte plugin-uri de depanare).

Erorile HTTP au fost returnate atunci când nu au existat versiuni mai noi, care este comportamentul așteptat al unei implementări corecte de API RESTful atunci când o resursă nu există.

Deoarece nu este trivial să înțelegem că acest comportament este așteptat până când ne contactați și a generat bilete de asistență inutile pentru dvs. (și noi), am modificat codul de răspuns HTTP la 200 pentru a elimina această confuzie o dată pentru totdeauna. Această modificare a API-ului a fost deja implementată cu câteva săptămâni în urmă, așa că există șanse mari să fi observat că acest tip de reclamație a dispărut.

Privind în urmă, recunoaștem acum că ar fi trebuit să facem această schimbare mult mai devreme. Doar că uneori aspectul tehnic „potrivit” nu este „potrivit” pentru utilizatorul final.

Toleranța la erori la problemele de conectivitate de fundal

Cu câteva săptămâni în urmă, AWS a avut o perioadă de nefuncționare temporară. Pe măsură ce ne găzduim serverele pe Amazon, desigur, timpul de nefuncționare a cauzat probleme de conectivitate la serverul nostru API. Site-urile web pe care cronul lor de sincronizare Freemius a fost executat în acea perioadă au fost adăugate cu o notificare respinsă despre problema de conectivitate, provocând o mulțime de întrebări de asistență din partea utilizatorilor în cauză. Scopul notificării este de a evidenția problemele de conectivitate în curs de desfășurare din cauza firewall-urilor, blocajelor ISP-ului etc. Nu este făcută pentru probleme temporare de conectivitate. Prin urmare, am îmbunătățit logica prin introducerea unui mecanism de toleranță la erori, astfel încât notificarea va fi adăugată numai după 3 încercări consecutive de conectivitate eșuate (de obicei, 3 zile).

Rezolvarea funcțiilor de rețea multisite depreciate

wpmu_new_blog() și deleted_blog() au fost depreciate în WP 5.1, care arunca o notificare când rula în modul de depanare. Am actualizat integrarea multisite pentru a folosi în schimb wp_insert_site() și wp_delete_site() în mod corespunzător atunci când rulăm pe noile versiuni WordPress. Mulțumesc Dario Curvino pentru contribuția ta 🙌

Filtre noi

Am introdus un nou filtru hide_freemius_powered_by pentru a vă permite să ascundeți fila Powered by Freemius din paginile generate de SDK:

my_fs()->add_filter( 'hide_freemius_powered_by', '__return_false' );

Și un alt filtru numit hide_billing_and_payments_info pentru a ascunde istoricul facturării și plăților afișat în mod implicit clienților în pagina Cont:

my_fs()->add_filter( hide_billing_and_payments_info', '__return_true' );

Activarea licenței „Anonim” — Te auzim!

Ca startup sau orice tip de afacere, aveți resurse limitate la început. Accentul numărul unu este să ajungi pe produs/adaptarea pieței, ceea ce te obligă în mod natural să prioritizezi și să faci sacrificii. Când am început Freemius, analiza noastră a pieței WordPress a fost că bricolagerii reprezintă cel mai mare procent de utilizatori din ecosistem. Prin urmare, unele dintre practici și UX au fost concepute pentru acel segment. Pe măsură ce ne maturizăm, în ultimii doi ani am depus un efort uriaș pentru a aplica feedback-ul colectat de-a lungul anilor pentru a răspunde mai bine nevoilor întrețintorilor și constructorilor. Deși acesta este un procent mult mai mic de utilizatori WordPress, este unul extrem de pasionat și important!

În această etapă, marea majoritate a feedback-ului comportamental primit de-a lungul anilor a fost deja încorporat în SDK-ul WordPress. Dar există încă o solicitare repetitivă care vine de obicei de la utilizatorii cunoscători de tehnologie, cu o sensibilitate mai mare a confidențialității: „De ce trebuie să mă înscriu atunci când activez o cheie de licență?”

Deși colectăm doar câteva valori de bază care beneficiază utilizatorii și producătorii de produse la activarea licenței - cum ar fi versiunea WordPress, versiunea PHP și localitatea site-ului web (informația completă este documentată în noua noastră pagină de practici de date) - este o îngrijorare corectă că noi am vrut să vă adresez astfel încât utilizatorii să se poată bucura de produsele dvs. cu încredere.

Deci, în următoarea ediție, intenționăm să introducem o nouă opțiune pentru activarea licenței fără a partaja date care nu sunt esențiale pentru activarea licenței și livrarea actualizărilor. În loc să reluăm arhitectura datelor, vom masca datele cu valori fictive pentru a oferi confidențialitate maximă. Rețineți că va trebui în continuare să colectăm adresa URL și IP-ul site-ului web, versiunea SDK și dacă produsul este activ sau inactiv. Dar asta e!

Pana data viitoare

Aveți feedback pentru următoarea activare a licenței „anonimă”? Aveți în minte anumite caracteristici pe care ați dori să le luăm în considerare? Simțiți-vă liber să le adăugați la panoul nostru Trello și, între timp, vânzări fericite!