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!

Armato di tempo libero ho deciso di crearlo e a questo link potrete trovare il plugin che ho sviluppato: wp-users-page.

Utilizzando un semplice shortcode o tag all’interno di una pagina o post si potranno visualizzare tutti gli utenti appartenenti ad un Gruppo (Admin, Editor, Author, Contributor,Subscriber) mostrando ognuno in un riquadro con:

• Nome
• Ruolo
• Descrizione Breve
• Avatar

Testatelo e datemi il vostro giudizio

Spesso capita d non ricordarsi la password o, a volte (purtroppo), ci troviamo la password cambiata in seguito a qualche attacco hacker.

Per poterla ripristinare basterà copiare il file “wordpress_reset_pwd.php” nella root del vostro WordPress e successivamente richiamarlo via Web all’indirizzo:

http://www.dominio.com/<root_wordpress>/wordpress_reset_pwd.php

Vi apparirà un form minimal come quello della seguente figura:

Basterà inserire l’username dell’utente e la password che si vuole impostare e il gioco è fatto!!

Download wordpress_reset_pwd.php

Spesso capita d non ricordarsi la password o, a volte (purtroppo), ci troviamo la password cambiata in seguito a qualche attacco hacker.

Per poterla ripristinare basterà copiare il file “joomla15_reset_pwd.php” nella root del vostro Joomla e successivamente richiamarlo via Web all’indirizzo:

http://www.dominio.com/<root_joomla>/joomla15_reset_pwd.php

Vi apparirà un form minimal come quello della seguente figura:

Basterà inserire l’username dell’utente e la password che si vuole impostare e il gioco è fatto!!

Download joomla15_reset_pwd.php

Proprio così! Stanchi del fatto che negli ultimi dieci anni non ci sono stati significativi progressi nel mondo dei linguaggi di programmazione hanno deciso di farselo in casa come spiega Rob Pike, principal software engineer in Google:

Abbiamo sviluppato Go perché siamo rimasti un po’ frustrati per quanto lo sviluppo software è diventato difficile negli ultimi dieci anni o giù di lì

Google Go è un linguaggio ad oggetti affidabile come il Python e performante come  C o C++, ottimizzato per applicazioni in ambito Server grazie al suo modello di programmazione concorrente. Tradotto in parole semplici questo linguaggio permetterà di avere velocità di compilazione elevata mentre le cosiddette “goroutine” consentiranno di eseguire più processi nello stesso momento.

E’ distribuito come prodotto open source e i membri del Google Team confidano molto nella rete e negli utenti per vedere questo progetto crescere. Eccovi due dichiarazioni:

Go è un progetto. Speriamo che gli utenti più audaci decidano di testarlo. Siamo consapevoli che Go non sarà adottato da tutti ma speriamo che quel numero di programmatori sia tale da giustificare lo sviluppo futuro di questo linguaggio di programmazione

Abbiamo bisogno di librerie e strumenti migliori, e la comunità open source è ottima per offrire un aiuto in tal senso

Il progetto Google Go è partito nel 2007 da Robert Griesemer, Rob Pike e Ken Thompson ma, come sottolineano a Mountan View, è ancora in fase sperimentale e infatti il Team di sviluppo a tempo pieno è stato creato solo 1 anno fa.

Nella precedente dichiarazione è stata utilizzata la frase “utenti più audaci” poiché BigG dichiara che bisogna avere una buona esperienza nell’ambito della programmazione e che la difficoltà di apprendimento è simile a quella del Java.

Alcuni Link utili:

Post ufficiale della nascita di GoogleGo (Google Code Blog)

Sito Ufficiale GoogleGo

F.A.Q.

Video:

Periodicamente provvederò ad inserire nuovi vocaboli e se qualcuno vuole condividere un suo dizionario sarò ben lieto di utilizzarlo per aggiungerlo al Database.

In seguito, sperando che il Database cresca in fretta, provvederò a rendere disponibili per il download i file txt così da poterli utilizzare autonomamente.

Per testarlo cliccate qui.

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.

E’ stato introdotto il tag “canonical” che consente di indicare agli Spiders dei Motori di Ricerca quale url indicizzare in presenza di contenuti doppi.

Per esempio, chi possiede un sito che è funzionante e raggiungibile sia indicando l’url:

http://www.nomedominio.com

sia usando

http://nomedominio.com

potrà evitare che la stessa pagina venga indicizzata in ambo due le forme.

Il codice da inserire all’interno delle pagine è il seguente:

Nel video seguente (in lingua inglese) potrete ascoltare Matt Cutts di Google intervistato circa il “canonical-tag“.

Sono stati già sviluppati appositi Plugins per i Cms più diffusi. Eccovi di seguito i link al download dei pacchetti:

WordPress – Canonical Tag Plugin

Magento – Canonical Tag Plugin

Drupal – Canonical Tag Plugin

Joomla – Canonical Tag Plugin

Questo, invece, è l’articolo ufficiale del Webmaster Central Blog dove viene fornita una descrizione riguardo l’uso di questo nuovo tag.

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).

Chi utilizzava  una versione precedente ha avuto la possibilità di effettuare l’aggiornamento automatico senza dover stare a scaricare il pacchetto, unzipparlo, uploadarlo via Ftp etc..

Terminato l’aggiornamento  alcuni hanno avuto la triste sorpresa di riscontrare l’errore “500 Internal Server Error” su tutte le pagine del proprio sito. Questa problematica si manifesta negli Hosting (nel mio caso Aruba) dove i permessi di default per avere il corretto funzionamento dei file devono essere impostati a CHMOD 0755 (dovuti all’utilizzo del suExec di Apache) dato che l’aggiornamento automatico comporta il reset dei permessi a CHMOD 0644.

L’errore è facilmente risolvibile reimpostando i permessi CHMOD corretti per tutti i file e cartelle che compongono il WordPress.

La community di WordPress aveva rilasciato già in data 5/12/2008 una modifica da apportare al file “wp-config.php” per evitare il manifestarsi di questo problema.

ARTICOLO ORIGINALE

Tale modifica consente di impostare manualmente i permessi CHMOD di default (attualmente sono a 0644) da assegnare ai file del WordPress in occasione di aggiornamenti o similari.

Per implementarlo è sufficiente seguire questi pochi semplici passi:

1) Aprire con un Editor il file “wp-config.php“;

2) Aggiungere le seguenti due righe in qualsiasi punto del file:

define('FS_CHMOD_FILE',0755);
define('FS_CHMOD_DIR',0755);

Fine! d’ora in poi tutti gli eventuali aggiornamenti automatici assegneranno di default i permessi 0755

Problema

I problemi che si riscontrano utilizzando detto componente in Hosting che hanno abilitato il “Mod_Security” sono principalmentdue due:

1) Mancato accesso all’interfaccia di gestione dal Pannello di Controllo del Joomla;

2) Errore nell’upload dei file tramite l’interfaccia Flash.

Perché?

Entrambe le problematiche nascono dalla presenza in diverse cartelle del file “.htaccess” contenente due istruzioni che, se abilitate nel Server in Hosting, consentono di disabilitare il “Mod_Security” per evitare che blocchi il passaggio di dati/file tra l’interfaccia Flash e il Server.

Il codice di questo file è il seguente:

SecFilterEngine Off
SecFilterScanPOST Off

Sul mio ed altri Hosting tale possibilità è disabilitata in quanto le misure di Sicurezza devono (giustamente) essere sempre attive e, quindi, il file “.htaccess” genera il manifestarsi di errori “500 Internal Server Error” e il mancato funzionamento degli applicativi/componenti dove esso è posizionato.

Al fine di risolvere le due problematiche precedentemente indicate, quindi, è necessario eliminare il file .htaccess dai seguenti percorsi:

/components/com_expose/expose/manager/amfphp
/components/com_expose/expose/manager/upload

Le righe in questione sono le seguenti:

<?
ob_clean();
flush();
?>

Cosa sono?

ob_clean() – E’ il comando che cancella/svuota il contenuto dell’output_buffer senza, però, eliminare il buffer stesso.

flush() -E’ il comando che elimina il buffer.

Perché? Cos’è l’Output Buffer?

Il mio Hosting attuale ha l’output_buffer attivo di default e anche provando a disattivarlo tramite override con php.ini resta comunque abilitato. Solitamente non crea problemi in quanto si tratta di un buffer creato appositamente per migliorare le performance del Web Server e del Php. Una volta, quando ancora avevamo 56K e ISDN eravamo abituati a vedere la pagina caricarsi piano piano, pezzo per pezzo. Appariva il logo, poi il menu e via dicendo si componeva tutta la pagina. Con l’avvento delle attuali ADSL questa situazione non si verifica più, almeno a livello visivo. A livello prettamente tecnico l’intepretazione e la visualizzazione di una pagina Web continuano ad avere questo comportamento.

L’output_buffer server a migliorare tutto ciò aggiungendo un buffer dove viene caricata la pagina prima ancora che venga “servita” al Client, ossia il vostro Browser. In questo modo quello che una volta era il vedere il singolo pezzo caricato ora diventa un’attesa temporale, seppur minima. Utilizzando un buffer è necessario attendere che si riempia tutto prima che vengano inviati i dati al Browser (e quindi prima che iniziate a vedere la pagina visivamente).

Come e Dove?

Da quel che ho scoperto facendo varie prove è consigliato inserire le due righe di codice prima di qualsiasi output della pagina. Io nel caso di WordPress l’ho inserito prima di qualsiasi cosa nella pagina header del mio Template che si trova a questo percorso:

/<root_di_wordpress>/wp-content/themes/<nome del template utilizzato>/header.php

Ho inserito le righe prima della dicitura “<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0…” nel seguente modo:

<?
ob_clean();
flush();
?>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

Risultati

Da quel che ho potuto constatare sul mio sito e su quello di (pochi) altri le performance e soprattuto i tempi di risposta del Server migliorano.

Tengo a precisare che al momento non ho prove “scientifiche”  a sostegno della mia tesi e, quindi, vi invito a provare e se avete voglia ad informarmi dell’eventuale miglioramento (e speriamo non peggioramento) del vostro sito commentate questo post fornendo quante più informazioni possibili.

Il mio attuale Hosting ha il Php configurato come Cgi di Apache e l’output_buffering impostato a 4096.

Configurazione Php come CGI

Configurazione output_buffering a 4096

Ho riscontrato che su alcuni Hosting (Aruba per esempio) quando si clicca su uno degli Eventi presenti alla voce “Prossimamente” va in errore mostrando una pagina simile alla seguente.

Errore nella visualizzazione Eventi di Gcalendar per Joomla

Andando a verificare la pagina segnalata nell’errore ossia

/components/com_gcalendar/hiddenviews/event/tmpl/default.php

si riscontra che la riga che genera l’errore è la seguente dove viene composto l’Url da richiamare per visualizzare in un iframe l’evento direttamente dal Google Calendar.

$url = $p['scheme'] . ‘://’ . $p['host'] . ‘/calendar/event?eid=’ . $this->eventID . $this->timezone;

Analizzando meglio il codice si riscontra che i due campi “scheme” e “host“, da come vengono utilizzati, dovrebbero essere presenti nell’”Array $p” ma, in realtà non esistono e di conseguenza l’Url che viene generato non è corretto.

Non ho potuto effettuare molti controlli ma effettuando una stampa dell’intero “Array $p” ho riscontrato che vi è un solo campo che, tra l’altro, non viene utilizzato all’interno della pagina. Per fare una verifica approfondita andrebbe verificato il popolamento dell’Array che avviene alla riga 12 dello stesso file tramite la seguente riga:

$p= parse_url($this->gcalendar);

Dato che, come detto, non ho avuto la possibilità di effettuare controlli approfonditi ho risolto il problema a monte commentando la riga 14 dove si generava l’errore e aggiungendone una in cui l’Url viene generato “manualmente”. Ecco il codice:

#$url = $p['scheme'] . ‘://’ . $p['host'] . ‘/calendar/event?eid=’ . $this->eventID . $this->timezone;

$url = ‘http://www.google.com’.'/calendar/event?eid=’ . $this->eventID . $this->timezone;

Così facendo il problema, ovviamente, si è risolto.

Sicuramente non è il metodo migliore per “fixare” il problema in quanto si tratta di un accorgimento piuttosto grezzo ma, temporaneamente, funzionante.

Eccovi il file già fixato:

Joomla Gcalendar Components – RAW FIX EVENT VIEW

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.

Tale applicativo giunto alla recente versione 2.2.6 scaricabile qui risulta generare un errore presso alcuni Hosting Provider come, per esempio, Aruba nello step 2 dell’installazione quando viene effettuata il check dei requisiti di Sistema.

Solitamente l’errore è un “500 Internal Server Error” causato dal superamento del tempo di Timeout impostato in Apache. Nel file “error_log” questo è l’errore che si riscontra:

[Mon Sep 22 14:18:54 2008] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Output filter: Failed to read bucket (rc 70007): The timeout specified has expired [hostname "<nome_host>"] [uri "<gallery_folder>/install/index.php?step=2"] [unique_id "M2dscH8FFFEDDDryFQ3AAAC5"]

La soluzione migliore sarebbe quella di far variare i limiti di Timeout al proprio Provider ma, visto che è una di quelle richieste che difficilmente vengono esaudite, ho provveduto ad editarmi i file di installazione in modo che indipendentemente da quello che il Server ha o non ha mi dia l’ok per proseguire allo step successivo.

Il file da scaricare per la versione Gallery 2.2.6 è questo: SystemChecksSteps.

A suo tempo li feci anche per la versione Gallery 2.2.5. Eccoli qui:

SystemCheksStep – INSTALLATION 2.2.5

SystemCheksStep – UPGRADE 2.2.5

Va sostituito al posto dell’originale.

Per la versione Installation:

<cartella di gallery>/install/steps/SystemChecksSteps.class

Per la versione Upgrade (solo 2.2.5):

<cartella di gallery>/upgrade/steps/SystemChecksSteps.class

Una volta sostituito si può effettuare la normale installazione (o upgrade) senza problemi.

Tengo a precisare che, come già detto prima, tale file non risolve il problema ma, semplicemente, lo bypassa evitando di far eseguire qualsiasi check. Questo significa che se il Vostro Server non possiede i requisiti necessari per l’utilizzo di Gallery i problemi legati a tale incompatibilità persistono.

Al link seguente troverete l’annuncio ufficiale:

http://developer.joomla.org/security/news/241-20080801-core-password-remind-functionality.html

Questo, invece, quello dal Sito Italiano:

http://www.joomlaitalia.com/content/view/323/90/

Sfruttare tale vulnerabilità risulta alquanto semplice poiché bastano pochi semplici passaggi per eseguire il reset:

1) Una volta individuato il Sito in Joomla caricare questo Url:

/index.php?option=com_user&view=reset&layout=confirm

2) A questo punto apparirà un form che chiederà l’inserimento di un codice che, teoricamente, avreste dovuto ricevere in mail

3) Inserite l’apice (‘) come carattere continuate

4) A questo punto avrete il campo di cambio password e, inserendola, editerete direttamente il profilo Administrator

Il supporto Joomla individuata la vulnerabilità (la variabile token non veniva correttamente verificata) ha provveduto a rilasciare in tempi da record la versione 1.5.6 con tale problema fixato. Dalla sua uscita sono stati scoperti ulteriori vulnerabilità che han portato alla release 1.5.7 in pochi giorni:

Potete scaricare dai seguenti link questa versione:

Joomla 1.5.7 Full Eng

Joomla 1.5.7 Full Ita

Per chi avesse subito un’hacking sfruttando questa vulnerabilità consiglio di aggiornare a questa versione e, nel caso siano ancora visibili “tracce” (home page cambiate) dell’hacker ho notato, per esperienza, che le pagine maggiormente colpite sono 3:

• configuration.php
• index.php (del template attivo nel Cms)
• la cartella “cache” (consiglio di svuotarla)

Provvedete a ripristinare le originali e il problema è risolto.

Dato che trovere il vostro account Admin non accessibile visto che è stata cambiata la password sarà necessario effettuare l’accesso direttamente al PhpMyAdmin e riscrivere la password nel Database.

Una guida a questa operazione la potete trovare qui.

Per chi non avesse sbattimento ho fatto uno scriptino veloce veloce che fa la stessa cosa. Basta copiare il file nella root della vostra installazione Joomla, richiamarlo da Browser e impostare la password.

Il file lo potete scaricare dal seguente link:

Joomla Change Admin Password

Infine, x chi ha molto sbattimento, di seguito la guida a come fixare tale vulnerabilità manualmente.

1. Aprire il file “/components/com_user/models/reset.php”
2. Posizionarsi alla riga 113 dopo la riga “global $mainframe;” ed inserire il seguente codice
   

   if(strlen($token) != 32) {
   $this->setError(JText::_(‘INVALID_TOKEN’));
   return false;
   }

3. Fine dei giochi!