Nuova home page di WordPress.org, acquisizione di Cloudways, WebP in attesa ️ Notizie WordPress di settembre 2022 con CodeinWP

DesktopServer, uno strumento di sviluppo WordPress locale, si sta spegnendo definitivamente

In una triste notizia, ServerPress ha annunciato che avrebbe chiuso lo strumento di sviluppo WordPress locale DesktopServer dopo 12 anni di attività (insieme al business ServerPress in generale).

Per quanto ne so, DesktopServer è stato uno dei primi strumenti di sviluppo locale specifici per WordPress e offriva una serie di comode funzionalità per gli utenti di WordPress.

Il team di DesktopServer stava lavorando su una nuova versione (5.0), ma ha smesso di lavorarci dopo essere giunto alla conclusione che non aveva molte possibilità di raggiungere una quota di mercato elevata.

Ad essere onesto, questo non mi sorprende davvero. La concorrenza in questo spazio si è davvero accesa, in particolare da parte degli host WordPress gestiti che rilasciano strumenti di sviluppo locale gratuiti come valore aggiunto/attrazione per i loro clienti di hosting.

Ad esempio, Flywheel (e successivamente WP Engine) ha avviato questa tendenza con Local WP. Quindi, anche Kinsta è entrato nel mix con DevKinsta.

Dato che entrambi questi strumenti hanno versioni gratuite funzionali e illimitate, è difficile giustificare il costo per DesktopServer, anche se è/era uno strumento solido.

Per non parlare del fatto che ci sono anche molte nuove opzioni di sviluppo locale che non sono specifiche per WordPress, ma funzionano comunque bene per i siti WordPress.

Penso che il team di ServerPress lo stia gestendo in modo davvero equo, però. ServerPress continuerà a supportare le persone con una licenza fino alla scadenza dell'abbonamento, inclusa l'assistenza nella migrazione a un altro strumento.

C'è la possibilità che ServerPress venda o renda disponibile il codice DesktopServer, ma non ci sono ancora notizie ufficiali al riguardo.

Per vedere alcune altre opzioni, puoi leggere la nostra raccolta completa dei migliori strumenti di sviluppo locale di WordPress.

Si presume che WP-Optimize aumenti artificialmente i suoi punteggi di ottimizzazione

Se hai mai approfondito l'ottimizzazione delle prestazioni di WordPress, probabilmente hai notato una tendenza davvero fastidiosa:

Molti utenti, specialmente quelli più casuali, si preoccupano più dei "punteggi di ottimizzazione" dei loro siti che delle prestazioni effettive dei loro siti.

Certo, il loro sito potrebbe caricarsi in meno di un secondo per tutti i visitatori, ma hanno ottenuto solo un 79 nel loro strumento di test della velocità, quindi chiaramente qualcosa non va.

Forse non sorprende, quindi, che alcuni plug-in per le prestazioni di WordPress facciano di tutto per aumentare i punteggi delle prestazioni in ogni modo possibile.

Questo mi porta a questo tweet di Gijo Varghese, che produce il popolare plug-in di ottimizzazione FlyingPress, oltre a una serie di strumenti di ottimizzazione gratuiti.

Nel tweet, Gijo afferma che il popolare plug-in WP-Optimize sta rilevando strumenti di test della velocità popolari e non fornisce JavaScript a tali strumenti, aumentando così artificialmente le prestazioni durante il test (anche se JavaScript sarebbe comunque servito ai visitatori umani).

WP-Optimize è un plug-in completo per le prestazioni di WordPress che è stato acquisito dallo stesso team dietro UpdraftPlus .

Se fosse vero, ciò risalirebbe allo scandalo delle emissioni Volkswagen, in cui la Volkswagen stava abbassando artificialmente le emissioni ma solo durante i test. Nel mondo reale, le emissioni erano fino a 40 volte superiori.

In una risposta alle richieste di WP Tavern, David Anderson di UpdraftPlus ha affermato che il codice è stato aggiunto come parte dell'inclusione del codice da un fork del plug-in Fast Velocity Minify e che il codice non è stato modificato da quando è stato inizialmente unito al WP- Ottimizza plug-in.

David ha affermato di aver incaricato lo sviluppatore JavaScript principale del team di indagare sul codice e, se è effettivamente disponibile solo per gli strumenti di test della velocità di gioco, verrà rimosso.

Nel complesso, sono un utente felice di UpdraftPlus da molto tempo, quindi sono propenso a concedere loro il beneficio del dubbio che non sia successo nulla di intenzionalmente sinistro. Eppure, non sarebbe dovuto succedere.

Ad ogni modo, questo è un buon promemoria del fatto che, quando si tratta di prestazioni di WordPress, dovresti sempre concentrarti sulle esperienze reali dei tuoi visitatori umani, piuttosto che sui "punteggi" di ottimizzazione nebulosi.

Newsletter La colla abbandona WordPress.org per diventare premium

A molti sviluppatori di plugin piace la directory dei plugin di WordPress.org perché consente loro di accedere a un vasto pubblico.

Tuttavia, ci sono anche alcuni aspetti negativi, in particolare alcuni... utenti autorizzati, per così dire, che desiderano un supporto di alta qualità da un'estensione gratuita.

Tuttavia, la maggior parte degli sviluppatori ignora la directory dall'inizio (ad esempio, Gravity Forms) o accetta la richiesta di supportare quegli utenti gratuiti in cambio dell'esposizione che offre loro.

Ecco perché ho pensato che fosse interessante che Newsletter Glue abbia preso la decisione di chiudere ufficialmente il suo plugin gratuito WordPress.org esistente per passare a un approccio all-premium ( dopo alcuni mesi di preavviso – non l'hanno fatto di punto in bianco ).

La pagina WordPress.org è ufficialmente disabilitata a partire dal 15 agosto.

In un'intervista con WP Tavern, Leslie Sim di Newsletter Glue ha affermato di non aver impostato l'esperienza free-to-premium in modo ottimale.

Ad esempio, gli utenti dovevano eliminare la versione gratuita del plug-in e installare un plug-in premium separato, il che significava che il conteggio delle "installazioni attive" di Newsletter Glue su WordPress.org sarebbe rimasto irrealisticamente basso ( poiché il conteggio delle "installazioni attive" sarebbe effettivamente diminuito se qualcuno è passato a premium ).

Se hai intenzione di rilasciare il tuo plugin o tema, questo è un buon promemoria che ti consigliamo di pensare a questi tipi di implementazioni prima di andare in diretta.

WebP per impostazione predefinita è in attesa (di nuovo)

Lo faranno o non lo faranno? Questa è stata la domanda sull'utilizzo predefinito di WebP nel core di WordPress.

Per "impostazione predefinita", intendo la generazione automatica di versioni WebP delle immagini JPEG appena caricate ( che essenzialmente raddoppierebbe il numero di file di immagine sul server ).

Anche se gran parte del lavoro principale era già stato unito alla prossima versione di WordPress 6.1, sembra che ora sia "in attesa" dopo le obiezioni di un certo numero di sviluppatori principali di WordPress.

I reclami comuni sull'attuazione sono i seguenti:

• Raddoppierà il numero di file di immagine sul server.
• Aumenta notevolmente l'elaborazione richiesta per il caricamento delle immagini, poiché il server ora dovrebbe convertirle ulteriormente in WebP. Ciò potrebbe anche causare più frequenti errori di caricamento delle immagini.

Nel complesso, tendo ad essere d'accordo sul fatto che questo non abbia senso come caratteristica principale, almeno nella sua attuale implementazione.

Se gli utenti desiderano effettivamente utilizzare le immagini WebP, hanno tantissime opzioni, inclusa la conversione delle immagini stesse o l'utilizzo di un plug-in come Optimole che ottimizza dinamicamente le immagini in tempo reale.

Sembra anche che gli sviluppatori sponsorizzati da Google siano quelli che guidano il cambiamento, il che potrebbe essere un po' un conflitto di interessi dato che Google ha anche sviluppato il formato WebP.

Nel complesso, la spinta per WebP di default non è sicuramente morta, ma resta ancora da vedere quando e come arriverà l'implementazione.