Consulente Informatico – Sergio Gandrus

Archivi per la categoria ‘CMS’

E’ ovvio, più diventa complesso un sistema più è probabile che ci siano delle falle per farlo cadere (o introdurvisi).
E’ il caso di un blog su piattaforma WordPress che in breve, normalmente, diventa un coacervo di plugin sicuramente utili ma complessi e, in teoria, vulnerabili.
Per togliersi qualche pensiero potremmo utilizzare periodicamente WordPress Exploit Scanner.
Come il nome lascia intuire, il plugin cerca all’interno del filesystem o del db codice malevolo senza rimuovere niente ma semplicemente effettuando una segnalazione.

Dopo averlo installato e attivato, per accedere alla pannello di controllo del plugin basterà cliccare sul link sotto “Bacheca”

e selezionare le opzioni che vengono offerte, in base alla profondità che vogliamo dare alla nostra indagine.

E’ possibile anche selezionare quanta memoria RAM vogliamo allocare per il processo e la dimensione massima dei file da scansionare.

Link: WordPress Exploit Scanner

Alex Netkachov è un ZEND Certified Engineer di cui leggo ogni tanto gli interessanti articoli.
Da poco sta passando a Drupal da una precedente piattaforma e si è scritto tutte le installazioni che ha dovuto fare per adattarlo alle sue esigenze.
Vedere questa lista mi ha fatto sorridere perchè effettivamente Drupal è un CMS che nasce un po’ spoglio e che ha bisogno di tempo e pazienza per essere customizzato.
Non sempre questa operazione è lineare e semplice, specie per chi è alle prime armi.

Condivido la sua to-do-list perchè contiene link a risorse utili per chi vuole cominciare con Drupal e perchè è nell’ordine cronologico esatto in cui deve avvenire l’installazione

1. Theme (@done, artisteer)
2. Install WYSIWYG module for creating content (@done, wysiwyg + tinymce + patch + new content format)
3. Install TLA (@done)
4. Install google analytics (@done, google analytics)
5. Redirect from alexatnet.com to www.alexatnet.com (@done, read Drupal’s .htaccess)
6. Cron jobs (@done, cron)
7. Automatic backup (@done, backup and migrate, daily backups)
8. bit.ly or some other short link for each node (@cancel)
9. Module for sending notifications about new comments (@done, comment notify)
10. Search friendly URLs (@done, Drupal’s .htaccess and pathauto)
11. Spam: Mollom and Spam modules (@done, spam and mollom)
12. Enable comments (@done)
13. OpenID Auth (@done)
14. OpenID provider (@done, phpMyId)
15. “Read more” is not necessary (@done, how to)
16. Private messages to users (@done, privatemsg)
17. Code highlighter: PHP, C#, XML, HTML, CSS (@done, syntaxhighlighter, #699968)
18. Favicon (@done)

link: Alex@net

Non c’è niente di più frustrante che avere una pagina bianca quando si sta testando un’applicazione oppure si è apportato qualche modifica a un CMS.
Molti dei server di produzione sono settati (in php.ini) per non mostrare gli errori o i warning che dovrebbero apparire.

Tutti i programmatori PHP sanno, però, che basta aggiungere all’inizio della pagina il codice

error_reporting(E_ALL);
ini_set(‘display_errors’, ‘1′);

per mostrare tutte le segnalazioni.
E se stiamo lavorando con Drupal o WordPress?
Basta inserire lo stesso codice ma in posti ben precisi

Drupal: /sites/default/settings.php
Wordpress: /wp-config.php

E’ l’eterna lotta tra i due mostri sacri dei CMS. Per questo articolo considero le versioni più recenti ed evolute di Drupal (la 6.14) e di Joomla! (la 1.5.15).
Sarò molto schematico altrimenti questa comparazione rischierebbe di essere verbosa e dispersiva.
I vantaggi e svantaggi dei due CMS rappresentano mie considerazioni e quindi opinabili.
Le funzionalità in più e in meno sono invece mere comparazioni tecniche e quindi oggettive.

Drupal

Vantaggi:

• I concetti che sono alla base della gestione dei contenuti (tassonomia, nodi, pagine, storie e dizionari/book sono adatti per qualsiasi tipo di contenuto)
• Ottima gestione delle Clean URL. Formidabili in ottica SEO
• Enorme numero di moduli per ogni tipo di esigenza

Svantaggi:

• Curva di apprendimento molto ripida. Il neofita per essere operativo e per sfruttare a pieno le potenzialità del CMS impiega molto tempo
• Setup iniziale apparentemente semplice ma ci si ritrova come con una configurazione estremamente scarna.
• Il pannello di controllo è di default integrato nel template grafico. Quasi sempre ci si ritrova ad usare il Garland (uno dei template di base) per poterlo gestire comodamente

Drupal ha in più rispetto a Joomla!:

• Gestione privilegi granulare
• Autenticazione LDAP e NTLM tramite add-on (ottima per l’integrazione del CMS in un sistema già definito)
• Template codice messi a disposizione per la creazione di plugin
• Creazione di contenuto con drag-n-drop tramite add-on
• WAI compliant (tranne particolari template grafici)
• XHTML compliant

Joomla!

Vantaggi:

• Pannello di controllo graficamente attraente anche se non tutte le icone sono intuitive
• Modifica del template grafico da pannello di controllo (limitata ma sufficiente)
• Operatività quasi immediata

Svantaggi:

• L’organizzazione dei contenuti tramite l’accoppiata sezioni/categorie è più intuitiva per il neofita ma, alla lunga, l’ordine degli stessi contenuti ne risente, generando problemi di gestione
• Gran numero di estensioni ma non tutte compatibili con la versione 1.5 di Joomla!

Joomla! ha in più rispetto a Drupal:

• Opzione SSL per login e altre sezioni sito
• Framework di test per il codice
• Ridimensionamento immagini nativo (Drupal con add-on)
• Gestione advertising nativa (Drupal con add-on)
• Funzionalità cestino

In genere Drupal permette di cucirsi addosso un CMS con niente di più e niente di meno di quello che serve.
Joomla! nella sua ultima versione totalmente PHP5/MVC si è evoluto tantissimo ma si è portato dietro una certa macchinosità nella gestione da pannello di controllo e una sovrabbondanza di funzioni base.

Sono entrambi strumenti molto potenti e possono rappresentare una formidabile base di partenza anche per applicazioni evolute.
La mia scelta cade su Drupal per una certa familiarità e abitudine di utilizzo ma anche per il controllo che si riesce ad ottenere sugli utenti e sui contenuti.

Link: Drupal e Joomla!

Capita, raramente in verità, che un plugin o un fattore esterno renda inaccessibile il pannello di controllo di WordPress.
Ovviamente la procedura vuole che si disattivino tutti i plugin e poi, a uno a uno, si riattivi tutto per trovare il o i colpevoli.
Per disattivare i plugin quando non si ha la possibilità di accedere al pannello di controllo si può fare in questo modo:

con phpMyAdmin

• Nella tabella wp_options,sotto il campo option_name cerca la riga active_plugins
• Cambia il campo option_value in: a:0:{}

oppure

crea sul server una cartella vuota plugins

• Via FTP o tramite il pannello di controllo del tuo Provider, naviga nella cartella wp-contents
• Via FTP o tramite il pannello di controllo del tuo Provider, rinomina la cartella  “plugins” in “plugins.hold“
• Via FTP o tramite il pannello di controllo del tuo Provider, crea una nuova cartella chiamata “plugins“
• Poi entra nel tuo pannello di controllo WordPress
• Via FTP o tramite il pannello di controllo del tuo Provider, cancella “plugins” creato
• Via FTP o tramite il pannello di controllo del tuo Provider, rinomina “plugins.hold” di nuovo in “plugins“

[via WordPress FAQ]