inizio la mia collaborazione con capn3m0 pubblicando la risoluzione per un piccolo problema che può affliggere gli utilizzatori del noto CMS Joomla!

Può capitare che nell’aggiornamento/modifica di un template dal back-end il sistema segnali l’impossibilità nell’esecuzione di tali operazioni a causa del file params.ini che presenta permessi di scrittura errati.

Tale errore può essere risolto aggiungendo al seguente file:

administrator/components/com_templates/admin.templates.html.php

nella riga 397 questa stringa:

chmod($client->path.$templatefile, 0755);

Nell’esempio viene impostato 755 poiché nell’attuale Hosting questi sono i permessi CHMOD minimi per rendere un file scrivibile. A seconda dei casi i permessi potranno essere diversi.

Il risultato finale dovrà essere:

<?php $templatefile = DS.’templates’.DS.$template.DS.’params.ini’;
chmod($client->path.$templatefile, 0755);
echo is_writable($client->path.$templatefile) ? JText::sprintf(‘PARAMSWRITABLE’, $templatefile):JText::sprintf(‘PARAMSUNWRITABLE’,$templatefile); ?>

Modificando i vostri templates non avrete più problemi

Ciauz!

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

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