WordPress 2.3 e le tabelle mancanti

Mai che ne andasse bene una…

Ecco cosa mostrava la procedura di aggiornamento a WordPress 2.3, una volta terminate le operazioni sul database.

Ops, per qualche ragione non sono state create quattro tabelle fondamentali.

Come rimediare? Semplice.

Come prima operazione, eseguite da shell un dump di tutto il database:

mysqldump -u nome_utente nome_database > 2007-09-25.database.dump.sql

Osservazione: prendete la buona abitudine di prefissare i vostri dump con data in stile americano.

Ora, eseguite da shell il dump delle tabelle categories e post2cat:


mysqldump -u nome_utente nome_database eventuale_prefisso_tabella_categories -p > 2007-09-26.categories.sql
mysqldump -u nome_utente nome_database eventuale_prefisso_tabella_post2cat -p > 2007-09-26.post2cat.sql

Adesso.

PRIMA di aggiornare, collegatevi al database utilizzato da WordPress, con la stessa utenza usata dal programma, e lanciate le seguenti query:


CREATE TABLE eventuale_prefisso_tabella_blog_terms (
term_id bigint(20) NOT NULL auto_increment,
name varchar(55) NOT NULL default '',
slug varchar(200) NOT NULL default '',
term_group bigint(10) NOT NULL default 0,
PRIMARY KEY (term_id),
UNIQUE KEY slug (slug)
);

CREATE TABLE eventuale_prefisso_tabella_blog_term_taxonomy (
term_taxonomy_id bigint(20) NOT NULL auto_increment,
term_id bigint(20) NOT NULL default 0,
taxonomy varchar(32) NOT NULL default ”,
description longtext NOT NULL,
parent bigint(20) NOT NULL default 0,
count bigint(20) NOT NULL default 0,
PRIMARY KEY (term_taxonomy_id),
UNIQUE KEY term_id_taxonomy (term_id,taxonomy)
);

CREATE TABLE eventuale_prefisso_tabella_blog_term_relationships (
object_id bigint(20) NOT NULL default 0,
term_taxonomy_id bigint(20) NOT NULL default 0,
PRIMARY KEY (object_id,term_taxonomy_id),
KEY term_taxonomy_id (term_taxonomy_id)
);
Ovviamente, eventuale_prefisso_tabella può essere tralasciato nel caso in cui le tabelle del database non avessero prefisso.

A questo punto, sovrascrivete i file del vostro blog con la nuova versione di WordPress e lanciate lo script di aggiornamento:

http://vostra_url/wp-admin/upgrade.php

Cliccate quanto basta per arrivare in fondo alla procedura, non preoccupatevi di eventuali chiavi duplicate (troppo pigri per farlo?)

Ora andate nel pannello di amministrazione, provate a scrivere un post, sbirciate in basso, dalle parti del modulo per il caricamento dei file e…

Ahem…durante l’aggiornamento la procedura ha cancellato le tabelle categories e post2cat. Ecco a cosa servivano i backup delle due tabelle in questione, eseguiti prima dell’aggiornamento.

Non rimane che ripristinare le due tabelle mancanti, lanciando da shell i seguenti comandi:


mysql -u nome_utente nome_database -p < 2007-09-26.categories.sql
mysql -u nome_utente nome_database -p < 2007-09-26.post2cat.sql

Fatto. WordPress riprenderà a funzionare senza segnalare ulteriori errori.

Per ora.

Indice di migrabilità a OpenOffice

Riporto un comunicato stampa:

L’Indice di Migrabilità analizza le configurazioni di Microsoft Office e individua le aree che richiedono un intervento per la migrazione di template e macro, e gli utenti che hanno bisogno di una formazione specifica che va oltre il corso di base sull’utilizzo di OpenOffice.org. Inoltre, permette di identificare con precisione gli utenti che devono continuare a utilizzare Microsoft Office, in quanto sfruttano le funzionalità più avanzate e quindi avrebbero delle difficoltà ad adattarsi alla suite open source in quanto le stesse funzionalità impongono una modifica radicale del modo di lavorare.

“Si tratta di uno strumento di analisi molto facile da implementare, che permette di avere – in anticipo sull’operazione – una visione chiara dei problemi e dei costi della migrazione, e quindi di ridurre l’impatto sull’organizzazione, che si traduce in una migliore e più rapida accettazione di OpenOffice.org”.

Oggi si può passare da Microsoft Office a OpenOffice.org conoscendo in anticipo l’impatto sulla struttura, i problemi e i costi dell’operazione.

Lo strumento è stato sviluppato da Yacme Srl un’azienda di consulenza e servizi di information technology.

Che dire? Sembrerebbe interessante.

FonPhone

Qualche minuto fa si discuteva con Dema del nuovo video messo in rete da Martin Varsavsky, nel quale si decantano le virtù del suo iPhone,FON appena sbloccato dai ragazzi dei labs.fon.com.

Vale la pena dare un’occhiata, così come è istruttivo il relativo post, sempre di Martin, intrigantemente intitolato My iPhone is now a PocketMac.

L’associazione Fon(era) e iPhone rende bene l’idea del malumore che affligge gli utenti più intraprendenti che vorrebbero la Fonera

I can finally turn the iPhone into a product of my choice.

Per dirla con le parole di Varsavsky. Ora, se lui vuole un iPhone che possa diventare qualcosa di utile per lui, perché noi non dovremmo desiderare una Fonera che sia qualcosa di utile per noi? Se sblocca lui, perché non possiamo sbloccare noi?

Le mie osservazioni partono da un mio commento a un post di Dema dello stesso tenore e argomento.

Perché?

Apple e Fon utilizzano più o meno gli stessi argomenti che, non a caso, sono alla base di annose argomentazioni fra chi si dibatte fra sistemi aperti e sistemi chiusi. Dico aperti e chiusi non liberi e chiusi, questo è un altro discorso.

Continua a leggere

Fonera+: a penzoloni è meglio

Voci di corridoio, ahem…di beta tester forum, affermano che La Fonera+ sembra avere una qualità del segnale inferiore a La Fonera precedente.

Come ricorrere ai ripari? Pare che il vecchio adagio del profeta della verticale funzioni: lasciate penzolare La Fonera+ dal cavo di rete, puntando l’antenna verso l’alto e il segnale wifi dovrebbe migliorare sensibilmente.

Dicono…