Oggi ho passato più di 6 ore per correggere un bug.

Scrivo questo post per aiutare quei poveri programmatori che si troveranno nella mia stessa situazione. Brevemente spiegherò i sintomi che venivano rilevati nell’applicazione web e poi vi illustrerò da cosa dipendeva il problema e come viene risolto.

I sintomi che si presentavano era un azzeramento anomalo della sessione, venivano resettate alcune variabili in sessione e rigenerati alcuni codici di controllo che quindi compromettevano il flusso tra le pagine web dell’applicazione. I cookie erano impostati correttamente e con durata infinita, quindi non poteva essere un problema di scadenza dei cookie. I file della sessione erano scrivibili e venivano correttamente aggiornati in altri casi e quindi non poteva essere un problema di permessi sui file della sessione, altrimenti l’errore si sarebbe presentato a monte. L’errore accadeva solo utilizzando Safari e con Firefox questo non accadeva, il che complicava ancora di più le cose perché trattandosi di sessioni PHP e quindi di script che vengono eseguiti lato server non aveva alcun senso che su un browser funzionasse mentre sull’altro no.

L’errore che era stato commesso era un tag immagine con l’attributo src uguale a stringa vuota (src=”" per intenderci).

In questo caso Firefox semplicemente eliminava l’immagine dal flusso HTML e quindi non accadeva nulla di strano, mentre Safari, il buono e caro Safari (sto cercando di trattenermi dal rompere tutto), cosa fà? Suppone che per qualche arcano motivo l’immagine inserita senza path si trovi nell’indirizzo della pagina php invocata e quindi effettua un secondo chiamata alla pagina che compromette tutto il funzionamento della sessione PHP e del flusso che stavano seguendo le pagine.

Per farmi capire meglio la pagina chiamata ad esempio era index.php e Safari trovando un tang IMG con src=”" sostituisce all’indirizzo dell’immagine index.php, quindi otteniamo una cosa del genere: src=”index.php”, in che corrisponde ad una seconda invocazione della pagina index.php che potrebbe, come nel mio caso, compromettere il flusso che si stava seguendo attraverso form etc… questo perché, ad esempio, nell’invocazione di index.php senza nessun parametro e sottomissione di form, veniva esegueto l’azzeramento della sessione…

Bhè ottimo lavoro da parte di quelli di Safari per questa emerita scelta progettuale… e spero di aver risparmiato tante ore di debug ad altri poveri programmatori che si troveranno in questa situazione.

Nel titolo è menzionato eclipse ma l’articolo si adatta comunque a qualsiasi IDE Eclipse-based, quindi se avete problemi col taglia/copia/incolla con Aptana o Zend Studio o qualsiasi altro va bene lo stesso.

Di che problema sto parlando? Chi utilizza uno di questi editor in ambiente kde avrà notato che il taglia/copia/incolla non funziona come dovrebbe: quando si copia del testo viene incollato il precedente, o ne viene incollato solo un pezzo e, peggio ancora, quando si taglia qualcosa poi non si riesce più ad incollarlo…perdendolo! Il problema si presenta solo con le scorciatoie da tastiera e non con l’uso del click destro.

Il problema sta nella fase di taglia/copia ed è dovuto ad un qualche tipo di conflitto con klipper, il gestore degli appunti di kde. Infatti pare che il problema non si presenti sotto ambiente Gnome.

Nel bugtrace di eclipse questo bug è segnalato da anni ma non è mai stato risolto, incredibile!

Per risolvere il problema ci sono due modi:

• Workaround: quando copiate il testo premete due volte ctrl+c e quando tagliate del testo premete prima ctrl+c e poi ctrl+x. Al momento dell’incolla tutto dovrebbe funzionare. Per qualche strano motivo premendo due volte i tasti il testo selezionato viene inserito correttamente in klipper.
• Drastico: chiudete klipper. Se non usate le funzionalità di klipper potete benissimo non eseguirlo all’avvio del sistema e il problema non si presenterà.
• Consigliato: come segnalato qui, click destro su klipper > configura klipper > togliete la spunta a “prevent empty clipboard”. Ora dovrebbe funzionare tutto!

Dopo l’aggiornamento del kernel alla versione 2.6.26 potreste aver problemi con l’aggiornamento di vmware-modules. Un errore simile a questo:

Using 2.6.x kernel build system.
make -C /usr/src/linux/include/.. M=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.26-gentoo-r3'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.

WARNING: Symbol version dump /usr/src/linux-2.6.26-gentoo-r3/Module.symvers
is missing; modules will have no dependencies and modversions.

CC [M]  /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/linux/driver.o
/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/linux/driver.c:171: error: unknown field ‘nopage’ specified in initializer
/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/linux/driver.c:172: warning: initialization from incompatible pointer type
/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/linux/driver.c:175: error: unknown field ‘nopage’ specified in initializer
/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/linux/driver.c:176: warning: initialization from incompatible pointer type
make[3]: *** [/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/linux/driver.o] Error 1
make[2]: *** [_module_/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only] Error 2
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.26-gentoo-r3′
make: *** [vmmon.ko] Error 2
*
* ERROR: app-emulation/vmware-modules-1.0.0.15-r1 failed.
* Call stack:
*               ebuild.sh, line   49:  Called src_compile
*             environment, line 3208:  Called linux-mod_src_compile
*             environment, line 2427:  Called die
* The specific snippet of code:
*               eval “emake HOSTCC=\”$(tc-getBUILD_CC)\”                                               CROSS_COMPILE=${CHOST}-                                          LDFLAGS=\”$(get_abi_LDFLAGS)\”                                           ${BUILD_FIXES}                                          ${BUILD_PARAMS}                          ${BUILD_TARGETS} ” || die “Unable to emake HOSTCC=”$(tc-getBUILD_CC)” CROSS_COMPILE=${CHOST}- LDFLAGS=”$(get_abi_LDFLAGS)” ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}”;
*  The die message:
*   Unable to emake HOSTCC=i686-pc-linux-gnu-gcc CROSS_COMPILE=i686-pc-linux-gnu- LDFLAGS=   auto-build VMWARE_VER=VME_S1B1 KERNEL_DIR=/usr/src/linux KBUILD_OUTPUT=/usr/src/linux
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at ‘/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/temp/build.log’.
* The ebuild environment file is located at ‘/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/temp/environment’.

Vediamo come risolverlo.

Dovete scaricare questi 4 file dentro la cartella /usr/portage/app-emulation/vmware-modules/files/:

• http://www.paldo.org/paldo/sources/VMware-server/VMware-server-vmmon-1.0.6-91891.tar.bz2
• http://www.paldo.org/paldo/sources/VMware-server/VMware-server-vmmon-1.0.6-91891-2.6.27-1.patch.bz2
• http://www.paldo.org/paldo/sources/VMware-server/VMware-server-vmnet-1.0.6-91891.tar.bz2
• http://www.paldo.org/paldo/sources/VMware-server/VMware-server-vmnet-1.0.6-91891-2.6.27-1.patch.bz2

Dopo editate l’ebuild /usr/portage/app-emulation/vmware-modules/vmware-modules-1.0.0.15-r1.ebuild

con questo contenuto:

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/app-emulation/vmware-modules/vmware-modules-1.0.0.15-r1.ebuild,v 1.4 2007/07/12 06:39:56 mr_bones_ Exp $

KEYWORDS=”amd64 x86″
VMWARE_VER=”VME_S1B1″

inherit vmware-mod

src_unpack() {
unpack ${A}

modver=”1.0.6-91891″
patchver=”1.0.6-91891-2.6.27-1″

for mod in ${VMWARE_MODULE_LIST}; do
cd “${S}”
tar -xf “${FILESDIR}”/VMware-server-${mod}-${modver}.tar.bz2
epatch “${FILESDIR}”/VMware-server-${mod}-${patchver}.patch.bz2
cd “${S}”/${mod}-only

EPATCH_SUFFIX=”patch”
epatch “${FILESDIR}”/patches
# [[ -d "${FILESDIR}"/patches/${mod} ]] && epatch “${FILESDIR}”/patches/${mod}
convert_to_m “${S}”/${mod}-only/Makefile
done
}

Ora create un nuovo digest e riemergete il pacchetto:

cd /usr/portage/app-emulation/vmware-modules/
ebuild vmware-modules-1.0.0.15-r1.ebuild digest
emerge -pv vmware-modules

Ora dovrebbe funzionare. A me è andato!

L’originale lo trovate qui.

Da un pò di tempo mi sono trovato a lavorare con questo CMS (http://www.xoops.org), in particolare ho utilizzato il modulo che ti permette di integrare il famoso phpbb all’interno del CMS. I moduli in questione si chiamano newbb e newbbex. L’ultimo dovrebbe essere il più aggiornato, ma entrambi avevano questo problema: non inviavano le notifiche nel momento in cui venivano inseriti nuovi post o venivano creati nuovi thread. Nonostante era attivate e tutto il sistema mail funzionava correttamente, solo in questi due moduli le notifiche non funzionavano.

Quale era il problema?

Il problema era la mancanza dei template per formare le email in lingua italiana. Quindi nel momento in cui si andava a caricare il file mancante del template smarty, la funziona per inviare le email terminava senza nessuna condizione di errore. Rendendo il problema non visibile a primo impatti ma solo attraverso un minizioso debug (quasi 2 ore di spulciamento nel codice).

Come si risolve?

Semplicemente creando i template in lingua italiana nella cartella “../modules/newbb/language/italian/mail_template” oppure “../modules/newbbex/language/italian/mail_template” se usate la versione ex del plugin. La cosa più semplice da fare è copiare e incollare la cartella “../modules/newbb/language/english” e rinominarla “italian”, poi aprite i file all’interno e vi mettete a fare la traduzione se volete.

Come mai c’è questo bug?

Non lo sò… in realtà sono molto stupito, anche perchè in giro non ho trovato nessuno che ne parlava… forse non avrò cercato bene.

Ultimamente uso molto spesso Skype, e fino a poco oggi pomeriggio lo odiavo quando usavo la mia webcam… quale modello?!

redvaio redsend # lsusb
Bus 001 Device 002: ID 046d:0928 Logitech, Inc. Quickcam Express

Una Logitech Quickcam Express, come questa…

Su linux uso il driver gspca compatibile con millemila webcam. Su tutti i programmi funzionava bene, l’immagine si vedeva “bene”, relativamente perchè non è una granchè la qualità della webcam… ma almeno si vedeva. Tranne su Skype!!!

Dopo 20, 30 secondi che avevo avviato la videochiamata su Skype il video diventava quasi nero e anche rendendo la stanza super illuminata, l’immagine si vedeva sempre scura. Cercando un pò su internet ho trovato un post sul forum di Skype che parla proprio di questo. Si discuteva della possibilità di aggiungere a Skype il controllo dei parametri della webcam, che manca attualemnte alla versione 2.0.68. Fosse quasi ora che lo aggiungono sto benedetto controllo e migliorino un pochino questo programma che su windows è arrivato già alla ventesima versione… mentre su Linux è rimasto fermo alla 2 da mesi.

Non è una critica a Skype quella che volevo fare, che fà il suo lavoro egreggiamente, ma l’obbiettivo del post era quello di spiegare come ho risolto questo problema. La soluzione che ho adottato, insieme a molti altri (leggendo dal forum di skype) è quella di impostare dei parametri personali per il gamma e i colori RGB della webcam, direttamente agendo sul driver senza nessun programma.

Sembra chisà cosa come l’ho detta prima invece è una sciocchezza…

Il driver offre, come tutti, la possibilità di impostare alcuni parametri per il dispositivo, per vedere quali potete lanciare il comando

redvaio redsend # modinfo gspca
filename:       /lib/modules/2.6.24-tuxonice-r9/usb/video/gspca.ko
license:        GPL
description:    GSPCA/SPCA5XX USB Camera Driver
depends:        videodev
vermagic:       2.6.24-tuxonice-r9 preempt mod_unload PENTIUMM
….
….
….
parm:           autoexpo:Enable/Disable auto exposure (default=1: enabled) …
parm:           debug:Debug level: 0=none, …
parm:           force_rgb:Read RGB instead of BGR (int)
parm:           gamma:gamma setting range 0 to 7 3-> gamma=1 (int)
parm:           OffRed:OffRed setting range -128 to 128 (int)
parm:           OffBlue:OffBlue setting range -128 to 128 (int)
parm:           OffGreen:OffGreen setting range -128 to 128 (int)
parm:           GRed:Gain Red setting range 0 to 512 /256  (int)
parm:           GBlue:Gain Blue setting range 0 to 512 /256  (int)
parm:           GGreen:Gain Green setting range 0 to 512 /256  (int)
parm:           compress:Turn on/off compression (not functional yet) (int)
parm:           usbgrabber:Is a usb grabber 0×0733:0×0430 ? (default 1)  (int)
parm:           lightfreq:Light frequency banding filter. Set to 50 or 60 Hz, or 0 ….
parm:           force_gamma_id:Forced assigning ID of contrast settings (0=default,1,2,3) …
parm:           force_sensor_id:Forced assigning ID sensor (Zc03xx only). Dangerous…

I parametri possono essere modificati on-the-fly (a volo) attraverso il filesystem sys, ovvero

redvaio redsend # echo 4 > /sys/module/gspca/parameters/gamma
redvaio redsend # echo 350 > /sys/module/gspca/parameters/GBlue
redvaio redsend # echo 350 > /sys/module/gspca/parameters/GGreen
redvaio redsend # echo 350 > /sys/module/gspca/parameters/GRed

Quello che vedete nell’esempio sopra sono anche i valori che ho usato per far sì che la webcam si vedesse “bene” anche dopo 20, 30 secondi che la videochiamata era partita. Non si vede proprio come all’avvio, ma è migliorato di molto il risultato tanto da farmi risparmiare di comprare un’altra webcam… :) per il momento…

I parametri possono essere impostati anche automaticamnente all’avvio, andando a scrivere nel file

redvaio redsend # nano /etc/modprobe.d/options
options gspca gamma=4
options gspca GRed=350
options gspca GGreen=350
options gspca GBlue=350

ricordatevi di dare il comando

redvaio redsend # modules-update

altrimenti le modifiche non vengono scritte nel file /etc/modules.conf che è quello che conta al caricamento del modulo. A questo punto ogni volta che verra caricato il modulo gspca avrete già i parametri impostati sul valore corretto. Corretto per skype, perchè negli altri programmi si vedrà un pò più bianco del solito… ora sta a voi decidere come usarli… l’importante che la soluzione c’è…

Chi utilizza jscalendar, noto script per la generazione di calendari dinamici nella pagine html, si sarà accorto che c’è un malfunzionamento quando si vuole che il calendario generato si porti su una data preselezionata.

Curiosando nel forum ufficiale, ho trovato un suggerimento che potrebbe risolvere il problema.

Individuare il file calendar-setup.js, portarsi alla riga 158 e sostituire al controllo:

if (dateEl)

il controllo:

if (dateEl && dateEl.value)

Questa piccola modifica a me ha funzionato!

Negli ultimi progetti che stavo sviluppando sono passato ad utilizzare Shadowbox, uno dei tanti framework per visualizzare immagini, filmati, pagine html e tanto altro all’interno della pagina stessa con una simpatica animazione. Se non avete capito di cosa sto parlando, forse non vi interesserà neanche quello che dirò dopo… In tutti i casi se volete un esempio di quello che può fare Shadowbox potete vedere i tanti esempi presenti a questo indirizzo: esempi shadowbox.

Ora che avete visto di cosa si tratta sicuramente vi siete accorti di aver già incontrato da qualche parte qualcosa del genere…

Bando alle ciance…

Mi sono trovato ad utilizzare Shadowbox per visualizzare alcuni campi di input in cui doveva venire digitato del testo. Tutto avveniva visualizzato correttamente, solo quando andavo a digitare del testo all’interno non veniva visualizzato niente. Provando a tenere premuti prolungatamente i tasti che volevo digitare mi veniva visualizzato qualcosa, ma ovviamente ripetuto più volte visto che lo avevo tenuto premuto più del dovuto.

Ci ho perso un bel pò di tempo, prima di arrivare a questa soluzione:

enableKeys: false

la riga che vedete sopra và inserita nelle opzioni con cui inizializzate Shadowbox (per info vedi qui).

Cosa succedeva? Perchè non funzionava?

Shadowbox fornisce anche delle scorciatoie da tastiera per poter eseguire delle operazioni, come: cambiare immagine durante la visualizzazione di una galleria, mettere in pausa un filmato, chiudere la finestra, etc…. Per fornire questa funzionalità viene catturato l’evento javascript “keypress” ed elaborato. La cattura di questo evento impedisce che alla prima pressione di un tasto quest’ultimo venga visualizzato nel campo input. La soluzione a questo problema non fà altro che disattivare la funzionalità delle scorciatoie da tastiera per effettuare operzioni e quindi funziona tutto normalmente.

Ho aggiornato il plugin per wordpress che permette un login sicuro su un canale insicuro… scusate il gioco di parole, ma il suo compito è proprio quello. Per approfondire il suo funzionamento potete visitare questa pagina “Chap Secure Login“, oppure la pagina del plugin su wordpress. In questa nuova versione è stato aggiunto il supporto per wordpress 2.5.

Una piccola nota se avete intenzione di installare il plugin. Dopo averlo installato e attivato vi capiterà sicuramente di loggarvi dinuovo nel vostro blog. Al primo tentativo dopo aver attivato il plugin, il login fallirà. Non vi preoccupate è tutto previsto. Al secondo tentativo sarete avvisati che la password viaggerà in chiaro sul canale di comunicazione, quindi se non siete in un lugo sicuro, vi consiglio di rimandare l’operazione. In caso contrario, se i dati che inserite sono corretti, sarete loggati in wordpress e da li in avanti non avrete più problemi del genere. Tutto questo ambaradan serve per bypassare il nuovo sistema di hashing delle password utilizzato dalla versione 2.5 di wordpress.

Nuovi miglioramenti sono stati apportati alla nostra applicazione che permette di condividere la propria connessione internet attraverso una seconda interfaccia di rete, che abbiamo presentato negli articoli “Condividere la connessione ad Internet tramite una connessione wireless Ad-Hoc” e “Condividi Internet! Ora su Gentoo… e non solo“.

Puoi scaricare l’ebuild gentoo qui o se usi un’altra distribuzione puoi usufruire del pacchetto che trovi qui.

Ecco cosa c’è di nuovo in questa versione.

Le modifiche apportate riguardano i seguenti punti:

• modifica delle regole iptables
• gestione dinamica delle applicazioni usate
• supporto all’assegnamento dinamico degli indirizzi tramite DHCP
• riorganizzazione della versione nogentoo con supporto all’installazione e alla disinstallazione
• refactoring e reordering del codice

La prima modifica è stata resa necessaria, perché qualcuno (grazie Dusk!) mi faceva notare che la strategia di resettare il firewall non era necessaria, né tantomeno positiva: potevano esistere nel firewall regole che non erano in conflitto con quelle necessarie per condividere la connessione e che all’utente poteva interessare continuare a mantenere durante l’esecuzione dello script. Con le modifiche apportate è stato così evitato che tale evenienza potesse verificarsi.

Anche nel caso delle applicazioni si erano verificati dei problemi (grazie raphè): con distribuzioni diverse, l’ubicazione degli eseguibili era differente necessitando di editare lo script. Le modifiche apportate permettono all’applicazione di individuare dinamicamente la locazione dell’eseguibile tramite il comando whereis.

È stato inoltre aggiunto il supporto DHCP e DNS tramite l’applicazione dnsmasq: in questo modo si può configurare la propria macchina in modo da assegnare dinamicamente gli indirizzi agli host e fornire inoltre un servizio DNS. Questa caratteristica è stata tuttavia resa opzionale e configurabile tramite l’apposito file di configurazione.

Infine, se nella precedente versione avevo forse un po’ colpevolmente snobbato gli utenti delle altre distribuzioni linux, stavolta mi sono fatto perdonare, fornendo loro un Makefile che li potesse aiutare nell’installazione e disinstallazione dell’applicazione.

Spero quindi che con queste modifiche share-connection diventi ancora più utile a chiunque ne abbia bisogno.

Come molti di voi avranno letto in giro, anche su gentoo è ora disponibile la versione del kernel 2.6.23, sia nella versione originale (vanilla-source), sia nella versione patchata appositamente per gentoo (gentoo-sources). Ma fate molta attenzione a quello che fate…

Infatti questa versione del kernel (gentoo-sources-2.6.23-r3) risulta incompatibile con i driver per schede nvidia obsolete (<=nvidia-drivers-1.0.9639). Nel caso possediate tale configurazione la ricompilazione del driver con il nuovo driver fallirà.

Data la recente uscita di tale nuova versione del kernel non sono disponibili ancora soluzioni per questo problema. Pertanto quello che vi consiglio di fare è di rimandare l’aggiornamento del kernel e consultare di tanto in tanto questo post per sapere se ci sono eventuali cambiamenti (potete eventualmente sottoscrivervi ai commenti grazie alla nuova funzionalità aggiunta dal caro redsend).

Appena so qualcosa di più (per ora solo forum in tedesco che riportano il problema ma non soluzioni) vi farò sapere.

La soluzione è la seguente:

Aggiornare gli nvidia-drivers alla versione 96.43.01. Per farlo bisogna modificare nel file /etc/portage/package.mask la riga relativa agli nvidia-drivers ponendola a:

>=x11-drivers/nvidia-drivers-97

Aggiornando poi i driver con

emerge -uav nvidia-drivers

non dovrebbero più verificarsi problemi di compilazione del modulo con la versione 2.6.23 del kernel.

In questa nuova versione è stato aggiunto il supporto per Internet Explorer che nella precedente versione non permetteva, sotto explorer, di loggarsi. Il problema era nel form per il login. Ora dovrebbe funzionare su tutte le versioni di explorer, sicuramente sulla 6 e la 7.

vi ricordo che potete scaricare il plugin dalla pagina ufficiale su wordpress oppure dalla pagina del plugin.

AGGIORNAMENTO: Come si fà in questi casi? si dovrebbe cancellare quasi tutto il post? Stamattina provo a collegarmi ad una rete wireless ad-hoc con chiave wep e non funziona…NOOOOOO bè non sò cosa sia successo ieri per far funzionare tutto… ma avrò interfogliato qualche operazione che alla fine mi ha fatto funzionare il collegamento, forse l’ho impostata prima a mano e poi ho provato… non sò… comunque chiedo scusa a tutti.

Nel post “Wicd non solo su Ubuntu” raphè segnalava già la presenza di una versione beta di wicd, ovvero la 1.3.4. In questa versione ho potuto notare che sono stati risolti alcuni problemi importanti che aveva la versione precedente, il più importante tra tutti secondo il mio utilizzo è stato quello di gestire in maniera diversa le chiavi wep su una connessione ad-hoc.

Vi spiego…

Il modulo che utilizzava la precedente versione per configurare la scheda wireless era wpa_supplicant, questo gli permetteva di supportare il wpa in tutte le sue varianti e quindi permetteva di configurare qualsiasi connessione wireless ad eccezione di un tipo, si! se si voleva configurare la scheda per connettersi ad una rete ad-hoc con chiave wep con quel modulo non era possibile perchè questo tipo di connessione non è supportato dal modulo (per motivi che ingoro ma che mi sono sempre chiesto…) e in effetti quello che accadeva era semplicemente che la chiave non veniva settata e con il conseguente non funzionamento della connessione. Quello che doveva accadere, e che accade nella nuova versione, è che in presenza di una tale connessione doveva essere utilizzato il modulo iwconfig per conifurare la connessione e impostare la key wep. Ora con la 1.3.4 si và molto meglio a configurare la wireless perchè prima in presenza di un tale connessione (cioè sempre, perchè all’università questo è il modo con cui condividiamo internet…) bisgonava comunque dare il comando a mano per impostare la chiave, e in definitiva si poteva fare tutto direttamente da console come si faceva prima di wicd…

Tra le novità, alcune già mensionate nel post precedente, ritroviamo una gestione dei DNS globale, in modo da non dover mettere ad ogni connessione che configuriamo sempre lo stesso DNS, ma basta impostarli nelle prefrenze globale e spuntare una voce nella connessione. E’ stato aggiunta la possibilità di creare una connessione ad-hoc e di condividerla, permettendo agli altri che si connettono tramite quest’ultima di accedere a internet o in generale ad una qualsiasi rete a cui si è connessi. Sono stati aggiunti altri modi di impostare la chiave per la criptazione della connessione e infine sembra che sia stato risolto il problema delle tray icon che avevano nel momento in cui venivano messe in esecuzione automatica di kde o di gnome, almeno quello che accadeva a me e a raphè era che l’iconcina si avviava, ma non compariva nella traybar ma al suo posto appariva il nulla, spazio bianco… e così rimaneva per un bel pò… poi dopo qualche minuto si riprendeva e cominciava a funzionare… non sò da cosa dipendeva, ma sembra che ora non lo faccia più.

Ho aggiornato il plugin per wordpress, “CHAP Secure Login”, ora è alla versione 1.1.

I cambiamenti effettuati sono minimi, sono stati corretti alcuni piccoli errori e soprattuto è stato risolto un problema che dava nel momento in cui si avevano abilitati i warning in php. Quando si effettuava il primo login, si aveva un problema di apertura della sessione, in quanto veniva chiamata la funzione session_start() dopo che erano stati inviati già dati nell’header… quindi in questi casi php segnalava il warning dove era abilitato, inizialmente non me ne ero accorto perchè sui server di aruba e sul mio portatile sono disattivati, quindi non li avevo mai visti, poi grazie alla segnalazione di Musikele alias Musicoglia :) ho corretto il problema e ora sembra funzionare correttamente.

Quì potete scaricare la nuova versione del plugin… “CHAP Secure Login — wordpress plugin”

Sayfa Sayac (Page & Pages read counter) è un plugin per wordpress che effettua delle statistiche sulle letture delle pagine. Questo plugin con la versione 2.2 (non sò con le precedenti) presenta un problema con i feed rss2 dei commenti. In particolare quando si vanno a recuperare i feed-rss dei commenti una delle query che viene invocata, genera un errore di questo tipo

WordPress database error: [Unknown column 'ss21.sayac_toplam' in 'field list']

SELECT SQL_CALC_FOUND_ROWS wp_posts.*, ss21.sayac_toplam, ss21.sayac_bugun, ss21.anlik_en_fazla_kisi, ss21.son_okuma FROM wp_posts WHERE 1=1 AND wp_posts.ID IN (156,152,149,149,149,144,1,145,144,144) ORDER BY post_date DESC LIMIT 0, 10

che inserito nel file xml contenente i feed-rss2 dei commenti, provoca un errore di parsing del file e quindi di conseguenza rende il file rss non valido.

Non vi sto a dire quello che ho passato per trovare l’errore, ma per risolvere questo problema basta semplicemente commentare la riga 1037 del file wp-includes/query.php, la riga in questione esegue l’istruzione < $join = ”; > perciò state attenti nel caso state usando una versione diversa dalla 2.2, perchè andando a mettere mano nel codice il numero di riga potrebbero cambiare.

Sicuramente questa non è la soluzione migliore per risolvere il problema, sicuramente si dovrebbe agire nel plugin (penso di aver intuito anche dove) e non nel codice di wordpress, ma siccome ora non ho molto tempo da dedicarci, penso che questa soluzione vada benissimo.

Dopo aver apportato la modifica ho provato molte funzionalità di wordpress che pensavo potessero utilizzare il codice modificato, per vedere se questa modifica aggiustava una cosa e ne rovinava un’altra. Sembra che sia tutto apposto. Se scoprite qualcosa che non và segnalatemela pure che vedremo di trovare un’altra soluzione.