Articoli, news e pillole sul mondo LAMP e l'opensource. Pillole di C#
Archivio di January 2006
Soluzione problemi codifica caratteri in MySQL/PHP
28 Jan
Buongiorno a tutti,
innanzitutto cominciamo ad inquadrare il problema e a fare presente che se ora sono in grado di scrivere questo articolo è grazie al supporto che ho ricevuto sul forum di HTML.IT da parte di Leandro Luccerini, per contatti: leandro980[AT]libero[DOT]it
PREMESSE AL PROBLEMA
DESCRIZIONE PROBLEMA
La situazione problematica nasce nel momento in cui abbiamo un sito web che deve gestire caratteri extra latini, per esempio nel mio caso ho affrontato questo problema dovendo realizzare un sito in lingua russa, ovvero utilizzando il cirillico.
Il mio approccio alla situazione e’ stato quello di realizzare TUTTE le pagine web con codifica utf8 e database, tabelle e campi di testo utf8 a loro volta.
La cosa che mi ha fatto impazzire e capirci veramente poco per diverso tempo e’ che se io inserivo nel database caratteri cirillici come ad esempio (ßрøòõт – ciao) e da PhpMyADMIN (di seguito PMA) vedevo male, idem il dump, mentre quando tiravo su i dati da applicativo tutto funzionava a meraviglia.
Capitava l’inverso con PMA, ovvero se inserivo in cirillico su PMA e visualizzavo da PMA tutto bene, via applicazione niente.
SOLUZIONE
Prima di tutto vi invito a leggervi questa parte di manualistica online di mysql, CHARSET.
Sostanzialmente sui server mysql di sistemi di hosting italiani (ma credo anche americani) e comunque in generale, l’impostazione del default_character_set è impostata a latin1.
Ma anche qualora sia impostata ad utf8 quando via script php ci connettiamo al database mysql la nostra sessione di default (nonostante la pagina sia encodata utf8) sarà attivata con character set latin1, cosa succede quindi, che i dati e le query che inviamo sfasano e il sistema memorizza erroneamente i dati.
Di fatto il comportamento giusto lo ha PMA, dobbiamo cercare quindi di emularlo.
Per farlo basta di fatto lanciare dopo ogni connessione la seguente query: SET NAMES utf8
Così facendo la connessione tra client e server sarà UTF8.
CONCLUSIONE
Per concludere possiamo dire che per siti che trattano lingua standard europee come italiano, inglese, francese etc… possiamo avere tutto il DB latin1, connessione client server latin1 ed encoding ISO-8859-1
Nel caso di siti con cirillico, arabo etc… utilizziamo tutto il database UTF8, encoding delle pagine UTF8 e soprattutto dobbiamo eseguire per sicurezza la query sopra indicata dopo ogni connessione con mysql.
Mi scuso per non essere stato molto chiaro in alcuni punti, purtroppo questo argomento è complesso e fastidioso…
Se avete suggerimenti sono benvenuti.
Ciao a tutti. Max
info[AT]massimo-caselli[DOT]com
WordPress gestione particolare mod_rewrite
23 Jan
Ciao a tutti,
dopo i due articoli scritti su mod_rewrite di apache vorrei trattare di come molti applicativi, tra cui wordpress (il sistema di blogging che utilizzo per questo blog) gestiscono il mod_rewriting in modo più stretto tra apache e php.
Fondamentalmente anzichè applicare regole specifiche come quelle trattate nei precedenti articoli es:
RewriteEngine On
….
….
RewriteRule ^([^/]+)/servizi/service.php?lang=$1 [L]
Utilizzano queste uniche regole:
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php
In pratica le regole che WordPress fa inserire nel file .htaccess provvedono a fare un check se il file o la directory richiesta esiste, in tal caso apache richiede la risorsa reale e presente fisicamente, altrimenti redireziona alla index.php di wordpress.
Questa pagina di fatto si occupa, in base a come è settato l’applicativo da admin (c’è un wizard molto comodo che vi allego, forse un po’ piccola… 
)
In pratica si imposta come WordPress deve trattare e gestire gli URL. A quel punto è l’applicativo stesso che si occupa di fare il parsing della variabile $_SERVER['REQUEST_URI'] (almeno credo che usino questa, al massimo ne utilizzano una simile ) e di generare on the fly i link corretti.
Questo tipo di gestione da realizzare è molto più flessibile ma anche più complicata in quanto richiede un notevole sforzo di parsing degli indirizzi. Soluzione MOLTO valida per applicativi completi e liberamente scaricabili come WordPress ma poco utile per siti web custom.
Ciao a tutti,
Max
info[AT]massimo-caselli[DOT]com
Libretto innovazione digitale per le famiglie (di Beppe Grillo)
23 Jan
Ciao a tutti,
vi segnalo un articolo molto ironico e schietto del mitico Beppe Grillo:
http://www.beppegrillo.it/2006/01/post_10.html
Ciao a tutti e speriamo in un nuovo governo più valido.
Max
Siti multilingua con mod_rewrite e parte sistemistica (2° parte)
16 Jan
Ciao a tutti,
a seguito dell’articolo http://www.massimo-caselli.com/2006/01/08/mod_rewrite-apache-sviluppo-siti-internet/ cerchiamo di trovare una buona soluzione per non diventare matti nella realizzazione di un sito web multilingua e che sia ottimizzato per una buona indicizzazione su Google.
Facciamo finta per comodità che le lingue siano due o tre. L’errore più comune è quello di buttare in sessione la lingua e con la stessa pagina avere un output in italiano, inglese, russo o quello che volete.
Quello che accade è che di fatto ci verranno indicizzate da Google (dico Google ma intendo i motori di ricerca in generale) solo le pagine in inglese.
Come fare quindi?
HOME PAGE IN CHE LINGUA?
Il primo dubbio che puà venire, ma la home page in che lingua deve essere?
Secondo me deve essere visualizzata all’utente (così come al bot di Google) nella lingua del browser (o se non riconosciuta nella lingua di default, l’inglese).
In questo modo siamo sicuri che Google prenderà la pagina index in lingua inglese (maggioranza di visitatori di solito…)
Se qualcuno avesse altre idee, suggerimenti etc… come sempre, sono ben accetti.
CAMBIO DELLA LINGUA, HOME PAGE “DI LINGUA”
Una volta che l’utente ha avuto accesso navigherà il sito nella lingua del suo browser, come fare cià?
Tutto quanto il sito deve essere così: http://www.miosito.com/$lang/
Chiaramente quella che io chiamo $lang deve essere presa come variabile tramite mod_rewrite e utilizzata, dopo adeguato parsing, per settare o risettare la lingua.
Mi spiego meglio, entro nel sito www.miosito.com e la home page mi viene mostrata in italiano, quando clicco su servizi devo ottenere nell’url qualcosa tipo:
http://www.miosito.com/it/servizi/
Come gestisco il tutto? Con una semplicissima rule di Rewrite:
RewriteEngine On
RewriteRule ^([^/]+)/servizi/ service.php?lang=$1 [L]
In questo modo $_GET['lang'] avrà valore “it” e potrà essere parsata da php e assegnato l’italiano alla sessione di lingua.
Di conseguenza anche tutte le home page potranno essere del tipo:
http://www.miosito.com/it/index/
Il cambio di lingua puà avvenire facilmente con classiche bandierine, link, quello che vi pare a voi o al vostro grafico di turno e saranno dei semplici link a:
http://www.miosito.com/en/index/
Da quel momento l’utente naviga in inglese.
VANTAGGI CON GOOGLE DATI DA QUESTA IMPLEMENTAZIONE
Anche se puà essere e sembrare banale i vantaggi dati da una soluzione tecnica del genere nei siti multilingua sono immensi perchè:
- Google indicizzerà ogni pagina per le X lingue
- Google non si perde in cambi di lingua strani etc…
- Avremo una home page indicizzata per lingua
- Non ne ricordo altri ma sicuramente ci sono…
MOD_REWRITE DAL PUNTO DI VISTA SISTEMISTICO
Innanzitutto sfatiamo un piccolo mito secondo cui mod_rewrite sarebbe pesante… l’esecuzione di semplici regular expression non sono di certo per i server attuali e in rapporto alla complessità di molti siti non sono nulla.
Personalmente non ho rilevato su siti mediamente trafficati alcun tipo di rallentamento/appesantimento sulla macchina o sul sito web stesso.
Utilizzare mod_rewrite con .htaccess
L’utilizzo di mod_rewrite avviene normalmente tramite l’inserimento delle rule da file .htaccess che viene poi caricato sul server web.
Va fatto presente che tale soluzione non è eccezionale dal punto di vista della sicurezza perchè seppur i file .htaccess di default non vengano visualizzati da apache sono pur sempre file contenenti direttive di configurazione.
Tale soluzione è inevitabile su server di hoster come Aruba o Serverplan etc… condivisi da centinaia di siti web di clienti che devono poter lavorare in autonomia senza disturbare il servizio di supporto dei provider.
Anche perchè offrire spazio web a costi come quelli dei sopra citati provider implica inevitabilmente e giustamente un servizio di supporto che deve essere limitato allo stretto necessario.
Utilizzare mod_rewrite via VH di apache
Una soluzione decisamente più comoda e sicura ma che richiede la possibilità di accedere all’amministrazione del server o, almeno di avere un sistemista (magari con il cappellino… ) che possa andare a inserire le vostre rule.
Solitamente e personalmente, sul server di sviluppo e di staging uso comodamente .htaccess mentre in produzione vado a manina in SSH e aggiungo le regoline che mi servono.
Personalmente metto le regole all’interno del VH di apache dentro il tag specifica. Se qualcuno ha suggerimenti non taccia…
Saluti a tutti,
Maxgrante
info[AT]massimo-caselli[DOT]com
Sviluppo siti internet con mod_rewrite di Apache (parte 1 – siti monolingua)
8 Jan
Buongiorno a tutti,
scrivo questo articolo per cercare di spiegare in modo semplice, pratico e diretto come sviluppare siti web dinamici ottimizzati per i motori di ricerca, Google su tutti.
Nello specifico mi avvarrà dell’utilizzo del comodissimo mod_rewrite di apache, l’intero articolo è incentrato particolarmente su di esso.
L’articolo sarà diviso in 2/3 parti:
- Sviluppo siti internet “monolingua” con mod_rewrite di apache
- Sviluppo siti internet “multilingua” + approfondimenti sistemistici
- Eventuale terzo articolo con approfondimenti dettati da vostre richieste e suggerimenti
PREMESSA (REGOLE PER UNA VALIDA INDICIZZAZIONE NEI MOTORI DI RICERCA)
- Evitare la porcata di mettere parole chiave nascoste (non mi riferisco al solito meta tag) a raffica all’interno delle pagine del sito, se i motori se ne accorgono sono dolori… anzi, cazzi…
- Utilizzare per le pagine titoli che siano brevi e rappresentanti il reale contenuto della pagina web
- Utilizzare nomi di pagine che non siano: pagina1-int.php o cose simili, se sto realizzando una pagina che visualizza notebook la chiamerà notebook.php o simili
- Inserire sempre in tutte le pagine keywords e description, anche se contano sempre meno male non fanno. Se possibile personalizzarle per pagina
- Scegliere un nome di dominio possibilmente coerente con il tipo di attività o prodotto da promuovere
- Scrivere codice compatibile con gli standard dettati dal W3C (quelli che tanto per intenderci alla Microsoft non sanno cosa sono…), personalmente consiglio XHTML 1.0 transitional che non stressa più di tanto ed è efficace (sono benvenuti suggetimenti differenti)
- Evitare sgami strani del tipo, quando passa Google gli faccio vedere qualcosa d’altro, se si accorgono che cià che il motore indicizza non è lo stesso di quello che visualizzerebbe un utente normale si incazzano e fanno bene
- Utilizzare tag come h1, h2 facilita il bot nel comprendere che quel testo è un titolo o un sottotitolo, per il corpo utilizzare ad esempio il tag html p
UTILIZZO DI MOD_REWRITE PER OTTENERE URL “PIACEVOLI” PER I MOTORI DI RICERCA
Veniamo ora al reale motivo per cui scrivo questo articolo.
Realizzare un sito dinamico è indubbiamente una cosa eccezionale per un cliente e per chi lo realizza, poter utilizzare un’unica pagina product.php?id=x è molto meglio di avere 800.000 pagine per ogni maledetto prodotto, idem per le news etc…
Purtroppo perà questi URL cosiddetti dinamici sono poco graditi ai motori di ricerca, Google su tutti, sia perchè la pagina esprime solo il concetto che tratta un prodotto, sia perchè proprio questo ?id=x non è amato da Google. Non parliamo poi di cose come ?id?x&a=2&b=y …
A salvarci da questo annoso problema viene incontro mod_rewrite di apache.
In pratica è possibile far puntare le nostre pagine a qualcosa di questo tipo: http://www.miosito.com/product/albero_motore_nave-10.html
Chiaramente questa risorsa non esiste sul nostro web server indiano preferito ma dovremo fare in modo che quando il browser dell’utente punta all’indirizzo sopra citato la pagina chiamata internamente da apache sia qualcosa tipo: product.php?id=x (il tutto trasparentemente per Google e per l’utente).
Per fare cià usiamo mod_rewrite e le direttive da lui fornite. Vediamo un esempio di direttiva che soddisfi il nostro caso:
RewriteEngine On
RewriteRule ^product/([^/]+).html product.php?id=$1 [L]
In sostanza con RewriteEngine On si dice al motore di avviarsi, con la seconda direttiva si comunica ad apache che per la risorsa /product deve prendere come variabile tutto cià che precede .html e utilizzarla come variabile $1 che poi verrà comodamente passata in GET alla pagina php.
Chiaramente nello script dovremo parsare $_GET['id'] e “prelevare” il valore reale che ci interessa di quanto in input, ovvero 10.
E’ assolutamente possibile far fare questo parsing già ad apache ma siccome non mi ricordo a memoria come si fa e sono le 3 di notte mi scuso e se lo scoprite segnalatemelo…
E’ probabile che in realtà il prodotto sia memorizzato nel DB con il nome di “Albero motore nave”, ovviamente prima di passarlo in GET è il caso di ripulirlo dei caratteri non prettamente alfanumerici e renderlo strtolower.
E’ assolutamente essenziale anche che tutto quanto presente e referenziato in product.php abbia come riferimento o il path assoluto alla risorsa o alla root del sito.
A seguire tra qualche giorno le restanti parti dell’articolo.
Tanti saluti e buon rewrite a tutti.
Max – info [AT] massimo-caselli [DOT] com
