Si può, infatti, impostare la dimensione della finestra in cui si digita per adattarla alla larghezza dei paragrafi del front-end.
Farlo è molto semplice grazie alla nuova funzione

add_editor_style();

che va inserita nel file functions.php del tuo tema.

Questa funzione cercherà il file editor-style.css nella cartella del tuo tema e lo utilizzerà per dare lo stile alla pagina “Visual” dell’editor. Potrai quindi definire lo stile ad esempio per unordered/ordered lists, blockquotes, images, headers, tables, etc.

Ovviamente per fare apparire il tutto uguale in maniera identica al front-end è necessario andare a prendere il setup del foglio di stile del tuo tema in style.css.
Copia quindi tutti i setup del testo da style.css e trasferiscili in editor-style.css e voilà il gioco è fatto (a parte ovviamente il campo mceContentBody che specifica la larghezza del campo in cui digiti e che deve essere uguale a quello della larghezza dei paragrafi nelle tue pagine).

Se volessi qualche setup personalizzato solo per le pagine di editing non c’è nessun problema a farlo, basterà infatti inserirli solo nel foglio di stile editor-style.css e appariranno solo nelle pagine dove componi i tuoi articoli.

<h2>I post più popolari</h2>
<ul>
<?php $result = $wpdb->get_results("SELECT comment_count,ID,post_title FROM $wpdb->posts ORDER BY comment_count DESC LIMIT 0 , 5");
foreach ($result as $post) {
setup_postdata($post);
$postid = $post->ID;
$title = $post->post_title;
$commentcount = $post->comment_count;
if ($commentcount != 0) { ?>
<li><a href="<?php echo get_permalink($postid); ?>" title="<?php echo $title ?>">
<?php echo $title ?></a> {<?php echo $commentcount ?>}</li>
<?php } } ?>
</ul>

Se vuoi modificare il numero di post visualizzati, puoi cambiare il numero 5 con il numero dei post che vuoi visualizzare.

Nel Codex di Wordpress c’è una frase che pochi leggono:

For performance reasons, it is not a good idea to start your permalink structure with the category, tag, author, or postname fields. The reason is that these are text fields, and using them at the beginning of your permalink structure it takes more time for WordPress to distinguish your Post URLs from Page URLs (which always use the text “page slug” as the URL), and to compensate, WordPress stores a lot of extra information in its database (so much that sites with lots of Pages have experienced difficulties). So, it is best to start your permalink structure with a numeric field, such as the year or post ID.

In pratica viene consigliato di non iniziare la struttura del permalink con una categoria, un tag, un autore o un nome di un post. Questo perchè, a causa della configurazione di Wordpress, il sistema consumerebbe tempo e risorse creando, e poi andando di conseguenza a leggere, delle informazioni extra nel database, aumentandone il carico inutilmente.

Un permalink dovrebbe iniziare con un campo numerico, come ad esempio un anno o l’ID di un post.
Ovvero non vanno mai usati:
/%category%/%postname%
o il solo
%postname%

E’ consigliabile, secondo le indicazioni di Wordpress una struttura del tipo:
/%year%/%monthnum%/%postname%/

Per avere una panoramica completa sulla questione, bisogna dire anche che molti SEO sostengono che l’impostazione sconsigliata da Wordpress, ovvero /%category%/%postname% sia invece efficace per i motori di ricerca.
A sostegno di tale tesi viene portato l’esempio del blog di Matt Cutts.

Per mia esperienza personale, ho constatato che l’impostazione consigliata da Wordpress non dà assolutamente problemi a livello di SEO, tant’è che molti miei articoli sono in prima pagina su Google e, considerando che un utente medio non può permettersi una struttura dei server come il buon Matt, ritengo consigliabile un’impostazione del tipo:
/%year%/%monthnum%/%postname%/

Qual’è la tua esperienza a riguardo?

Link: Using permalink – Wordpress Codex

W3 Total Cache

W3 Total Cache necessita, infatti, dell’abilitazione delle funzioni di compressione di PHP, che nell’installazione di default di questo linguaggio sono settate su Off.

Per abilitare la compressione in PHP devi modificare (va benissimo qualsiasi editor di testo, anche il block notes) il file php.ini alla riga
zlib.output_compression = Off
e al posto dell’Off mettere On
zlib.output_compression = On

Riavvia il server e con un comando phpinfo() controlla che alla riga zlib.output_compression corrisponda un valore di On.

Se non fai questa modifica gli utenti che visiteranno il tuo sito otterranno un messaggio di errore di incompatibilità del tipo di compressione.

Se utilizzi Aruba come hosting, questa modifica è molto semplice:
- accedi al pannello di controllo del tuo sito
- clicca sul pulsante Servizi Hosting Linux
- clicca su Personalizzazione del file PHP.INI
- metti la spunta a Wordpress (impostazione ottimizzata per l’utilizzo di wordpress)

Nei commenti segnala altri eventuali problemi che hai riscontrato con W3 Total Cache o, se vuoi, segnala come configurare il file php.ini del tuo hosting.

Link: W3 Total Cache

Vediamo come procedere:
1) Per prima cosa facciamo un bel backup del sito e del database. Non sto a rispiegarvi tutta la procedura, ma vi rimando alla parte relativa all’interno dell’articolo “Come fare l’upgrade di Wordpress a mano“.

2) Scarichiamo il plugin Wordpress Table Prefix Rename e installiamolo nella cartella dei plugin. Attiviamolo.

3) Andiamo in Settings > Table Rename
Appare la seguente schermata in cui possiamo inserire il nuovo prefisso:

Non c’è bisogno di inserire l’underscore alla fine del prefisso, perchè lo farà in automatico il plugin (l’underscore è utile in futuro se dobbiamo mettere mano alle tabelle in phpMyAdmin e non vogliamo impazzire per capire il nome delle tabelle che cerchiamo).
In questa fase è importante ricordare che come caratteri vengono accettati solo lettere, numeri o underscore.

4) A livello di database abbiamo finito, manca solo una piccola modifica al file config.php nella cartella principale dell’installazione di Wordpress.
Dobbiamo trovare la riga di codice in cui viene definito il prefisso delle tabelle, quella di default è
$table_prefix = ‘wp_’;
va sostituita con il prefisso che abbiamo scelto all’interno della schermata del plugin, nel nostro caso diventerà:
$table_prefix = ‘dfrt43xd_’;

5) Il processo è terminato. Se tutto funziona non ci resta che cancellare a mano tutte le vecchie cartelle con il prefisso wp_ (il plugin intelligentemente non le cancella di suo, ma ne fa un duplicato per il nuovo prefisso).
Ricordo che in phpMyAdmin occorre prima svuotarle cliccando sull’icona del cestino.

Breve tips per i programmatori: se siete alla ricerca di validi cheat sheet (tradotto letteralmente fogliettini) per i vari linguaggi di programmazione o CMS come ad esempio Wordpress, vi segnalo il sito che ha come obiettivo quello di raccogliere i migliori, ovvero Quicklycode.

Per risolvere il problema ho utilizzato la guida proposta dal sito  W3it che consiglia semplicemente di inserire:

$out = ob_get_contents();
$out = str_replace(array("\n", "\r", "\t", " "), "", $input);
ob_end_clean();

subito dopo il codice
header('Content-Type: text/xml; charset=' . get_option('blog_charset'), true);
$more = 1;

all’interno dei file relativi ai feed RSS:
feed-rss2.php, feed-rss2-comments.php, feed-rss2-comments.php, feed-rss.php, feed-rdf.php, feed-atom.php, feed-atom-comments.php.

In pratica con poche righe di codice diciamo al sistema di cancellare tutti gli a capo con uno spazio vuoto.

function caption_off() {
    return true;
}

add_filter( 'disable_captions', 'caption_off' );

Ecco quelli che ho riscontrato e come si possono risolvere:

Problema nuova installazione Wordpress 2.9 – Il processo di installazione può bloccarsi con un messaggio di errore in cui il sistema dice di non riuscire ad accedere al server localhost. Il problema è dovuto dal fatto che questa versione non scrive correttamente il file config.php lasciandolo con i dati di default. Per risolvere dovete andare nella root della vostra installazione di Wordpress, cercare il file config.php e inserire a mano i dati di connessione al database.
Ovvero: nome utente, nome del database, indirizzo IP della macchina su cui risiede e ovviamente la password di accesso al database MySQL.

Problema su hosting Aruba e altri (mancato aggiornamento – malfunzionamento – il sito non funziona più) – Il problema è dovuto al fatto che Aruba e altri hosting hanno ancora su alcune vecchie macchine delle versioni di MySQL non aggiornate, spesso hanno la 4.0.3.
Dalla versione 2.9 di Wordpress in poi i requisiti minimi per il suo corretto funzionamento sono cambiati, ora occorre almeno la versione 4.1.2 di MySQL.
Per risolvere è inutile chiedere un aggiornamento della versione MySQL all’hosting, perchè vi dirà al 99% di comprare un nuovo  database e trasferire il blog qui. Fortunatamente Aruba sulle nuove macchine ha una versione molto aggiornata di MySQL, la 5 e oltre, quindi per un po’ starete tranquilli.
Fate un bel backup dell’attuale blog (sia dei files che del database), comprate il nuovo database e trasferite tutto.

Al momento non ho riscontrato problemi con i plugin, vi consiglio comunque, prima di aggiornare, di andare sul Codex di Wordpress e controllare se i plugin che usate risultano essere compatibili con la nuova versione.

Infatti, oltre al nuovo sistema di aggiornamento dei plugin stessi, è cambiata anche la procedura per testare la loro compatibilità con le diverse versioni di Wordpress.

Prima per verificare se un plugin era compatibile con una versione di Wordpress occorreva andare su questa pagina del Codex e controllare nei diversi elenchi se il plugin che ci interessava era presente nella lista.

Da oggi invece il sistema diventa social, ovvero sulla pagina di ogni singolo plugin nella colonna di destra è stata inserita una nuova sezione in cui gli utenti possono “votare” la compatibilità fra la versione di Wordpress installata e la versione del plugin in questione.

Ecco ad esempio la schermata che ci conferma la compatibilità del plugin NextGEN Gallery nella sua versione 1.4.3 con l’attuale versione di Wordpress, la 2.9. Per poter lasciare il feedback è necessario registrarsi.