PhocaPDF è un plugin scaricabile gratuitamente che permette di aggiungere alcune comode funzioni quali appunto la trasformazione di un articolo Joomla in PDF e l’aggiunta di alcune personalizzazioni come il logo, l’header, il footer, etc.

Presso alcuni Hosting può capitare che invece che la creazione del PDF generi errori quali:

• 504 Gateway Timeout
• 500 Internal Server Error

Questi errori difficilmente vengono segnalati nei log e pertanto sono difficili da individuare e risolvere.

Per esperienza personale ho potuto constatare che questi errori si manifestano poiché PhocaPDF prova di default ad utilizzare le Librerie ImageMagick per convertire e ridimensionare le immagini. Se queste ultime non sono presenti allora utilizzerà le Librerie GD.

Presso l’Hosting su cui ho avuto modo di testare questa problematica le Librerie ImageMagick, sebbene correttamente installate e funzionanti, quando vengono interrogate da PhocaPDF mandano in errore lo script generando migliaia di file di cache nel percorso:

administrator/components/com_phocapdf/assets/tcpdf/cache

causando di conseguenza l’errore 500 o 504.

Per risolvere il problema basterà modificare il file:

administrator/components/com_phocapdf/assets/tcpdf/tcpdf.php

alla riga 7603 sostituendo la voce:

if (extension_loaded('imagick')) { // ImageMagick

con

if (!extension_loaded('imagick')) { // ImageMagick

In questo modo si forzerà l’utilizzo delle Librerie GD che non daranno problemi e PhocaPDF convertirà correttamente l’articolo in PDF.

Se riscontrate problemi o anomalie scriveteci!

Per analizzare le performance e l’impatto delle nostre modifiche su di esse ci siamo serviti del plugin “YSlow” di Yahoo e “PageSpeed” di Google che offrono la possibilità di visionare statistiche e analisi dettagliate delle varie aree del sito suggerendo le modifiche da effettuare per ottenere un punteggio migliore.

Come funziona?

Solitamente i punteggi assegnati da YSlow e PageSpeed si basano su valutazioni effettuate sui singoli oggetti di una pagina Web quali i Css, i Javacript, la loro posizione nella pagina, il peso della pagina etc.

Tutti questi fattori hanno pesi diversi ai fini della valutazione finale ma, per ottimizzare le performance del sito è necessario concentrarsi sul numero di richieste Http generate, la posizione dei Javascript e il peso della pagina che, ovviamente, è composto da tutti i singoli oggetti quali immagini, css/js, codice,etc.

Il plugin W3 Total Cache agisce in particolar modo sul peso finale della pagina e sul numero di richieste Http generate. Come è noto al momento della richiesta di una pagina il Server provvede ad inviare tutti i singoli oggetti nell’ordine previsto nel codice sorgente al Browser dell’utente. Questo avviene ad ogni click di ogni utente. Se però, come è probabile, un articolo una volta pubblicato rimane invariato per giorni non è performante far elaborare ogni volta l’intera pagina al WebServer. Il plugin serve proprio a questo ossia a creare una copia “html” dell’intera pagina elaborata dal Browser per fare in modo che alle successive richieste venga servita direttamente la pagina html (l’output generato dal Server) invece che farla elaborare ogni volta.

In questo modo, analizzando una pagina con un Http Viewer come Fiddler o Tamper Data si noterà che la prima richiesta genererà per esempio

100 richieste Http x 400 Kb x 5 secondi

mentre il seguente refresh solo

35 richieste Http x 114 kb x 2,4 secondi.

Oltre ciò è possibile applicare una compressione all’output così da ridurre ulteriormente i tempi di caricamento.

Procediamo!

Per prima cosa sono necessari i seguenti plugins:

• W3 Total Cache by W3 EDGE – consente di gestire in maniera avanzata il caching delle pagine, del Database e il Minify dei Css e Javascript. A mio avviso si tratta del miglior plugin disponibile attualmente per la gestione della cache e non appena lo si installa e attiva si riscontrano subito dei miglioramenti nei tempi di caricamento.
• No Frames -  permette di evitare che il proprio sito venga visualizzato in Frames aumentandone così il punteggio Seo.
• Javascript To Footer – utilizzando questo plugin tutti gli scripts Javascript del proprio sito verrano posizionati a fine pagina garantendo una maggior velocità di caricamento del sito.
• SEO Friendly Images – Aggiunge automaticamente i tag Html “ALT” e “TITLE” alle immagini utilizzate nei post così come consigliato dal W3C.

W3 Total Cache by W3 EDGE

Per il plugin si suddivide in più aree ognuna delle quali è personalizzabile dall’utente.

A seconda dell’Hosting utilizzato alcune funzionalità possono non essere supportate e per evitare di impazzire nella configurazione ho provveduto a creare il file di configurazione adatto all’Hosting Linux Aruba. Se dovessero verificarsi degli errori nel suo utilizzo non esistate a contattarmi.

W3 Total Cache Configuration – Hosting Linux Aruba

Una volta scaricato è necessario modificare il riferimento alla sitemap. Per fare ciò aprite il file e andate alla riga 407 che apparirà nel seguente modo:

‘pgcache.prime.sitemap’ => ‘http://www.xxxxxxx.xxx/sitemap.xml’,

e sostituite l’url con quello della vostra sitemap. Per questo sito, quindi, andrà inserito:

‘pgcache.prime.sitemap’ => ‘http://www.capn3m0.org/sitemap.xml’,

Eseguita tale modifica rinominate il file da:

w3-total-cache-config.txt

a

w3-total-cache-config.php

ed importatelo nel plugin.

Accedete al vostro Pannello Admin del WordPress e seguite il percorso:

Performace -> General Settings

In basso troverete le opzioni di “Import/Export” come nella seguente figura:

Importate il file “w3-total-cache-config.php” e il gioco è fatto!

Navigate un po’ il sito e tornate sulle stesse pagine almeno due volte per verificare come appaiono dopo che sono state cachate. Se si dovessero verificare dei problemi con Javascript o Css provvedete a disabilitare tutte le opzioni di Minify del plugin.

N.B. – Potrebbero verificarsi degli errori “500 Internal Server Error” poiché il plugin modifica automaticamente il file “.htaccess” di WordPress e non tutti gli Shared Hosting supportano alcune istruzioni che vengono inserite. No panic!

Scaricate il file “.htaccess” seguente e sostituitelo a quell presente nella root di WordPress e il problema è risolto.

.htaccess WordPress + W3 Total Cache + Mod_Deflate On

Come indicato all’inizio dell’articolo oltre al caching, che riduce notevolmente il numero di richieste e la dimensione delle pagine, è possibile applicare una ulteriore compressione. Nel file .htaccess fornito ho provveduto ad inserire le istruzioni che abilitano il Mod_Deflate di Apache che, appunto, applicano la compressione all’output inviato all’utente.

Le righe che svolgono tale compito sono le seguenti:

SetOutputFilter DEFLATE
AddOutputFilter DEFLATE text/plain
AddOutputFilter DEFLATE text/xml
AddOutputFilter DEFLATE application/xhtml+xml
AddOutputFilter DEFLATE text/css
AddOutputFilter DEFLATE application/xml
AddOutputFilter DEFLATE image/svg+xml
AddOutputFilter DEFLATE application/rss+xml
AddOutputFilter DEFLATE application/atom_xml
AddOutputFilter DEFLATE application/x-javascript
AddOutputFilter DEFLATE application/x-httpd-php
AddOutputFilter DEFLATE application/x-httpd-fastphp
AddOutputFilter DEFLATE application/x-httpd-eruby
AddOutputFilter DEFLATE text/html
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.avi$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mov$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mp3$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mp4$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.rm$ no-gzip dont-vary
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

In seguito procedete con l’installazione degli altri plugins indicati; la loro configurazione di default andrà bene.

A questo punto le operazioni sono terminate e, se tutto è andato bene, il vostro sito guadagnerà qualche punto nelle valutazioni di YSlow e PageSpeed.

Ma non ci fermiamo qui!

Faccio presente che in alcuni Shared Hosting è presente anche il Modulo Apache chiamato “Mod_expire” che consente di indicare al Browser di salvare gli oggetti nella cache locale del Pc per un periodo da noi prefissato.

Questa configurazione aumenta notevolemente i tempi di caricamento del sito poiché tutti gli oggetti quali parti del template, immagini, css e javascript saranno già presenti nell’Hard Disk del visitatore e pertanto i dati REALMENTE da scaricare saranno minimi.

Come è facile intuire aprendo due articoli a caso di questo sito le differenze tra le due pagine sono limitate all’immagine dell’articolo, il testo di esso e altri pochissimi dati. Ogni volta che navighiamo, quindi, scarichiamo per intero delle pagine da 400 kb (template,css,testo,immagini,javascript,video,etc) in cui in realtà le differenze sono solo di 10 kb (testo,immagini).

Il Mod_Expire consente proprio di evitare questo inutile spreco di banda, richieste DNS e request HTTP, facendo salvare tutto nel Browser locale e interrogando realmente il sito solo per richiedere i pochi dati necessari.

Ecco di seguito i risultati ottenuti applicando quanto indicato in questo articolo:

Come si può constatare è stato classificato come Grade B in YSlow tra gli “Smaller Site or Blog” e le richieste sono passate da 49 a 10 con una riduzione di 300k sul peso delle pagine.

Postate i risultati per i vostri siti !!!

Questo CMS di default (personalmente non ne capisco il motivo) ha abilitata la “ricerca ricorsiva” per tutto ciò che riguarda l’elencazione (listing) di file e cartelle di una path. In questo caso in particolare mi riferisco al componente “com_media” che si occupa della gestione dei contenuti multimediali quali foto e video. Nella pagina principale dell’Amministrazione del Joomla andando su “Gestione Media” si accede ad un interfaccia stile “client ftp” che permette di navigare all’interno delle cartelle “images” e “media” ed eseguire le normali operazioni di cancellazione/modifica/etc su file e cartelle in esse contenute.

Il problema sorge quando il numero di file contenuti in queste due cartelle raggiunge dimensioni tali da non rendere possibile il listing di tutto il contenuto nei 120 secondi di Timeout impostati sul Server (tranne servizi dedicati appostivamente al Joomla i normali Hosting Provider impostano il max_execution_time a 120 secondi). Al termine di tale tempo se l’operazione non è completata, a seconda della configurazione e della versione del WebServer, viene mostrato l’errore “500 Internal Server Error” o “504 Gateway Timeout“. Tradotto in parole povere significa che lo script ha provato ad eseguire l’operazione ma il processo era ancora in corso trascorsi 2 minuti e pertanto è stato bloccato.

Per disabilitare la “ricerca ricorsiva”, quindi, è necessario aprire il file “manager.php” presente nella path:

<root_di_Joomla>/administrator/components/com_media/models/manager.php

e successivamente posizionarsi alle Righe 63 e 102 che appariranno così:

$folders = JFolder::folders($base, '.', true, true);

e modificarle variando il 1° true su false come di seguito:

$folders = JFolder::folders($base, '.', false, true);

Di seguito le prime righe della funzione che viene richiamata che dimostrano che il parametro variato va a disabilitare la ricorsione.

	/**
	 * Utility function to read the folders in a folder.
	 *
	 * @param	string	The path of the folder to read.
	 * @param	string	A filter for folder names.
	 * @param	mixed	True to recursively search into sub-folders, or an
	 * integer to specify the maximum depth.
	 * @param	boolean	True to return the full path to the folders.
	 * @param	array	Array with names of folders which should not be shown in
	 * the result.
	 * @return	array	Folders in the given folder.
	 * @since 1.5
	 */
	function folders($path, $filter = '.', $recurse = false, $fullpath = false, $exclude = array('.svn', 'CVS'))
	{
		// Initialize variables
		$arr = array();
 
		// Check to make sure the path valid and clean
		$path = JPath::clean($path);
 
		// Is the path a folder?
		if (!is_dir($path)) {
			JError::raiseWarning(21, 'JFolder::folder: ' . JText::_('Path is not a folder'), 'Path: ' . $path);
			return false;
		}
 
		// read the source directory
		$handle = opendir($path);
		while (($file = readdir($handle)) !== false)
		{
			if (($file != '.') && ($file != '..') && (!in_array($file, $exclude))) {
				$dir = $path . DS . $file;
				$isDir = is_dir($dir);
				if ($isDir) {
					// Removes filtered directories
					if (preg_match("/$filter/", $file)) {
						if ($fullpath) {
							$arr[] = $dir;
						} else {
							$arr[] = $file;
						}
					}
					if ($recurse) {
						if (is_integer($recurse)) {
							$arr2 = JFolder::folders($dir, $filter, $recurse - 1, $fullpath);
						} else {
							$arr2 = JFolder::folders($dir, $filter, $recurse, $fullpath);
						}
 
						$arr = array_merge($arr, $arr2);
					}
				}
			}
		}
		closedir($handle);
 
		asort($arr);
		return $arr;
	}

Come spiegato nei commenti della funzione stessa l’impostare su “false” il 3° parametro disabilita la ricorsione evitando il manifestarsi dell’errore di Timeout.
In alternativa è possibile modificare il parametro inserendo un valore numerico intero. Così facendo si indicano quanti livelli deve scendere nella ricerca dei file/cartelle.

Esempio della modifica da apportare se si vuole che la ricerca scenda al massimo di 3 livelli, ossia:

<root_di_Joomla>/images/cartella1/cartella2/cartella3

La riga andrebbe modificata nel seguente modo:

$folders = JFolder::folders($base, '.', 3, true);

Fatto ciò il problema sarò risolto e all’apertura del “com_media” verrà effettuata la ricerca per le sole cartelle “images” e “media” e per il numero di livelli da voi impostato. Tale modifica crea un piccolo problema visivo che, a mio avviso, non è molto rilevante poiché disabilitando la ricorsività dal menu ad albero del “Gestione Media” non si potrà vedere il solito “+” davanti alle cartelle che ne contengono delle altre. Analizzando solo il primo livello delle cartelle non può creare l’albero di navigazione fin da subito e pertanto si aggiornerà man mano che si scende nelle sottocartelle.

Per un problema risolto ritengo sia una piccola perdita.

In questo caso parliamo del componente “Virtuemart” di Joomla che consente di trasformare il Cms in un negozio on line. In alcuni Hosting a causa della configurazione del “Timeout CGI” impostato in Apache possono verificarsi errori “500 Internal Server Error” in occasione dell’aggiunta di nuove immagini per un prodotto.

Questo perché quando si carica l’interfaccia di upload il Virtuemart esegue un check su tutti i file e cartelle della cartella predefinita delle immagini. Se, quindi, sono presenti numerosi file lo script non riesce a terminare in tempo la verifica di ogni singolo file andando in errore di “Timeout CGI”.

Nel mio attuale Hosting tale Timeout è impostato a 60 secondi e, quindi, ho provveduto ad editare direttamente il codice sorgente del Virtuemart per fare in modo che non esegua tale verifica indipendentemente da quanti file son presenti nella cartella predefinita.

Per fare ciò è necessario aprire il file “product.file_form.php” presente nella path:

<root_di_Joomla>/administrator/components/com_virtuemart/html/

e successivamente posizionarsi alla Riga 105 che apparirà come segue:

$downloadRootFiles = vmReadDirectory(DOWNLOADROOT, '.', true);

e modificarla variando il parametro da “true” a “false” come di seguito:

$downloadRootFiles = vmReadDirectory(DOWNLOADROOT, '.', false);

In questo modo il problema dell’error “500 Internal Server Error” in fase di upload dei file sarà risolto.

Tengo a precisare che la versione del Virtuemart su cui ho eseguito tali modifiche è la 1.1.3.

Resto a disposizione per qualsiasi chiarimento o qualora dopo tali modifiche si riscontrino altri generi di problematiche.

[11/03/2009 - 00.40] AGGIORNAMENTO #1: Ho fatto delle verifiche per validare il perché di tale modifica e vi riporto direttamente il codice dell’intera funzione “vmReadDirectory” presa dal file originale “ps_main.php“:

/**
* Utility function to read the files in a directory
* @param string The file system path
* @param string A filter for the names
* @param boolean Recurse search into sub-directories
* @param boolean True if to prepend the full path to the file name
*/
function vmReadDirectory( $path, $filter='.', $recurse=false, $fullpath=false  ) {
	$arr = array();
	if (!@is_dir( $path )) {
		return $arr;
	}
	$handle = opendir( $path );
 
	while ($file = readdir($handle)) {
		$dir = vmPathName( $path.'/'.$file, false );
		$isDir = is_dir( $dir );
		if (($file != ".") && ($file != "..")) {
			if (preg_match( "/$filter/", $file )) {
				if ($fullpath) {
					$arr[] = trim( vmPathName( $path.'/'.$file, false ) );
				} else {
					$arr[] = trim( $file );
				}
			}
			if ($recurse && $isDir) {
				$arr2 = vmReadDirectory( $dir, $filter, $recurse, $fullpath );
				$arr = array_merge( $arr, $arr2 );
			}
		}
	}
	closedir($handle);
	asort($arr);
	return $arr;
}

Come spiegato nei commenti della funzione stessa l’impostare su “false” il 3° parametro disabilita la ricorsione evitando che il check dei file venga effettuato anche nelle sottocartelle generando l’errore di Timeout (Timeout CGI = 60 sec; max_execution_time = 120).

Non vi sono consigli veri e propri da dare in merito ma, per mia esperienza personale, l’utilizzo di un “php.ini” con abilitate alcune funzioni quali, ad esempio, la “Compressione Gzip“, permette di diminuire il numero di volte in cui il proprio sito va in Timeout o in errore “500 – Internal Server Error“.

La Compressione Gzip consente di far si che il Server comprima alcuni oggetti delle pagine ottimizzando così le performance in quanto il “peso” generale della pagina risulta ridotto.

Per attivare tale opzione vi sono vari modi ma, sinceramente, io preferisco utilizzare l’override tramite “php.ini”. Tale file contiene tutte le configurazioni del Web Server che sono, praticamente, quelle che vengono visualizzate quando si esegue il comando “phpinfo()” del Php. Per vederlo in azione basta creare e, successivamente, caricare via browser una pagina .php contenete le seguenti righe:

<?php

phpinfo();

?>

Utilizzando un php.ini opportunamente modificato è possibile variare (quando consentito del Provider) alcuni parametri come, ad esempio, il “memory_limit“, il “max_execution_time“, l’”output_buffering“, etc.

A questo link potete leggere tutti i parametri impostabili in tale file e la loro descrizione.

Tornando al discorso “Compressione Gzip” eccovi di seguito il codice da inserire nel vostro “php.ini” per abilitarla.

Io utilizzo il metodo che si appoggia alle Librerie Zlib. Il file “php.ini” per utilizzarle è il seguente:

output_buffering = 4096
output_handler =
zlib.output_compression = On
zlib.output_compression_level = 3
safe_mode = Off
max_execution_time = 120
memory_limit = 24M
post_max_size = 8M
register_globals = On
upload_max_filesize = 18M
variables_order = GPCS
disable_functions = system,popen,dl,passthru,proc_open,shell_exec
enable_dl = Off
error_reporting = 6135
expose_php = Off
extension_dir = ./
include_path = “.:/php/lib/php/”
log_errors = On
register_argc_argv = Off
safe_mode_exec_dir =
sendmail_from = me@localhost.com
upload_tmp_dir = “/tmp/”
user_dir = “home”
y2k_compliance = Off

Per chi non avesse sbattimento eccovi il file già preparato da copiare nella root del proprio sito (o dove richiesto):

Php.ini – Compressione Gzip On – Librerie Zlib

In alternativa a tale metodo è possibile abilitare la compressione utilizzando le Gzip e, in tal caso, il codice da inserire è il seguente:

output_buffering = 4096
output_handler = ob_gzhandler
safe_mode = Off
max_execution_time = 120
memory_limit = 24M
post_max_size = 8M
register_globals = On
upload_max_filesize = 18M
variables_order = GPCS
disable_functions = system,popen,dl,passthru,proc_open,shell_exec
enable_dl = Off
error_reporting = 6135
expose_php = Off
extension_dir = ./
include_path = “.:/php/lib/php/”
log_errors = On
register_argc_argv = Off
safe_mode_exec_dir =
sendmail_from = me@localhost.com
upload_tmp_dir = “/tmp/”
user_dir = “home”
y2k_compliance = Off

e questo il file già preparato:

Php.ini – Compressione Gzip On – Librerie Gzip

NOTE – Il file “php.ini” ha la particolarità di resettare alle impostazioni di default di Apache le eventuali impostazioni  omesse. Se inserite solo una riga contenente l’impostazione da cambiare le restanti verrebbero resettate ai valori minimi. E’ quindi importante inserire sempre tutte le impostazioni di base necessarie per evitare il crearsi di tale situazione. Il file da me pubblicato vale per il mio Hosting e, quindi, è possibile che su altri Provider crei problemi oppure necessiti di maggiori impostazioni inserite.

Se riscontrate problemi contattatemi tramite i Commenti che provvederò a darvi una mano.