WordPress 3.2 il piano: leggerezza e velocità


A pochi giorni dal rilascio della versione 3.1 si inizia a pianificare la futura versione, la 3.2, dal blog di sviluppo di WP Mark Jaquith ci informa che mentre questa settimana si definiranno le scadenze e le assegnazioni dei compiti, le principali linee di sviluppo della futura versione sono ormai delineate e punteranno a due obbiettivi fondamentali, la leggerezza e la velocità ecco le principali linee guida della prossima versione:

  • Tempi di irlascio più rapidi rispetto alla 3.1 — una release più focalizzata, si decideranno gli sviluppi con maggior precisione e ci si assicurerà che le persone si mantengano su questi obbiettivi per non cadere nella fase “ancora una cosa soltanto”.
  • IL tema principale sarà “veloce, leggero”— Si abbandonerà il supporto a tecnologie obsolete. CI si concentrerà per rendere le cose più veloci e sopratutto nel rendere il alvoro di scrittura dei contenuti più semplice e veloce.
  • Miglioramenti API List Tables — si finalizzerà la API per l’utilizzo da parte di terzi rendendola anche più flessibile.
  • Caricamento XHR delle Tabelle — da analizzare con attenzione dopo aver stabilitto le List Table API. Verificare che sia un vero miglioramento prima di dedicare tempo al suo sviluppo completo.
  • PHP 5.2—(nello specifico 5.2.4) come requisito minimo. SI abbandonerà al compatibilità precedente ma senza aggiungere molto codice specifico di PHP5. Lo scopo di questa release sarà quello di abbandonare il vecchio e non aggiungere grosse novità.
  • MySQL 5— come requisito minimo. Modifica che non comporterà particolare lavoro se nonq uello di cambiare i requisiti minimi. Non verranno modificate le query (N.d.t. Anche inq uesto caso si abbandonano vecchi requisiti ma senza introdurre grandi novità, un lavoro di pulizia più che di costruzione).
  • IE6 EOL (End Of Life) per l’admin — Se BrowseHappy verrà aggiornato in tempo, si considererà la possibilità di aggiungere un avvertimento “use a real browser” per gli utenti IE6. Ciò non permetterà di scartare molto dei CSS per IE6 perchè IE7 ne condivide buona parte dei problemi. Si tratta di una operazione sopratutto simbolica e riduce la combinazione di piattaforme da utilizzare nei test. Ciò comporterà anche che i problemi di sicurezza che dovessero verificarsi solo in relazione a IE6 potranno avereuna priorità più bassa nella loro risoluzione.
  • Distrazioni nella scrittura (di articoli) — Lo scopo è far dire: “ooh, che bello”. L’idea è rimpiazzare la versione corrente a tutto schermo conq ualche cosa di più bello, utilizabile (in termini di lunghezza di linea e di dimensione dei caratteri) e di semplice (limitatamente alla funzionalità dell’edito visuale). Per una idea di quello che vorremo si veda WriteRoom, OmmWriter, http://www.quietwrite.com/. Si sta analizzando la cosa e probabilmente verrà realizato un plugin come primo passo per lo sviluppo di questa parte.
  • Miglioramenti sull’aggiornamento — Gli aggiornamenti del tipo Solo-i-file-modificati possono venir eseguiti senza modifiche ai file di core di WordPress. Come primo passo si pensa di eseguire gli aggiornamenti solo da una versione alla successiva di una versione principale. Quindi ad esempio da  3.2 a 3.2.1 e dalla 3.2.1 alla 3.2.2. Come opzione si potrà pensare di eseguire una scansione completa dei file per identificare le modifiche e offrire la possibilità di un aggiornamento completo sovrascrivendo i soli file modificati. Inoltre, durante gli aggiornamenti, si escluderà completamente la directory wp-contents directory (nessun aggiornamento del tema standard e dei plugin a corredo).
  • Miglioramenti nella velocità — Vi è una enorme serie di cose che si possono fare per rendere WordPress più veloce nel caricamento o al limiti farlo “apparire” più veloce. SI sta considerando il PHP lazy loading. SI sta inoltre lavorando ad una modifica per rendere il caricamento del menu di amministrazione più veloce facendone l’espansione in PHP. Vorremmo rendere la bacheca più veloce non eseguendo richieste asincrone quando la cache è ancora calda. Stiamo anche lavorando a miglioramenti sull’FTP che dovrebbero rendere gli aggiornamenti più veloci per chi utilizza alcuni tipi di server FTP.

Come vedete questa release, oltre ovviamente alla correzione dei ticket aperti si concentra su due obbiettivi che pure non introducendo eclatanti novità “visuali” o funzionalità innovative dovrebbe rendere l’uso giorno per giorno di WordPress più semplice veloce e produttivo, preparando il campo ad ulteriori migliorie una volta abbandonate vecchie tecnologie e requisiti oramai obsoleti, che permetteranno con le future lrealese di introdurre effettive migliori a livello di codice php o di query SQL.

Voi che ne pensate? Quale altre cose avreste voluto vedere in questa versione? Quali pensate saranno gli sviluppi futuri?

Hai qualche Domanda o vuoi Commentare?

11 commenti su “WordPress 3.2 il piano: leggerezza e velocità

🙁 mai una considerazione in merito all’accessibilità
Non hanno minimamente preso in considerazione, come invece hanno fatto per i widget, che per esempio l’interfaccia drag&drop degli elementi menu è assolutamente inaccessibile a utenti con disabilità
siamo proprio presi in considerazione come la polvere sull’ultima ruota del carro.

Reply

basta supporto per ie6 e ie7, inoltre speriamo che succhi meno memoria!

Reply

A me piacerebbe una soluzione di archiviazione statica degli articoli vecchi magari per blog che superano i 10-20mila post pubblicati in modo da far rivitalizzare il database mysql.

In tal modo avremmo una parte recente molto veloce ed una più vecchia con qualche compromesso (neppure tanto eclatante, visto che l’accesso al file system è comunque veloce nei server. è la ricorrenza che lo mette un po’ in crisi rispetto ad un db tutto in memoria).

Reply

perche non permettere la creazione di un database di “riserva” nel caso il primo (quello principale) vado per qualsiasi ragione out il secondo entra automaticamente a lavoro e non appena il primo torno accessibile copia tutto il nuovo lavoro dal secondo restando cosi entrambi aggiornati e garantendo più sicurezza… 🙂 inoltre per chi ha molti articoli perche non dare la possibilità di dividere la tabella deli articoli, in modo da creare un database con tutti gli articoli nuovi e vecchi?? in modo da rendere piu veloce il resto e meno pesante il database principale…

Reply

@Elena: si vero non posso che concordare…

@evilripper: Quando si sviluppa un prodotto usato da milioni di persone abbandonare piattaforme ancora molto diffuse (e se per IE6 oramai le percentuali sono minime per IE7 non è così) non è una scelta possibile ne realistica… occorre una transizione lenta che segua il calo percentuale delle varie versioni.

@Traffyk & Vincenzo La Rosa: Le soluzioni da voi proposte sono estremamente pesanti da gestire in WP, quando si hanno siti con decine di migliaia di articoli con DB carichi e quindi anche con flussi di traffico significativi, la soluzione non è nell’applicativo ma nell’infrastruttura, nella configurazione dei sistemi nel caching fatto in modi diversi (es Varnish su cui sto avendo esperienze interessanti) ed esterni a WP, in soluzioni con DB master slave e uso di hyperDB etc etc… il lavoro è sopratutto sistemistico… e prevede uan infrastruttura adeguata.

50.000 articoli su un blog in hosting condiviso economico magari NON hanno senso… occorre macchine dedicate performanti DB dedicato o semidedicato etc.

Reply
Andrea

Io vorrei maggiore attenzione alla struttura della parte amministrazione per quanto concerne la sua semplificazione.

La parte admin ha tantissime opzioni che si usano in casi rari.
E se da un lato il poter fare tutto da più flessibilità dall’altro confonde l’utente inesperto.

Per fare un esempio pratico la gestione delle immagini sui media è piuttosto complicata.
Per cominciare ha troppi campi distinti titolo, alternativo, descrizione, didascalia. Nella stragrande maggioranza dei casi non serve la distinzione tra titolo e testo alternativo.
Poi prendiamo in considerazione il link url (link a file, link a articolo , none). E’ poco intuitivo e spesso è una cosa che confonde ed inutile oltre a far dei casini se metti nel tema delle lightbox in javascript.

In sostanza tutte queste opzioni vanno bene ma dovrebbero essere configurabili.
A me piacerebbe avere tutta una collezione di configurazioni per poter semplificare il pannello di amministrazione a discapito delle funzionalità attive.

In parte il problema lo risolve il plugin adminimize che nasconde parti di html identificate da id html. Ma rimane una soluzione pariziale.

Reply

@SteveAgl, ciao grazie per la tua risposta. Io fortunatamente ho a disposizione un dedicato molto prestante per la mia installazione di wordpress, è velocissimo ma so che la struttura del database è inefficiente perchè mysql carica in memoria tutte le tabelle per una rapida ricerca e selezione.

Questo comporta comunque uno spreco di risorse, spreco che ci porta sempre a sovradimensionare la nostra apparecchiatura hardware e mi piange il cuore (a volte pure il portafogli 😛 ).

La soluzione di @Vincenzo è accettabile soltanto se hai a disposizione una seconda macchina dedicata o una vps separata..altrimenti se il database hosta sulla stessa macchina di quello caduto non funziorebbe lo stesso.

Io invece ho in mente una cosa un po’ diversa, praticamente i post vecchi dovrebbero finire in una sorta di archivio (un po’ come quelli del corriere se ricordo bene).. Nell’archivio non sarebbe possibile commentare i post e i commenti precedenti dovrebbero essere integrati direttamente a corredo del post (sulla stessa pagina o link esterno fa uguale) senza intaccare la tabella mysql dei commenti.

Questo archivio può essere un secondo database esterno, io starei pensando ad esempio ad una strutturazione in sqlite divisa per cartelle relative agli anni e ai mesi ognuna con un db a se stante internamente, oppure un’archiviazione totalmente statica dei file alla stregua dei plugin wp-super-cache (che comunque utilizzo sempre!).

Sono tentato dal fare delle prove, a me interessa sempre risparmiare anche se fosse soltanto di 0,2 secondi in meno ad ogni esecuzione di pagina.. sono argomenti che mi piacciono molto e nel limite delle mie esigue competenze tecniche provo a metterci il mio.

Reply
Je92

A me non dispiacerebbe un pò di restyling grafico e la possibilità di personalizzare di più l’interfaccia amministrativa.

Penso poi che sarebbe utile rendere native alcuni funzioni oggi estendibili tramite plugin come la modalità manutenzione e le breadcrumbs…per i meno esperti sarebbe una manna dal cielo. Poi punterei sul rendere la piattaforma più leggera possibile perchè rispetto ad altri CMS, WordPress è ancora un pò pesantuccio…

Ciao

Reply

@traffyk: be certo naturalmente il db dovrebbe essere messo su una macchina diversa.. :), ottima funzionalità da aggiungere al wp sarebbe la gestione dell’archivio in modo tale da allegerire il carico del database… proprio per come dici tu usando due databasi diverse.. xò mi sorge una domanda e se il mio piano hosting mi permette di avere un solo db??? a mio parere ci dovrebbe essere una doppia possibilità, la prima: come dici tu, la seconda: implementare una tabella per l’archivio.. ma ciò dovrebbe essere una cosa fatta autonomamente ma questo se non sbaglio dovrebbe richiedere anche il cronjob male che va si fa tutti in modo manuale.. 😉 (nel limite del possibile)

concordo con @Je92 ottima cosa sarebbe integrare all’interno di wp alcuni plugin utili.. 😉 però per quanto riguarda tutto il cms sarebbe da “alleggerire” eliminando funzioni non piu usate.. ma in quel casa sarebbe da fare un cms “at personam” o meglio alle esigenze di chi lo usa effettivamente.. 😉

Reply

@traffyk: be certo naturalmente il db dovrebbe essere messo su una macchina diversa.. :), ottima funzionalità da aggiungere al wp sarebbe la gestione dell’archivio in modo tale da allegerire il carico del database… proprio per come dici tu usando due databasi diverse.. xò mi sorge una domanda e se il mio piano hosting mi permette di avere un solo db??? a mio parere ci dovrebbe essere una doppia possibilità, la prima: come dici tu, la seconda: implementare una tabella per l’archivio.. ma ciò dovrebbe essere una cosa fatta autonomamente ma questo se non sbaglio dovrebbe richiedere anche il cronjob male che va si fa tutti in modo manuale.. 😉 (nel limite del possibile)

concordo con @Je92 ottima cosa sarebbe integrare all’interno di wp alcuni plugin utili.. 😉 però per quanto riguarda tutto il cms sarebbe da “alleggerire” eliminando funzioni non piu usate.. ma in quel casa sarebbe da fare un cms “at personam” o meglio alle esigenze di chi lo usa effettivamente.. 😉

Reply

[…] ufficiali: WordPress Italia WordPress.com STAMPA Category PilloleTags news wordpressTrackback Track URL […]

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Archivi

Categorie