Dalla localizzazione in italiano su WordPress.com:
Un esempio di dominio è “wodpress.com”. Puoi avere il tuo blog con ogni dominio tu possieda come esempio.com o impostare un dominio ad inidirizzare automaticamente i visitatori all’indirizzo del tuo blog.
I grassetti sono miei.
Da qualche settimana il provider “da battaglia” Tophost ha aggiunto una nuova proposta ultraeconomica per chi vuole cimentarsi con un blog.
Si chiama Topblog e la descrizione ufficiale recita:
Topblog nasce per tutti quelli che in pochi passi vogliono avere un sito pronto all’uso, pensando solo ai contenuti e divertendosi.
con in evidenza l’allettante
scrivi, pubblica i tuoi file audio e video e le tue foto in 1 Giga di spazio
Seguendo il link in fondo si possono leggere alcuni dettagli/
Visto che però il costo è addirittura inferiore a quello già molto basso di Topweb viene la curiosità di capire cosa effettivamente si riceva al di là di un blog preimpostato e tanto spazio e quali siano le differenze pratiche rispetto all’altro pacchetto.
Ecco perciò qualche dato ulteriore grazie ad un amico che ha aderito e mi ha permesso di fare un giro tra opzioni, pannelli ed impostazioni.
La versione breve è che Topblog equivale ad un’installazione pronta di WordPress con un solo utente, un solo database e un set discreto di funzionalità per produrre e gestire contenuti ma poco modificabile e per nulla estendibile.
La versione più lunga comincia con la precisazione che i tipi di Tophost hanno installato WordPress MU, la variante multiutente del CMS, in una versione equivalente alla “vecchia” 2.3.x di WordPress. L’utente è unico e coincide con quello del contratto nonché del nome scelto per il dominio.
Se nella gestione (Edit o Manage che sia) e scrittura dei post non ci sono novità o sorprese, la prima limitazione si nota nei campi per cambiare la password che offre due link: uno punta alla guida e l’altro ad un cpanel (molto) ridotto rispetto a quello di Topweb.
Si scopre qui che NON si possono creare altri utenti e come da contratto NON si possono avere/creare altri indirizzi email. Ci sono però gli alias e alcuni già fatti, info, postmaster e webmaster, che rimandano al nome utente (principale) scelto, e c’è l’accesso via webmail, effettivamente utile quando ci si trova fuori sede.
Sempre nel cpanel viene fornita l’impostazione del DNS. Dando un’occhiata dentro c’è una voce ftp e vicino un IP del tipo ab-xx.th.seeweb.it Che sia possibile entrare anche via ftp? Da qualche prova pare di no. fpt.dominiopreso.est esiste ma a varie combinazioni di username e password risponde il diniego del server e un (se ricordo bene) login incorrect.
Tornando a WordPress i plugin sono limitati a un tot fornito. Si possono attivare o disattivare. Non aggiungere, togliere, aggiornare o modificare. Non vedo un antispam e visto che non si può installare un plugin per il backup suggerisco di usare la funzione di esportazione (Manage->Export) a intervalli regolari, per dormire sonni un po’ più tranquilli.
Anche l’aspetto grafico del sito, come i plugin, può essere solo scelto tra quelli forniti dal provider con i temi non modificabili se non nelle opzioni previste dal creatore. Ergo: scegliere temi che sono efficaci di loro (come si suol dire: out of the box) o al limite in cui si può smanettare con i widget.
Tra le opzioni troviamo AMP, che è l’Anarchy Media Player per incorporare, mostrare e gestire file MP3, FLV, Quicktime, WMP e contenuti multimediali da vari siti esterni (raggruppati sotto la voce) Media Players).
Tiriamo le somme rispondendo a due immaginarie domande:
[digg-me] Avete appena registrato un dominio e preso hosting con database MySQL e installato WordPress.
E adesso?
Beh, tanto per cominciare potreste…
Con le versioni 2.1, 2.2 e seguenti WordPress può prospettare una disfunzione molto fastidiosa, con cui mi sono scontrato in varie installazioni, tra cui quelle di due grandi gruppi editoriali italiani.
Quello a cui avevo accennato in “<sarcasmo>Grazie, WordPress…</sarcasmo>” non è un bug tout court del cms ma una combinazione di impostazioni del server con cambiamenti strutturali in WordPress (a leggere un thread dedicato) l’effetto di cui è che il “save” e l’impostazione della data non sortiscono alcun effetto e il post rimane “appeso” in eterno all’interno della coda dei contenuti in via di pubblicazione
Nella pratica si ha garanzia che compia sul sito solo quanto pubblicato subito.
Se si vuole provare a far uscire quanto programmato ma reticente bisogna riaprire e pasticciare con il Save o Publish, operazione che non è detto vada in porto. Una soluzione vera e propria non c’è, ci sono vari tentativi e smanettamenti da fare, o un downgrade a 2.0 o precedenti: peggio ancora le poche o nulle informazioni e discussioni in merito* su questo grave intoppo a qualsiasi seria attività di programmazione editoriale mi paiono sintomatiche dell’approccio tuttora alla base di WordPress e rivolta all’hic et nunc
È un’impostazione che traspare in più punti e un esempio lampante è il messaggio che compare quando si salva un testo (pardon, post) anche se è come bozza (draft).
Articolo salvato. Vedi sito »
Ergo: vai a vedere ciò che hai appena pubblicato. Perché se salvi vuol dire che hai finito e devi aver pubblicato. Giusto?
In altre parole: tutta la gestione è ancora ferma alla concezione del blogging live, di getto, anche ora che WordPress è usato per ben altro come CMS, come sistema di gestione contenuti a tutto tondo come dimostrano anche molti temi e guide che suggeriscono l’adozione per riviste online, siti istituzionali, ecc.
Quello che manca è proprio la comprensione più vasta nella comunità del cms di questo uso “altro” rispetto al “blogging”, dell’uso reale e avanzato di WordPress, delle esigenze che seguono alla sua adozione come strumento editoriale (vedi news.com) e il seguente necessario salto di prospettive nella progettazione, dagli sviluppatori ufficiali di WordPress a chi ne estende le funzioni con plug-in e hack vari. Arriverà mai?
* i dati trovati in merito sono archiviati su delicious mentre Nicola “Dj Batman” Battista mi segnala la entry e (presunta) pezza a problema che però in alcuni casi persiste.
In “Grazie WordPress” mi interrogavo su una delle limitazione progettuali di WordPress e cioé:
Perché sono previsti anche due o più autori ma non che questi firmino insieme un articolo.
Nei commenti mi si faceva notare che con altri CMS e nello specifico Joomla è possibile scrivere liberamente il nome che dovrà apparire nella firma. La valutazione dello strumento “giusto” è forse uno dei punti cruciali ma va fatta all’inizio, prima di cominciare a curare un sito, blog o rivista online. Se si è ormai fatta la scelta e questa è ricaduta su WordPress può essere difficile (o scomodo) cambiare strumento e bisogna intervenire con una soluzione, magari “rimediata” ma efficace.
La mia soluzione è la seguente: creare in WordPress un utente nuovo, con i nomi degli autori che firmeranno insieme il testo. Ecco un esempio tratto da MusicBlob dove c’è stata l’esigenza di scrivere in coppia con Nicola Battista:
Al nome breve (quello per il login) si può infatti associare un qualsiasi nome esteso, nel nostro caso i due (o più) nomi degli autori.
Un utente di questo tipo non sarà usato per fare login ma verrà sfruttato solo ed esclusivamente per la sua “firma”, che si può tranquillamente applicare -previo giusto livello di abilitazione- a stesura ultimata dell’articolo.
Ripetete insieme a me: grazie, WordPress…
Esperimento di embedding* di una mia presentazione del (e sul) nuovo Google Presentations in una pagina di WordPress:
Per vedere solo le diapositive e sfruttare meglio lo spazio ridotto basta fare click sul triangolino sulla riga di separazione tra contenuto e chat con gli altri che stanno vedendo le slide.
La spiegazione sul come fare viene da InsideGoogle. In realtà più che di una spiegazione si tratta di una semplice conferma che basta usare il tag HTML iframe.
Il codice che ho usato io è il seguente:
<iframe src=”http://docs.google.com/Present?docid=d4nkcfw_116d26qbp” width=”450″ height=”300″></iframe>
* Nota sull’uso per visualizzare la presentazione valgono gli stessi criteri di compatibilità di Google Docs. Ergo: Mozilla Firefox dalla 2 in poi per Windows, Linux e Mac OK, Safari 2 per Mac NO, Webkit per Mac recente (r25238 o superiore) OK.
Sono gradite segnalazione per Internet Explorer e Safari 3 beta per Windows e Mac.
