Drupal Italia il riferimento italiano per Drupal

host: dreamhost.com
hosting: condiviso
sistema: Linux 2.6.31.5-modsign-aufs2-grsec-xeon #1 SMP Fri Nov 20 20:08:17 UTC 2009 x86_64
risultati:
Drupal status test - Test dello stato Drupal -> passed
Apache/PHP mode rewrite test - Test del modo rewrite Apache/PHP -> passed
Files directory test #1 - Test del indirizzo files # 1 -> passed
Files directory test #2 - Test del indirizzo files # 2 -> passed
Alternative files directory test #1 - Test del indirizzo files alternativo #1 -> passed
Alternative files directory test #2 - Test del indirizzo files alternativo #2 -> passed
Confermo l'errore "Overridden values of PHP settings not accepted."

**************************************

host: locale
sistema: XAMPP su Windows NT 5.1 build 2600
risultati:
Drupal status test - Test dello stato Drupal -> passed
Apache/PHP mode rewrite test - Test del modo rewrite Apache/PHP -> passed
Files directory test #1 - Test del indirizzo files # 1 -> passed
Files directory test #2 - Test del indirizzo files # 2 -> passed
Alternative files directory test #1 - Test del indirizzo files alternativo #1 -> passed
Alternative files directory test #2 - Test del indirizzo files alternativo #2 -> passed
Ancora l'errore "Overridden values of PHP settings not accepted."

sto "aggiustando" lo style (questione di gusti ovviamente ;))

Grazie Carlo, apprezzo il sostegno. Ho sistemato l'errore di "Overridden values of PHP settings not accepted." (dovuto al cretino che ha scritto il codice).

host: locale
sistema: Ubuntu 9.10 (64 bit)
risultati:
Drupal status test - Test dello stato Drupal -> passed, eccetto: GD image rotate, GD image filtering
Apache/PHP mode rewrite test - Test del modo rewrite Apache/PHP -> passed
Files directory test #1 - Test del indirizzo files # 1 -> passed
Files directory test #2 - Test del indirizzo files # 2 -> passed
Alternative files directory test #1 - Test del indirizzo files alternativo #1 -> passed
Alternative files directory test #2 - Test del indirizzo files alternativo #2 -> passed

host: hostmonster.com
hosting: condiviso
sistema: Linux host294.hostmonster.com 2.6.31-12.9.BHsmp #1 SMP PREEMPT Thu Feb 4 14:06:06 MST 2010 x86_64
risultati:
Drupal status test - Test dello stato Drupal -> passed, eccetto: GD memory (32MB), Controllo sovvrascrittura impostazioni PHP
Apache/PHP mode rewrite test - Test del modo rewrite Apache/PHP -> passed
Files directory test #1 - Test del indirizzo files # 1 -> passed
Files directory test #2 - Test del indirizzo files # 2 -> passed
Alternative files directory test #1 - Test del indirizzo files alternativo #1 -> passed
Alternative files directory test #2 - Test del indirizzo files alternativo #2 -> passed

host: A2Hosting.com
hosting: condiviso
sistema: Linux a2s34.a2hosting.com 2.6.18-164.10.1.el5 #1 SMP Thu Jan 7 19:54:26 EST 2010 x86_64
risultati:
Drupal status test - Test dello stato Drupal -> passed
Apache/PHP mode rewrite test - Test del modo rewrite Apache/PHP -> passed
Files directory test #1 - Test del indirizzo files # 1 -> passed
Files directory test #2 - Test del indirizzo files # 2 -> passed
Alternative files directory test #1 - Test del indirizzo files alternativo #1 -> passed
Alternative files directory test #2 - Test del indirizzo files alternativo #2 -> passed

host: Aruba.it
hosting: condiviso
sistema: Windows NT WEBS22 5.2 build 3790
risultati:
Drupal status test - Test dello stato Drupal -> passed
Apache/PHP mode rewrite test - Test del modo rewrite Apache/PHP -> passed, eccetto: register_globals, Unicode, Controllo sovvrascrittura impostazioni PHP
Files directory test #1 - Test del indirizzo files # 1 -> passed
Files directory test #2 - Test del indirizzo files # 2 -> failed
Alternative files directory test #1 - Test del indirizzo files alternativo #1 -> passed
Alternative files directory test #2 - Test del indirizzo files alternativo #2 -> failed
(Windows, quindi IIS 6.0 che non legge .htaccess)

Uhm, ho provato sul mio VPS Debian con qualche personalizzazione e mi dà errore sul mod_rewrite (quando credo che non dovrebbe, ma non sono sicuro: non ho provato sugli stessi virtual-host su cui ho Drupal)

Comunque, in generale, preferirei che lo script eseguisse autonomamente tutti i test e restituisse in una volta sola i problemi riscontrati

Grazie del feedback Marcello

Beh, è praticamente lo stesso commando:
RewriteRule ^(.*)link([^/]*).html$ $1rewrite.php?q=$2 [L,QSA]
invece di
RewriteRule ^(.*)$                 index.php?q=$1 [L,QSA]
ma forse questo è un pò più pulito:
RewriteRule ^(.*)link(.*)\.html$   $1rewrite.php?q=link$2 [L,QSA]

Per fare ciò dovro "invocare" la chiamata al link programmaticamente - il che potrebbe non essere disponibile (http://www.drupalitalia.org/node/8881) - ma forse questo è un'altro "prerequisito" da testare? (E' anche una funzione un pò grande: drupal_http_request con altri chiamate a funzioni drupal, più di un cut&paste)

Comunque forse ci vuole un bel <pre> così avremmo un risultato 'uniforme' da metter qui...
Hmmm, ci penso su...

@Pinolo Meglio adesso?

Wow!
molto, molto meglio, A+!
Grazie John

Tentativo 1:

Il mio server casalingo Ubuntu 8.04 LTS:

Fatal error: Cannot redeclare http_request() in /var/www/localhost/htdocs/hosting-tests/hosting-tests.php on line 254

Il problema è dovuto al fatto che http_request è una funzione di PHP OPZIONALE (PECL) che uso ed è installata nel sistema, per rendere le cose funzionanti sempre non usare nomi di funzioni riservate; se noti nel file /include/common.php vedi che la funziona ha un namespace a prova di configurazione del server: drupal_http_request.

Domani con colma lo provo con qualcosa di esotico!

Grazie per le risposte...

Eh si, come sempre Pinolo aveva ragione. (Ma presumo che sbaglia ogni tanto in tanto, se non che divertimento c'è?)

Grazie Uccio. Qualcuno una volta mi diceva che scrivere software è come fare i figli - un momento di piacere, seguito da una vita di mantenimento. Infatti si chiamava drupal_http_request (perchè è proprio lui, con qualche piccolo modiica), forse meglio rimetterlo come prima, o metto un ht_ d'avanti a tutte le funzione? O bisgna cercare "php nome_della_funzione" prima?

John

P.S. Spero che non dò fastidio a nessuno se tengo l'intestazione (e link) a/da questo sito? (Non avevo chiesto, solo letto il testo qui in fondo alla pagina). In più devo aggiungere una licenza (GPL, come Drupal) ed un readme...

Versione 0.2.1:
Sistemato problema di conflitto del nome funzione http_request.
Aggiunto test per il valore di safe_mode (da Drupal requirements http://drupal.org/requirements)
Aggiunto test per file php.ini nel indirizzo.
Aggiunto test di Upload progress.
Migliorato (copiato dal codice Drupal) il meccanismo per calcolare l'URL dello script.

Scusate, mi ero assentato un attimo.
Intanto scatta la standing ovation per il fatto che John ha obbedito ai miei desiderata e per l'ottima personalizzazione grafica di Carlo!

Poi, rispetto ai miei problemi, sì, il rewrite non era attivo sul quel v-host, quindi era giusto così.
Adesso però ricevo 2 errori:

e non so interpretarli. Il primo vuol dire che non è permesso fare override di valori INI di PHP in .htaccess?

Ah, 'attimo' è uno di quei strani unità di misura della Système international d'unités? Come torno subito, pocchino...

He he he. Buahh hah hah hah. Ecc, ecc, ecc.

Come, non hai letto il manuale? Ooops, non ho scritto il manuale. Sigh. Comunque hai capito benissimo...

Prima, non sono errori (quelli sono rossi), questi sono avvisi (in un delicato arancio, con sottile tinto di rame) - versione 0.2.1. Forse devo aggiungere icone tipo Drupal - ma non mi ricordo la tema...

Su shared hosting ci sono varie possibilità di cambiare i valori ini. Uno è di metterli nel .htaccess, e il secondo (su certi hosting) e semplicemente aggiungendo un php.ini nel root del applicativo. Lui testa entrambi.

Francamente il terzo test (cioè ini_set()) mi sembra troppo banale, forse devo tentare di settare qualcosa di importante, tipo memory_limit...

Sto pensando di inserire il codice da system.install per l'indirizzo files, forse aiuta con problemi tipo questo: http://www.drupalitalia.org/node/9651

Versione 0.2.2
Migliorato il controllo di PHP ini_set()/ini_get() - simile a Drupal Tweaks
Aggiunto test di scrivibilità del indirizzo files e files-alt a la Drupal.

John, te la sei andata a cercare…
Allora, se non sono errori, li farei di un colore un po' più lontano dal rosso (giallo?). Qui mancano proprio le basi eh…
;)

Versione 0.2.3
Aggiunto controllo che gli indirizzi files e files-alt sono protetti da essere elencati (directory listing protection)
Aggiunto iconi e colori da Drupal admin/reports/status (chi sa perchè)

Grazie! John veramente utile questo "non" modulo.

Anche un elenco dei "buoni, brutti e cattivi" (per noi) no guasterebbe. :)

Direi che ho scelto un buon hosting.

Host : Shinjiru

Web Server
Apache/2.2.14 (Unix) mod_ssl/xxx OpenSSL/xxxe-fips-rhel5 mod_auth_passthrough/xxmod_bwlimited/xx FrontPage/xxxxx mod_jk/xxx
Server API
CGI

Thread safety
disabled

Registered Stream Socket Transports
tcp, udp, unix, udg, ssl, sslv3, sslv2, tls

PHP memory_limit
128M

Allow URL fopen()
On

PHP register_globals
Off

PHP safe_mode
Off

MySQL Client API version
5.0.89

MySQLi Client API version
5.0.89

PostgreSQL Version
-

Full PHP information page
Use this link to see the full report.

Drupal Requirements Tests
PHP phpversion() check
PHP phpversion() acceptable.

PHP memory_limit check
PHP memory_limit acceptable.

PHP register_globals check
PHP register_globals acceptable.

PHP safe_mode check
PHP safe_mode acceptable.

PHP Unicode support check
PHP Unicode support acceptable.

PHP (ImageApi) GD check
GD library: bundled (2.0.34 compatible).

PHP (ImageApi) GD support acceptable.

Upload progress check
Your server is capable of displaying file upload progress, but does not have the required libraries. It is recommended to install the PECL uploadprogress library (preferred) or to install APC.

Overridden PHP settings (.htaccess) check
Overridden values of PHP settings not accepted.

Overridden PHP settings (php.ini) check
Overridden values of PHP settings not accepted.

Overridden PHP settings (ini_set()) check
Overridden PHP settings accepted. If all other PHP settings overrides fail, consider using Drupal Tweaks

Directory files check
The directory hosting-tests/files exists, and is writable.

Directory files-alt check
The directory hosting-tests/files-alt exists, and is writable.

HTTP request check
HTTP request http://www.xxx/hosting-tests/rewrite.php?s=1&q=1

HTTP request successful - code: 200.

Server rewrite check
HTTP request http://www.xxx/hosting-tests/link2?s=1

Server rewrite successful - code: 200.

Retrieve image in files directory check
HTTP request http://www.xxx/hosting-tests/files/drupalitalia.png

Retrieve image successful - code: 200, size: 5605.

Retrieve script in files directory check
HTTP request http://www.xxx/hosting-tests/files/script.php?s=1

Retrieve script successful - code: 200, size: 608.

Directory files listing protection check
HTTP request http://www.xxx/hosting-tests/files/

Directory listing protection successful - code: 404.

Retrieve image in files-alt directory check
HTTP request http://www.xxx/hosting-tests/files-alt/drupalitalia.png

Retrieve image successful - code: 200, size: 5605.

Retrieve script in files-alt directory check
HTTP request http://www.xxx/hosting-tests/files-alt/script.php?s=1

Retrieve script successful - code: 200, size: 608.

Directory files-alt listing protection check
HTTP request http://www.xxx/hosting-tests/files-alt/

Directory listing protection successful - code: 404.

Per la versione 0.2.4:
http://drupal.org/project/coder
http://drupal.org/project/coder_tough_love

hehe ;)

Ciao Johnny13,

Grazie di averlo usato. Si, direi che il tuo hosting va più che bene per big D. Nelfrattempo, posso consigliarti un buon barbiere...
Adesso ho aggiunto (versione 0.2.4) un link per generare il report in testo semplice (plain-text), con questi risultati:

Anche se uso regorlarmente il primo, non ti seguo Carlo. Vuoi che faccio un controllo di tutto il codice su sito, compreso hosting-tests? ;-)

Versione 0.2.5
Tolto ogni riferimenti al dominio sul quale gira il programma. L'informazione raccolto (HTML o plain-text) è adesso totalmente anonimo.

A me piace di piu "hosting_test perche ha il logo di drupal italia :)

Grazie ancora John.

In questa discusione continua la descrizione .

Non vorrei scrivere una fesseria...
ma se configuri un export in xml (o JSON?) con invio automatico, poi possiamo pensare di mettere su un sito dove raccogliamo tutte queste info sulla compatibilità Drupal dei vari servizi di hosting.
Oppure si potrebbe fare con un sistema copypasta stile hijackthis...
Mah, forse è esagerato.

Orpo! Troppi capi e troppi pochi indiani?

Allora, XML no (odio il "angle bracket tax") JSON forse, serialised PHP meglio. Ma, (c'è sempre un ma) se non funziona drupal_http_request? Chi scrive il codice per ricevere quest'informazione?

L'idea del plain-text è proprio un sistema c&p non so se simile a hijackthis (non lo conoscevo, ho dovuto vedere il sito). Comunque l'idea è quello. Voglio usare il programma così non siamo obbligati a chiedere quale OS, quale web server, versione PHP, mysql, ecc, ecc. Più "Posta qui i risultati e vedremo"...

Io sono abbastanza contento che ht adesso fa più o meno tutto quello che può. Vedremmo se qualcuno altro qui sul forum usa il software. Ho scritto tanti di quei programmi meravigliosi - che non lo vuoleva nessuno - in passato... Credo che ho un 'talento' in quel senso.

Versione 0.2.6
Tolto qualche messaggio informativo un pò troppo pericoloso dal punto di vista sicurezza
Tolto link a phpinfo() per sicurezza
Aggiunto version di PHP nei messaggi informativi
Modificato il file .htaccess in files-alt per testare problemi su certi hosting (come questo: http://www.drupalitalia.org/node/9651)

Adesso lo considero abbastanza completo. Devo ancora aggiungere una licenza ed il readme (leggimi). Attendiamo qualche girono di prova poi credo che è pronto per drupal.org...

vedo ora l'enorme e ottimo lavoro che avete fatto (è stato un periodo incasinato), e avrei alcuni appunti da fare (prendeteli con le pinze).

Il primo è che dal punto di vista della sicurezza quelle sono informazioni POTENZIALMENTE pericolose da lasciare scoperte, quindi non sarebbe male avere una password di accesso (scritta nel file o gestita da .htpasswd, anche se in questo secondo caso non sarebbe più indipendente dalla configurazione di apache). Giustamente mi direte di non farmi paranoie mentali e che gli utenti devono rimuoverla dopo aver fatto i test, ma siamo sicuri che poi lo facciano veramente? :)

Seconda cosa che farei è di modificare il file con il nome index e le directory files. Ipotiziamo che un utente a seguito dell'installazione si accorga che qualche cosa non funziona, cosa fa? carica il file, ma ovviamente se non lo inserisce in una subdirectory ma nella directory principale SOVRASCRIVE il file index.php di drupal e poi ci sarebbe da fargli spiegare che deve rimettere quello corretto e bla bla bla... io lo vedo come struemento di test per newbbie, quindi quando è possibile evitargli complicazioni ben venga.

Per il resto eviterei di andare a usare la generazione di testo da parsare per vedere se i vari servizi sono ok, ma preferirei PHP serializzato o JSON. Il primo se le informazioni devono essere processate lato server, il secondo se si pensa di fare un widget da mettere che lanci le interrogazione dal client e elabori le risposte in modo da visualizzarle sul browser.
Io propenderei per la seconda, perchè in caso di molti server da interrogare il server "master" di controllo è possibile che, per il blocco di uno solo dei servizi che interroghi, mandi in timeout la generazione della pagina, quindi +1 per la genrazione del JSON :D

ancora compliment a tutti

PS: a me il titoletto grigio non piace, se qualceh grafico vuole metterci mano..
PS2: ho dato un occhio al codice, so ceh mi odierete, ma sarebbe possibile splittarlo su diversi file di cui ogniuno è un test? Una pagina che si carica gli altri test e li esegue, un pò nella logica Drupal dell'hook :D

Che perfezionista ! : )

Grazie del feedback Mavimo,

Hai ragione. Infatti nella versione 0.2.6 ho tolto certe informazione ed anche il link a phpinfo() - proprio per questo motivo. Spero che adesso c'è un giusto bilancio fra quello che bisogna sapere, e la sicurezza.

Giusto, ma c'è anche un .htaccess. Credo che il rischio di non mettere il codice in hosting-tests sia limitato. Non a prova di idioti, perchè gli idioti sono sempre molto furbi...

Non ho intenzione oggi come oggi di creare un server per accogliere questi dati. Se lo faccesse, sono propenso a serialised PHP, perchè userei big D!

Il colore del titolo è solo una riga di CSS. Meglio bianco come questo sito? Dopo tutto ho scopiazzato tutto il resto del header!
Si, si può splittare il codice. A ~45K non lo considero troppo grosso (ma siamo vicino).

The devil's in the details ;-)

John

Versione 0.3.0
finalmente testato su aruba.it versione Linux. Dove ho dovuto tribulare con il file .htaccess - ci sono parecchie comandi non consentiti, ma per fortuna le regole di rewrite funzionano...
Aggiunto controllo per il modulo rewrite di Apache.
Risultati di aruba.it Linux:

Versione 0.3.2
- Aggiunto un vero test di drupal_http_request ad un sito esterno per controllare permessi http outbound

primo accesso "hosting condiviso pro" di netsons, non male. :)

Forte :) "The directory hosting-tests/files-alt exists, is readable, writable, and traversable."

Versione 0.3.3
Grazie alla collaborazione di WebLino, modificato l'ordine dei test HTTP, e aggiunto controllo del URL interno.
Adesso prima controlla se può parlare con il sito degli update di Drupal (http://updates.drupal.org).
Poi controlla che l'URL interno è simile a http(s)://dominio(/path)/hosting-tests
Poi tenta di chiamare se stesso.