Category Archives: CMS

WordPress: tradurre la funzione human_time_diff

Pubblicato da

WordPress: tradurre la funzione human_time_diff

In WordPress esiste questa funzione che permette di calcolare il tempo trascorso tra due date.
Generalmente serve per indicare le date in una maniera diversa. Nei commenti o nei post.
Ad esempio: “Questo post è stato pubblicato 3 mesi fa.”
La funzione che viene utilizzata è human_time_diff che si trova in /wp-includes/formatting.php .
Purtroppo la funzione porta le indicazioni  in inglese

Leggi tutto

WordPress: ruoli e capacità degli utenti

Pubblicato da

WordPress: ruoli e capacità degli utenti

WordPress pur non essendo un vero e proprio CMS ha sempre avuto una vocazione multiutente.
Nella versione attuale (ad oggi siamo alla 3.5.1) esistono sei profili di utenti possibili:

  • Super Admin
  • Amministratore
  • Editore
  • Autore
  • Collaboratore
  • Sottoscrittore

nel caso di sito singolo il ruolo di Super Admin coincide con quello di Amministratore.
Sommario delle capacità degli utenti

  • Super Admin: gestisce le caratteristiche del network di siti
  • Amministratore: gestisce ogni aspetto del singolo sito
  • Editore: pubblica e modifica gli articoli suoi e degli altri utenti
  • Autore: pubblica e modifica i suoi articoli (può inserire immagini)
  • Collaboratore: può scrivere e gestire i suoi articoli ma non può pubblicarli (non può inserire immagini)
  • Sottoscrittore: può solo gestire il proprio profilo

Le capacità possono essere aggiunte o eliminate con le funzioni add_cap() e remove_cap() mentre i ruoli possono essere aggiunti o eliminati con le funzioni add_role() and remove_role()
Essendo informazioni che vengono scritte nel database, è meglio farle “girare” all’attivazione di un tema o di un plugin.

Insomma, con un po’ di pazienza e un po’ di dimestichezza nella programmazione, è possibile creare degli utenti ad hoc per l’utilizzo multiutente di WordPress.
Tenendo sempre presente che WP non è stato pensato per permettere una gestione granulare dei permessi.

Link: Roles and Capabilities

Htaccess: limitare l’azione di bot, spider ed exploit

Pubblicato da

Htaccess: limitare l'azione di bot, spider ed exploit

Uno dei modi più semplici per attaccare un sito realizzato con un linguaggio dinamico (ASP.NET, PHP, ecc.) è quello di scrivere URL malformati o di inoltrare molteplici richieste contemporanee.
Anche l’azione troppo “invadente” di certi spider automatici può causare problemi di accessibilità ad un sito.
I server come Apache hanno la possibilità di configurare l’accesso ad una directory tramite il file .htaccess .
Sfruttando questa caratteristica si possono impostare una serie di regole per filtrare gli accessi.

5G Blacklist è un progetto condiviso per la realizzazione di un .htaccess “definitivo” in cui siano contemplati tutti i casi per limitare l’azione di bot, spider automatici e hacker alle prime armi.
Il nome deriva dal fatto che è la quinta generazione di questo file che è un po’ come una blacklist di un firewall.
Non si tratta della soluzione contro tutti i mali ma permette di risparmiare molta banda e rintuzza gli attacchi più classici.
Il file è strutturato molto bene permettendo di personalizzare, ad esempio, l’elenco degli IP bloccati (o consentiti) oppure quello degli User-Agent (i software che manifestano la propria identità) non consentiti.
Bisogna  dire che entrambi i metodi sono soggetti a raggiro: uno spider può avere diversi IP e un User-Agent può essere simulato.

C’è poi tutta una sezione che “cura” le query string (quelle URL che al loro interno passano valori e parametri).
Il lungo lavoro della community è stato quello di filtrare le URL formate in maniera anomala facendo passare quelle corrette.
Nonostante qualche limite la validità di 5G Blacklist rimane. E’ un metodo semplice e alla portata di tutti per aumentare la sicurezza delle proprie applicazioni web.

Funziona perfettamente con WordPress.

Link: 5G Blacklist (qui la versione beta della 6G)

phpList: principali problemi subito dopo l’installazione (e le soluzioni)

Pubblicato da

phpList: principali problemi subito dopo l'installazione (e le soluzioni)

phpList: principali problemi subito dopo l'installazione (e le soluzioni)

phpList è il sistema di gestione newsletter open source più diffuso al mondo.
L’installazione non richiede particolari abilità ma mi sono capitate due seccature e una rogna, risolte grazie a Google e il forum di phpList.
Racchiudo tutto qua, in questo post, in modo da non dover cercare più in futuro (e per condividere ovviamente).

Prima seccatura:

Subito dopo l’installazione, si entra nel pannello di controllo ed esce questa scritta

Running in testmode, no emails will be sent. Check your config file.

Si risolve così. http://forums.phplist.com/viewtopic.php?p=38321
Apri config.php  e setta

define ("TEST",0);

 Seconda seccatura:

Se si clicca su “Invia un messaggio” si viene reindirizzati alla pagina 404 (not found).
Si risolve così. http://forums.phplist.com/viewtopic.php?t=4114
Apri sempre config.php e setta il percorso giusto a phpList

$pageroot = '/lists';
$adminpages = '/lists/admin';

 Terza rogna:

In fase di composizione del messaggio non compare l’editor (FCKeditor).
Ci sono molte possibili cause ma a me ha funzionato in questo modo.
Cancellate la cache e poi editate il file /lists/admin/FCKeditor/editor/fckeditor.html

Cercate

// Base configuration file.
//LoadScript( '../fckconfig.js' ) ;
LoadScript( '../../?page=fckphplist&action=js4' ) ;

e modificate in

// Base configuration file.
LoadScript( '../fckconfig.js' ) ;
//LoadScript( '../../?page=fckphplist&action=js4' ) ;

Caricando quest’altro script l’editor diventa visibile (e usabile)

Link: phpList

WordPress: usi sistemi di caching per WordPress? Aggiornali subito!

Pubblicato da

WordPress: usi sistemi di caching per WordPress? Aggiornali subito!

WordPress: usi sistemi di caching per WordPress? Aggiornali subito!

E’ di questi giorni la notizia che nei popolari sistemi di caching per WordPress

  • WP Super Cache
  • W3 Total Cache

siano state individuate gravi falle che permettono ad un utente remoto di eseguire codice (Remote Code Execution).
Sembra, addirittura, che non basti neanche tenere disattivati i plugin.
Gli autori dei plugin hanno rilasciato abbastanza velocemente gli aggiornamenti necessari per correggere la vulnerabilità.
Il consiglio è o di aggiornare subito o di cancellare i plugin

Link: W3 Total CacheWP Super Cache

WordPress: creare un pulsante nel menù non attivo, solo per accedere a sottopagine

Pubblicato da

WordPress: creare un pulsante nel menù non attivo, solo per accedere a sottopagine

WordPress: creare un pulsante nel menù non attivo, solo per accedere a sottopagine

Creare menù di navigazione con WordPress è estremamente semplice e intuitivo. Se ne possono creare tantissimi e utilizzarli, se previsto dal tema, in qualsiasi parte dell’interfaccia utente.
Generalmente per creare un menù di navigazione andiamo in Aspetto->Menù e poi aggiungiamo un menù dandogli un nome.
Subito dopo inseriamo i link alle pagine che vogliamo che compaiano in questo menù, scegliendoli dalla finestra riepilogativa che si trova in basso a sinistra.
Ma se vogliamo creare solo una categoria cui poi aggiungere sottopagine (vedi immagine di apertura)? Non dobbiamo per forza creare una pagina!
Ad esempio, il pulsante Management dà accesso alle due sottosezioni Artists e Productions, da cui poi si apriranno i pulsanti alle pagine con i contenuti.
Non vogliamo che Management, Artists e Productions siano delle vere pagine (probabilmente dovremmo inserire dei contenuti ridondanti).
Vogliamo solo che ci permettano l”accesso alle sottopagine.

WordPress: creare un pulsante nel menù non attivo, solo per accedere a sottopagine

Creiamo così dei link personalizzati con URL di destinazione il cancelletto (#).
Questi link diventeranno i nostri pulsanti finalizzati all’apertura dell’elenco delle sottopagine (o sottosezioni come in questo esempio).
Il clic su di essi non ha nessun effetto.

WordPress: creare un pulsante nel menù non attivo, solo per accedere a sottopagine

Starà poi a noi disporre nella maniera più corretta e logica questi pulsanti per favorire una navigazione semplice e intuitiva.

Link: guida sui menù WordPress

vBulletin: contenuto condizionale per la home page del CMS

Pubblicato da

vBulletin: contenuto condizionale per la home page del CMS

vBulletin: contenuto condizionale per la home page del CMS

In vBulletin si può settare come home page sia la prima pagina del forum, sia la prima pagina del CMS (vBCms).
Come già scritto in un altro post, esiste una sintassi condizionale che ci permette di personalizzare i template.
Se voglio mostrare, ad esempio, del contenuto solo nelle pagine del CMS la sintassi è

<vb:if condition="THIS_SCRIPT == 'vbcms'">
Mostra solo nelle pagine di contenuto CMS</vb:if>

questa sintassi mi permette appunto di mostrare del contenuto ma in tutte le pagine del CMS.
Presupponendo che abbiamo settato come home page del nostro Vbulletin quella del CMS, se voglio mostrare un contenuto solo in questa pagina come posso fare? Basta usare un “trucco”.
Tutti contenuti creati da vBCms hanno appesi dei parametri, ad esempio:

http://www.miovbulletin.com/content.php?pagina-di-prova

questo parametro viene richiamato nella sintassi dei template con

$_GET[‘r’] == xx

dove xx può essere l’id di una sezione ma anche il nome del contenuto
Per richiamarci la home, che non ha parametri nell’URL, scriveremo quindi

<vb:if condition="THIS_SCRIPT=='vbcms' AND $_GET['r'] == ''">
Mostra solo nella home del CMS</vb:if>

ossia poniamo la condizione di essere nel CMS e lasciamo il parametro r vuoto.
Quindi siamo nella home del CMS.

Liberamente ispirato da questo post

vBulletin 4: la sintassi condizionale per i template

Pubblicato da

vBulletin 4: la sintassi condizionale per i template

vBulletin 4: la sintassi condizionale per i template

vBulletin utilizza una sintassi proprietaria per permettere di personalizzare i template dei forum.
All’interno dei template per vBulletin si possono mostrare/posizionare elementi a seconda di determinate condizioni.
Ecco quelle più comuni

Se membri del forum:

<vb:if condition="$show['member']">Show this to members only</vb:if>

Se ospiti del forum:

<vb:if condition="$show['guest']">Show this to guest only</vb:if>

Se membri del gruppo

<vb:if condition="is_member_of($bbuserinfo, 1,2,3)">Show this to user group 
1, 2, and 3</vb:if>

Se utente specifico

<vb:if condition="$bbuserinfo['userid'] == 318713">Show this only to the 
member with the user id of 318713</vb:if>

Se non è utente specifico

<vb:if condition="$bbuserinfo['userid'] != 318713">Show this to every one 
but the member with the user id of 318713</vb:if>

Se moderatori

<vb:if condition="can_moderate()">Show this to all moderators</vb:if>

Se moderatore di un determinato forum

<vb:if condition="can_moderate($forum['x])">Show this if moderator is moderator 
of the forum with the id of x</vb:if>

Se moderatore del forum attuale

<vb:if condition="can_moderate($forum['forumid'])">Show this to the moderator 
of the current forum</vb:if>

Se l’id del forum è

<vb:if condition="$forum[forumid] == x">Show this if forum id is x</vb:if>

Se l’id del forum NON è

<vb:if condition="$forum[forumid] != x">Show this if forum id is not x</vb:if>

Se l’id del forum si trova tra questi id

<vb:if condition="in_array($forum['forumid'], array(1,2,3))">Show this to 
forum 1, 2 and 3</vb:if>

Se ci troviamo in questo script

<vb:if condition="THIS_SCRIPT != 'calendar'">Show this only on calendar.php</vb:if>

Se la variabile personalizzata è valorizzata

<vb:if condition="$customvar">Show this if $customvar is set</vb:if>

Se la variabile personalizzata è valorizzata ad un determinato valore

<vb:if condition="$customvar == blah">Show this if $customvar equals blah</vb:if>

Se la variabile personalizzata NON è valorizzata ad un determinato valore

<vb:if condition="$customvar != blah">Show this if $customvar does not equal 
blah</vb:if>

Esempio di utilizzo di else

<vb:if condition="$show['guest']">
Show this to only guest.
<vb:else />
Show this to all registered users
</vb:if>

Esempio di utilizzo con elseif

<vb:if condition="$show['guest']">
Show this to only guest.

<vb:elseif condition="is_member_of($bbuserinfo, 5,6)" />
Show this to user group 5 and 6 which is  mods and admins

<vb:else />
Show this to all registered users

</vb:if>

[via vBulletin.org Forum]

Proteggere WordPress da attacchi di tipo ‘brute force’

Pubblicato da

Proteggere WordPress da attacchi di tipo 'brute force'

Proteggere WordPress da attacchi di tipo 'brute force'

Ci sono hacker e hacker. Oggetto di questo post non è discutere l’etica hacker ma cercare di proteggere un blog basato su WordPress e faticosamente costruito negli anni dagli attacchi di chi vuole semplicemente creare il caos.

Una delle tecniche per accedere al pannello di controllo di un blog basato su WordPress è quello di andare nella pagina di login

www.miosito.com/wp-login.php

e tentare, attraverso un computer, infinite combinazioni di user e password fino a trovare quella giusta. Un attacco di questo tipo si chiama ‘brute force‘.
Di base, WordPress permette infiniti tentativi favorendo di fatto un attacco di questo tipo.
Come ci si protegge? Innanzitutto creando una password robusta: molti caratteri (compresi quelli speciali), maiuscole e minuscole, lettere e numeri.
Poi si può utilizzare un plugin semplice ma efficace come Limit Login Attempts.
Esso limita il numero di tentativi falliti di login imponendo di aspettare prima del tentativo successivo. Sia il numero di tentativi che il tempo di attesa sono impostabili. Così come si può impostare un avviso che ci viene recapitato in posta e che segnala l’IP da cui stanno arrivando gli attacchi.
Consigliatissimo.

Link: Limit Login Attempts