Lasciando perdere i motivi di questo passaggio, già anticipati in un mio recente commento, mi soffermerei piuttosto su qualcosa di più uitle, ovvero come passare da Rapidweaver a WordPress, due piattaforme blog estrememente diverse.
Questo post ha dunque l’obiettivo di fornire un paio di indicazioni a chi vuol passare da Rapidweaver a WordPress e, essendo per forza di cose un po’ lungo, ne sconsiglio la lettura a chi non usa Rapidweaver e a chi lo usa ma non ha intenzione di passare a WordPress.

Allo stato delle cose, il sistema in sé abbastanza semplice.

E’ infatti sufficiente utilizzare il file RSS che genera Rapidweaver e procedere ad importare il tutto su WordPress.
Vi basterà infatti accedere al menu Manage del vostro pannello WordPress 2.6 e selezionare la voce Import.
Qui troverete varie opzioni di importazione, ma per importare da Rapidweaver a WordPress dovete selezionare la voce “RSS Import posts from an RSS feed“.

Lasciate lavorare WordPress.
Una volta completata l’importazione, se è andato tutto bene vi ritroverete con tutti i vecchi post importati e le vecchie categorie generate.
Ci sono però  da tenere presenti giusto un paio di cose: l’RSS che genera Rapidweaver è all’altezza del software stesso, quindi non è certo il massimo.
Vi capiterà quindi di dover rimettere mano ad ogni singolo post: se siete degli inguaribili pignoli come il sottoscritto dovrete infatti sistemarne la formattazione (come sto facendo io) e rivedere i vari link, non si sa mai.

Altra cosa da valutare, è che i post con categorizzazione doppia, come ad esempio nel caso del post Un paio di eventi a Pisa nella prima settimana di Giugno, inserito in cosa c’è a pisa e in eventi e corsi, non vengono gestiti in modo corretto da questa importazione, di conseguenza dovrete assegnare la seconda categoria in modo manuale, post per post.
Poco male, soprattutto se non avete un numero particolarmente alto di post.

Adesso che avete importato tutti i post fatti su Rapidweaver sul vostro nuovo blog in WordPress… beh, siete appena all’inizio, se avete intenzione di fare le cose per bene.
In base a come venivano costruite le url sul vecchio blog, è molto probabile che adesso su WordPress i post appena importati abbiano delle url completamente diverse, tantopiù che ora potete impostare il vostro blog in modo da creare dei permalink organizzati in cartelle in base a vari criteri.
Ad esempio potete generare delle url che riportano anno e mese di pubblicazione (come ho deciso di fare io), in modo da offrire all’utente una chiara informazione sulla data di pubblicazione del post ancor prima di visitare il vostro blog.
Questo aspetto è particolarmente importante per determinate categorie merceologiche.

Per intervenire vi basterà accedere al menu Settings posto in alto a destra sul vostro pannello WordPress e selezionare la voce Permalink.
Da qui potete scegliere se lasciare tutto di default (sconsigliato), optare per una struttura di url per data, numerica o completamente custom.

Qualsiasi scelta farete, al 99% vi ritroverete con delle nuove url diverse dalle vecchie url.
E questo è male (quasi quanto incrociare i flussi canalizzatori ).
Infatti, se non correrete ai ripari, gli utenti che cercheranno di accedere al vostro sito tramite bookmark, da un link da una risorsa esterna (ad esempio un vecchio trackback su un altro blog) o dai motori di ricerca, si ritroverano di fronte ad un poco incoraggiante errore 404: la risorsa non è più disponibile dove viene cercata, forse è stata spostata.

Dunque non si tratta “solo” di un disservizio per i vostri utenti, ma anche per i motori di ricerca: lasciando così le cose, con tutta probabilità potrete constatare un decremento del ranking dei vostri post sui motori di ricerca.
Tra l’altro, a chi fosse interessato, consiglio di dare una lettura ai suggerimenti per gestire al meglio gli errori 404, recentemente messi a disposizione sul blog che Google dedica al proprio pannello Webmaster.

Già, la risorsa è stata spostata… ma dove? E come faccio a comunicarlo?
Con i redirect 301, ossia dei redirect permanenti: la risorsa che stai cercando non la trovi più qui, è stata spostata definitivamente a quest’altro indirizzo.
Questi redirect potrete impostarli con un redirect dei poveri o magari con un .htaccess ben fatto, grazie al quale potrete utilizzare specifiche direttive Apache per directory e file, gestire gli errori, le regole di riscrittura delle url, configurare php e un sacco di altre cose: tanto utile quanto delicato da maneggiare: se non vi sentite sicuri e i post non sono molti, potete optare per il meta redirect dei poveri (un meta refresh a tempo 0 implementato su una pagina priva di contenuti di altro tipo).

Per implementare l’htaccess vi potrà tornare d’aiuto un tool per generare l’htaccess, comunque sia vi ritroverete con delle regole di tipo:

RewriteEngine On
RewriteBase /
RewriteRule ^files/rebus-pisano.html /2008/03/rebus-pisano/ [L,R=301]

In modo specifico, quello che vedete è un url rewrite sulla root del dominio con un redirect permanente 301, grazie al quale si comunica al client (utente, bot, etc.) che il contenuto disponibile sul documento “repus.pisano.html” conservato nella cartella “files” è ora disponibile alla url “http://www.sbrana.com/2008/03/rebus-pisano/”.

E detto così può anche sembrare semplice… un po’ più articolato è farlo per tutti i post, i tag, le categorie… insomma, per tutte le url del veccio sito/blog che adesso sono cambiate e che potrebberò fornire un’utie fonte di accessi.
Se proprio non avete voglia di farlo per tutte le sezioni del sito, potete valutare per un più pratico (e probabilmente meno efficace) redirect generalizzato verso la home, limitando i redirect specifici solo per quei post del blog che vi generano un certo volume di traffico.

Una volta completato il lavoro e pubblicato il file htaccess, se avete fatto le cose per bene, accedendo alle vecchie url verrete veicolati al nuovo indirizzo e, ipoteticamente, non si verificheranno sostanziali cambiamenti nel posizionamento di quello specifico docuemento.

Pur trattandosi di regole abbastanza generiche per il passaggio da una piattaforma A ad una piattaforma B, rimango a disposizione per dare una mano a chi avesse bisogno di un aiuto per passare da Rapidweaver a WordPress.

Related posts:

1. Habemus WordPress Finalmente è fatta: dopo tanti dubbi, incertezze, tribolazioni e ibernazioni...
2. RapidWeaver e canonizzazione con htaccess In realtà avrei dovuto parlare di “canonicalizzazione” o magari “canonicalizzation”,...
3. RapidWeaver 3.6, già meglio Dopo lunga attesa (almeno per quanto mi riguarda), è finalmente...

Finalmente è fatta: dopo tanti dubbi, incertezze, tribolazioni e ibernazioni temporanee, ho abbandonato definitivamente Rapidweaver e sono passato a WordPress.
Un ringraziamento particolare va a DSOM, che mi ha dato una mano non da poco con l’htaccess e Riccardo che si è destreggiato con il CSS.

Rimangono un po’ di cosette da sistemare, tipo gli stili dei vari post: essendo stati importati via rss va da sé che contengono un ignobile quantitativo di castronerie html.

Stessa cosa dicasi per i vecchi commenti, che allo stato attuale sono completamente assenti: prima utilizzavo Haloscan per la loro (ignobile) gestione, mentre adesso dovrò escogitare un sistema per importarli nel modo meno doloroso possibile.

Anzi: se vi vengono idee fatevi vivi.

Related posts:

1. Evitare l’hotlinking con WordPress L’hotlinking delle immagini è senza ombra di dubbio una pratica...
2. Passare da Rapidweaver a WordPress, con avvitamento di RSS e htaccess carpiato Come qualcuno già sa, ho recentemente cambiato piattaforma per questo...
3. Blog in ibernazione Giusto una comunicazione di servizio prima della breve pausa estiva....

Giusto una comunicazione di servizio prima della breve pausa estiva.

Questo blog da adesso verrà ibernato, anche se per un numero abbastanza contenuto di giorni: giusto il tempo necessario per il passaggio definitivo da RapidWeaver (tanto interessante quanto un vero dirompimento testicolare per la gestione e l’aggiornamento dei vari progetti) a WordPress, anche se temo non si tratterà di un passaggio così indolore.

Beh, a dire il vero questo blog era mezzo ibernato già da un po’ di tempo, soprattutto a causa del meno tempo che ho a disposizione e della scarsa comodità di postare sotto piattaforma Rapidweaver.
I motivi di questo cambio potrebbero dunque essere molti, ma tutti sono più o meno riconducibili ad un cambiamento delle mie esigenze, per le quali mi auguro che WordPress rappresenti uno strumento molto più adattabile. O forse è solo voglia di cambiare.

Comunque ci rivediamo a Settembre, e buone vacanze a chi sta per partire (un po’ vi invidio!).

Related posts:

1. Passare da Rapidweaver a WordPress, con avvitamento di RSS e htaccess carpiato Come qualcuno già sa, ho recentemente cambiato piattaforma per questo...
2. Habemus WordPress Finalmente è fatta: dopo tanti dubbi, incertezze, tribolazioni e ibernazioni...
3. RapidWeaver 3.6, già meglio Dopo lunga attesa (almeno per quanto mi riguarda), è finalmente...

Veniamo alla descrizione del problema.
RapideWeaver genera un file index.html o .php che è la home page del sito o blog che stiamo andando a generare.
Fin qui niente di strano, lo fanno tutti i cms anche se poi il file in questione potrà chiamarsi default.asp, index.php, etc. in base al software e al linguaggio che stiamo utilizzando.
Il problema invece si fa un po’ più spinoso per quanto riguarda la gestione del linking interno tra le pagine che compongono il sito.
Ipotizziamo di avere creato il sito “Alessio For President” raggiungibile alla url “http://www.alessio-for-president.com”, composto da una home page e da:

• una pagina “chi sono” (http://www.alessio-for-president.com/chi-sono.html),
• una pagina “perché eleggermi” (http://www.alessio-for-president.com/perche-eleggermi.html),
• e una pagina “contatti” (http://www.alessio-for-president.com/contatti.html).

Naturalmente ogni pagina secondaria sopra elencata dovrà contenere un link verso la home page del sito, in modo da offrire all’utente una struttura informativa ben chiara e permettergli la navigazione completa del sito.
Ora il fatto è che RapidWeaver genererà verso la home dei link di tipo “http://www.alessio-for-president.com/index.html” anziché puntare alla root del sito “http://www.alessio-for-president.com”, con tutte le conseguenze del caso che sono sintetizzabili in una perfettibile gestione di situazioni simili da parte dei motori di ricerca.
E se è vero che con Big Daddy è sicuramente migliorata la gestione di situazioni da canonizzare come Google comanda e oggi tramite il proprio pannello Webmaster di Google è possibile indicare il dominio preferito per il nostro sito… ammettiamolo: vedere nella barra degli indirizzi del browser “http://www.alessio-for-president.com/index.html” fa veramente cagare.

Ad esempio questo blog riceve un paio di link verso “http://www.sbrana.com/index.html”: visto che ero io il primo a fare la castroneria sul mio sito, qualche altro amico e blogger ha fatto la stessa cosa.
Come risolvere senza mandare in loop il tutto con assurdi redirect (lo dico perchè prima ho pure provato, eh)?
Senza stare a spiegare troppo che cosa significhi ogni singolo comando, visto che gli utenti di RapidWeaver spesso non sono skillatissimi da questo punto di vista, si dovrà creare un file di testo dove inserire quanto segue:

RewriteEngine On
# Redirect index.html to root
rewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.html\ HTTP/
rewriteRule ^index\.html$ http://%{HTTP_HOST}/ [R=301,L]
# Redirect non-www and IP addresses to www.
RewriteCond %{HTTP_HOST} !^www.nomesito.com$ [NC]
RewriteRule (.*) http://www.nomesito.com/$1 [R=301,L]

Che poi non è altro che una riscrittura delle url (o url rewrite).
Poi prendete il vostro abituale programma FTP e caricate il file nella root del vostro sito o comunque nella cartella (tipo httpdocs) dove è conservato il file index.html.
Una volta caricato lo rinominate in .htaccess: sì, con il punto davanti e senza estensione.
Non vi preoccupate se il file sparirà una volta rinominato: lo deve fare.
I file con il punto davanti al nome sono file invisibili: alcuni programmi ftp ve li faranno vedere comunque, altri invece hanno un’opzione per poterli visualizzare.
A questo proposito, al fine di evitare problemi non da poco, è opportuno verificare che già non esista un file htaccess sul vostro sito: se c’è non dovrete fare altro che inserire il codice subito dopo ciò che già trovate scritto nel file: dovrebbe funzionare, ma per scrupolo prima fatevi una copia del vecchio htaccess.

Sì ma che cosa fa?
E’ presto detto: un redirect che dirotta il client, voi con il vostro browser o i vari robot dei motori di ricerca, verso la root del sito.
La prima parte esegue un redirect 301 dalla pagina “index.html” alla root del sito.
La seconda parte, per fare la cosa ancora più figosa, esegue un redirect 301 dall’indirizzo senza “www” (http://sbrana-for-president.com) all’indirizzo che a noi piace tanto dotato di “www”.
Chiaramente al posto di “nomesito.com” dovrete mettere l’indirizzo del vostro sito web.

Il risultato lo potete vedere cliccando sulla link “Bloggando” in alto a sinistra, oppure cliccando su http://www.sbrana.com/index.html o su http://sbrana.com

Quando non funziona?
Se chi vi fa hosting/housing non vi da la possibilità di creare o modificare il file htaccess, e non è raro che ciò accada… beh, chiaro che siete col culo per terra.

E se non ti funziona più niente dopo questa modifica?
Cancella il file htaccess e tutto dovrebbe tornare come prima… se così non fosse, è ovvio che declino ogni responsabilità per danni di qualsiasi genere e/o perdita di dati, parziale o meno che sia.

Funziona solo con RapidWeaver?
No, ma è con RapidWeaver che vengono generati quei deprecabili link interni.
Certo non fa male, ma se né voi dall’interno né altri dall’esterno linkeranno mai il file relativo alla home, ma sempre e solo la root con il www… beh, non avrete problemi.
In fondo sono solo seo-pippe: oggi non è più grave come lo era un tempo.

Related posts:

1. Passare da Rapidweaver a WordPress, con avvitamento di RSS e htaccess carpiato Come qualcuno già sa, ho recentemente cambiato piattaforma per questo...
2. Temi RapidWeaver: Butella Come qualcuno già sa, non fosse altro per il fatto...
3. Aria fresca su RapidWeaver L’aria fresca è arrivata proprio in coincidenza con il rientro...

Quasi contemporaneamente è uscito anche l’aggiornamento del plugin SiteMap di Loghound che con pochi spiccioli vi da la possibilità di creare comodamente la mappa html del sito (utile per gli utenti almeno quanto le lampadine per le anguille), un sitemap.xml per Google, un urllist.txt per Yahoo!, permette di assegnare la prority alle pagine, ed altre seo-fuffe. Inizialmente l’ho provato, ma poi ho deciso che mi divertivo di più a smanettare da solo, anche se devo dire che è comodo.

Ah, il post è stato inserito sotto la categoria “il poco che so di apple” in quanto RapidWeaver è disponibile solo per Macintosh. D’altra parte che vi aspettavate da una software house che si chiama appunto “Realmac”?

Related posts:

1. RapidWeaver e canonizzazione con htaccess In realtà avrei dovuto parlare di “canonicalizzazione” o magari “canonicalizzation”,...
2. RapidWeaver 3.6, già meglio Dopo lunga attesa (almeno per quanto mi riguarda), è finalmente...
3. Temi RapidWeaver: Butella Come qualcuno già sa, non fosse altro per il fatto...