Un suggerimento.
SE nel vostro database c'è una tabella originariamente proveniente da
un altro database.
SE avete aggiornato alla versione 8.3.2 o superiore
SE nell'editare una pagina (record) vedete questo messaggio di errore
Database error: Invalid SQL: SELECT COUNT(*) AS numRighe FROM
`nometabella` WHERE sarelAutoOnline<'2999-12-31'
MySQL Error: 1054 (Unknown column 'sarelAutoOnline' in 'where clause')
Invoked from: /usr/local/apache/htdocs/sarat833/editAddPage.php at
line 767
ALLORA vuol dire che la vostra tabella era stata convertita con una
vecchia versione del nostro convertitore, il quale sbagliata e non
inserita un campo Sar-At la cui assenza non dava problemi nelle
versioni sino alla 8.2, ma che è diventato obbligatorio nella 8.3
In questo caso, la soluzione vi costa due clic. Cliccate la linguetta
INFORMAZIONI e nella pagina che appare cliccate il pulsante VERIFICA ORA
Sar-At riconosce il problema e aggiunge il capo mancante.
L.A.
"There's alwaqys one more bug"
MIGLIORAMENTI
* Le schermate conseguenti alla modifica di una pagina (hai cancellato
una pagina con successo, hai aggiunto una pagina con successo, hai
editato una pagina con successo) ora mostrano tutte le linguette per
la sezione corrente (dati, viste... informazioni), velocizzando la
navigazione.
* L'esportazione in formato UTF-16 ora è consistentemente più veloce
* Quando siete collegati come root, il menu Server mostra i numeri di
versione di Sar-At per ogni sito. Nella 8.3.3 vengono mostrati anche
le versioni più vecchie, e questo numero è recuperato dalla copia
installata, non dal database del sito come avveniva sino alla 8.3.2.
Quindi root con un colpo d'occhio vede tute le versioni di tutti i
siti installati.
BUG FIX (showstopper)
* showerr non eseguiva correttamente alcune viste.
* un aggiornamento minore poteva scombiccherare i gruppi dinamici --
in questo caso il tentativo di spedire una newsletter ad essi
produceva un elenco di zero destinatari. La versione 8.3.3 risolve il
problema e ricostruisce il database alla situazione corretta se per
caso il bug aveva fatto danni
* Una Vista avanzata nella 8.3.1 poteva perdere il criterio di
ordinamento e il limite sul numero di record recuperati. Nella 8.3.2,
poteva perdere il criterio di ordinamento. Nella 8.3.3, nessuna delle
due cose
BUG FIX (minori)
* Nell'e-commerce non è più consentito di aggiungere molte volte al
carrello un oggetto in copia unica
* la verifica delle pagine mastro che contengono viste ad hoc e
mailmerge ora funziona anche se la vista ad hoc usa un JOIN
* La cancellazione di una Vista il cui nome contiene lettere accentate
non ha più errori di visualizzazione
* L'apertura di un record correlato in un portale non dà problemi
estetici neppure se il record correlato viene compilato in modo
incompleto più e più volte
C'è una nuova faq sul sito Sar-At. È un sunto di tutto quel che serve
per creare un riquadro di login al sito, passo passo, con tutti i
possibili errori in bella evidenza.
http://www.sar-at.it/showPage.php?template=faq&id=131
Abbiamo preparato un miniaggiornamento per Sar-At 8.3.2 che stiamo
applicando come silent update a tutti i clienti. Ha rilevanza solo per
chi si collega come root. Nel menu Server, Sar-At 8.3 mostra il numero
di versione in uso sui siti, ma il numero non veniva aggiornato dal
momento della prima installazione. Ora viene aggiornato quando si
passa da masterSites.php
L.A.
--
Accomazzi.net di Luca Accomazzi
Via Antonio Gramsci, 40
20017 Rho (Mi)
Tel. 02.00615556
Fax 02.700537345
Cell. 349.7680116
Skype misterakko
http://www.accomazzi.net
P. IVA 04850210966
La perfezione non è di questo mondo. Però lavoriamo in quella
direzione. E pertanto:
NUOVA FUNZIONALITÀ
Ho riscritto interamente checkMasterPage, il componente di Sar-At che
esamina le vostre pagine mastro, le convalida, le "compila" e consente
di usarle nel sistema di gestione contenuti.
Per capire i motivi che mi hanno portato a questo duro lavoro e per
intuire il miglioramento di cui ora godete, immaginate un sito web con
un commercio elettronico che contiene queste due pagine mastro:
1. Pagina prodotto: sulla destra contiene la scheda di un prodotto:
foto, prezzo, pulsante per aggiungerlo nel carrello. A sinistra
contiene una Vista che mostra tutti i prodotti che sono già nel
carrello attraverso la vista ad hoc sarelShowCart, e c'è scritto
quanto costa l'intero carrello -- viene usato il plugin standard
sarelcart_expense.
2. Pagina newsletter. Viene spedita periodicamente ai clienti.
Contiene una vista standard, treProdottiRecenti, che pesca i tre vini
aggiunti in vendita per ultimi. Contiene anche un mailmerge, cioè c'è
scritto Caro {nome} noi della ditta Acme abbiamo tre nuovi vini da
proporti: {BEGIN treProdottiRecenti} {nomeVino} {END
treProdottiRecenti} {testoNewsletter}. Quando genera questa pagina,
Sar-At deve prendere le informazioni sui clienti ({nome}) dalla
tabella con le loro anagrafiche, le informazioni sulla newsletter
({testoNewsletter}) dalla apposita tabella e le info sui prodotti
({nomeVino}) attraverso la Vista treProdottiRecenti
In Sar-At 8.3.1 avreste incontrato alcuni problemi.
Nella pagina 1, la validazione effettuata da checkMasterPage ignorava
la vista ad hoc. Tutto quello che si trova tra {BEGIN
sarelShowCart} ... {END sarelShowCart} veniva lasciato passare sulla
fiducia. Una vista ad hoc può contenere dati tratti da più tabelle del
database (nel nostro caso, il numero di bottiglie di vino arriva dalla
sezione carrello, ma il costo di una singola bottiglia di grignolino
attiva dalla sezione prodotti) e anche campi sintetici ottenuti con
funzioni del linguaggio SQL come IF (vini.stock < 10, 'in
esaurimento', 'ampiamente disponibile') AS quantiPezziRimasti.
Nella pagina 2, la validazione di checkMasterPage non funzionava sotto
8.3.1 e precedenti. checkMasterPage non riusciva a capire che la
pagina mastro faceva affidamento su due differenti tabelle. Nel
validare la vista standard, cjeckMasterPage 8.3.1 controllava quali
campi venivano usati, ma non mostrava questa informazione.
checkMasterPage 8.3.2 risolve tutte queste limitazioni.
C'è una conseguenza di cui dovreste tenere conto. Se avete commesso un
errore in una pagina mastro, dentro una vista ad hoc, può darsi che
non ve ne siate mai resi conto e che il passaggio alla v8.3.2 faccia
emergere il problema. Il sito funzionerà perfettamente, ma se provate
a validare la pagina mastro l'errore verrà segnalato.
Se avete scritto dei plug-in di showPage ad hoc per il vostro sito, e
se essi definiscono più di un tag, dovete aggiornarli perché siano
compatibili con checkMasterPage 8.3.2
Se non li aggiornate allora il vostro sito continua a funzionare
perfettamente anche dopo l'aggiornamento, ma le pagine mastro che
contengono questi plug-in non vengono validate.
L'aggiornamento può venire eseguito in un battito di ciglia attraverso
una espressione regolare. Cercate:
\$segnapostiDefiniti\["(.*)"\](.*)\);
E rimpiazzate con:
$segnapostiDefiniti["..\1"]\2, '\1');
BUG FIX
* Internet Explorer 7 ha un brutto bug per cui la presenza di commenti
nello HTML blocca l'esecuzione degli script e di conseguenza impedisce
la corretta apparizione dei menu a discesa di Sar-At.La versione 8.3.2
aggira il bug.
* La prima pagina di Sar-At (subito dopo il login) tradizionalmente
mostra un elenco delle pagine invisibili. L'idea è di consentire a un
gruppo di redattori di interagire: se un autore scrive un pezzo e lo
carica, il suo caposervizio lo vede non appena si collega e può
controllarne le bozze e approvarne la pubblicazione. Nella v8.3.2 i
sub-amministratori che hanno visibilità solo su alcune sezioni non
trovano più listate nella prima pagina le pagine di sezioni su cui non
hanno autorità (il caposervizio della cronaca nera non vede listate le
pagine invisibili della cornaca rosa).
* Migliorata la sicurezza di loginBuyer. L'aggiornamento 8.3.2 è
fortemente consigliato a chi eroga contenuti riservati ad abbonati,
clienti o dipendenti attraverso il sito web.
* Incollare testi che contengono caratteri malformati era possibile
con alcuni browser e provocava errore se poi quei testi venivano usati
in contesti delicati come il feed RSS. Ora Sar-At pulisce i testi
prima di inserirli nel database.
* Rivista la schermata di inserimento utenti registrati, ora più
leggibile. È possibile usare caratteri di alfabeti non latini per lo
username.
* Nelle Viste in modalità completa, l'opzione "limita a non più di X
record" ora funziona correttamente
* Il pulsante Clona lavora correttamente anche sulle Viste di modalità
Completa
* L'importazione di pagine ora permette anche di importare lo speciale
campo masterId, che indica le traduzioni di una pagina. Attenzione: se
avevate personalizzato l'ordine dei campi che importate da file, la
vostra importazione viene conservata nella v8.3.2, ma se cliccate il
pulsante "ripristina l'ordine di importazione" allora il campo
masterId appare (al primo posto) come importabile.
* L'importazione di pagine ora riconosce correttamente il formato del
file (andate a capo in stile Windows, Unix o Macintosh) anche quando
state importando esattamente due righe
* L'esportazione in formato Unicode UTF-16 ora usa il subformato
"little endian", per maggiore compatibilità con Excel
* Le sezioni in cui il Localization Manager è attivo e che sono state
create sotto 8.3.0 o 8.3.1 non rispettavano il canone di unicità della
traduzione (potevano esistere due traduzioni in georgiano della
medesima pagina). La 8.3.2 corregge il difetto anche retroattivamente.
* Il proprietario del sito che sbagliava la password nella v8.3.1
vedeva un messaggio di errore MySQL. Nella 8.3.2 è ripristinata la
consueta amichevole messaggistica
* Alcuni cambiamenti minori per migliorare la compatibilità con server
basati su sistema operativo Windows
* Il sistema di sincronizzazione (staging) restituisce messaggi di
errore più significativi in caso di problemi
* Un componente mancava e rendeva impossibile l'accodamento degli
invii periodici, funzionalità introdotta con la v8.3.1
