due chiacchiere

WordPress 2.9, beta 1

Ok, non ho resistito, ho già aggiornato questo blog alla prima beta (non stabile, stando agli sviluppatori) di WordPress 2.9. Se non altro perché bastano un paio di click per farlo: uno per installare un plugin che consente di “attingere” agli aggiornamenti quotidiani anziché alle versioni stabili, ed uno per scaricare l’ultima versione dal repository. Le funzionalità della versione 2.9 sono succose, sebbene manchi ancora quella che io attendo da sempre (una più robusta gestione di utenti, permessi e workflow, che renderà finalmente WordPress in grado di competere con blasonati sistemi a pagamento). Tra le più importanti vorrei citare:

  • possibilità di modificare le immagini direttamente online (rotazione, specchio, ridimensionamento, ritaglio)
  • cestino per articoli, pagine e commenti: finalmente non bisognerà andare a recuperare un backup su nastro, per ripristinare un articolo cancellato per errore dal sistema
  • inserimento di video da youtube ed altre fonti con il semplice copia e incolla dell’indirizzo a cui si trova il video stesso (già provato, molto figo)

Non consiglio l’aggiornamento a chi non ha dimestichezza con quest’aggeggio, meglio aspettare la versione stabile e lasciare ai temerari il lavoro sporco di trovare le magagne 🙂 Anche perché la versione in Italiano ancora non è stata resa disponibile (ovviamente!).

Commenti

  1. Tommy David ha detto:

    Argh, mi hai preceduto! Io però, più che sul mio sito, volevo provarlo su un sito di test, o in una directory separata…

  2. Emanuele ha detto:

    Non ho ancora cercato informazioni su una cosa importante: l’editor delle immagini si preoccupa anche effettuare un’ottimizzazione per il web? (Compressione corretta, possibilità di salvare come jpg progressive, eliminazione di tag inutili…).
    Senza queste funzioni l’editor serve solo a chi non si preoccupa di questi aspetti.
    Ciao,
    Emanuele

  3. camu ha detto:

    @Tommy David: ma no, bisogna vivere la vita sul fil di lana, sennò che gusto c’è 🙂
    @Emanuele: infatti secondo il mio personalissimo parere, è stato tempo “sprecato” dagli sviluppatori, che avrebbero potuto dedicare nell’implementare una gestione raffinata dei diritti e degli utenti, ed un sistema di workflow più completo. Ma come si dice, a caval donato non si guarda in bocca…

  4. Tommy David ha detto:

    No, no, non mi va proprio di rischiare di risolvere noie… 😉
    Non capisco invece cos’abbia la gestione utenti che non vada. Certo, non è adatta per farci una community. Ma per un blog multiutente è più che buona… (Ricordi quando c’erano dieci livelli per gli utenti?)

  5. camu ha detto:

    @Tommy David: beh, ogni tanto bisogna dare una mano per migliorare il software 🙂 Non si può sempre aspettare che gli “altri” facciano da cavie. Perché, come cantava qualcuno, a volte… gli altri siamo noi. Riguardo alla gestione utenti, io penso all’uso di WordPress come vero e proprio sistema per la gestione dei contenuti di un sito di medie dimensioni, dove hai redattori che devono poter scrivere solo in certe categorie, o gente in grado di correggere le bozze di altri, e via dicendo. Certo, per un blog personale va più che bene così com’è. L’idea di avere livelli di permessi è troppo rigida (appunto, ne servivano 10 per aumentarne un po’ la flessibilità), serve qualcosa più simile a Linux, dove ogni oggetto (articoli, pagine, categorie) è associato ad un proprietario ed un gruppo, con i rispettivi permessi di lettura e scrittura. Non sarebbe fantastico?

  6. Tommy David ha detto:

    Certo, come lo prospetti sarebbe un sistema davvero efficiente. Però, ribadisco, ci allontaneremmo sempre più dalla concezione di CMS per blog!

  7. camu ha detto:

    @Tommy David: concordo solo al 50%, nel senso che un gestore di blog non significa soltanto blog casalingo curato da una singola persona. WordPress è usato da grossi nomi, come il Wall Street Journal e la Fox, per dirne un paio. Si tratta sempre di “blog” (o meglio giornali online, ma la differenza è davvero sottile) ma le cui redazioni potrebbero beneficiare di un tale miglioramento. Lo so, ci sono dei plugin che più o meno fanno quello di cui parlo, ma capisci bene che mettere nel “core” una cosa del genere, sarebbe molto meglio…

  8. Tommy David ha detto:

    Dai, magari implementeranno tutto ciò nella 3.0. 🙂

  9. Emanuele ha detto:

    “Molto meglio”? Aggiungere funzioni significa sempre aggiungere peso alla piattaforma e, come si discuteva nell’altro post, bisogna sempre valutare le esigenze di tutti. I plugin sono un ottimo metodo per rendere modellabile WP e, personalmente, apprezzo i progetti che sanno rimanere compatti ma altamente personalizzabili.
    Ciao,
    Emanuele

  10. Tommy David ha detto:

    Mannaggia. Dal plugin devo scegliere le “Bleeding edge nightlies”, giusto?

  11. camu ha detto:

    @Tommy David: si, imposta a bleeding edge e poi vai nel pannello per aggiornare WordPress. Il sistema scaricherà la night build invece che il ramo stabile. Attento che alcune parti non sono tradotte in Italiano, quindi avrai un sistema ibrido 🙂 Ma che, ti sei convinto?

  12. Tommy David ha detto:

    No, lo sto solo provando in un dominio privato, per adesso… 😉

  13. Francesco ha detto:

    Ho sviluppato un tema accessibile per WordPress (ringrazio Camu per gli ottimi consigli), comprende anche un aggiornamento di due file del core (functions.php della directory wp-includes e wp-comments-post della directory principale) che uniformano al template le pagine contenenti i messaggi di errore.

    Ottempera alle indicazioni della legge 4/2004 e ai requisiti delle linee guida Wcag 2.0.

    Per le altre valutazioni mi affido a voi.

    Info e download alla pagina http://4elementi.info/wordpress/?page_id=47

    Francesco Carzedda

  14. camu ha detto:

    @Francesco: il prossimo passo potrebbe essere quello di sviluppare un plugin anziché modificare il core, il bello di WordPress è proprio nella sua flessibilità in tal senso!

  15. Francesco ha detto:

    Grazie Camu, ma a proposito del template della pagina degli errori, buona parte del codice della quale è contenuto in functions.php della cartella wp-includes… cosa dovrebbe fare il plugin?

    Modificare functions.php (della vartella wp-includes) o intercettare la funzione e sostituirsi allo stesso functions.php?

    Dammi un’altra pillola…

    Francesco

  16. camu ha detto:

    @Francesco: visto? A forza di pillole sta diventando una droga anche per te 🙂 Scherzi a parte, molte delle funzioni in functions.php sono “intercettabili” tramite un plugin e quindi personalizzabili. Puoi cominciare a dare un’occhiata alla documentazione ufficiale 🙂

  17. Francesco ha detto:

    Grazie della pillola, ma adesso ho bisogno dello zucchero… 🙁

    La funzione che fa comparire i tetri messaggi di errore è wp_die (in effetti cercare allegria in un nome cosi…) contenuta nel file wp-includes/function.php.
    Vorrei intercettarla con il file functions.php del tema per circondarla di formattazione html come ho fatto nel file originario, oppure… aiutoooooooo!!!

    Salutone

    Francesco

  18. camu ha detto:

    @Francesco: eh, hai trovato una delle poche funzioni che non si possono (ahime) intercettare a tutt’oggi 🙁 In quel caso si, hai bisogno di modificare il core del sistema, è vero…

  19. Francesco ha detto:

    Sollievo…. è come dire che il tema “Santa Lucia” (download alla pagina http://4elementi.info/wordpress/?page_id=47) può comprendere, nel pacchetto, il file wp-includes/functions.php? Almeno in attesa di evoluzione di WordPress?

    Non so se un plugin posa risolvere il problema.

    La mia idea è condividere il tema mettendolo a disposizione tra i temi di WordPress.

    Che ne pensate?

    http://4elementi.info/wordpress/

    Caro saluto

    Francesco

  20. Francesco ha detto:

    Ciao Camu,

    in effetti l’unico modo che ho trovato per non affidare a wp-includes/functions.php la gestione del template delle pagine di errore per mancato inserimento di nome, indirizzo di posta elettronica, commento è l’utilizzo delle pagine/formulario intermedie di verifica e correzione dei commenti inseriti: ho affidato a una funzione “if-elseif-else” l’azione di visualizzazione del formulario ovvero del messaggio di errore, prevenendo così l’attivazione della funzione wp_die.

    Non riesco ancora a impedire che arrivi alla funzione wp-die (“ammazzare” WordPress, contenuta in wp-includes/functions.php) l’input del messaggio già inserito.

    Se interessati a visualizzare il codice della soluzione del problema, il tema è all’indirizzo http://4elementi.info/wordpress/?page_id=47, il file è sendmail.php.

    Caro saluto

    Francesco

  21. Francesco ha detto:

    Scusate l’aggiornamento continuo, ma ho trovato il modo di non far arrivare alla funzione wp_die anche i commenti duplicati.

    Brevemente (per non farmi odiare :-/ ):
    ho messo le dita nel database (connessione a database) e ho richiamato tre valori dalla tabella wp_comments: autore, e-mail e contenuto.
    Nelle pagine intermedie “sendmail” ho inserito la funzione mysql_fetch_array nel contesto di un ciclo while e ho assegnato a una variabile i valori risultanti dalla lettura (ciclica appunto) dei tre elementi di ogni commento.
    Li ho confrontati con i valori “postati” alle pagine sendmail dalla pagina principale relativamente a nome, e-mail, contenuto commento e ho creato un ciclo if-else annidato che recita più o meno così:

    if “i tre valori coincidono nel formulario di input e nel risultato della ricerca su database” echo che “c’è un commento duplicato” e echo “nient’altro”;
    else (funzione if annidata) echo “tutto il form con le sue condizioni che già c’erano dentro” (nè nome, nè email nè contenuto devono essere = “”).

    Questa è la logica, che fa sembrare difficile la cosa, ma è tutt’altro.

    Potete vedere la pagina sendmail.php zippata col tema all’indirizzo http://4elementi.info/wordpress/?page_id=47 e – naturalmente – scrivermi (è tutto Gnu).

    Lo scoglio era pensare che gli errori (campi vuoti o commenti duplicati) non dovevavno arrivare a wp-includes/functions.php.

    Perchè tutto questo?

    Per inserire il messaggio die errore in una pagina col template del tema.

    Cari saluti

    Francesco

  22. camu ha detto:

    @Francesco: grazie per aver condiviso la tua soluzione… in effetti anche io ero alla ricerca di un metodo per visualizzare qualcosa di più “accessibile” del laconico messaggio di WordPress. Nel mio caso ho preferito mettere le mani nel core, anche se questo è un po’ scocciante perché bisogna rifarlo ogni volta che aggiornano il sistema, vedi imminente rilascio della 2.9 stabile.

  23. Francesco ha detto:

    Grazie Camu,

    ma in effetti… non funziona 🙁

    L’ho semplificata confrontando solo il testo dei commenti in database con il contenuto dell’input, ma c’è un problema.

    Inserisco nel ciclo while l’attribuzione del valore commento in database alla variabile “testo”, poi esco dal ciclo.
    Quindi ha acquisito tanti valori quanti sono i commenti.
    Quando vado a confrontare l’input (variabile Commento) con la variabile Testo, questa assume +uno+ dei valori tra i contenuti dei commenti in database, che non necessariamente coincide con l’input.

    Devo affinare il confronto, evidentemente if ($testo==$commento) non va bene.

    Ecco il testo della funzione

    $query = “SELECT comment_content FROM wp_comments”;
    $result = mysql_query($query) or die(mysql_error());

    while($row = mysql_fetch_array($result)){
    $testo = $row[‘comment_content’];
    }
    if ($testo==$commento)
    {
    print “Attenzione, esiste gia’un commento con lo stesso contenuto: probabilmente non l’hai scritto tu, se vuoi ritorna alla pagina precedente e correggi il testo. Se il link di ritorno alla pagina non funziona, premi il pulsante “indietro di una pagina” del tuo browser”;
    }
    else
    (e va avanti mostrando il form per la verifica che funziona).

    Però penso che la strada sia buona.

    Caro saluto

    Francesco

  24. camu ha detto:

    @Francesco: interessante, ma a questo punto si rischia di reinventare la ruota, nel senso che in fondo non si fa altro che rifare quello che farebbe WordPress. A questo punto forse ritengo più semplice modificare il core, in attesa che anche loro si decidano ad implementare la personalizzazione grafica dei messaggi d’errore…

  25. Francesco ha detto:

    Camu, in effetti è l’obiettivo che mi sono prefisso in quanto vorrei convidere (pubblicare con licenza Gnu) il tema creato (si chiama Santa Lucia, è la località dove abito), i temi accessibili sono davvero pochi.

    Il nodo adesso è: con questa funzione

    while($row = mysql_fetch_array($result)){
    $testo = $row[‘comment_content’];

    richiamo nella variabile $testo il contenuto di tutti i messaggi (li posso visualizzare se inserisco l’azione echo nel ciclo while).

    La variabile $commento contiene il testo del commento inserito dall’utente.

    Come posso confrontare $testo *in tutti i valori che assume* con $commento?

    Così chi installa il tema ha risolto tutti i problemi.

    Un caro saluto

    Francesco

  26. camu ha detto:

    @Francesco: non mi è chiara la domanda, ma l’intenzione di rilasciare un tema accessibile mi sembra lodevole 🙂

  27. Francesco ha detto:

    Camu, un amico su un forum mi ha aiutato a risolvere il problema, adesso la condizione per far comparire il messaggio di errore e non il formulario di verifica/correzione è

    $query = “SELECT comment_content FROM wp_comments WHERE comment_content='”.$commento.”‘”;
    $result = mysql_query($query) or die(mysql_error());
    $esiste=mysql_num_rows($result);
    if($esiste >0){

    e funzia.

    Così la funzione wp_die con la sua bianca paginetta di errore viene prevenuta dall’operato della pagina intermedia.

    Rimane il messaggio che indica all’utente che sta inviando i messaggi troppo velocemente, ma è un’eventualità remota.

    E poi l’errore 404, che cercherò di gestire.

    Dopo l’errore 404 condividerò il tema in modo Gnu.

    Eccolo all’opera

    http://4elementi.info/wordpress/

    Caro saluto

    Francesco

  28. camu ha detto:

    @Francesco: a voler essere strapignoli, c’è anche da sistemare quel die(mysql_error()) a questo punto eheh 🙂 Comunque complimenti, la tua perseveranza t’ha portato dove volevi!

  29. Francesco ha detto:

    mmm… considerato che la stessa funzione nelle istruzioni di connessione al database potrei anche toglierla… ma cosa ti preoccupa?

    Al limite scriverà che non c’è connessione al database senza tags .

    Dopo l’error 404 pubblico Gnu e vi informo.

    Salutone

    Francesco

  30. ALessandro ha detto:

    Ho aggiornato a 2.9 MA NON VEDO UNA SOLA PAGINA !
    Trovo File NOT FOUND sia sul sito che sul panello di controllo

  31. camu ha detto:

    @ALessandro: questo è molto strano in effetti, ci sono molte possibilità, tipo che provider utilizzi, che plugin hai installato, se usi .htaccess e via dicendo 🙂 Dammi qualche indicazione e vediamo che si può fare 😉 Su WordPress Italia segnalano che gli utenti Aruba potranno avere problemi. Viva Tophost eheh

  32. Francesco ha detto:

    .htaccess è anche il mio problema (non ho migrato a 2.9): cosa scrivete per ottenere la puntatura alla pagina 404.php in caso di url errato?

    Come promesso, vi informo che il tema Santa Lucia è ultimato, zippato e free alla pagina

    http://4elementi.info/wordpress/?page_id=47

    Buon Natale

    Francesco

  33. camu ha detto:

    @Francesco: non serve far nulla, WordPress chiama quel file automaticamente se tutto è configurato a dovere 🙂

  34. Francesco ha detto:

    Camu, la pagina del tema si chiama 404.php, funzia ma solo se configutr .htaccess con “ErrorDocument 404 /index.php?error=404”.

    E anche così funziona sul sottodominio ma non sull’indirizzo naturale http://miospazioweb/directoryblog/

    Buon prefestivo a tutti

    Francesco

  35. camu ha detto:

    @Francesco: hmmmm, strano, sarà allora qualcosa legato al provider che uso per questo blog, dato che nel mio caso la pagina viene servita automaticamente (in caso di URL non esistente) senza settare nulla nel file .htaccess. Buone feste anche a te!

Lascia un commento